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