本番環境では、すべてのイベントが同じ重要度ではありません。一つのbackendがメンテナンス中であること、すべてのbackendがdownであること、クラスタIPが別のノードへ移行すること、証明書が30日以内に失効すること、リクエストレート閾値を超過することは、それぞれ異なる運用対応を必要とします。これらがすべて単一型のメールアラームに変換されると、チームは短期間でアラーム疲労に陥ります。
従来のアプローチでは、通知は一般にemailとsyslogに限定されます。しかし運用チームは、異なるイベントを異なるチャネルで受け取りたいと考えます：重要なfailoverはSMSで、日常的な警告はUIで、セキュリティイベントはSNMPまたはSyslogで、管理者サマリーはemailで伝達されるべきです。チャネルの区分がなければ、誰もがすべてを受け取るか、重要なイベントが見逃されるかのいずれかになります。
サイレント時間管理も重要です。深夜3時に低重要度の警告で全チームを起こす必要はありません。しかし実際の障害やクラスタIP変更は依然として可視である必要があります。サイレント時間とは、イベントが完全に消えることではなく、適切なチャネルで適切なタイミングで処理されることを意味すべきです。
pool down、backend down、cluster IP swap、ゾーン閉鎖といったイベントが同じテキストでレポートされると、根本原因分析が困難になります。オペレーターはまずアラームの意味を解明し、それからアクションを取ります。この遅延は、特に高トラフィックのプラットフォームでサービス品質に直接影響します。
TR7通知システムは、アラームライフサイクル、30+の事前定義された状態キー、マルチチャネル、多言語、サイレント時間、per-pool閾値管理によりイベントを分離し、適切な相手に、適切なチャネルで、適切なコンテキストとともに伝達します。
TR7は通知を単発のメッセージとしてではなく、ライフサイクルを持つアラームオブジェクトおよびチャネルベースのアクションとして管理します。
アクティブなアラームはalarmKeyベースで保持され、updateAlarmで更新され、endAlarmでクローズされます。これにより同じイベントが繰り返し新しいアラームとして生成されることはなく、イベントの開始、更新、クローズが追跡されます。
アラームと通知の状態はクラスタ内の他のノードへ伝達できます。これにより運用チームは、接続しているノードのイベントだけでなく、クラスタ全体の重要な状態も確認できます。
プール状態はUNKNOWN、OK、WARN、DISABLED、ERR、EVALUATINGの値で分類されます。このモデルは、メンテナンス、警告、エラー、評価の状態を同じ平坦なアラームテキストに還元しません。
クラスタIP状態は、interfaceの到達性、IP競合、IP移行、2ノード挙動など、異なるシグナルで評価されます。failoverイベントは運用チームへより明確なコンテキストとともに伝達されます。
通知システムは、アラームライフサイクル、プール閾値、マルチチャネル、多言語、サイレント時間、証明書警告、アーカイブ可能なイベント履歴を提供します。
updateAlarm、endAlarm、getAlarmsのフローがアクティブなアラームをライフサイクルとともに追跡します。同じalarmKeyが再度到着するとイベントは更新され、完全に新しいアラームとして複製されることはありません。staticPayload、ifAbsent、dontNotifyなどのフィールドによりイベント挙動をより制御された形で管理できます。この構造はアラームノイズを軽減し、イベント履歴をより意味のあるものにします。
各プールに対してserviceStatus、poolStatus、bandwidth、request rate、current session、new connectionの閾値を定義できます。同じ構造内でemail、SMS、WhatsApp、BiP、SNMP、UIのチャネル設定を指定できます。これにより重要なサービスはより積極的なアラームポリシーで、低重要度のサービスはより静かなポリシーで監視できます。通知挙動がプラットフォーム全体に単一型で適用されることはありません。
TR7はemail、SMS、WhatsApp、BiP、SNMP、Syslog、UIなど複数のチャネルをサポートする通知モデルを提供します。重要なインフライベントはSMSまたはSNMPでネットワーク管理システムへ、管理者サマリーはemailで、日常的な状態はUI経由で伝達できます。同じイベントを異なるチャネルへ異なる優先度で送信できます。この柔軟性は外部アラームマネージャーへの依存を軽減します。
NotificationTranslatorは、ディクショナリベースの翻訳ロジックで通知テキストを異なる言語で生成できます。一部の運用チームは現地言語で、国際チームはEnglishで通知を受け取れます。同じイベントを異なるユーザーへ異なる言語で伝達することが可能です。これは複数国にまたがる運用における誤解のリスクを軽減します。
poolDisabled、allBeDown、noBeGiven、beDown、beStateUnknown、beMaint、poolDown、poolInterfaceAbsent、zoneClosed、clusterIpBoth、clusterIpPossibleCollide、clusterIpSwitched、clusterIpNoneなど30+の状態キーが使用できます。これらのキーはアラームテキストをより説明的にします。オペレーターは単なる「サービス障害」メッセージを受け取るのではなく、問題の種類も把握できます。対応時間が短縮されます。
silentAtNightにより特定の通知を夜間にミュートできます。これはイベントが完全に消えることを意味しません。UIに表示され続けたり、朝のサマリーに含めたりできます。重要なイベントには別のチャネルポリシーを適用することで、本当に重要なアラームは依然として伝達できます。アラーム疲労を軽減しながら運用の可視性を保ちます。
notifyDaysBeforeCertificateExpiryフィールドにより、証明書の失効日の特定日数前に警告を生成できます。例えば30日前にemailまたはUI通知を送信できます。これにより証明書更新の運用が最終日に持ち越されることはありません。TLS中断を引き起こしかねない失念を早い段階で捕捉します。
Contact groupのメンバーはemailアドレス、SMS番号、ユーザータイプ情報で定義できます。通知は個別ユーザー、チームグループ、ユーザータイプへルーティングできます。このモデルは、オンコールチーム、SOC、SRE、管理者グループを個別にターゲットすることを容易にします。担当者の変更をチャネルポリシーを崩さずに管理できます。
SMTP host、port、authentication、username、password、TLSセキュリティ、証明書検証、sender name、sender address、cc、bcc、attachment、HTMLメッセージの設定を構成できます。email接続のtimeout値は10秒程度に保てます。この構造は組織の既存のメールリレーまたはSMTPインフラとの統合を容易にします。email通知はブランドおよびセキュリティポリシーに適合させられます。
アラームとnotificationのログは別々の名前でアーカイブできます。Zip圧縮と高圧縮レベルにより、過去のイベントを監査およびレビューのために保存できます。PCI、変更管理、インシデント後分析のプロセスで通知履歴を証拠として使用できます。ローカルの可視性を失うことなく、外部のアーカイブプロセスと併用できます。
NotificationTypeフィールドはA、N、Iのクラスでアラーム、notification、infoの区別を行います。この区別はイベントの重要度とユーザーへの提示方法にとって重要です。すべての情報メッセージがアラームのように振る舞うわけではなく、すべてのアラームが平凡な通知として消えるわけでもありません。UIと外部チャネルの挙動がこの分類から決まります。
BasicNotificationのpairIdフィールドは、同じイベントグループに属する通知を関連付けるために使用できます。例えばアラームのオープン、更新、クローズを同じイベントファミリー内で追跡できます。これはSIEMや監査側でイベントチェーンをまとめて確認することを容易にします。個別のメッセージではなく、イベントプロセス全体を分析できます。
通知システムは、status値、ログ名、圧縮、SMTPセキュリティ、クラスタIPステートマシンとともに運用されます。
プールstatus値はUNKNOWN=-1、OK=0、WARN=1、DISABLED=2、ERR=3、EVALUATING=4として分類されます。この数値モデルはアラーム評価とUI表示のための一貫した基盤を提供します。状態は単なるテキストとしてではなく、判断可能な値として扱われます。
アラームログはbasic-alarms、通知ログはbasic-notificationsという名前で保持できます。この区別は、イベントライフサイクルとユーザーへ伝達された通知を別々にレビューすることを可能にします。運用と監査のプロセスが異なるログタイプをそれぞれのニーズに応じて読み取れます。
アラームと通知のアーカイブはzip形式かつ高圧縮レベルで保持できます。これは長期保存コストを軽減します。監査のために過去の通知記録へより容易にアクセスできます。
`_lb.*`の下に30+の事前定義された状態キーが存在します。これらのキーは、プール、backend、interface、ゾーン、クラスタIPの挙動をより細かく説明するために使用されます。通知テキストと判断ロジックがこれらのキーを通じて充実します。
email送信における接続timeout値は10000 msとして構成できます。TLSセキュリティと証明書検証の挙動はユーザーが制御します。これにより組織のセキュリティ要件に応じたメールリレー統合が可能になります。
クラスタIP状態は別個のステートマシンで解釈されます。IPの到達不能、interface状態、潜在的な競合、ノード移行などの状態が、統合されたクラスタIP state値に変換できます。failoverアラームはこのコンテキストでより正確に生成されます。
低重要度のbackend downイベントが午前2時に発生したとき、silentAtNightがemail送信を停止できます。イベントはUIでアクティブなまま残り、朝のサマリーに含めることができます。これにより不要な夜間アラームを減らし、イベントが完全に消えることはありません。
運用チームはnotifyDaysBeforeCertificateExpiry値を30日に設定できます。証明書の有効期限が近づくと、システムがemailまたはUI通知を生成します。TLS中断を引き起こしかねない直前の更新リスクが軽減されます。
クラスタIPが別のノードへ移行すると、clusterIpSwitchedイベントを生成できます。このイベントは運用チームへSMS、SNMP、UI経由で伝達できます。failoverが発生したとき、チームはイベント後ではなく、イベントの瞬間に把握できます。
request rate、bandwidth、session、新規接続の閾値を超過すると、SNMP通知を生成できます。ネットワーク管理システムはこのイベントを自身のアラームダッシュボードに取り込みます。セキュリティチームとネットワーク運用チームが同じ閾値を共通の監視フローで確認できます。
アラームとnotificationのログを圧縮アーカイブとして保存できます。監査時には、どのイベントがいつ発生したか、どのチャネルが使用されたか、アラームがクローズされたかどうかを提示できます。通知履歴が運用の証拠へと変わります。
一部のチームが同じアラームを現地言語のemailで受け取る一方、国際運用チームはEnglishのメッセージを受け取れます。NotificationTranslatorがイベントテキストをユーザーの言語に応じて生成します。複数国にまたがる運用でアラームの誤解が軽減されます。
アラームライフサイクル、30+の状態キー、マルチチャネル、サイレント時間。お客様の環境でのライブセットアップでご紹介します。