手当たり次第に書くんだ

飽きっぽいのは本能

監視設計

Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ

Runbook は固定手順を並べるだけの文書ではなく、アラート通知を受けた人が影響範囲、原因候補、確認画面、ログ、エスカレーション条件へ進むための入口です。Prometheus、Alertmanager、Grafana、Loki と Runbook の関係を整理します。

Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける

Alertmanager はアラートを発火させる場所ではなく、通知の束ね方、宛先、抑制、沈黙、エスカレーションを設計する場所です。Prometheus の alert rule と Alertmanager の役割を分け、通知疲れを避けるための設計観点を整理します。

ThousandEyes を導入する前に整理しておきたいこと – エージェント、テスト、コスト体系

ThousandEyes を導入する前に、Cloud Agent、Enterprise Agent、Endpoint Agent の観測地点、テスト種別、BGP 監視、ユニットとライセンスの考え方を整理します。

Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する

Ubuntu 26.04 の物理ホストで smartctl exporter を使い、S.M.A.R.T. 情報を Prometheus メトリクスとして収集します。smartd との役割分担、/metrics 確認、scrape 設計、通知責任を確認します。

Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する

Ubuntu 26.04 の物理ホストで smartd と smartmontools を使い、S.M.A.R.T. 状態を継続監視します。ConditionVirtualization、smartd.conf、DEVICESCAN、journald 記録、Ansible 管理の判断点を確認します。

Kubernetes kube-state-metrics の基本 – オブジェクト状態を監視に渡す

kube-state-metrics を、CPU やメモリ使用量ではなく Kubernetes API のオブジェクト状態を Prometheus へ渡す部品として扱い、Deployment、Pod、PVC、Node、Job の状態監視とアラート設計を確認します。

リソース予測・トラフィック予測とは何か – キャパシティ管理として設計する

リソース予測・トラフィック予測を、未来を当てる作業ではなく、Grafana、Prometheus、Zabbix などの監視データからキャパシティ不足と増強判断につなげる設計として扱います。

SRE とは何か – SLI / SLO、エラーバジェット、トイルから理解する

SRE とは、サービスの信頼性をソフトウェアエンジニアリングで扱う考え方です。SLI、SLO、エラーバジェット、トイル、DevOps や Platform Engineering との違いを解説します。

監視とは何を見ることなのか – Zabbix、Prometheus、Grafana の責務分界で考える

監視をツール名ではなく、運用判断に接続するための責務分界として整理します。Zabbix、Prometheus、Grafana、Alertmanager、SNMP Trap、外形監視、SLI / SLO の役割を分けて考えます。

Prometheus のメトリクス設計 – ラベル、カーディナリティ、アラート条件を分けて考える

Prometheus で監視を作るときは、値、ラベル、集計単位、保持期間、アラート条件を分けて設計する必要があります。メトリクス名、ラベル、カーディナリティ、recording rule、alert rule の役割を整理します。

トップへ戻る