はじめに
Oracle Cloud 上で作成したリソースの死活監視ってどんな具合にされていますか？ Oracle Cloud 標準機能の Monitoring, OMC, Mackerel, Zabbix などなど、いろいろな選択肢があります。Monitoring は、Oracle Cloud のサービス群と統合されており、簡単にアラート設定が出来ます。名前が一般用語で紛らわしいですが、「Monitoring」という名前のサービスです。アラート設定の通知先は、メール、Slack、Pagerduty、Webhook とよく使われているものが簡単に設定できます。運用していく中で、障害を検知するのは非常に重要な機能です。運用に組み込みやすい、Monitoring 機能を紹介していきます。
今回は、OCI Load Balancer のバックエンドに設定している Web Server 群の中で、1個でも Unhealthy (通信不可) となったものを検知して、自動的に Slack に通知する手順を紹介します。
LB 構成について
すでに次の構成が出来上がっている状態から、アラームの設定をしていきます。
- Load Balancer 1台
- Backend Webserver 2台 (Nginx) : HTTP 80 Port
Monitoring Service Metrics の確認
まず、Monitoring 機能でどういったメトリックが取得できるか見てみましょう。Monitoring > Service Metrics を選択します。
oci_lbaas を選択します。
表示された画面は、Tokyo Region 内の全ての Load Balancer のメトリックが表示されています。1 個の Load Balancer にフィルターをしたいので、Add を押します。
対象の Load Balancer の OCID を選択して、Done を押します。Load Balancer の名前では選択できないので、事前に OCID をメモっておく必要があります。
これで、指定した Load Balancer のたくさんの Metrics が確認できます。どれも便利そうですが、特に便利そうなものを太字にしています。
- Inbound Requests : リクエスト数
- Active Connections : コネクション数
- Active SSL Connections
- Bytes Received
- Bytes Sent
- Accepted Connections
- Handled Connections
- Failed SSL Handshakes : SSLハンドシェイクのエラー。証明書の有効期限切れを検知出来そう
- Accepted SSL Handshakes
- Failed Client SSL Cert Verifications
- HTTP Responses
- HTTP 200 Responses
- HTTP 2XX Responses
- HTTP 3XX Responses
- HTTP 4XX Responses : エラーがあまりにも多いと、何かがおかしいことが検知できそう
- HTTP 5XX Responses
- HTTP 502 Responses
- HTTP 504 Responses
- Backend Servers
- Unhealthy Backend Servers : Backend への通信が出来ないサーバーの数
- Average Response Time (HTTP Only)
- Average Response Time (TCP Only)
Slack Incoming Webhook の生成
次に、Slack へ通知するために、Incoming Webhook の URL を生成します。以下のURLを参考にどうぞ。
自分の場合はこんな感じです。
Notification
Slack へ通知するために、Notification の設定をしていきます。Notification を選択します。
Create Topic を押します。
Name や Description を適当に入れます。
Create Subscription を押します。
Protocol に Slack, URL に WebHook の URL を指定して、Create を押します。
PENDING となります。
Pending になったと同時に、Notification から確認メッセージが Slack に到着します。URL をクリックして確認してね、という内容です。
URL をクリックして、 Confirmed にします。
Alarm
ここまでの設定で、Slack へ通知が出来るようになりました。次に、実際のアラームの条件を作っていきます。
Create Alarm を押します。
各種パラメータを入れて、Save alarm を押します。
一番気にしたほうがいいのが、Alarm Body です。Slack へ通知されるメッセージの本文となるので、わかりやすい説明を入れましょう。自分の場合は、該当の Load Balancer の詳細画面 URL を埋め込んでいます。Slack から直接リンククリックで飛べるので、便利に使えます。
Sample です。URL の前後に半角空白を入れると、Slack の画面上でクリックがしやすいので、おすすめです。
ロードバランサー : test01 のバックエンドに、何かしらのエラー発生しています。こちらのリンクをご確認ください
https://console.us-ashburn-1.oraclecloud.com/load-balancer/load-balancers/ocid1.loadbalancer.oc1.ap-tokyo-1.aaaaaaaad2omcimsaanugevw2fesgcyxmvxtb2hj4g5zxmu62nzguazeudbq/metrics
アラームテスト
設定完了です。これで実際にアラームを起こすために、Backend Server の Nginx 停止してみます。
停止してから数分待つと、Slack に自動的にこのようなメッセージが通知されます。Notification からのメッセージとなるので、いろいろなメタデータを含めたメッセージになっています。
もし、更に見やすい形で整形したいときは、Oracle Functions という名前のサーバレスサービスを使って、コーディングしていくと出来ます。今回は取り上げませんので、もし興味があれば検索してみてください。
Slack 上の URLをクリックすることで、詳細画面を開きます。これで、検知から確認までの動線が楽になります。
