この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは 園部です。
サービス監視を行う際に、障害や異常が検知された場合、通知する運用を行っているかと思います。一方で、リソースやコンポーネントが絶え間なく変化することがスタンダードとなりつつある中で、「アラートのオオカミ少年」問題が発生し、現場が疲弊・重大なメッセージの取りこぼしが発生しています。
そのため、アラートを重大度等により通知の方法を分ける考え方が取り入れられています。Google や Datadog などで非常に参考となる考え方が紹介されています。ここでは、分類だけをご紹介しますが、ご興味のある方は詳細をご確認ください。
- ログ（人間が見る必要はないが、診断やフォレンジックなどで利用）
- チケット（人間のアクションが必要だが即座である必要はない）
- アラート（人間が即座にアクションを起こして対応が必要）
- 記録するアラート（重大度が低い場合）
- 通知するアラート(重大度が中程度の場合)
- 緊急メッセージを送信するアラート（重大度が高い場合）
今日は、Datadog アラート通知方法を確認して、それぞれのケースでのアラート通知する方法を試していきます。
Datadog アラート通知について
以下の二つを参考に進めていきます。「Datadogで始めるモニタリング基盤」 は先日の技術書典で出されており、丁寧に書かれていてとても参考になりました！
構成要素
- タイトル: Markdown 記述（変数）
- 本文: Markdown 記述（変数、条件式も利用可）
- タグ: タグを付与
- 再通知設定： ステータスがリカバリされない場合に再通知を行う間隔（利用しないも可能）
サンプルを通知してみる
- タイトル：
Host {{host.name}} with IP {{host.ip}} is down.- 本文：
{{#is_alert}} System disk usage is too high! {{/is_alert}}
{{^is_alert}} System disk usage is OK - but check dash 1234 just in case. {{/is_alert}}
@slack-slack_notification-sandbox- Slack 通知結果
変数
メッセージ内で、変数として以下を利用できます。
| 変数 | 説明 |
|---|---|
| {{value}} | アラートに違反した値を表示します。 |
| {{threshold}} | モニターの[ アラート条件の設定]セクションで選択したアラートしきい値を表示します。 |
| {{warn_threshold}} | モニターの[ アラート条件の設定]セクションで選択した警告しきい値がある場合は表示します。 |
| {{ok_threshold}} | モニターを回復した値を表示します。 |
| {{comparator}} | モニターのアラート条件の設定セクションで選択した関係値を表示します。 |
| {{last_triggered_at}} | モニターが最後にトリガーされたUTC日付/時刻を表示します。 |
タグ変数
付与されている タグを利用したメッセージの作成が可能です。
先ほどのサンプルでは、 以下の部分です。
[ 記述 ]
Host {{host.name}} with IP {{host.ip}} is down.
[ メッセージ ]
Host i-062017c01f16e2717 with IP 192.168.1.155 is down.条件変数
以下のような条件によって表示する内容を分けることが可能です。
| 条件変数 | 説明 |
|---|---|
| {{#is_alert}} | アラートを監視するときに表示する |
| {{^is_alert}} | モニターアラートを表示しない |
| {{#is_match}} | コンテキストが文字列に一致したときに表示する |
| {{^is_match}} | コンテキストが文字列に一致しない限り表示 |
| {{#is_exact_match}} | コンテキストが文字列と完全に一致したときに表示する |
| {{^is_exact_match}} | コンテキストが文字列と正確に一致しない限り表示 |
| {{#is_no_data}} | モニターが欠落データについて通知したときに表示する |
| {{^is_no_data}} | モニターが欠落データについて通知しない限り表示 |
| {{#is_warning}} | モニターが警告したときに表示する |
| {{^is_warning}} | モニターが警告しない限り表示 |
| {{#is_recovery}} | WARNING、ALERT、またはNO DATAからモニターが回復したときに表示する |
| {{^is_recovery}} | モニターが警告、警告、またはデータなしから回復しない限り表示 |
| {{#is_warning_recovery}} | モニターが警告からOKに回復したときに表示する |
| {{^is_warning_recovery}} | モニターが警告からOKに回復しない限り表示 |
| {{#is_alert_recovery}} | モニターがALERTからOKに回復したときに表示する |
| {{^is_alert_recovery}} | モニターがALERTからOKに回復しない限り表示 |
| {{#is_alert_to_warning}} | モニターがアラートから警告に移行したときに表示する |
| {{^is_alert_to_warning}} | モニターがアラートから警告に移行しない限り表示 |
| {{#is_no_data_recovery}} | モニターがデータなしから回復したときに表示する |
| {{^is_no_data_recovery}} | モニターがデータなしから回復しない限り表示 |
Markdown で記述するため、リンクなども記述できるので、対応手順への導線とすることも可能です。
やってみる
冒頭で、引用している3つのパターンを用いて、それぞれ Datadog でやってみます。
| アラート | Datadog |
|---|---|
| ログ(記録するアラート) | 通知せずダッシュボード |
| チケット(通知するアラート) | Datadog --> Slack |
| アラート(緊急メッセージを送信するアラート) | Datadog --> PagerDuty |
事前準備
以下はすでに準備が完了しているとして進めます。
- Slack Integration
- PagerDuty Integration
ログ(記録するアラート)
ロードアベレージの一時的な上昇のみの場合は対応不要とし、検知するが通知しない 設定で Monitor を作成します。検証用EC2で負荷もかかっていないので、閾値はだいぶ現実離れしていますが...正しく評価されて Alert となります。
過去の状況は、Monitor から確認することが可能です。
チケット(通知するアラート)
ディスク使用率は、ある程度余裕を持った閾値としておけば、即時対応は不要で、翌日確認および対応を開始する形で概ね問題ないため、 Slack へ通知させます。 Slack に通知することでチームの共有の場で確認することが可能です。
アラート(緊急メッセージを送信するアラート)
あるサイトで、レスポンスタイムが SLO を下回っているとしたケースで、即時に状況確認が必要とし、PagerDuty へ通知されます。今回は担当者へのコールまでは行ないませんが、実際には電話連絡まで行うことで、緊急対応通知を行う可能です。
PagerDuty での電話通知に関しては、弊社メンバーがブログ( pagerdutyでMackerelのアラート通知を管理する ) を書いてくれています。
まとめ
Datadog と Slack、 PagerDuty を利用することで、アラートによって通知する方法を分けることを行いました。もちろん、Datadog 以外でも、このような形を実現することは可能です。ご利用のサービスを活用しながら不足している部分は別サービスで補うなどの方法で、運用現場に優しい監視が広まっていけばと思います。
Happy Monitoring! ですね。
4
