【初心者向け】Prometheusでの監視業務

# 📖 はじめに

理解のために **Prometheusでの監視業務** を、小咄形式でまとめました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/143127/8fac1ede-3789-45a5-b569-d1210ad97909.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/143127/0f8f42d9-d4bb-44f5-874e-5a48d6130be5.png)

**登場人物**
- **太郎（後輩）**：入社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のインストール手順を説明するね。次の記事を見てほしいわ。」

:::note info
- [【2025年03月版】PrometheusとGrafanaによる監視システムの構築メモ](https://qiita.com/nouernet/items/26d2782111cb7ac3c160)
:::

**太郎**：「Node Exporterをダウンロードして、システムサービスとして動かせばいいんですね！」

**花子**：「そうね。Node Exporterが動いているか確認するには、ブラウザで次のURLを開いてみましょう。」

```sh
http://<サーバーのIP>:9100/metrics
```

**太郎**：「めちゃくちゃいろんなメトリクスが並んでいますね。」

**花子**：「そうね。このメトリクスをPrometheusが取得して、監視できるようになるのよ。」

### **📌 Prometheusの設定（Node Exporterをスクレイピングする）**
**花子**：「次に、PrometheusがNode Exporterからデータを取得できるように設定しましょう。」

**太郎**：「どこを設定するんですか？」

**花子**：「Prometheusの設定ファイル `prometheus.yml` に、Node Exporterのターゲットを追加するのよ。次の記事を見てほしいわ。」

:::note info
- [【2025年03月版】PrometheusとGrafanaによる監視システムの構築メモ](https://qiita.com/nouernet/items/26d2782111cb7ac3c160)
:::

**太郎**：「なるほど。これで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をインストールしてみましょう。次の記事を見てほしいわ。」

:::note info
- [【2025年03月版】PrometheusとGrafanaによる監視システムの構築メモ](https://qiita.com/nouernet/items/26d2782111cb7ac3c160)
:::

**太郎**：「これでGrafanaが起動するんですね。」

**花子**：「そうね。ブラウザで `http://<サーバーのIP>:3000` にアクセスすると表示されるわ。」

### **📌 Grafanaの初期設定**
1. **ログインする**
   - 初回ログインは **ユーザー名：`admin`、パスワード：`admin`**
   - ログイン後、パスワードを変更する

2. **データソース（Prometheus）を追加**
   - 左側の **設定（⚙️ Settings） → Data Sources** を開く
   - **[Add data source]** をクリック
   - **Prometheus** を選択
   - **URL** に `http://<PrometheusのIP>:9090` を入力
   - **[Save & Test]** を押して、接続を確認

**太郎**：「これでGrafanaがPrometheusのデータを読めるようになるんですね！」

**花子**：「そうね。サーバーのメトリクスを可視化するダッシュボードを作ると捗るわ。」

### **📌 Grafanaでダッシュボードを作成**
1. **左側メニューの `＋ Create` → `Dashboard` をクリック**
2. **"Add a new panel" を選択**
3. **Prometheusのクエリを設定**
   - 例：CPU使用率
     ```promql
     100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
     ```
   - 例：メモリ使用率
     ```promql
     1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)
     ```
   - 例：ディスク使用率
     ```promql
     1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})
     ```
4. **[Save] をクリックして保存**

**太郎**：「リアルタイムでCPUやメモリのグラフが表示されました！」

**花子**：「そうね。このダッシュボードを使えば、サーバーの状態が一目で分かるようになるわよ。」

### **📌 Grafanaの便利な機能**
**花子**：「Grafanaには他にも便利な機能があるのよ。」

✅ **アラート設定**
- **一定の閾値を超えたら通知を送る**（例：CPU使用率90%以上でアラート）
- `Alerting` タブでしきい値を設定し、SlackやEmailに通知可能

✅ **ダッシュボードのテンプレート**
- **公式のダッシュボードテンプレート** を使えば、すぐに用意されたグラフが作れる
- **[Grafana Dashboards](https://grafana.com/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したら通知**

```yaml
- 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のアプリケーション監視でできること**
1. **リクエスト数・レスポンスタイムの監視**
   - 各APIエンドポイントのリクエスト数を計測
   - レスポンスタイムの分布を可視化

2. **エラーレートの監視**
   - HTTPステータスコード（200, 400, 500）の割合を監視
   - 異常なエラーレート増加時にアラートを発生

3. **バックエンド処理のパフォーマンス測定**
   - データベースのクエリ時間、キャッシュのヒット率を記録
   - メモリ使用量やスレッド数を監視

4. **ビジネス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クライアントをインストール**
```sh
go get github.com/prometheus/client_golang/prometheus
go get github.com/prometheus/client_golang/prometheus/promhttp
```

#### **2. メトリクスを定義**
```go
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` でデータを取得**
```sh
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` エンドポイントを追加するのよ。」

```yaml
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]))`)

#### **✅ 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`)

#### **✅ 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)`)

---

### **📌 Goアプリで主要メトリクスを計測する**
**花子**：「Goアプリで主要なメトリクスを記録する例を見てみましょう。」

#### **1. HTTPリクエストのレスポンスタイムを計測**
```go
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. エラーレートを記録**
```go
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を連携させましょう。次の記事を参考にして構築してほしいわ。」

:::note info
- [【2025年03月版】PrometheusとGrafanaによる監視システムの構築メモ](https://qiita.com/nouernet/items/26d2782111cb7ac3c160)
:::

**花子**：「次にダッシュボードを作成するわ。」

### **📌 ダッシュボードの作成**
#### **1. ダッシュボードを追加**
1. 左メニューの **「＋ Create」** → **「Dashboard」**
2. **「Add a new panel」** を選択

#### **2. PromQLを設定**
- **リクエスト数**
  ```promql
  rate(http_requests_total[5m])
  ```
- **エラーレート**
  ```promql
  rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
  ```
- **P95 レイテンシ**
  ```promql
  histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
  ```

**太郎**：「グラフが表示されました！」

### **📌 ダッシュボードテンプレート**
**花子**：「Grafanaには **公式のダッシュボードテンプレート** もあるわ。」

- **[Grafana Dashboards](https://grafana.com/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を使って、アラートを発生させる条件を定義すのよ。基本的な構成はこんな感じよ。」

```yaml
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ファイルはこうなるわ。」

```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. すぐに対応できるアラートにする**
- アラートを受け取った **担当者がすぐに対処できる内容** にする。
- 「○○がダウン」だけではなく、「再起動が必要」など **具体的なアクション** を含める。
- 例：
  ```yaml
  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）を明確にする**
✅ **対応できるアラートにする（"で、何をすればいいの？" をなくす）**
✅ **ノイズを減らし、アラート疲れを防ぐ（本当に重要な通知だけ）**
✅ **定期的にアラートを見直し、不要なものを削除する**

**太郎**：「これなら、適切にアラートを運用できそうです！」

# さいごに

続きます。

# リンク

- [入門 Prometheus ― インフラとアプリケーションのパフォーマンスモニタリング](https://www.oreilly.co.jp/books/9784873118772/)
- [SRE の原則を使用し、Cloud Monitoring ダッシュボードでパイプラインをモニタリングする](https://cloud.google.com/blog/ja/products/management-tools/the-right-metrics-to-monitor-cloud-data-pipelines)
- [Prometheus 公式](https://prometheus.io/)
- [Grafana 公式](https://grafana.com/ja/)
- [「アラートが鳴りやまないクラウド」にしないためのベストプラクティス5選と主要ツール](https://techtarget.itmedia.co.jp/tt/news/1903/26/news05.html)