オンコール@監視¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. オンコール¶
オンコールとは¶
アラートが通知された時に、エラー修正の担当者に連絡できる状態 (メールアドレス、電話番号、SMS、など) にあること。
オンコール対応時間¶
▼ グローバル企業の場合¶
グローバル企業の場合、世界各地にオンコールセンターを配置している。
各オンコールセンターには時差があるため、特定の時間に、どこかの国でオンコールセンターが必ず営業している。
アラートのタイミングで営業しているオンコールセンターに通知を送信するため、『24時間365日対応可能』といったサービスを提供できる。
02. アラートの設定¶
アラート発火の事前検証¶
▼ システムの実際値の変更¶
アラートが発火するように、システムの実際値を調節 (例:負荷を高める) し、アラートが発火するかを検証する。
▼ 閾値の変更¶
必ずアラートが発火するような閾値 (例:ゼロ) に変更し、アラートが発火するかを検証する。
アラートの付加情報¶
▼ イベントの内容¶
- タイムスタンプ
- ログステータス
- ログメッセージ
▼ ラベル¶
- 実行環境名
- リージョン名
- Cluster名
- Node名
- Namespace名
- Pod名
- マイクロサービス名
- コンテナ名
03. エラーイベント重要度 (severity) レベル¶
エラーイベント重要度レベルとは¶
全ての事象をエラーイベントとして見なしてしまうと、アラート疲れしてしまう。
そのため、どのようなイベントをエラーイベントと見なしてアラートを通知するか否かを確認するか、を決めておく必要がある。
また、レベルに応じてアラート先のチャンネルを区別すると良い。
メトリクスの単位 | エラーイベントと見なす閾値例 | 閾値とするメトリクス例 | 補足 |
---|---|---|---|
パーセント | 60 % |
CPU使用率、メモリ使用率、など | 平常時は30 %である仮定し、エラーイベントと見なす閾値を60 %に設定することが多い。 |
カウント | 1 〜3 個 |
ログステータス、ステータスコード、など | どのログステータスやステータスコードをカウントするかを決める必要がある。 |
バイト数 | メトリクスによる | メモリの空きサイズ、ストレージのスワップ領域の使用サイズ、など | メトリクスによって、エラーイベントと見なせるバイト数が異なる。 |
カウントする必要があるステータスの判断¶
▼ ステータスの重要度レベルへの変換¶
ステータスは、重要度を判断しやすいように、重要度レベルに変換して考える。
該当の重要度レベルに当てはまるステータスのみを、エラーイベントとしてカウントする。
重要度レベルの例 | エラーイベントと見なし、アラートを通知するか否かの判断例 |
---|---|
critical | する |
warning | しない |
information | しない |
▼ ログステータスの場合¶
エラーイベントと見なすログステータスの目安は以下の通りである。
ログステータス | 説明 | 重要度レベルへの変換例 |
---|---|---|
emergency | システムが使用できない状態にある緊急事態 | critical |
alert | 早急に対応すべき事態 | critical |
critical | 対処すべき重要な問題 | critical |
fatal | 対処すべき重要な問題 | critical |
error | 何かが失敗している | criticalまたはwarning |
warn | 普通ではないことが発生したが、心配する必要はない | criticalまたはwarning |
notice | いたって普通だが、注意すべきことが起こっている | information |
info | 知っておくといいかもしれない情報 | information |
debug | 問題が起こっている場所を知るのに有効な情報 | information |
▼ ステータスコードの場合¶
エラーイベントと見なすステータスコードの目安は以下の通りである。
各ステータスコードをバラバラに扱うことは大変なため、系ごとにまとめて扱えるように、レベルを割り当てる。
ステータスコード | 本番環境のアラートの目安 | 重要度レベルへの変換例 |
---|---|---|
500 系 |
する | critical |
400 系 |
どちらでも | warning |
300 系 |
しない | information |
200 系 |
しない | information |