オンコール＠監視¶

はじめに¶

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。

https://hiroki-it.github.io/tech-notebook/

アラートが通知された時に、エラー修正の担当者に連絡できる状態 (メールアドレス、電話番号、SMSなど) にあること。

https://response.pagerduty.com/oncall/being_oncall/

グローバル企業の場合、世界各地にオンコールセンターを配置している。

各オンコールセンターには時差があるため、特定の時間に、どこかの国でオンコールセンターが必ず営業している。

アラートのタイミングで営業しているオンコールセンターに通知を送信するため、『24時間365日対応可能』といったサービスを提供できる。

アラートが発火するように、システムの実際値を調節 (例：負荷を高める) し、アラートが発火するかを検証する。

必ずアラートが発火するような閾値 (例：ゼロ) に変更し、アラートが発火するかを検証する。

全ての事象をエラーイベントとして見なしてしまうと、アラート疲れしてしまう。

そのため、どのようなイベントをエラーイベントと見なしてアラートを通知するか否かを確認するかを決めておく必要がある。

また、レベルに応じてアラート先のチャンネルを区別すると良い。

メトリクスの単位	エラーイベントと見なす閾値例	閾値とするメトリクス例	補足
パーセント	`60`%	CPU使用率、メモリ使用率など	平常時は`30`%である仮定し、エラーイベントと見なす閾値を`60`%に設定することが多い。
カウント	`1`〜`3`個	ログステータス、ステータスコードなど	どのログステータスやステータスコードをカウントするかを決める必要がある。
バイト数	メトリクスによる	メモリの空きサイズ、ストレージのスワップ領域の使用サイズなど	メトリクスによって、エラーイベントと見なせるバイト数が異なる。

ステータスは、重要度を判断しやすいように、重要度レベルに変換して考える。

該当の重要度レベルに当てはまるステータスのみを、エラーイベントとしてカウントする。

重要度レベルの例	エラーイベントと見なし、アラートを通知するか否かの判断例
critical	する
warning	しない
information	しない

エラーイベントと見なすログステータスの目安は以下の通りである。

https://engineering.otobank.co.jp/entry/2016/09/20/181756

エラーイベントと見なすステータスコードの目安は以下の通りである。

各ステータスコードをバラバラに扱うことは大変なため、系ごとにまとめて扱えるように、レベルを割り当てる。