📖 はじめに
理解のために Prometheusでの監視業務 を、小咄形式でまとめました。
登場人物
- 太郎（後輩）：入社1年目の若手エンジニア。
- 花子（先輩）：システムエンジニア歴3年の先輩。
もくじ
📖 監視業務
🌟 オフィスのカフェスペース 🌟
太郎：「先輩！来週からいよいよ、監視業務に入ることになりました！」
花子：「監視システムって、運用の安定性を支える重要な仕事だから、しっかり学んでね。」
太郎：「はい！でも正直、監視って言われても 具体的に何をするのか、まだイメージが湧かなくて…」
花子：「最初はそうよね。まず、監視業務で 何が求められるのか から理解しすると捗るわ。」
📌 監視業務の目的
花子：「システムの監視には、大きく分けて 3つの目的 があるのよ。」
✅ 1. システムの健全性を保つ（アプリやサーバーの状態を把握）
- CPUやメモリの使用率、レスポンスタイムなどをモニタリングし、異常があれば即対応
✅ 2. 障害を早期検知し、迅速に対応する
- サーバーが落ちた、APIレスポンスが遅くなったなどの 異常をリアルタイムで検知し、アラートを出す
✅ 3. パフォーマンスの最適化（ボトルネックの分析）
- 負荷が集中する時間帯、クエリの遅延などを分析し、システムの最適化につなげる
太郎：「なるほど、監視って単に異常を見つけるだけじゃなくて、システムをより良くするためのデータ収集 でもあるんですね！」
花子：「その通り。それを実現するために Prometheus という監視ツールを使うのよ。」
📌 Prometheusとは？
太郎：「Prometheusって、どんなツールなんですか？」
花子：「Prometheusは、オープンソースの監視ツール で、システムの状態をメトリクスとして収集・保存し、リアルタイムで分析できる仕組みよ。」
📌 Prometheusの特徴
✅ 1. プル型監視（監視対象からデータを取得する方式）
✅ 2. 時系列データベース（過去のデータを分析可能）
✅ 3. 強力なクエリ言語（PromQL） を使って柔軟に分析
✅ 4. アラート機能 を活用して異常を検知
✅ 5. Grafanaと連携 してダッシュボードを作成できる
太郎：「監視に必要な機能が全部そろってるんですね！」
花子：「そうね。じゃあ、次は 監視の全体像 を見てみましょう。」
📌 監視の全体フロー
花子：「システム監視の全体の流れは、ざっくりこんな感じよ。」
✅ 1. メトリクスを収集する（Application & Infrastructure Monitoring）
- サーバーの状態（CPU・メモリ・ディスク使用率など）
- アプリケーションの動作（リクエスト数・エラーレート・レスポンスタイムなど）
✅ 2. 異常を検知し、アラートを発生させる（Alerting）
- しきい値を設定 し、異常が発生したら通知を送る
- アラートの分類（Critical, Warning, Info）を適切に設定
✅ 3. データを可視化し、分析する（Grafanaによるダッシュボード作成）
- ダッシュボードを活用 してリアルタイムの状態を把握
- 履歴データをもとにパフォーマンスの最適化
✅ 4. 本番環境にデプロイし、スケーラブルな監視を構築（Deployment）
- セキュリティ対策（TLS, Basic認証）
- スケールアウト（シャーディング, フェデレーション）
- 長期データ保存（Thanos, Cortex）
- フェイルオーバー対応（冗長化, Meta-Monitoring）
太郎：「こうして見ると、監視って色々な要素が組み合わさってるんですね！」
花子：「そうね。監視は"作って終わり"ではなく、運用しながら改善していくもの なのよ。」
太郎：「学ぶことがたくさんありますね！」
花子：「実際に試しながら学べばすぐに身につくはずよ。」
📖 インフラの監視
🌟 オフィスの休憩室 🌟
太郎：「先輩！Prometheusを使ってインフラを監視する方法について勉強したいんですが、どんなことができるんですか？」
花子：「いい質問ね。Prometheusのインフラ監視（Infrastructure Monitoring）は、サーバーやネットワーク、コンテナなどのリソースをリアルタイムで監視し、異常を検知する仕組みよ。」
太郎：「リアルタイムで監視できるんですね！それってどうやって実現しているんですか？」
花子：「基本的には 'エクスポーター' と呼ばれるプログラムを使って、各サーバーやコンテナのメトリクスを取得するのよ。Prometheusがそれを定期的に収集（スクレイピング）して、ダッシュボードで可視化したり、アラートを発生させたりする仕組みよ。」
太郎：「なるほど。じゃあ、具体的にどんな監視ができるんですか？」
花子：「具体的には、次のようなインフラの監視ができるわ。」
📌 Prometheusのインフラ監視でできること
✅ 1. サーバーの監視（Node Exporter）
- CPU、メモリ、ディスク使用率、ネットワークトラフィックなどを収集
✅ 2. サービスの自動検出（Service Discovery）
- クラウド環境（AWS, GCP, Kubernetes）などのインフラに動的に対応
✅ 3. コンテナ監視（cAdvisor & kube-state-metrics）
- DockerやKubernetesのリソース消費、コンテナの状態監視
✅ 4. 特定のサービス監視（Common Exporters）
- MySQL、Consul、Nginx、Blackbox Exporterを使った外形監視など
太郎：「サーバーからコンテナまで、いろんなものを監視できるんですね！」
花子：「そうね。今度、基本的な Node Exporter を使ったサーバー監視の仕組みを理解すると捗るわ。」
🌟 オフィスのサーバールーム 🌟
📌 Node Exporterとは？
太郎：「先輩！サーバー監視を始めるには、まず何をすればいいんですか？ Node Exporter からですか？」
花子：「そうね。まずは 'Node Exporter' を使って、サーバーのCPUやメモリ、ディスクのメトリクスを収集するのがいいわ。Node Exporterは、サーバーのシステムメトリクスをPrometheusに渡すためのエージェントよ。Linuxの /proc や /sys を読み取って、CPU、メモリ、ディスク使用率、ロードアベレージ、ネットワークトラフィックなどを取得できるわ。」
太郎：「つまり、Node Exporterをサーバーにインストールすれば、Prometheusがデータを取得できるようになるんですね！」
花子：「その通り。じゃあ、Node Exporterのインストール手順を説明するね。次の記事を見てほしいわ。」
太郎：「Node Exporterをダウンロードして、システムサービスとして動かせばいいんですね！」
花子：「そうね。Node Exporterが動いているか確認するには、ブラウザで次のURLを開いてみましょう。」
http://<サーバーのIP>:9100/metrics
太郎：「めちゃくちゃいろんなメトリクスが並んでいますね。」
花子：「そうね。このメトリクスをPrometheusが取得して、監視できるようになるのよ。」
📌 Prometheusの設定（Node Exporterをスクレイピングする）
花子：「次に、PrometheusがNode Exporterからデータを取得できるように設定しましょう。」
太郎：「どこを設定するんですか？」
花子：「Prometheusの設定ファイル prometheus.yml に、Node Exporterのターゲットを追加するのよ。次の記事を見てほしいわ。」
太郎：「なるほど。これでPrometheusがNode Exporterのデータを取りに行くんですね。」
花子：「そうよ。設定が終わったら、Prometheusを再起動すればOK。」
太郎：「これでサーバー監視の準備が整いましたね！」
📌 Node Exporterで取得できる主なメトリクス
太郎：「具体的にどんなデータが取れるんですか？」
花子：「例えば、こんな感じのメトリクスがあるわ。」
| メトリクス名 | 説明 |
|---|---|
node_cpu_seconds_total |
CPU使用率 |
node_memory_MemAvailable_bytes |
空きメモリ |
node_filesystem_avail_bytes |
空きディスク容量 |
node_load1 |
1分間の平均負荷 |
node_network_receive_bytes_total |
受信ネットワークトラフィック |
node_network_transmit_bytes_total |
送信ネットワークトラフィック |
太郎：「こんなに細かい情報まで取得できるんですね。」
花子：「そうね。これらの細かい取得したデータを Grafanaで可視化 すると捗るわよ。」
🌟 オフィスのミーティングルーム 🌟
太郎：「先輩！Node Exporterでサーバーのメトリクスが取得できるようになったんですが、あの大量のデータをどうやって見やすくするんですか？」
花子：「そこで登場するのが Grafana よ。Grafanaを使えば、Prometheusのデータを ダッシュボード形式で可視化 できるわ。」
太郎：「グラフなどで状況を一目で把握できるようになるんですね。」
📌 Grafanaとは？
花子：「Grafanaは、Prometheusなどの時系列データを元に、直感的なダッシュボードを作れるオープンソースの可視化ツールよ。」
太郎：「Prometheusだけじゃなくて、他のデータソースにも対応してるんですか？」
花子：「そうね。例えば、Elasticsearch、InfluxDB、MySQL、PostgreSQL なんかのデータも可視化できるわ。」
📌 Grafanaのインストール手順
花子：「まず、Grafanaをインストールしてみましょう。次の記事を見てほしいわ。」
太郎：「これでGrafanaが起動するんですね。」
花子：「そうね。ブラウザで http://<サーバーのIP>:3000 にアクセスすると表示されるわ。」
📌 Grafanaの初期設定
-
ログインする
- 初回ログインは ユーザー名：
admin、パスワード：admin - ログイン後、パスワードを変更する
- 初回ログインは ユーザー名：
-
データソース（Prometheus）を追加
- 左側の 設定（⚙️ Settings） → Data Sources を開く
- [Add data source] をクリック
- Prometheus を選択
-
URL に
http://<PrometheusのIP>:9090を入力 - [Save & Test] を押して、接続を確認
太郎：「これでGrafanaがPrometheusのデータを読めるようになるんですね！」
花子：「そうね。サーバーのメトリクスを可視化するダッシュボードを作ると捗るわ。」
📌 Grafanaでダッシュボードを作成
- 左側メニューの
＋ Create→Dashboardをクリック - "Add a new panel" を選択
-
Prometheusのクエリを設定
- 例：CPU使用率
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) - 例：メモリ使用率
1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) - 例：ディスク使用率
1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})
- 例：CPU使用率
- [Save] をクリックして保存
太郎：「リアルタイムでCPUやメモリのグラフが表示されました！」
花子：「そうね。このダッシュボードを使えば、サーバーの状態が一目で分かるようになるわよ。」
📌 Grafanaの便利な機能
花子：「Grafanaには他にも便利な機能があるのよ。」
✅ アラート設定
- 一定の閾値を超えたら通知を送る（例：CPU使用率90%以上でアラート）
-
Alertingタブでしきい値を設定し、SlackやEmailに通知可能
✅ ダッシュボードのテンプレート
- 公式のダッシュボードテンプレート を使えば、すぐに用意されたグラフが作れる
- Grafana Dashboards で検索可能
✅ 複数のデータソースを統合
- PrometheusのデータとMySQLのデータを組み合わせる などの連携が可能
太郎：「アラートまで設定できるんですね！もうNagiosとかZabbixの代わりになりそう！」
花子：「そうね。でも、Prometheusは 'プル型' の監視だから、SNMP監視みたいな用途には向かないこともあるわ。」
太郎：「長所と短所を理解して使い分けるのが大事なんですね。これなら運用がグッと楽になりそうですね！」
🌟 オフィスのカフェスペース 🌟
太郎：「先輩！サーバーの監視はNode Exporterでできましたし、Grafanaで可視化もできました。でも、最近はDockerやKubernetesが増えてるので、コンテナの監視もしたいです！」
花子：「そうねね。コンテナ環境の監視には cAdvisor や kube-state-metrics を使うのが一般的よ。特にKubernetesでは、Prometheus Operatorを使うと捗るわ。」
📌 コンテナ監視の基本
花子：「コンテナの監視には、次の3つの方法があるわ。」
✅ 1. cAdvisor（Container Advisor）
- DockerコンテナのCPU、メモリ、ディスク使用率、ネットワークトラフィックを監視
- Prometheusと連携し、コンテナ単位のリソース使用状況を取得
✅ 2. kube-state-metrics
- Kubernetesのリソース（Pod、Node、Deploymentなど）の状態を監視
- 例：「このPodは正常に動いているか？」「Nodeのリソースは不足していないか？」
✅ 3. Prometheus Operator（Kubernetes環境向け）
- Kubernetesクラスタ全体の監視を効率化
- Service Discoveryを活用し、動的に監視対象を検出
太郎：「cAdvisorはDockerコンテナ単体、kube-state-metricsはKubernetesの状態、Prometheus Operatorは全体管理って感じですね！」
花子：「そうね。そこまで理解できていれば、コンテナ監視の基本は理解できているわ。」
🌟 オフィスの会議室 🌟
太郎：「先輩！Node ExporterやcAdvisor、kube-state-metricsを使ってインフラを監視できるようになりました。でも、これを実際の運用で使うには、どんな点に気をつければいいんですか？」
花子：「いい質問ね。インフラ監視のベストプラクティス について理解すると捗るわ。」
📌 インフラ監視のベストプラクティス
花子：「監視をうまく運用するには、次の 5つのポイント が大切になるわ。」
✅ 1. 監視対象を明確にする
- 監視対象の範囲を 明確に定義 する（サーバー、コンテナ、ネットワーク、アプリケーションなど）。
- 「何を監視するのか？」「どこまで詳細に監視するのか？」を事前に決める。
- 例：
- インフラ（CPU、メモリ、ディスク、ネットワーク）
- コンテナ（Podの状態、リソース使用率）
- アプリケーション（レスポンスタイム、エラーレート）
太郎：「確かに、全部を監視しようとすると、どれが本当に重要か分からなくなりそうですね…」
花子：「そうね、本当に必要なメトリクスだけを監視することが大切 なのよ。」
✅ 2. しきい値（Thresholds）を適切に設定する
- 「しきい値（アラートを発生させる基準）」を適切に決める。
- 例：
- CPU使用率が 80%超えたら警告、90%超えたらクリティカル
- ディスク使用率が 90%超えたらアラート
- KubernetesのPodが 10分間CrashLoopBackOffしたら通知
- alert: HighCPULoad
expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU Load"
description: "CPU usage has exceeded 80% for more than 5 minutes."
太郎：「このしきい値の設定が適当だと、不要なアラートが増えそうですね…」
花子：「そうね。本当に対応が必要な状態だけをアラートにすることが重要なのよ。」
✅ 3. アラートの重要度を分類する
- アラートの 優先度（Severity） を明確に分類する。
- "全部Critical" だと、重要なものが埋もれる…
-
例：
- 🔴 Critical（緊急） → サーバーがダウン、Kubernetesノードが停止
- 🟠 Warning（警告） → CPU使用率が高い、レスポンスタイム遅延
- 🔵 Info（情報） → 新しいPodが作成された、サービスのスケールアップ
太郎：「ちゃんと分類しないと、運用が回らなくなる気が…」
花子：「そうね。"このアラートが来たら、誰が、どう対応するのか？" を決めておくことが大切だわ。」
✅ 4. ダッシュボードを活用して視覚的に監視
- アラートだけでなく、リアルタイムの可視化も重要
- Grafanaを活用して、異常をすぐに把握できるようにする。
-
よく使われるダッシュボード：
- サーバーリソースダッシュボード（CPU、メモリ、ディスク、ネットワーク）
- Kubernetesダッシュボード（Podの状態、Nodeリソース、エラーレート）
- アプリケーションパフォーマンス（レスポンスタイム、エラーレート、スループット）
太郎：「アラートだけに頼らず、ダッシュボードで '何が起きているのか' を確認するのも大事ですね。」
花子：「そうね。アラートだけだと 'なぜそうなったのか？' が、分からないことが多いわ。」
✅ 5. 定期的に監視ルールを見直す
- 運用していくうちに、「不要なアラート」「設定ミス」が増えてくる。
- "このアラート、本当に必要？" を定期的に見直す
- 月に1回、監視ルールレビューを実施するのがオススメ
- 例：
- 不要なアラートを削除
- しきい値の調整
- 対応フローの確認（アラート対応の手順を見直す）
太郎：「確かに、ずっと昔に設定したアラートが、いまだに飛び続ける…みたいなこと、よくありますね。」
花子：「そうね。定期的にメンテナンスしないと、監視システム自体が機能しなくなるわ。」
💡 まとめ
✅ 監視対象を明確にする（何を監視するのか？）
✅ 適切なしきい値を設定する（無駄なアラートを減らす）
✅ アラートの重要度を分類する（Critical, Warning, Info）
✅ ダッシュボードで視覚的に監視する（アラートだけに頼らない）
✅ 定期的に監視ルールを見直し、不要なアラートを削除する
太郎：「監視は '作ったら終わり' じゃなくて、ちゃんと運用し続けることが大事なんですね！」
花子：「そうね。監視システムは、実際に運用しながら最適化していくもの よ。インフラの次は、アプリケーションの監視について理解すると捗るわ。」
📖 アプリケーションの監視
🌟 オフィスのカフェスペース 🌟
太郎：「先輩！Prometheusを使ってアプリケーションの監視をしたいんですが、どんなことができるんですか？」
花子：「そうね。Prometheusのアプリケーション監視は、アプリケーション内部の動作を可視化し、パフォーマンスや異常をリアルタイムで検知できる 仕組みがあるわ。」
太郎：「インフラ監視とは何が違うんですか？」
花子：「インフラ監視は サーバーやコンテナ の状態を監視するのに対し、アプリケーション監視は アプリの内部動作（リクエスト数、エラーレート、レスポンスタイムなど） を監視するのよ。」
📌 Prometheusのアプリケーション監視でできること
-
リクエスト数・レスポンスタイムの監視
- 各APIエンドポイントのリクエスト数を計測
- レスポンスタイムの分布を可視化
-
エラーレートの監視
- HTTPステータスコード（200, 400, 500）の割合を監視
- 異常なエラーレート増加時にアラートを発生
-
バックエンド処理のパフォーマンス測定
- データベースのクエリ時間、キャッシュのヒット率を記録
- メモリ使用量やスレッド数を監視
-
ビジネスKPIのモニタリング
- ユーザーのアクティビティ（ログイン数、購入数）を可視化
太郎：「アプリの動作を詳細に監視できるんですね！アプリケーションの動作を監視するには、どうやってデータを取得するんですか？」
花子：「いい質問ね。アプリケーションの監視には、Instrumentation（計測の埋め込み） を行う必要があるよ。」
太郎：「Instrumentationって何ですか？」
花子：「簡単に言うと、アプリのコードに メトリクスを収集するための処理 を追加することよ。Prometheusのクライアントライブラリを使って、アプリケーション内部の動作を記録できるわ。」
📌 PrometheusのInstrumentationの流れ
花子：「Instrumentationの基本的な流れは次の4ステップよ。」
✅ 1. Prometheusクライアントライブラリを導入（Go, Java, Python, Node.js など）
✅ 2. メトリクスを定義（リクエスト数、レスポンスタイム、エラーレートなど）
✅ 3. エンドポイントを作成（/metrics でメトリクスを公開）
✅ 4. Prometheusの設定を追加（アプリをスクレイピング対象にする）
📌 GoアプリにPrometheusメトリクスを埋め込む
花子：「例えば、GoでAPIサーバーを作ってるとするわ。そこにPrometheusのメトリクスを追加すると、こんな感じになるのよ。」
1. PrometheusのGoクライアントをインストール
go get github.com/prometheus/client_golang/prometheus
go get github.com/prometheus/client_golang/prometheus/promhttp
2. メトリクスを定義
package main
import (
"net/http"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)
// HTTPリクエストのカウンター
var requestCount = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests",
},
[]string{"method", "endpoint"},
)
func main() {
// メトリクスをPrometheusに登録
prometheus.MustRegister(requestCount)
// ハンドラ関数
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
requestCount.WithLabelValues(r.Method, "/").Inc()
w.Write([]byte("Hello, Prometheus."))
})
// メトリクスエンドポイント
http.Handle("/metrics", promhttp.Handler())
// サーバー起動
http.ListenAndServe(":8080", nil)
}
3. /metrics でデータを取得
curl http://localhost:8080/metrics
太郎：「http_requests_total っていうカウンターが増えていくんですね！」
花子：「そうね。アプリケーションが受けたリクエストの数をリアルタイムで記録できるわ。」
📌 他のプログラミング言語でのInstrumentation
太郎：「Go以外の言語でも同じことはできるんですか？」
花子：「もちろん。Prometheusは 主要な言語ごとにクライアントライブラリ を提供してるわ。」
| 言語 | クライアントライブラリ |
|---|---|
| Go | github.com/prometheus/client_golang |
| Java | io.prometheus:simpleclient |
| Python | prometheus_client |
| Node.js | prom-client |
📌 Prometheusのスクレイピング設定
花子：「アプリにメトリクスを埋め込んだら、Prometheusがデータを取得できるようにする必要があるわ。」
太郎：「どうやって設定するんですか？」
花子：「prometheus.yml に、アプリの/metrics エンドポイントを追加するのよ。」
scrape_configs:
- job_name: 'my_app'
static_configs:
- targets: ['localhost:8080']
太郎：「これでPrometheusがアプリのメトリクスを取得できるようになるんですね！」
💡 まとめ
✅ Instrumentationは、アプリケーション内部の動作を監視するために必要
✅ 各プログラミング言語のPrometheusクライアントライブラリを使ってメトリクスを定義
✅ /metrics エンドポイントを作成し、Prometheusのスクレイピング設定を追加
🌟 オフィスのホワイトボード前 🌟
太郎：「先輩！アプリにInstrumentationを埋め込む方法は分かりました。でも、どんなメトリクスを記録すればいいのか迷います…」
花子：「いい質問ね。アプリケーション監視では、"何を計測すべきか？" をしっかり決めることが大事よ。」
📌 監視すべき主要なメトリクス
花子：「監視すべきメトリクスは、"4つのゴールデンシグナル（Four Golden Signals）" を基準に考えるといいわ。」
✅ 1. レイテンシ（Latency）
- リクエストの処理時間（レスポンスタイム）を計測
- ユーザー体験に直結する重要指標
- 例：
- HTTPリクエストの平均応答時間 (
http_request_duration_seconds) - 95パーセンタイル（P95）レイテンシ (
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])))
- HTTPリクエストの平均応答時間 (
✅ 2. トラフィック（Traffic）
- アプリが処理するリクエスト数やユーザーアクティビティ
- 負荷の把握に重要
- 例：
- 総リクエスト数 (
http_requests_total) - APIごとのリクエスト数 (
http_requests_total{method="GET", endpoint="/api"})
- 総リクエスト数 (
✅ 3. エラーレート（Errors）
- 失敗したリクエストやエラー率を監視
- サービスの安定性を評価
- 例：
- HTTP 5xx エラーレート (
rate(http_requests_total{status=~"5.."}[5m])) - アプリの例外発生数 (
application_errors_total)
- HTTP 5xx エラーレート (
✅ 4. サチュレーション（Saturation）
- リソースの使用率（CPU、メモリ、ディスク）
- どれだけ余裕があるか？ を示す
- 例：
- CPU使用率 (
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) - メモリ使用率 (
1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))
- CPU使用率 (
📌 Goアプリで主要メトリクスを計測する
花子：「Goアプリで主要なメトリクスを記録する例を見てみましょう。」
1. HTTPリクエストのレスポンスタイムを計測
var requestDuration = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "Histogram of response time for handler.",
Buckets: prometheus.DefBuckets,
},
[]string{"method", "endpoint"},
)
func handler(w http.ResponseWriter, r *http.Request) {
timer := prometheus.NewTimer(requestDuration.WithLabelValues(r.Method, r.URL.Path))
defer timer.ObserveDuration()
w.Write([]byte("Hello, Prometheus."))
}
2. エラーレートを記録
var errorCount = prometheus.NewCounterVec(
prometheus.CounterOpts{
Name: "http_errors_total",
Help: "Total number of HTTP errors",
},
[]string{"method", "endpoint", "status"},
)
func errorHandler(w http.ResponseWriter, r *http.Request) {
errorCount.WithLabelValues(r.Method, r.URL.Path, "500").Inc()
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
📌 PromQLを使ったメトリクス分析
太郎：「メトリクスを記録できたら、それを分析するにはどうすればいいですか？」
花子：「いい質問ね。PromQLを使えば、メトリクスを簡単に分析できわよ。」
| 目的 | PromQLクエリ |
|---|---|
| APIのリクエスト数 | rate(http_requests_total[5m]) |
| エラーレートの割合 | rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) |
| P95のレイテンシ | histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) |
| メモリ使用率 | 1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) |
太郎：「PromQLを使えば、どのAPIが遅いのか、どのぐらいの頻度でエラーが起きているのかが分かるんですね！どんなメトリクスを記録すべきかイメージが湧いてきました！」
💡 まとめ
✅ アプリ監視では "4つのゴールデンシグナル" を記録する（Latency, Traffic, Errors, Saturation）
✅ GoやPythonなどのクライアントライブラリを使ってメトリクスを定義する
✅ PromQLを使えば、メトリクスを柔軟に分析できる
🌟 オフィスのミーティングルーム 🌟
太郎：「先輩！PromQLでメトリクスを分析できるようになりました。でも、毎回クエリを書くのは大変じゃないですか？」
花子：「そうね。Grafanaのダッシュボード を使うのが捗るわ。視覚的にメトリクスを表示できて、一目でアプリの状態が分かるわよ。」
太郎：「それは便利ですね！どうやって作るんですか？」
花子：「まずは、PrometheusとGrafanaを連携させましょう。次の記事を参考にして構築してほしいわ。」
花子：「次にダッシュボードを作成するわ。」
📌 ダッシュボードの作成
1. ダッシュボードを追加
- 左メニューの 「＋ Create」 → 「Dashboard」
- 「Add a new panel」 を選択
2. PromQLを設定
-
リクエスト数
rate(http_requests_total[5m]) -
エラーレート
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) -
P95 レイテンシ
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
太郎：「グラフが表示されました！」
📌 ダッシュボードテンプレート
花子：「Grafanaには 公式のダッシュボードテンプレート もあるわ。」
- Grafana Dashboards で検索
- 「Import Dashboard」から IDを入力 すると、すぐに使える
太郎：「便利ですね！ゼロから作らなくてもいいのは助かります！」
📌 Grafanaのアラート機能
花子：「Grafanaは アラート通知 もできるわ。」
1. アラートを設定
- 「Alert」タブを開く
- 「Create Alert Rule」をクリック
- 条件を設定（例：レスポンスタイムが1秒を超えたら通知）
- Slackやメールに通知を送る設定を追加
太郎：「これなら、異常が発生したときにすぐ気づけますね！Grafanaがあると、監視がグッと楽になりますね！」
💡 まとめ
✅ Grafanaを使えば、メトリクスを直感的に可視化できる
✅ Prometheusをデータソースに追加し、リクエスト数・エラーレート・レスポンスタイムを表示
✅ 公式ダッシュボードを活用すれば、すぐに監視環境を構築できる
✅ アラート機能を活用して、異常発生時に通知
🌟 オフィスの会議室 🌟
太郎：「先輩！PrometheusとGrafanaを使って、アプリの動作を可視化できるようになりました。でも、運用していく中で、どうやってうまく監視を回せばいいのか、まだよく分かりません…」
花子：「そうね。アプリケーション監視のベストプラクティス を理解すれば捗るわ。」
📌 アプリケーション監視のベストプラクティス
花子：「運用をうまく回すには、次の 5つのポイント を押さえることが大切よ。」
✅ 1. "4つのゴールデンシグナル" を基準に監視する
- 監視対象を無闇に増やすのはNG。
- "Four Golden Signals"（Google SREの概念）を基準に必要なメトリクスを決める。
- 最小限の監視で最大のインサイトを得る。
| シグナル | 監視対象 |
|---|---|
| Latency（遅延） | APIレスポンスタイム (http_request_duration_seconds) |
| Traffic（負荷） | リクエスト数 (http_requests_total) |
| Errors（エラー率） | HTTP 5xxエラーレート (rate(http_requests_total{status=~"5.."}[5m])) |
| Saturation（リソース逼迫） | CPU/メモリ使用率 (node_memory_MemAvailable_bytes) |
太郎：「何でもかんでも監視するんじゃなくて、本当に重要なデータに絞ることが大事なんですね！」
花子：「そうね。最適なメトリクス選びが、運用の成否を分けるのよ。」
✅ 2. 適切なしきい値を設定する
- アラートのしきい値を適切に設定することが重要。
- しきい値が低すぎると 不要なアラートが増えてノイズになる。
- 逆に、高すぎると 本当に危険な状態に気づけない。
| メトリクス | しきい値の例 |
|---|---|
| CPU使用率 | 80%でWarning, 90%でCritical |
| メモリ使用率 | 85%でWarning, 95%でCritical |
| HTTPエラーレート | 5%超過でWarning, 10%超過でCritical |
太郎：「しきい値の設定が適当だと、運用がカオスになりますね…」
花子：「そうね。アラートの閾値は運用しながら最適化していくのが大切なのよ。」
✅ 3. アラートの優先度を明確にする
- すべてのアラートを "Critical" にすると、対応がパンクする。
- "対応すべきアラート" と "様子を見るアラート" を区別することが重要。
アラートの分類例
| 優先度 | 例 | 対応 |
|---|---|---|
| 🔴 Critical（緊急） | APIのダウン、データベース接続エラー | 直ちに対応 |
| 🟠 Warning（警告） | CPU使用率80%、エラーレート5%超 | 状況を監視しつつ対応 |
| 🔵 Info（情報） | 新しいPodの作成、正常なスケールアップ | ログとして記録 |
太郎：「アラートの優先度が明確じゃないと、運用チームが混乱しますね！」
花子：「そうね。"どのアラートにどう対応すべきか" をあらかじめ決めておくのが重要よ。」
✅ 4. ダッシュボードを定期的に見直す
- 監視ダッシュボードは「作ったら終わり」ではない。
- 運用しながら、より見やすく、より実用的に改善する。
- よくある失敗例：グラフが増えすぎて「どこを見ればいいか分からない…」
改善のポイント
- 不要なグラフを削除し、本当に必要な指標だけ残す
- 一目で異常を検知できる カラースキーム（赤/黄/緑）を活用
- 重要なアラートを Grafanaのトップページに表示
太郎：「たしかに、ダッシュボードが複雑すぎると、逆に運用しづらいですね…」
花子：「そうね。シンプルで直感的なダッシュボードが理想よ。」
✅ 5. 定期的にアラートの運用を見直す
- "このアラート、本当に必要？" を定期的にチェック
- 月に1回、アラートレビューを実施
- 例：
- 対応されていないアラートは削除
- しきい値を調整し、ノイズを減らす
- 発生頻度が高すぎるアラートを改善する
太郎：「昔作ったアラートが、いまだに飛び続けてる…みたいなことありますよね。」
花子：「そうね。アラートの "棚卸し" を定期的にやるのが大事なのよ。」
💡 まとめ
✅ "4つのゴールデンシグナル" を基準に監視する
✅ 適切なしきい値を設定し、ノイズを減らす
✅ アラートの優先度を明確にし、対応方針を決める
✅ ダッシュボードはシンプルで実用的に
✅ 定期的にアラート運用を見直し、不要なものを削除する
太郎：「監視の運用って、技術だけじゃなくて、ちゃんと設計することが大事なんですね！」
花子：「そうね。監視システムは、実際に運用しながら最適化していくもの なのよ。」
📖 アラート
🌟 オフィスの休憩室 🌟
太郎：「先輩！Prometheusのアラートについて勉強しようと思ってるんですけど、ざっくりどんなものなのか教えてもらえますか？」
花子：「いい質問ね。アラートは、システム監視の重要な要素の一つよ。簡単に言うと、『システムに異常があったら、それを検知して通知する仕組み』のこと。」
太郎：「監視するだけじゃなくて、異常を見つけたら教えてくれるんですね！Zabbixのアラートとにた感じですね。」
花子：「そうね。Prometheusでは、アラートの設定を『アラートルール』として定義するのよ。そのアラートを実際に通知するのが『Alertmanager』という仕組みよ。」
太郎：「アラートルールって、具体的には何をするものなんですか？」
花子：「PromQLを使って、『どんな状態になったらアラートを発生させるか』を定義するのよ。例えば、『CPU使用率が80%以上が5分続いたらアラートを発生させる』みたいに。」
太郎：「そのアラートが発生したら、Alertmanagerが通知するんですね！」
花子：「その通りよ。Alertmanagerは、発生したアラートをグルーピングしたり、通知頻度を調整したりして、適切な方法で管理する役割を持っているわ。例えば、Slackやメール、PagerDutyに通知を送ることができるのよ。」
太郎：「なるほど、アラートが発生したら即座に何百件も通知が飛ぶと大変だから、適切にまとめたり、優先度をつけたりするんですね。」
花子：「その通り。ただし、適切なアラートを作らないと、不要な通知が増えて逆に運用の負担になるから、『良いアラート』を設計するのが大事なのよ。」
🌟 オフィスの会議室 🌟
太郎：「先輩！アラートの概要はなんとなくわかったんですけど、アラートルールって具体的にどうやって書くんですか？」
花子：「いい質問ね。アラートルールは、PromQLを使って、アラートを発生させる条件を定義すのよ。基本的な構成はこんな感じよ。」
groups:
- name: example-alerts
rules:
- alert: HighCPUUsage
expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage detected"
description: "CPU usage is above 80% for more than 5 minutes."
太郎：「YAMLで書くんですね。これは何をしているんですか？」
花子：「このルールでは、『CPU使用率が80%を超えた状態が5分続いたら、"HighCPUUsage" というアラートを発生させる』っていう条件を定義しているわ。」
太郎：「なるほど、expr っていうのがアラートの条件を決めるんですね。」
花子：「そうね。expr にはPromQLを使って、アラートの閾値を決める式を書くのよ。for: 5m っていうのは、『この状態が5分続いたらアラートを出す』って意味よ。」
太郎：「一時的にCPUが跳ね上がるだけでアラートが飛んじゃうと、誤検知が増えちゃうから、時間の条件をつけるんですね！」
花子：「その通り。それに、labels ではアラートのラベルを定義できるから、たとえば severity: warning ってつけると、優先度を管理しやすくなるわ。」
太郎：「じゃあ、annotations っていうのは…？」
花子：「annotations は、通知するときに表示するメッセージよ。summary はアラートの簡単な説明で、description は詳細な内容を記述できるわ。」
太郎：「このルールをPrometheusに適用すると、実際に監視が始まるんですね！」
花子：「そうね。ただし、Prometheus単体ではアラートの評価はできても、通知まではできないわ。通知には、Alertmanagerを使うわ。Prometheusのアラートを受け取って、適切な方法で通知するためのコンポーネントよ。」
太郎：「じゃあ、Alertmanagerがないと通知できないってことですか？」
花子：「そうね。Prometheusはアラートを評価するだけで、それを実際にメールやSlackに送るのはAlertmanagerの役割なのよ。」
📌 Alertmanagerの主な機能
花子：「Alertmanagerには、いくつか重要な機能があるわ。」
✅ 1. アラートのグルーピング
- 似たようなアラートをまとめて通知できる。
- 例えば、複数のサーバーでCPU使用率が高い場合、1つの通知にまとめられる。
✅ 2. サイレンシング（Silencing）
- 一定期間アラートを抑制できる。
- 例えば、メンテナンス中に不要なアラートが飛ばないようにする。
✅ 3. 通知のルーティング（Routing）
- 重要度に応じて通知先を振り分ける。
- 例：「重大な障害はPagerDutyに送る」「警告レベルならSlackに送る」
✅ 4. 再通知（Inhibition）
- あるアラートが発生している間、関連するアラートを抑制できる。
- 例えば、「全サーバーがダウンしている時、個別のサーバーダウン通知は不要」
太郎：「ただ通知するだけじゃなくて、賢く管理できるんですね！」
📌 Alertmanagerの基本設定
花子：「実際にAlertmanagerを設定するYAMLファイルはこうなるわ。」
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5m
repeat_interval: 3h
receiver: 'slack-notifications'
receivers:
- name: 'slack-notifications'
slack_configs:
- channel: '#alerts'
send_resolved: true
text: "{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}"
花子：「簡単に説明すると…」
✅ route : どういうルールで通知を送るかを定義。
✅ group_by : 似たアラートをまとめるキー（この場合はalertname）
✅ group_wait : 最初のアラートが発生してから、どれくらい待つか（30秒）
✅ group_interval : 同じグループの次の通知までの間隔（5分）
✅ repeat_interval : 同じアラートを再通知する間隔（3時間）
✅ receivers : どこに通知を送るか（この場合はSlack）
太郎：「これでアラートをSlackに送れるんですね！」
花子：「そうね。でも、Slack以外にも メール、PagerDuty、Webhook なんかにも対応してるから、用途に応じて使い分けられるのよ。」
太郎：「Alertmanagerがあれば、運用がめちゃくちゃ楽になりそうですね！」
花子：「そうね。適切に設定しないと『通知が多すぎて誰も見なくなる』とか、『肝心な時にアラートが届かない』みたいなことが起こるので注意が必要よ。」
太郎：「うわ、それは怖い… じゃあ、どうやって適切なアラートを設計するんですか？」
花子：「いい質問ね。アラートは適当に作ると、むしろ運用の負担になることが多いわ。だから、『良いアラートの設計』が大事になるわ。」
📌 良いアラート設計の3つの原則
花子：「まず、良いアラートを設計する上で大切な 3つの原則 を押さえると捗るわ。」
✅ 1. 重要な問題だけを通知する
- 「本当に対処が必要な問題」だけをアラートにする。
- 一時的なリソース使用率の変動など、放置しても問題ないものはアラートにしない。
- 例：「CPU使用率80%以上が5分続いたらアラート」 → 短時間なら無視されるので適切
✅ 2. ノイズを減らす（不要なアラートを減らす）
- 「アラートの数が多すぎると、誰も見なくなる」
- 一度の障害で大量のアラートが発生すると、運用者が何が本当に重要なのか分からなくなる。
- Alertmanagerのグルーピング や Inhibition（抑制） を活用する。
- 例：「サービス全体がダウンしたときは、個々のサーバー障害の通知を抑制する」
✅ 3. 具体的で分かりやすい内容にする
- アラートの通知メッセージは、受け取った人が すぐに行動できるように 書く。
- 「サーバーのCPUが高い」ではなく、「
web-server-01のCPUが90%を超え、負荷が高い状態が10分続いている」と具体的に。 - 次にやるべきアクションも書く（例：「再起動推奨」など）
太郎：「適当にアラートを設定すると、運用チームが混乱するんですね。」
花子：「そうね。だから、通知の設計を工夫することが重要になるわ。」
📌 アラートの優先度を決める
花子：「アラートの優先度（Severity） をちゃんと設計することも大事よ。」
🔴 Critical（緊急）
- すぐに対応しないと、ビジネスに影響が出るもの
- 例：「サービス全体がダウン」「データベース接続エラー」
🟠 Warning（警告）
- 今すぐではないが、近い将来問題になりそうなもの
- 例：「CPU使用率が80%以上」「ディスク使用率が90%に達した」
🔵 Info（情報）
- 監視対象だが、今すぐ対応しなくても良いもの
- 例：「サービスのレスポンス時間が遅くなっている」
太郎：「なるほど… これがちゃんと整理されてないと、全部Criticalみたいになって運用がパンクしそうですね。」
花子：「その通り。優先度を決めて、適切な対応ができるようにするのが大事よ。」
💡 まとめ
✅ 重要な問題だけをアラートにする（ノイズを減らす）
✅ 具体的で分かりやすいメッセージを書く
✅ 優先度を決めて、対応の順番を明確にする
太郎：「これでアラートの設計がかなりイメージできました！」
🌟 オフィスのホワイトボード前 🌟
太郎：「先輩！アラートのルールや設計は分かりました。でも、実際に運用するとなると、どんな点に気をつければいいんですか？」
花子：「そうね。アラートの運用ベストプラクティス について理解すると捗るわ。ちゃんとやらないと、アラート疲れになって、肝心な通知を見落とすことになるのよ。」
📌 アラートの運用を成功させるための5つのベストプラクティス
✅ 1. まずダッシュボードを整備する
- アラートを設計する前に、まず可視化することが重要。
- Grafanaなどでダッシュボードを作り、「どんな値が異常なのか？」を確認する。
- 例：「CPU使用率が80%を超えたら問題なのか？それとも100%に張り付いたらなのか？」
太郎：「確かに、しっかり可視化しないと、何を基準にアラートを作ればいいのか分からないですね。」
花子：「そうね。アラートはダッシュボードで '異常' だと確認できたものだけ作るといいわ。」
✅ 2. アラートの重要度を明確にする
- Critical, Warning, Info の分類をちゃんと決める。
- Criticalが増えすぎると、緊急度の判断ができなくなる。
- 例：「サーバーダウンはCritical、CPU 80%超えはWarning」
太郎：「これ、適当に設定してると、全部Criticalになっちゃいそう…」
花子：「そうね。それを防ぐために、ちゃんと整理するのが大事なのよ。」
✅ 3. すぐに対応できるアラートにする
- アラートを受け取った 担当者がすぐに対処できる内容 にする。
- 「○○がダウン」だけではなく、「再起動が必要」など 具体的なアクション を含める。
- 例：
annotations: summary: "DB connection failure" description: "Database {{ $labels.instance }} is unreachable. Check network and restart if necessary."
太郎：「たしかに、"CPU使用率が高い" って言われても、何をすればいいのか分からないと困りますね。」
花子：「そうね。'で、どうすればいいの？' ってならないようにしないと困るわね。」
✅ 4. ノイズを減らし、アラート疲れを防ぐ
- 本当に重要なアラートだけを通知する（不要なアラートは消す）。
- AlertmanagerのグルーピングやInhibition（抑制）を活用する。
- 例えば「サービス全体が落ちたら、個別のサーバーダウンアラートは抑制」する。
太郎：「これ、やらないと通知が多すぎて誰も見なくなりそうですね…」
花子：「まさに 'アラート疲れ' の原因になるわね。適切にフィルタリングしないと、運用が回らなくなるのよ。」
✅ 5. 定期的にアラートを見直す
- アラートを 定期的に見直して、不要なものを削除 する。
- 1ヶ月以上誰も対応していないアラートは、本当に必要か検討する。
- 運用チームで定期的に「アラートレビュー」を実施するのがオススメ。
太郎：「たしかに、最初に作ったアラートがずっと放置されると、いつの間にか無駄な通知が増えそうですね。」
花子：「そうね。 "このアラートは本当に必要か？" を定期的に確認するのが重要なのよ。」
💡 まとめ
花子：「アラートの運用で大事なことはこの5つよ。」
✅ ダッシュボードを整備してからアラートを作る
✅ アラートの重要度（Critical, Warning, Info）を明確にする
✅ 対応できるアラートにする（"で、何をすればいいの？" をなくす）
✅ ノイズを減らし、アラート疲れを防ぐ（本当に重要な通知だけ）
✅ 定期的にアラートを見直し、不要なものを削除する
太郎：「これなら、適切にアラートを運用できそうです！」
さいごに
続きます。