通知メッセージのベスト プラクティス

概要

モニターは、ビジネスやシステムを円滑に稼働させるために不可欠です。モニターがアラートを発したら、注意が必要であることを示します。しかし、問題の検知は氷山の一角にすぎません。解決までの時間に大きく影響するのは、通知です。

通知メッセージは、監視システムと問題解決を担う人々の橋渡しをします。不明瞭または質の低いメッセージは混乱を招き、対応を遅らせ、問題の未解決につながることがあります。一方、明確で実行可能なメッセージは、チームが何が起きているのか、次に何をすべきかをすばやく理解するのに役立ちます。

このガイドを活用して通知メッセージを改善し、次の内容を学びましょう:

  • 効果的なコミュニケーションの主要原則
  • 避けるべき一般的なミス
  • 結果につながるメッセージ作成のコツ

プロダクト マネージャーから開発者まで、このリソースは通知がシステムの信頼性とチームの効率を高めるのに役立ちます。

通知の設定

最初のステップは、必須フィールドで通知を設定することです:

Monitor 通知メッセージの設定

名前

対応担当者がアラートの状況をすばやく理解できるよう、Monitor Name に主要な情報を含めて作成します。タイトルは、シグナルを明確かつ簡潔に説明し、次を含めます:

  • 障害モード (複数可) または乖離しているメトリクス
  • 影響を受けるリソース (例: データセンター、Kubernetes クラスター、ホスト、サービス)
要修正改善されたタイトル
メモリ使用量{{pod_name.name}} 上でメモリ使用量が高い

どちらの例もメモリ消費に関するモニターを指しますが、改善されたタイトルは、集中的な調査に必要な重要なコンテキストを備えた、より完全な表現になっています。

メッセージ

オンコール担当者は、通知の本文を手掛かりにアラートを理解し、行動します。明確さのために、簡潔で正確かつ可読性の高いメッセージを書きましょう。

  • 何が失敗しているのかを正確に示し、主な根本原因を列挙する
  • 迅速な解決のための手順がまとまったランブックを追加する
  • 次のアクションが明確になるよう、関連ページへのリンクを含める
  • 通知が適切な受信者に送られるようにする (直接のメール通知、または インテグレーション ハンドル 経由。例: Slack)

以下のセクションを読み、モニター メッセージをさらに強化する高度な機能を確認してください。

変数

モニター メッセージ変数は動的なプレースホルダーで、リアルタイムのコンテキスト情報を用いて通知メッセージをカスタマイズできます。変数を使ってメッセージの明確さを高め、詳細なコンテキストを提供しましょう。変数には 2 種類あります:

変数の種類説明
条件付きモニターの状態などの条件に応じて “if-else” ロジックでメッセージの文脈を調整します。
テンプレートコンテキスト情報でモニター通知を充実させます。

変数は Multi-Alert モニターで特に重要です。トリガーされたとき、どのグループが対象かを把握する必要があります。例えば、コンテナごとの CPU 使用率を監視し、ホストでグループ化している場合です。有用な変数は {{host.name}} で、アラートをトリガーしたホストを示します。

container.cpu.usage メトリクスをホスト平均で集計するモニター クエリの例

条件付き変数

これらの変数を使うと、ニーズやユースケースに基づく分岐ロジックを実装して、通知メッセージを調整できます。アラートをトリガーしたグループに応じて、異なる人物/グループへ通知するために条件付き変数を使用します。

{{#is_exact_match "role.name" "network"}}
  # アラートをトリガーしたホストのロール名に `network` が含まれる場合、この内容を表示し、@network-team@company.com のみに通知します。
  @network-team@company.com
{{/is_exact_match}}

アラートをトリガーしたグループ名に特定の文字列が含まれている場合のみ、通知を受け取ることもできます。

{{#is_match "datacenter.name" "us"}}
  # アラートをトリガーしたリージョンに `us` が含まれる場合 (例: us1 または us3)、この内容を表示します。
  @us.datacenter@company.com 
{{/is_match}}

詳しい情報と例は、条件付き変数 のドキュメントを参照してください。

テンプレート変数

モニターのテンプレート変数を追加すると、{{value}} のようなアラート発火の原因となったメタデータだけでなく、そのコンテキストに関する情報にもアクセスできます。

例えば、ホスト名、IP、モニター クエリの値を表示したい場合:

{{host.name}} の CPU (IP:{{host.ip}}) が重大な値 {{value}} に達しました。

利用可能なテンプレート変数の一覧は、ドキュメント を参照してください。

テンプレート変数を使って、通知を自動ルーティングする動的なリンクやハンドルを作成することもできます。 ハンドルの例:

@slack-{{service.name}} {{service.name}} で進行中の問題があります。

グループ service:ad-server がトリガーされた場合の出力例:

@slack-ad-server ad-server で進行中の問題があります。

リンクの例:

[https://app.datadoghq.com/dash/integration/system_overview?tpl_var_scope=host:{{host.name](https://app.datadoghq.com/dash/integration/system_overview?tpl_var_scope=host:{{host.name)}}

ベスト プラクティスに従った通知メッセージの例

## 何が起きていますか？ {{host.name}} の CPU 使用率が定義済みのしきい値を超えました。

現在の CPU 使用率: {{value}} しきい値: {{threshold}} 時刻: {{last_triggered_at_epoch}}

## 影響 1. 顧客がウェブ サイトで遅延を体験しています。 2. タイムアウトとエラーが発生しています。

## なぜですか？ CPU 使用率がしきい値を超えた理由はいくつか考えられます:

  • トラフィックの増加
  • ハードウェアの問題
  • 外部からの攻撃

## トラブルシューティング / 解決方法 1. ワークロードを分析し、CPU 負荷の高いプロセスを特定する。 a. OOM の場合 - ポッド制限が低すぎる場合は増やす 2. レプリカを追加して {{host.name}} のキャパシティを拡張する: a. 直接: <Code to do so> b. レプリカ追加のランブック で設定を変更する 3. Kafka の問題 がないか確認する 4. その他の障害 / インシデント (試行された接続) がないか確認する

## 関連リンク * [トラブルシューティング ダッシュボード](<Link>) * [アプリ ダッシュボード](<Link>) * [ログ](<Link>) * [インフラストラクチャー](<Link>) * [パイプライン 概要](<Link>) * [アプリ ドキュメント](<Link>) * [障害モード](<Link>)

参考資料

お役に立つドキュメント、リンクや記事:

Monitor Notifications の詳細ドキュメント more more