OCIも使いなれて、さまざま管理をするようになりました。
管理する上で、重要なのが、インシデントの監視ですかね。
例えば、IPSecで、VPNとかしていますが、この回線の接続性を監視しておかないと、切断されちゃっても気づかないと、やばいことになる場合があります。
他にも、サーバーのダウン的な監視とかですね。
そこで、とりあえず、問題があった場合、メール通知する仕組みが必要となります。
OCIで、そういった通知の定義を行うには、開発者サービス -> アプリケーション統合 -> 通知 で構築します。
ここには、トピックとサブスクリプションなんてのを作成するのですが、初見では、意味わからんです。
トピックとは、通知する為の名前定義です。
なんか問題とかがあったら、このトピックに通知してねの、トピックの名前です。
サブスクリプションとは、通知する手段です。
例えば、メールに通知してねとか、Functionをたたけとか、Slackとか、HTTPSとかです。※SMSがありますが、限定的な通知になるので、ご注意を
ここは、そんなに難しくないので、Webコンソールで適当に構築は出来ると思います。
さーてと、次が本命の監視です。
監視および管理 -> モニタリング -> アラーム定義 で構築します。
まず、IPSec VPNの監視を構築してみましょう。
アラーム名と重大度は、適当に決めて下さい。
ポイントだけ、記述しますよ。
メトリックの説明
メトリック・ネームスペース:oci_vpn
メトリック名:TunnelState
間隔:5分
統計:Sum
メトリック・ディメンション
ディメンション名:parentResourceId
ディメンション値:[IPSec VPN の OCIDを選択する]
トリガー・ルール
演算子:次より小さい
値:4
トリガー遅延分数:1
アラーム通知の定義
宛先サービス:通知
コンパートメント:[構築したトピックのコンパートメントを選択]
トピック:[構築したトピックを選択]
で、構築したアラーム定義を有効化すれば監視を開始します。
トリガールールの4の意味は、監視間隔5分毎に対して1分間隔で、正常であれば +1(Sum)すると最大5になるので、これを閾値に下回ればアラートということにしています。
理解出来ましたかね。要するに、アラート定義の本質は、閾値を定義して、監視間隔中に、対象値(トリガーにより変化)が閾値と比較して、どうなればアラート状態かを定義する物となります。
今回は、シンプルにSumとしたので、正常であれば1分毎に+1加算することになります。となると、5分間隔で測れば、5になることが通常状態と定義しました。
そして、5分毎に閾値と比較して下回れば、アウトとし、トピックに通知するように定義したのです。
さーてと、VPNの接続状態は、監視出来ましたが、サーバーの状態は、どうすんだってことですよね。
oci_compute関連のメトリックでも監視しとけば良いかと思いますが、そんなことをしても、本質的なサービスの異常は、いまいち監視出来ないのですよ。
ping的なICMP監視も、ちょっとねー
やっぱり、TCPポートとかの監視をしないと意味無しですよね。
ということで、編み出したのが、ネットワークロードバランサーのバックエンドによる監視です。
ネットワークロードバランサーって、コスト的に激安なので、使い易いですよね。本来は、ポートに接続された通信を良い感じで、バックエンドにバランシングする物ですが、バックエンドに対してヘルスチェックする機能を備えています。
このヘルスチェックが、それなりに使えるので、これを使って監視を行うことで、より本質的なサービス監視を行えます。
まー、あくまでも、簡易的なポートチェックになりますが、Pingとかより、だいぶましです。
ネットワークロードバランサーは、サーヒズ制限で、最大2となっているので、色々と監視したい人は、上限の修正を依頼しておきましょう。
ネットワークロードバランサーの構築方法は、他のサイトで説明されているでしょうから、それを参照してください。
重要なのは、バックエンドのヘルスチェックですので、ここを理解しておいて下さい。
それと、ヘルスチェックだけ使用するからといって、リスナーを構築せずに長く使うと、ネットワークロードバランサーが死んじゃうようですので、必ずリスナーも構築するようにして下さい。 <- Oracleさん、修正して下さいね。
ということで、このネットワークロードバランサーのバックエンド状態をアラーム定義することで監視することが可能です。
メトリックの説明
メトリック・ネームスペース:oci_nlb
メトリック名:UnhealthyBackends
間隔:5分
統計:Sum
メトリック・ディメンション
ディメンション名:resourceName
ディメンション値:[対象NLBを選択する]
トリガー・ルール
演算子:次より大きい
値:1
トリガー遅延分数:1
アラーム通知の定義
宛先サービス:通知
コンパートメント:[構築したトピックのコンパートメントを選択]
トピック:[構築したトピックを選択]
今回は、異常を加算する方式にしたので、閾値が1となっています。シンプルに、ちょっとでも異常を検知すれば、通知するようにしてみました。
この辺りの加減は、サービスの重要度とかで決めましょうね。
では、しっかり、インシデント監視して、早急な対応を担当者になげつけてやりましょう。