Prometheus & Grafana Cloud で Kusanagi サーバーを監視する方法（ Grafana Cloud 編）

Prometheus & Grafana Cloud で Kusanagi サーバーを監視する方法（サーバー編）にて、サーバーの設定が完了しているのが、前提で Grafana Cloud の説明を行います。

Grafana Cloud について

Grafana Cloud は管理サーバーをクラウド化してくれていますので、安心して利用ができます。よくあることなのですが、管理サーバーがクラウドの方が良いと個人的に思います。管理工数もサーバー1台ですみますし。

Pro版で$19/month(2025年7月)なので、サーバー費用とサーバー管理費などを考えたら、効率がいいと思います。状況によっては、この費用をクライアントにお願いしてもいいのではという価格だと思います。
Grafana Cloudの価格表

もちろん、自社サーバーを立てて、Grafana を利用することも可能です。

Grafana Cloudアカウントの準備

まず、Grafana Cloud でアカウントを作成し、以下の情報を取得してください：

• Prometheus Remote Write URL
• Username/Instance ID
• API Key

これらの情報は、Grafana Cloud の Prometheus 設定画面で確認できます。

Prometheus Onboarding Guide のページに行く

1Page目

1. How do you want to get started?

• Collect and send metrics to a fully-managed Prometheus Stack
• Connect and enhance an existing Prometheus instance(こっちを選択)

2. What do you want to do with your Prometheus Data?

• Send metrics to Grafana Cloud(こっちを選択)
  既存の Prometheus インスタンスからメトリクスを収集、保存、視覚化する
• Visualize
  Grafana Cloud でデータを収集または保存せずにダッシュボード、クエリ、アラートを作成する
• Enhance
  Grafana Cloudの監視統合を使用して、新しい、より優れた監視設定を作成します。

3. How do you want to connect your Prometheus data to Grafana Cloud?(Send metrics to Grafana Cloudの場合)

• Prometheus Remote Write
  スケーラブルなストレージとクエリのためにメトリックをGrafana Cloudに送信する
• Alloy
  ベンダー中立のエージェントを使用して Grafana Cloud に remote_write メトリックを送信する

2Page目

1. Choose a method for forwarding metrics

• Via Grafana Alloy
  コンポーネントベースのテレメトリコレクターを使用してメトリクスを送信し、Grafana Cloud アラートのメリットを活用できます。データをローカルに保存する必要はありません。
• From my local Prometheus server(こっちを選択)
  スクレイピングしたサンプルのコピーを Grafana Cloud に送信し、同時に Prometheus データのローカルコピーも維持します。

Show Instructions for
Standard もしくは Kubernetes を選ぶ。現状KUSANAGIの場合は Standard かと。

2. Choose your use case for forwarding metrics

• Send metrics from a single Prometheus instance(こっちを選択)
• Send metrics from multiple Prometheus instances
• Send metrics from multiple HA (high-availability) Prometheus instances

3. Configure remote_write

1. Select how to send the metrics from Prometheus to Grafana Cloud

• Directly(こっちを選択)
  Prometheus から Grafana Cloud へ直接メトリクスをリモート書き込み
• Via Grafana Alloy
  コンポーネントベースのテレメトリコレクターを使用して Grafana Cloud にメトリックをリモートで書き込む

2. Update Prometheus configuration(Directlyの場合)
Create a new Token
Token name にユニークな名前を入れます。

そうすると、自動で yaml 形式のデータが出力されます。これは、先にサーバー編の方で利用するものとなります。

yaml 出力例

global:
  scrape_interval: 60s
remote_write:
  - url: https://******.grafana.net/api/prom/push
    basic_auth:
      username: [USERNAME]
      password: [PASSWAORD]
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["localhost:9090"]

4. View your Starter Dashboard
Go to Starter Dashboardのボタンを押してダッシュボードへ。

この流れでサーバー側の Promeheus と連携させるための情報が手に入りました。

Grafana Cloud と Prometheus との接続テスト

まずは、ダッシュボードでそれぞれの設定した Prometheus で登録した job が表示されているかどうを確認します。緑色になっていたら、接続されています。(Running 表示)接続されていなかった場合は、赤色になっています。(Failed 表示)

このため、複数のサーバーを監視する場合には job 名をしっかりと分けた方が良いと思います。

Exploer で接続テスト

Explore で Bulider か Code にて接続テストを行います。No Data にならなければ、それで通信ができています。No Data の場合は何かしらの問題が発生しているので、それの対応をしなければなりません。

Alerting で通知機能を作成する。

通知機能を実装するには、最低でも以下の３つの設定が必要です。
Contact Point 設定、Alert Rule 作成、Notification Policy 作成です。

Contact Point 設定

Grafana Cloudにログインし、サイドメニュー → 「Alerting」→ 「Contact points」に移動して、Contact Pointの設定を行います。

1. Contact Point の新規作成

「+ Create contact point」をクリックをクリックして、作成します。

2. 設定

Discordの通知設定の例が下です。
Webhookに関しては、Discordの方で「チャンネル編集」>「連携サービス」>「ウェブフック」から 新しいウェブフック をクリックして作成してください。自動的に「Spidey Bot」と命名されるので、分かりやすくするために「Grafana Notice」などの名前を変更することをお勧めします。

Name: Discord Alerts
Integration: Discord
Webhook URL: https://discord.com/api/webhooks/YOUR/DISCORD/WEBHOOK
Title: {{ template "default.title" . }}
Message: {{ range .Alerts }}{{ .Annotations.summary }}{{ end }}

Test ボタンをクリックして、Discord に送信されるかどうかのテストをしてください。

Notification Policiesの設定

Default policyが最初に設定されています。右上の More から Edit を選択して、編集作業ができます。
Timing options のタブをクリックして、wait などの時間に関連する設定を行うことができます。

• Group by: アラートのグループ化基準を定義します。
• Group wait: 最初のアラートが発火してから、同じグループの他のアラートを待つ時間
• Group interval: 同じグループで新しいアラートが追加された時の再通知間隔
• Repeat interval: 解決されていないアラートの定期的な再通知間隔
  Default policy だけでなく Child policy を作成することで、ラベルなどを利用することで、独自に通知設定を変更することができます。例えばですが、緊急性の高いものに関しては、早く再通知をするなど Override general timings を設定することで対応が可能です。

以下は設定例です。

Matching labels:
- severity = critical

Contact point: Discord Alerts, Email Alerts
Group wait: 0s
Group interval: 2m
Repeat interval: 4h
Continue matching subsequent sibling nodes: false

Matching labels:
- severity = warning

Contact point: Slack Alerts
Group wait: 30s
Group interval: 10m
Repeat interval: 24h
Continue matching subsequent sibling nodes: false

実用的な WordPress/WEB サーバー監視用 Alert Rules 例

Alert rule を作ることによって、いろいろな条件で通知をすることができます。
設定場所は Alert & IRM > Alerting > Alert rules から New alert rule をクリックして、作成します。

1. Website Down

Rule name: Website Unreachable
Query: probe_success{job="blackbox-http"}
Condition: IS BELOW 1
Labels:
  severity: critical
  service_name: website
Evaluation: every 30s for 1m
Annotations:
  summary: Website {{ $labels.instance }} is down
  description: HTTP probe failed for {{ $labels.instance }}

2. High Response Time

Rule name: High Response Time
Query: probe_duration_seconds{job="blackbox-http"}
Condition: IS ABOVE 5
Labels:
  severity: warning
  service_name: website
Evaluation: every 1m for 2m
Annotations:
  summary: High response time for {{ $labels.instance }}
  description: Response time is {{ $value }}s for {{ $labels.instance }}

3. High CPU Usage

Rule name: High CPU Usage
Query: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Condition: IS ABOVE 80
Labels:
  severity: warning
  service_name: server
Evaluation: every 1m for 5m
Annotations:
  summary: High CPU usage on {{ $labels.instance }}
  description: CPU usage is {{ $value }}% on {{ $labels.instance }}

4. High Memory Usage

Rule name: High Memory Usage
Query: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
Condition: IS ABOVE 85
Labels:
  severity: warning
  service_name: server
Evaluation: every 1m for 5m
Annotations:
  summary: High memory usage on {{ $labels.instance }}
  description: Memory usage is {{ $value }}% on {{ $labels.instance }}

5. Disk Space Low

Rule name: Low Disk Space
Query: 100 - ((node_filesystem_avail_bytes{mountpoint="/"} * 100) / node_filesystem_size_bytes{mountpoint="/"})
Condition: IS ABOVE 90
Labels:
  severity: warning
  service_name: server
Evaluation: every 5m for 5m
Annotations:
  summary: Low disk space on {{ $labels.instance }}
  description: Disk usage is {{ $value }}% on {{ $labels.instance }}

6. MySQL High Disk Temp Tables Rate

Rule name: MySQL High Disk Temp Tables Rate
Query: rate(mysql_global_status_created_tmp_disk_tables[5m])
Condition: IS ABOVE 10
Labels:
  severity: warning
  service_name: database
Evaluation: every 1m for 5m
Annotations:
  summary: MySQL disk temporary tables creation rate is high on {{ $labels.instance }}
  description: MySQL is creating {{ $value }} disk temporary tables per second (threshold: 10)

7. MySQL Buffer Pool Utilization Too Low

Rule name: MySQL Buffer Pool Utilization Too Low
Query: |
  (
    mysql_global_status_innodb_buffer_pool_bytes_data / 
    mysql_global_variables_innodb_buffer_pool_size
  ) * 100
Condition: IS BELOW 50
Labels:
  severity: warning
  service_name: database
Evaluation: every 1m for 5m
Annotations:
  summary: MySQL Buffer Pool utilization is too low on {{ $labels.instance }}
  description: The buffer pool utilization is {{ printf \"%.2f\" $value }}% which is less than 50% in the last 5 minutes. This means that there is a lot of unused RAM allocated for the buffer pool, which you can easily reallocate at the moment.

8. PHP-FPM Detected Slow Requests

Rule name: PHP-FPM Detected Slow Requests
Query: increase(phpfpm_slow_requests[5m])
Condition: IS ABOVE 5
Labels:
  severity: warning
  service_name: server
Evaluation: every 1m for 1m
Annotations:
  summary: PHP-FPM detected slow requests on {{ $labels.server | default $labels.instance }}
  description: PHP-FPM has detected {{ $value }} slow request(s) in the last 5 minutes on {{ $labels.server | default $labels.instance }}. The slow request means that it took more time to execute than expected (defined in the configuration of your pool).

9. PHP-FPM High Load

Rule name: PHP-FPM High Load(80% utilization)
Query: (phpfpm_active_processes / phpfpm_total_processes) * 100
Condition: IS ABOVE 80
Labels:
  severity: warning
  service_name: server
Evaluation: every 1m for 3m
Annotations:
  summary: PHP-FPM high process utilization on {{ $labels.server | default $labels.instance }}
  description: {{ printf \"%.1f\" $value }}% of PHP-FPM processes are active on {{ $labels.server | default $labels.instance }}, indicating possible high CPU load or slow requests

10. PHP-FPM Critical Load

Rule name: PHP-FPM Critical Load(95% utilization)
Query: (phpfpm_active_processes / phpfpm_total_processes) * 100
Condition: IS ABOVE 95
Labels:
  severity: critical
  service_name: server
Evaluation: every 1m for 3m
Annotations:
  summary: PHP-FPM critical process utilization on {{ $labels.server | default $labels.instance }}
  description: {{ printf \"%.1f\" $value }}% of PHP-FPM processes are active on {{ $labels.server | default $labels.instance }}, indicating possible high CPU load or slow requests

11. Process Pool Exhaustion（Critical）

Rule name: Process Pool Exhaustion（Critical）
Query: (phpfpm_active_processes / phpfpm_max_active_processes) * 100
Condition: IS ABOVE 80
Labels:
  severity: critical
  service_name: server
Evaluation: every 30s for 1m
Annotations:
  summary: PHP-FPM process pool near exhaustion on {{ $labels.server | default $labels.instance }}
  description: PHP-FPM process pool is {{ printf \"%.1f\" $value }}% utilized ({{ $labels.phpfpm_active_processes }}/{{ $labels.phpfpm_max_active_processes }}) on {{ $labels.server | default $labels.instance }}. Service outage imminent!