Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Alertmanager, Grafana, Loki, Prometheus, Runbook, SRE, アラート, 監視, 監視設計, 運用設計, 障害対応Runbook は手順書ではなく判断の入口である – アラート、ダッシュボード、ログを対応へつなぐ へのコメントはまだありません Runbook は固定手順を並べるだけの文書ではなく、アラート通知を受けた人が影響範囲、原因候補、確認画面、ログ、エスカレーション条件へ進むための入口です。Prometheus、Alertmanager、Grafana、Loki と Runbook の関係を整理します。
Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Alertmanager, Grafana, Prometheus, SLO, SRE, アラート, 監視, 監視設計, 運用設計Alertmanager の通知設計 – ルーティング、抑制、沈黙、責任分界を分ける へのコメントはまだありません Alertmanager はアラートを発火させる場所ではなく、通知の束ね方、宛先、抑制、沈黙、エスカレーションを設計する場所です。Prometheus の alert rule と Alertmanager の役割を分け、通知疲れを避けるための設計観点を整理します。
Grafana ダッシュボードはグラフを並べる場所ではない – 運用判断の順番を設計する 作者: si62512548投稿日: 2026年7月22日カテゴリー: 監視タグ: Grafana, LogQL, Loki, ModSecurity, Observability, Prometheus, ダッシュボード, ログ設計, 監視, 運用設計Grafana ダッシュボードはグラフを並べる場所ではない – 運用判断の順番を設計する へのコメントはまだありません Grafana ダッシュボードを、グラフの置き場ではなく、異常検知、分類、絞り込み、詳細確認へ進む運用判断の順番として設計する考え方を整理します。
Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する 作者: si62512548投稿日: 2026年7月11日カテゴリー: Ubuntuタグ: Exporter, Prometheus, Ubuntu 26.04, Ubuntu Server, 監視, 監視設計Ubuntu 26.04 smartctl exporter の基本設定 – Prometheus でディスク SMART メトリクスを収集する へのコメントはまだありません Ubuntu 26.04 の物理ホストで smartctl exporter を使い、S.M.A.R.T. 情報を Prometheus メトリクスとして収集します。smartd との役割分担、/metrics 確認、scrape 設計、通知責任を確認します。
Ceph のクラスタログはデフォルトで DEBUG だった – 通常運用で INFO へ変更した理由 作者: si62512548投稿日: 2026年7月11日カテゴリー: Cephタグ: Ceph, Ceph クラスタ, journald, MGR, MON, Prometheus, Ubuntu 26.04, Ubuntu Server, ログ, ログ転送Ceph のクラスタログはデフォルトで DEBUG だった – 通常運用で INFO へ変更した理由 へのコメントはまだありません Ceph 20.2.1 の mon_cluster_log_level が debug のため、正常時の pgmap などのクラスタログが journald、Grafana Alloy、Loki へ大量転送された事例です。HEALTH_OK を確認したうえで info へ変更し、Prometheus メトリクスと INFO 以上のログを残す判断を確認します。
Kubernetes kube-state-metrics の基本 – オブジェクト状態を監視に渡す 作者: si62512548投稿日: 2026年7月8日カテゴリー: Kubernetesタグ: Kubernetes, Prometheus, PVC, メトリクス, 監視, 監視設計Kubernetes kube-state-metrics の基本 – オブジェクト状態を監視に渡す へのコメントはまだありません kube-state-metrics を、CPU やメモリ使用量ではなく Kubernetes API のオブジェクト状態を Prometheus へ渡す部品として扱い、Deployment、Pod、PVC、Node、Job の状態監視とアラート設計を確認します。
リソース予測・トラフィック予測とは何か – キャパシティ管理として設計する 作者: si62512548投稿日: 2026年7月2日カテゴリー: 設計・運用タグ: Grafana, IT インフラ, IT 運用, Prometheus, Zabbix, インフラ設計, キャパシティ管理, トラフィック予測, リソース予測, 監視, 監視設計リソース予測・トラフィック予測とは何か – キャパシティ管理として設計する へのコメントはまだありません リソース予測・トラフィック予測を、未来を当てる作業ではなく、Grafana、Prometheus、Zabbix などの監視データからキャパシティ不足と増強判断につなげる設計として扱います。
監視とは何を見ることなのか – Zabbix、Prometheus、Grafana の責務分界で考える 作者: si62512548投稿日: 2026年6月28日カテゴリー: 設計・運用タグ: Alertmanager, Grafana, Prometheus, SLI, SLO, SNMP, SNMP Trap, Zabbix, 可観測性, 外形監視, 監視, 監視設計, 運用設計, 障害切り分け監視とは何を見ることなのか – Zabbix、Prometheus、Grafana の責務分界で考える へのコメントはまだありません 監視をツール名ではなく、運用判断に接続するための責務分界として整理します。Zabbix、Prometheus、Grafana、Alertmanager、SNMP Trap、外形監視、SLI / SLO の役割を分けて考えます。
Prometheus のメトリクス設計 – ラベル、カーディナリティ、アラート条件を分けて考える 作者: si62512548投稿日: 2026年6月23日カテゴリー: 監視タグ: Prometheus, SLO, アラート, メトリクス, 監視, 監視設計Prometheus のメトリクス設計 – ラベル、カーディナリティ、アラート条件を分けて考える へのコメントはまだありません Prometheus で監視を作るときは、値、ラベル、集計単位、保持期間、アラート条件を分けて設計する必要があります。メトリクス名、ラベル、カーディナリティ、recording rule、alert rule の役割を整理します。
Ubuntu 26.04 node_exporter の基本設定 – Prometheus でホストメトリクスを収集する 作者: si62512548投稿日: 2024年4月25日カテゴリー: Ubuntuタグ: Exporter, Linux, node_exporter, Prometheus, Ubuntu, Ubuntu 26.04, サーバー管理, メトリクス, 監視Ubuntu 26.04 node_exporter の基本設定 – Prometheus でホストメトリクスを収集する へのコメントはまだありません Ubuntu 26.04 で node_exporter を導入し、Prometheus から Linux ホストの CPU、memory、disk、network などのメトリクスを収集するための基本設定を整理します。
