監視のポイント
監視のためにメトリクス／ログに対してアラートを設定しますが、以下のようなポイントを意識することが大切です。
対応不要なアラートは設定しない
対応不要なアラートが大量に流れてくると、本当に対応が必要なアラートが埋もれてしまうと同時にアラートに対する緊張感がなくなってしまいます。
これらは問題への対応スピードを下げてしまう恐れがあるので、調査などの何かしらの対応が必要なもののみアラートを設定することが重要です。
Datadogには閾値、異常値、外れ値など様々なアラートトリガーが設定できるので、必要なアラートを比較的容易に設定することが可能です。
アラートへの対応を明確にしておく
アラートへの対応をあらかじめ明確にしておくと、問題解決までのスピードを上げることができます。特に問題が発生している時は余裕がないことも想定されるため、事前の準備をしておくことは大切です。
例えばKARTEではDatadogのダッシュボードとアラートメッセージを利用することで、アラート発生時に以下のような通知を行い対応の明確化を行っています。
ダッシュボードは問題箇所を簡単に把握できるように作成しており、以下のように複数種類作成しています。
- 問題が発生しているコンポーネントを把握するための、サービスの全体感が見えるダッシュボード
- コンポーネント内の問題箇所を把握するための、コンポーネントごとのダッシュボード
最適なダッシュボードを選択すれば数分で問題の切り分けが完了することもあるので、ダッシュボードの作成はとても重要になります。
また、アラートによってある程度ダッシュボードの確認ポイントが決まっているので、確認作業の定型化が可能です。
そこでアラートメッセージには
- 最適なダッシュボードのURL
- ダッシュボードの確認ポイント
を記載するようにし、エンジニアはそれにベースに対応を行うようにしています。
これによりアラート発生時に均質化された、スピーディな対応を行うことができます。
通知先は重要度で分ける
問題を知るべき人は複数いると思いますが、その人たちはエンジニアであったり、セールスだったり役割が異なる人達です。その全員が同じレベルで問題を知る必要があるかと言えばそうではありません。
例えば、エンジニアに内部SLOに基づく厳しめのアラートを通知するのは、外部SLOを守る上で有効ですが、セールスにそのアラートを通知してもあまり有効ではあるとは言えません。外部から見てサービスは正常であるからです。
一方で外部SLOに満たない場合は顧客へのサポートなどが必要になってくる場合があるので、エンジニアだけでなく、セールスにも通知が必須になります。
私たちは社内のコミュニケーションツールであるSlackをベースに、以下のように緊急度に応じて、通知先／通知方法を分けて運用しています。PagerDutyとStatuspageというクラウドサービスを活用しているのがポイントです。
PagerDutyとは
PagerDutyは、インシデントマネジメントのためのクラウドサービスです。
API経由で登録済みの電話番号に電話をかけることができる機能が存在し、KARTEではこの機能を主に利用しています。
PagerDutyはDatadogと連携が可能なので、以下の図のようにDatadogのアラートをトリガーに担当のエンジニアに電話をかける仕組みを実現しています。
また、LogDNAにもPagerDutyとの連携機能が存在するので、Datadogと同様の仕組みを作っています。
Statuspageとは
Statuspageは文字通り、サービスのステータスページを簡単に作れるクラウドサービスです。
以下のようにサービスの稼働状況や障害情報を掲載することができ、KARTEではユーザへの障害通知は主にStatuspage経由で行っています。
この稼働状況や障害情報の更新はAPI経由で実行できるので、ユーザへの通知を自動的かつ最短で行うことができます。
StatuspageはDatadogとは直接連携ができませんが、PagerDutyとは連携が可能なので、以下の図のようにPagerDutyをハブにしてDatadogからのアラートをトリガーに稼働状況や障害情報の更新をしています。
