ガイド

アラートのモニタリング

このドキュメントでは、モニタリングダッシュボードで定義されているアラートの説明とアクション項目を示します。問題を修正できない場合は、ダッシュボードのスクリーンショットとログを添付して直接サポートチケットを提出することができます。

本ドキュメントのコンテンツ:

ビジネスクライアントダッシュボードアラート

重大なAPI障害のアラート

説明

contacts APIまたはmessages APIの成功率が低い

アクション項目

  1. contactsまたはmessages APIのリクエスト/秒パネルで、該当するAPIエラーコードを見つけます。
  2. エラーコードのドキュメントを確認します。
  3. CoreAppリクエスト/秒とDBクエリ/秒パネルを確認して、障害がCoreappの障害やデータベースの障害と関連しているかどうかを調べます。
  4. 詳しくは、CoreApp概要ダッシュボード(Node変数に問題の発生しているCoreappを代入)およびMySQL概要ダッシュボードを確認してください。

統計なしアラート

説明

モニタリングするためのデータが足りない

アクション項目

  1. Prometheusターゲットエンドポイント(http://your-monitoring-hostname:9090/targetsなど)にアクセスし、webstatsおよびappstatsのエンドポイントの状態がUPであることを確認します。
  2. PrometheusがWebappとの接続に失敗する場合、WADebugを実行してエラーをトラブルシューティングします。
  3. WebappおよびCoreappのコンテナが実行中の場合、.envファイルのWA_WEB_ENDPOINT、WA_WEB_USERNAME、およびWA_WEB_PASSWORDが有効かどうかを確認します。

Coreapp概要ダッシュボードのアラート

コールバック失敗アラート

説明

アプリ設定で指定されているWebhook URLにコールバックを送信する成功率が低い

アクション項目

  1. コールバックリクエスト/秒パネルから、該当するコールバック応答エラーコードを見つけます。
  2. Grepにより、Coreappログからnetwork errorを検索し、実際のエラーメッセージを確認します。
  3. 基になるエラーコードとメッセージ:
    • WebhookがCoreappから到達可能かどうかを確認します。
    • 通知処理後にWebhookが常にHTTPS 200 OK応答を返すかどうかを確認します。
    • Webhookが応答するのに長い時間がかかるかどうかを確認します。

保留中送信メッセージが高いアラート

説明

送信メッセージキューがほとんど満杯状態であり、まもなくAPIリクエストがSystem overloaded error (1016)で失敗します

アクション項目

  1. 送信メッセージパネル行から、異常なトラフィック増加がないかを確認します。異常なトラフィック増加がある場合、アラートがクリアされるまで、トラフィック負荷を減らすようにします。
  2. 最近データベースが別のリージョンにフェールオーバーしたことがあるかを確認します。WhatsApp Business APIは、クロスリージョンの遅延のため、負荷に追いつけないかもしれません。
  3. 時間とともにゆっくりと送信メッセージのキューが一杯になっている場合は、不具合を報告してください。
  4. 単一のWhatsApp Business APIクライアントでは負荷要件を満たすことができない場合、マルチコネクトを設定して、もっと高い負荷でも持ちこたえられるようにしてください。

キューコールバックが高いアラート

説明

コールバックキューがほとんど満杯状態であり、まもなくAPIリクエストがSystem overloaded error (1016)で失敗します

アクション項目

  1. コールバックエラー速度パネルを見て、コールバックが正常に処理されているかどうかを確認します。
  2. Webhookのためのコールバック処理時間を削減します。
  3. アプリ設定でmax_concurrent_requestsを構成し、実行中のコールバックリクエスト数を増やします(デフォルトでは6)。

マシン概要ダッシュボードのアラート

CPU使用量が高いアラート

説明

マシンのCPU使用状況が高すぎる

アクション項目

  1. CPU詳細使用率パネルを見て、使用状況分布を調べます。
  2. マシン上でatopまたはtopを実行し、CPUを最も消費しているプロセスを見つけます。また、コンテナ概要ダッシュボードで、Machine変数に問題の発生しているマシンを代入することにより、コンテナレベルのCPU指標を確認します。
  3. Webapp、Coreapp、データベースのいずれかがCPUのほとんどを消費している場合、それをホスティングするためのより強力なマシンを見つけてください。高可用性/マルチコネクトモードの場合、WebappコンテナとCoreappコンテナが同じマシン上で実行されているなら、それらを別個のマシンに移すことを試みてください。

ディスク使用量が高いアラート

説明

マシンの機器のディスク使用状況が高すぎる

アクション項目

  1. 機器でduコマンドとdfコマンドを実行してディスク使用状況を分析します。また、コンテナ概要ダッシュボードで、Machine変数に問題の発生しているマシンを代入することにより、コンテナレベルのディスク指標を確認します。
  2. メディアファイルやログがある場合、機器上で不必要にスペースを消費するデータを消去し、古いデータを定期的にクリーンアップするためのcronジョブを設定します。

メモリ使用率が高いアラート

説明

マシンのメモリ使用率が高すぎる

アクション項目

  1. メモリ詳細パネルを見て、使用率分布を調べます。
  2. マシン上でatopまたはtopを実行し、最もメモリを消費しているプロセスを見つけます。また、コンテナ概要ダッシュボードで、Machine変数に問題の発生しているマシンを代入することにより、コンテナレベルのメモリ指標を確認します。
  3. Webapp、Coreapp、データベースのいずれかがメモリのほとんどを消費している場合、それをホスティングするためのより強力なマシンを見つけてください。
  4. 時間とともにゆっくりとCoreappのメモリ使用が増加している場合、メモリリークが原因の可能性があります。不具合を報告してください。Coreappを再起動して、メモリの問題が緩和するようにします。

オープンファイルが多すぎるアラート

説明

マシンのファイルデスクリプターがまもなく不足する

アクション項目

  1. ファイルデスクリプターパネルを見て、オープンファイルの上限を確認します。
  2. /etc/sysctl.confファイルでもっと高い値(fs.file-max = 600000など)を構成し、オープンファイルの上限を引き上げます。
  3. sysctl -pを実行して変更内容を適用します。

MySQL概要ダッシュボードのアラート

DB接続が多すぎるアラート

説明

DB接続プールの使用率が高く、新しいDBリクエストがまもなくToo many connectionsエラーで失敗する可能性があります

アクション項目

  1. 接続パネルを見て、現在の接続上限を調べます。
  2. my.cnfのMySQLシステム変数max_connections (デフォルトでは151)を上げて、MySQLサーバーを再起動します。詳しくは、「MySQLサーバーシステム変数」のドキュメントをご覧ください。
  3. AWS RDSの場合、より大規模なRDSインスタンスに移行することが必要です。詳しくは、AWSデプロイメントの詳細のRDSインスタンスのサイズ変更セクションをご覧ください。

Webapp概要ダッシュボードのアラート

HTTPサーバー保留中接続が高いアラート

説明

Webapp内部HTTPサーバー接続キューが満杯に近い

アクション項目

  1. Businessクライアントダッシュボードを見て、異常なAPIトラフィックがあるかどうか、またAPIリクエストの遅延値が高くなっていないかどうかを確認します。
  2. Webappログから詳細を確認します。
  3. Webapp CPU使用率が高くなっているかどうか確認し、もしそうなら、Webappのためのより強力なマシンを見つけてください。