Oracle Cloud Infrastructure（OCI）では、サーバーや各種クラウドリソースの状態を監視し、異常が発生したときに管理者へ通知する仕組みを構築できます。代表的なのが、MonitoringサービスのAlarms（アラーム）とNotifications（通知）を組み合わせる方法です。
この2つは似た機能に見えますが、役割は異なります。基本的にはAlarmsがメトリックを評価して異常状態を検知し、Notificationsがメールなどの宛先へメッセージを届けます。ここではOCIにおけるAlarmsとNotificationsの関係、設定の考え方、具体例、通知されない場合の確認ポイントまで整理します。
OCIではAlarmsとNotificationsを使って異常検知を通知できる
OCI MonitoringにはMetricsとAlarmsの機能があり、OCIリソースなどから送られるメトリックを監視できます。Oracleの公式ドキュメントでも、Alarmsはメトリックが指定したトリガー条件を満たした場合に通知するための機能として説明されています。
たとえばComputeインスタンスのCPU使用率を監視し、一定値を超えた状態が続いた場合にAlarmsをFIRING状態へ変化させ、そのアラームメッセージをNotificationsのTopicへ送る、といった構成が可能です。
つまり、Alarmsが異常を判断する部分、Notificationsがその情報を届ける部分と考えると理解しやすいでしょう。Oracle公式のMonitoring概要は[参照]から確認できます。
AlarmsとNotificationsの役割の違い
OCIで監視を設定するときは、AlarmsとNotificationsを同じものとして考えないことが重要です。それぞれを簡単に整理すると次のようになります。
| 機能 | 主な役割 | 具体例 |
|---|---|---|
| Metrics | リソースの状態を数値として取得 | CPU使用率など |
| Alarms | メトリックを条件に従って評価 | CPU使用率が80％を超えたか判定 |
| Notifications | メッセージを購読先へ配信 | メール、SMS、Slack、HTTPSなどへ通知 |
Notificationsは、Topic（トピック）とSubscription（サブスクリプション）を利用するPublish-Subscribe型のサービスです。Topicへメッセージが公開されると、そのTopicに設定されたSubscriptionへメッセージが配信されます。
そのため、Notifications自体がCPU使用率などを監視して異常判定をするというより、Alarmsなどから受け取ったメッセージを指定した通知先へ届ける役割と理解するのが適切です。Notificationsの仕組みについてはOracle公式ドキュメント[参照]でも確認できます。
AlarmsからNotificationsへ通知する基本的な流れ
一般的な構成は、監視対象 → Metrics → Alarm → Notifications Topic → Subscription → 管理者という流れになります。
まず監視対象となるOCIリソースからMonitoringへメトリックが送られます。次にAlarmが設定された条件に基づいてメトリックを評価します。条件を満たしてAlarmがFIRING状態になると、設定されたNotificationsのTopicへアラームメッセージが送られます。
TopicにメールアドレスなどのSubscriptionを登録しておけば、その通知を担当者が受け取れるようになります。AlarmではNotificationsだけでなくStreamingを通知先として使用する構成も可能です。
CPU使用率を監視する場合の具体例
たとえばOCI Computeインスタンスについて、CPU負荷の異常を検知したいケースを考えてみます。MonitoringではComputeインスタンスが出力するCPU使用率などのメトリックを利用できます。
Alarm側では、対象となるメトリック、統計方法、評価間隔、しきい値などを設定します。たとえば「CPU使用率が一定の基準を上回った場合」のような条件を定義し、その状態が指定時間継続した場合にAlarmをFIRINGにする構成が考えられます。
そのAlarmの通知先としてNotificationsのTopicを指定し、Topicに運用担当者のメールアドレスをSubscriptionとして登録します。これにより、CPU負荷上昇 → Alarm発火 → Topicへメッセージ送信 → メール受信という監視通知を構築できます。Alarm作成方法の詳細はOracle公式ドキュメント[参照]に掲載されています。
Notificationsではメール以外にも通知できる
Notificationsのメリットは、通知先をメールだけに限定する必要がないことです。OCIの公式ドキュメントでは、Alarmの通知先となるTopicのSubscriptionとして、Email、Function、HTTPS、PagerDuty、Slack、SMSなどを設定できます。
たとえば小規模なシステムなら担当者のメールアドレスへ通知し、チーム運用ならSlackへ通知するといった使い分けができます。さらにHTTPSエンドポイントやOracle Functionsを利用すれば、異常発生後の処理を自動化する構成も検討できます。
AlarmでNotificationsのTopicを通知先に指定する具体的な方法については、Oracle公式ドキュメント[参照]が参考になります。
設定しても通知されない場合の確認ポイント
Alarmを作成したのにメールが届かない場合は、AlarmだけでなくNotifications側まで確認する必要があります。特にメールSubscriptionでは、登録後の確認手続きが完了しているかを確認しましょう。
また、Alarmが有効になっているか、監視対象のメトリックが実際に取得できているか、Alarmの条件が想定通りになっているか、正しいTopicが通知先として設定されているかも確認します。IAMポリシーによって必要な操作権限が付与されていることも重要です。
テスト時には、実際に異常が起きるまで待つのではなく、検証用として安全に到達できるしきい値を設定し、AlarmがFIRINGへ遷移して通知が届くところまで確認すると運用開始後のトラブルを減らせます。なお、テスト終了後は本番用のしきい値へ戻すことを忘れないようにします。
Alarmsは復旧時の通知にも利用できる
Alarmは異常発生時だけを知らせる仕組みではありません。OCI MonitoringではAlarmがOKからFIRINGへ変わった場合だけでなく、FIRINGからOKへ戻った場合などにもメッセージが送信されます。
また、FIRING状態が継続している場合に繰り返し通知する設定も利用できます。そのため「異常を検知したこと」だけでなく、「異常が継続していること」「正常状態へ復旧したこと」まで運用担当者が把握できる監視設計が可能です。
ただし通知を過剰に設定すると大量のアラートによって重要な異常を見落とす、いわゆるアラート疲れにつながります。重要度に応じてしきい値、継続時間、通知先、繰り返し通知などを調整することが大切です。
まとめ
Oracle Cloud Infrastructureでは、MonitoringのAlarmsとNotificationsを組み合わせて、メトリックの異常検知から担当者への通知までを構築できます。Alarmsが監視条件を評価し、NotificationsがTopicとSubscriptionを通じてメッセージを配信するという役割分担です。
基本的な構成は「Metrics → Alarms → Notifications Topic → Subscription」です。ComputeのCPU使用率などを監視して、しきい値を超えたらメールやSlackなどへ通知するといった運用ができます。
OCIの仕様やConsole画面は変更される可能性があるため、実際に設定するときはOracle Cloud Infrastructureの最新公式ドキュメントも確認しながら進めると安全です。
コメント