【ITニュース解説】Monitoring engines should know when to stay quiet

監視システムは、システムの状態を常にチェックし、問題が発生した際にアラートを通知する重要な役割を担っている。しかし、その役割の中で見過ごされがちなのが、「いつ沈黙すべきか」という判断だ。特に新しい監視対象が追加されたばかりの状況では、この判断がシステムの信頼性に大きく影響する。

システムエンジニアが新しいウェブサイトやAPIのエンドポイントを構築し、それを監視システムに登録したと仮定しよう。そのエンドポイントはまだ完全にデプロイされていなかったり、DNSの設定が浸透中だったり、セキュリティ証明書が発行される途中だったりする。このような「初期段階」では、一時的にアクセスできない、あるいはエラーを返すのがごく普通のことだ。

ところが、監視システムは数秒から数分おきにエンドポイントの状態をチェックし始める。最初のチェックで失敗、次のチェックでも失敗、さらに次のチェックでも失敗。これらの失敗データが一定数に達すると、監視システムは「エンドポイントがダウンしている」と判断し、すぐにアラートを発してしまう。しかし、この時点ではエンドポイントはまだ正常に稼働し始める準備ができていなかっただけであり、一度も正常な状態を記録したことがない。これはシステムが誤った情報を自信満々に通知している状態であり、ユーザーにとっては混乱の原因となり、結果的にアラート疲れを引き起こす可能性がある。

この問題に対処するため、既存の監視ツールもさまざまな工夫をしている。例えば、新しい監視対象グループの評価を一定時間（例えば60秒）遅延させる機能や、エラーが一定時間連続した場合にのみアラートを発する機能などがある。しかし、これらの機能の多くはユーザーが普段意識しない設定パラメータとして提供されており、また「時間」を基準にしていることが多い。監視間隔が短い場合は効果的だが、監視間隔が数分や数時間と長い場合、設定された時間だけでは十分な学習期間を確保できないという限界があった。ユーザーが本当に知りたいのは、監視システムが「この監視対象について何かを学習したか」という点である。

そこで、Mycellisという監視製品では、この問題に対して異なるアプローチを提案している。そのアプローチとは、「AWAKENING（覚醒）」という新しい状態を監視対象のライフサイクルに導入することだ。この考え方は、生物が成熟するまでの期間になぞらえている。まるで植物が最初のうちは根や葉をしっかりと育てることに専念し、十分なエネルギーを蓄えてから初めて茎や花を伸ばし始めるように、監視対象も最初の段階ではシステムがその状態を「学習」する期間を設けるべきだという発想である。

MycellisのAWAKENING状態を支える二つのデザイン決定がある。一つ目は、「時間」ではなく「パルスのカウント」を基準にすることだ。監視間隔はユーザーが自由に設定できるため、10秒から24時間まで大きく異なる可能性がある。この幅広い監視間隔に対応するためには、単なる時間に基づくウォームアップ期間では不十分である。監視パルス（監視システムが状態をチェックした回数）の数を基準にすることで、監視対象が実際にデータを収集し、「何かを学習した」と判断するまでの期間をより適切に管理できる。例えば、デフォルトで3回のパルスを学習期間とすると、監視対象は3回分のチェックが完了するまでAWAKENING状態に留まる。これにより、監視システムが十分なデータポイントを収集し、その挙動について確かな意見を持つまで、アラートは発されない。

二つ目のデザイン決定は、このウォームアップ期間をユーザーから見えない設定ではなく、正式な「状態」としてダッシュボードに表示することだ。既存の多くのツールでは、ウォームアップ期間は裏側の設定で処理され、ユーザーは監視対象がなぜアラートを発しないのか理解できない場合がある。しかし、Mycellisでは、監視対象（これを「ストーク」と呼ぶ）がAWAKENING状態にあることをダッシュボード上で明確に表示し、その意味も説明する。これにより、ユーザーは自分の監視対象が現在「学習中」であり、システムがその振る舞いを理解しようとしている段階であることを認識できる。これはシステムが「知っていること」をユーザーに対して正直に伝えるという、より大きな製品哲学に基づいている。

具体的には、新しいストークが登録されると、自動的にAWAKENING状態から始まる。そして、設定されたパルスのカウント閾値（デフォルトは3回）に達するまでこの状態が維持される。この期間中、たとえすべてのパルスが失敗を報告したとしても、監視システムはアラートを発しない。パルスのカウントが閾値を超えると、それまでに蓄積されたヘルスインデックスに基づいて、ストークは「HEALTHY（正常）」または「DEGRADED（劣化）」のいずれかの状態に移行し、この時点で初めてアラートの生成が可能になる。アラートパイプラインには簡単なガードが実装されており、AWAKENING状態のストークについては、その後のアラート評価処理がスキップされる仕組みになっている。これにより、不要なデータベース読み込みや評価処理、そして誤ったアラートの送信が防止される。

実は、この「AWAKENING状態のストークに対してアラートを停止するガード」は、当初の設計には含まれていたものの、実際のコード実装が漏れていたという開発者の反省がある。この記事を書く過程で自身のコードを見直した際、初めてこの実装漏れに気づき、すぐに修正・デプロイされた。このエピソードは、自分のシステムについて公に文章化すること自体が、コードのバグや設計と実装のギャップを発見するための強力な「デバッグツール」になることを示している。何かを明確に記述しようとすると、その対象を詳細に検討せざるを得なくなり、その過程で今まで見過ごしていた問題点を発見できるのだ。

もちろん、このAWAKENINGアプローチにもトレードオフは存在する。カウントベースのウォームアップは、監視間隔が非常に長い場合（例えば24時間間隔）には、たとえ3パルスでも数日間AWAKENING状態に留まることになり、ウォームアップ期間が長すぎる可能性がある。将来のバージョンでは、「NパルスまたはM時間のうち、いずれか早く条件を満たした方でウォームアップを終了する」といった複合的な条件を導入することも検討されるだろう。また、このアプローチが「既存の時間ベースの遅延設定の別名ではないか」という意見もあるかもしれない。しかし、その違いは「時間」ではなく「カウント」に基づくメカニズムと、「不可視な設定」ではなく「可視的な状態」としてユーザーに提示するUXにある。そして、多くのユーザーがデフォルト設定を使用することから、システムが賢明なデフォルトを提供しつつ、必要に応じてユーザーが調整できる余地を残すことが重要である。

結局のところ、AWAKENING状態にある監視対象は、壊れているわけでも完全に正常なわけでもない。「まだ十分に生きておらず、システムがその振る舞いを学習している途中」という状態なのだ。システムが「知っていること」を正直に表現し、その状態をユーザーが理解できる言葉で伝えること。これは、監視システムが提供する情報に対する信頼性を高め、ユーザーエクスペリエンスを向上させる上で非常に重要な考え方だ。