こんにちは。CI事業部の川瀬です。
今回は運用で役立つAlert通知について説明します。Alertと言えば、キャパシティ管理でCPUの利用率が70％を超えたら通知、5分回にXX回以上のエラーが発生したら通知ということを思い浮かべる人が多いと思います。勿論、MuleSoftのAPI Platformでもいろいろな通知方法が提供されています。このいろいろという所が実は悩ましいです。
では、実際に機能を見ていきましょう。
Runtime Mangerによる通知
ここでは、以下の通知が提供されています。
Deployment failed (デプロイに失敗しました)
Deployment success (デプロイメントに成功しました)
Worker not responding (ワーカーが応答していません)
実際の設定画面はこんな感じです。
API Mangerによる通知
CPU Utilization (CPU 使用率)
Memory Utilization (メモリ使用量)
Thread Count (スレッド数)
Message count (メッセージ数)
Message error count (メッセージエラー数)
Message response time (メッセージ応答時間)
実際の設定画面はこんな感じです。
Monitoringによる通知
API を管理する 1 つ以上のポリシーで違反が発生する。
要求数
ユーザが指定された期間で許可されている回数を超えて API にアクセスを要求する。応答コード
API が要求を受信したときに、400、401、403、404、408、500、502、503 のいずれかの HTTP コードを返す。
実際の設定画面はこんな感じです。
Monitoringのカスタムダッシュボードでの通知
カスタムダッシュボードで設定したメトリクスに応じて設定できる項目が変わります。
実際の設定画面はこんな感じです。
MonitoringのFunction Monitoringでの通知
期待するHTTPレスポンスを定期的に監視することができます。例えば、死活監視を設定することができます。
実際の設定画面はこんな感じです。
Runtime ManagerによるAlert通知はどのライセンス形態でも使用できますが、その他のAlert通知はライセンス形態により使用できない場合があるので注意してください。
いろいろな個所でAlert通知ができるので、最初のうちは混乱してしまうかもしれませんが、ライセンスに応じでできることがどんどんできることが増えていくと考えればよいです。
ここでクイズです。Function Monitoringで死活監視ができますが、Runtime ManagerのWorker not respondingを使用しても死活監視ができます。どちらを使えばいいでしょうか？
即時性を求めるならFunction Monitoringです。Runtime ManagerのWorker not respondingによる通知は、若干、時間がかかります。ただし、Function Monitoringではバッチ系のアプリに対し死活監視ができません。その場合は、Runtime ManagerのWorker not respondingを使うしかありません。
