集中監視とアラート

1台のマシンであれば、topやjournalctlを使って各サーバーにログインしても問題ありません。しかしサーバーが増えると、この方法は拡張できず、問題が起きても確認するまで気付けません。

一元監視では、すべてのサーバーからメトリクスとログを1か所に集め、ダッシュボードと自動アラートで確認できます。

可観測性を支えるデータには、次の2種類があります。

• メトリクス — CPU使用率、メモリ、リクエストレートなどの数値時系列データ
• ログ — エラーやアクセス記録などの個別のテキストイベント

通常は両方を収集しますが、それぞれに最適化された異なるツールを使用します。

Prometheusは、広く使われているメトリクスシステムです。各サーバーが公開するHTTPエンドポイントをスクレイピングして、メトリクスをプルします。

各サーバーではexporterを実行します。ホストのメトリクスにはnode_exporterを使い、Prometheusが読み取るデータを公開します。

Prometheusがスクレイプする対象は、設定ファイルで指定します。各ジョブには対象（exporterのhost:port）を列挙します。

このスニペットは、2台のサーバー上のnode_exporterからスクレイプします。

Prometheusには独自のクエリ言語PromQLがあります。これを使って、サーバー群全体のレートや平均などを計算できます。

この式は、サーバーごとのCPU使用率を推定します。

GrafanaはPrometheusやその他多くのデータソースに接続し、ダッシュボードを作成します。Prometheusをデータソースとして追加し、PromQLクエリからパネルを作成します。

node_exporter用の既成ダッシュボードを使えば、数分でCPU、メモリ、ディスク、ネットワークのグラフを表示できます。

ログについては、各サーバーから中央の保存先に送信します。よく使われる構成は、Grafanaと連携するLokiとPromtailの組み合わせです。

Promtailを各サーバーで実行し、ログファイルとジャーナルをLokiに転送します。

アラートによって、メトリクスを対応につなげられます。Prometheusのアラートルールは、式が一定時間にわたって真である場合に発火します。

このルールは、ノードが2分間停止している場合にアラートを発します。

Alertmanagerは発火したアラートを受け取り、メール、Slack、PagerDutyなど適切な送信先に振り分けます。また、アラートの重複排除や抑制も行います。

severityのようなラベルに基づいて、アラートを受信者に割り当てます。

アラートがまったくないのと同じくらい、多すぎるアラートも問題です。人はアラートを無視するようになります。適切なアラート設計では、次の点を心がけます。

• すべてのメトリクスの変動ではなく、ユーザーが感じる症状に対してアラートを発します
• forで継続時間を指定し、フラッピングを防ぎます
• 重大度を設定して、ノイズをフィルタリングできるようにします

長期的に使える可観測性を構築するためのポイントです。

• メトリクスとログの両方を一元的に収集します
• コミュニティ製のダッシュボードを基に始め、必要に応じてカスタマイズします
• 対応可能な条件に対してのみアラートを発します
• アラートが実際に届くことをテストします

一元監視についての理解度を確認しましょう。

これで、サーバー群全体を一元的に監視できるようになりました。

• node_exporterをPrometheusでスクレイプし、PromQLでクエリするメトリクス
• Grafanaのダッシュボード
• Promtail経由でLokiに送るログ
• Prometheusのルールで検出し、Alertmanagerで振り分けるアラート

これにより、1台のサーバーのログ管理スキルを、サーバー群全体を対象としたプロアクティブな可観測性へと発展させられます。