AppDynamicsのエージェントの可用性アラートによるサービス停止の防止

はじめに

このドキュメントでは、AppDynamicsでエージェント可用性アラートを設定し、問題をトラブルシューティングする方法について説明します。

前提条件

要件

• 可用性メトリックをコントローラに報告するJava/マシン/データベースエージェント。
• ヒースルールとポリシーを作成する権限。
• AppDynamics Controller （SaaSまたはオンプレミス）。

使用するコンポーネント

• AppDynamicsコントローラー

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

デジタルファーストの環境では、中断のないアプリケーションパフォーマンスが、ユーザの満足度だけでなく、ビジネスの継続性とレピュテーションにも不可欠です。AppDynamicsは、スタックの隅々まで重要なテレメトリを収集することで、強力な監視機能を提供します。しかし、この可視性を担当するエージェントが暗くなるとどうなりますか。エージェントの停止をタイムリーに検出しなければ、監視能力が低下し、新たに発生する問題や停止の可能性が見えなくなります。

問題の説明

AppDynamicsエージェント（アプリケーションエージェントまたはマシンエージェント）がレポートを停止すると、アプリケーションの状態、パフォーマンス、およびインフラストラクチャのステータスに関するリアルタイムの情報が失われます。この盲点は、エージェントのクラッシュ、不適切な設定、ネットワーク障害、またはリソースの枯渇によって発生する可能性があります。その結果、次のような大きな影響が生じます。

• 監視データの損失：監視データにギャップがあると、パフォーマンスや可用性の問題をプロアクティブに検出、診断、解決する機能が失われ、お客様の環境に重大な死角が残ります。
• インシデント対応の遅れ：タイムリーなアラートがなければ、サービスの停止や品質低下はエンドユーザに影響を与えるまでは気付かれず続くことがあり、ダウンタイムの長期化や問題解決の平均時間の延長につながります。
• コンプライアンスと監査の脆弱性：不完全なモニタリング記録は、法規制の遵守を妨げ、監査の準備状況を示すことが困難になるため、組織が処罰される可能性があります。
• ビジネスおよび顧客への影響：検出されない停止やパフォーマンスの問題は、ユーザエクスペリエンスを低下させ、信頼を損ない、組織の評判に悪影響を与え、直接的な収益損失につながる可能性があります。

エージェントの可視性の重要性

1. エンドツーエンドの可視性の維持：

エージェントの可用性に関するアラートにより、エージェントがレポートを停止した場合に即座に通知を受け取ることができるため、重大なギャップが生じる前にモニタリングを再開できます。これは、分散システム全体でエンドツーエンドの可観測性を維持するための基盤となります。

2. プロアクティブなインシデント管理：

自動アラートにより、チームは監視ギャップがビジネスに影響を与える停止にエスカレートする前に対応できます。早期検出により、迅速な修復とダウンタイムの最小化を実現します。

3. コンプライアンスとガバナンスのサポート：

コンプライアンスのために継続的なモニタリングが必要になることがよくあります。エージェント可用性アラートは、完全な監視レコードを維持し、運用標準への準拠を実証するのに役立ちます。

4. 信頼性の高い拡張：

環境の規模や複雑さが増すにつれ、エージェントを手動でチェックすることが現実的ではなくなります。エージェントの可用性の自動アラートにより、規模に応じた監視が可能になり、すべてのノードとサービスのギャップが明らかになります。

5. 誤検出の削減：

AppDynamicsを使用すると、正常性ルールを微調整し、修飾子（時間枠を超えたSUMや値など）を使用して、一時的な切断や短いネットワークの問題による不要なアラートを回避できます。これにより、実際の観察可能性のギャップが発生したときにのみアラートが通知されるようになります。

設定

AppDynamicsでエージェントの可用性アラートを設定するには、正常性ルールの作成、アクションの定義、ポリシーとのリンクという3つの主要な手順を実行する必要があります。

手順1：正常性ルールの作成

• AppDynamicsコントローラーUIに移動します。
• Alert & Respondに移動して、Health Rulesを選択します。
• 新しい正常性ルールを追加するには、+ボタンをクリックします。
• ルールに名前を付けます（Agent Down Alert - BookHouzeServiceなど）。

• 「影響を受けるエンティティ」セクションで、監視するノードまたは階層を選択します。
  
  
• Critical Criteriaセクションで、メトリックパスを設定します。
• App Agentの場合：Agent|App|Availability
• マシンエージェント：ハードウェアリソース|マシン|可用性
• データベースエージェント： DB|KPI|DBの可用性

（Metrics Browserを使用してこれらのパスを表示および確認します）。

• 値が1未満の場合にトリガーする条件を設定します(< 1)。 これは、エージェントが報告していない場合にアラートが発生することを意味します。
• エージェントがメトリックの送信を完全に停止したケースを検出するには、Evaluate to true on no dataオプションにCriticalが設定されていることを確認します。
  
  
  

ヒント：アプリケーションでアイドル期間（トラフィックがない）が発生すると、エージェントがアンロードされてダウンしているように見える場合があります。誤検出を避けるために、アプリケーションのアイドルタイムアウト設定を調整するか、または正常性ルールの評価ウィンドウを微調整することを検討してください。

ステップ2：アクションの作成

• Alert & Respond > Actionsの順に移動します。
• 電子メール通知の送信やWebフックの呼び出しなどのアクションを作成します。
  • アラートの受信者または統合エンドポイントを指定します。
    
    
    

    

ステップ3：ポリシーの作成

• Alert & Respond > Policiesの順に移動します。
• 新しいポリシーを作成し、作成した正常性ルールを選択します。
  
  
• このポリシーにアクションを割り当てます。
  
  
  

エージェントがレポートを停止するたびに、AppDynamicsが自動的にチームに通知するため、迅速な調査と修復が可能になります。

確認

手順1：正常性ルールの評価状態の確認

• 「Health Rules」に移動します。
  AppDynamics ControllerでAlert & Respond > Health Rulesに移動します。
• ルールの検索：
  リストからエージェントの可用性の正常性ルールを探します。
• ステータス インジケータ:
  ルールの横にあるステータスアイコンまたは評価サマリーを探します。緑色のチェックマークまたはOKステータスは、評価されていることを示します。警告またはエラーは、設定に問題があることを示します。
  
  

ステップ2：メトリック・ブラウザの使用

• メトリックブラウザを開く：
  Monitor > Metric Browserの順に選択します。
• アベイラビリティメトリックの検索：
  ターゲット・ノードまたは階層のエージェント|アプリケーション|可用性またはエージェント|マシン|可用性にドリルダウンします。

ステップ3：エージェント停止シナリオのシミュレーション

• エージェントを停止します。
  テストノードでAppDynamicsエージェントサービスを一時的に停止します。
• 評価の待機：
  正常性ルールの評価ウィンドウが経過するまで十分な時間を与えます。
  
  

• アラートのチェック：
  ヘルスルール違反がUIに表示されるかどうか、および設定したアクション（電子メール、Webフックなど）がトリガーされるかどうかを確認します。  
  
  

ステップ 4：アラートおよび応答ダッシュボードの確認

• Alert & Respond > Actions and Policiesの順に移動します。
  正常性ルールにリンクされているアクションとポリシーに、最近のアクティビティまたはトリガーログが表示されていることを確認します。
  

ステップ5：通知配信の確認

• 電子メール/Webフックを確認します。
  受信トレイまたはエンドポイントでアラートを受信していることを確認します。
• アラートの内容の確認：
  アラートメッセージは、正しい正常性ルールと影響を受けるノード/層を参照する必要があります。
  
  
  

チェックリストの検証：
√ Health RuleのステータスがOKであるか、アクティブに評価されています。

√最近の正常性ルールの評価と（該当する場合は）違反がUIに表示されます。

メトリック・ブラウザ√、可用性メトリックのリアルタイム・データを表示します。

√シミュレートされたエージェントのダウンシナリオにより、ヘルスルール違反とアラートがトリガーされます。

√アラートは、設定された通知チャネルを介して受信されます。

これらの検証手順により、エージェントの可用性アラートが適切に設定されるだけでなく、アクティブに監視され、エージェントがオフラインになった際に通知を受け取る準備ができていることが確認されます。この簡単なルーチンにより、予期しない死角のモニタリングを防止し、全体的な監視戦略を強化できます。

トラブルシュート

最適な設定を行っても、予期した場合にアラートが発生しない場合があります。AppDynamicsでエージェントの可用性アラートが機能していない場合のトラブルシューティングに役立つ実用的なチェックリストを次に示します。

役立つ情報：テストの正常性ルールとポリシーを非実稼働環境に保持することで、設定の変更やアップグレードの後でもアラート動作を安全に実験および検証できます。

これらのトラブルシューティング手順は、AppDynamicsのエージェントの可用性アラートに関するほとんどの問題を迅速に特定して解決するのに役立ちます。これにより、監視の信頼性を維持し、チームが停止を回避できます。

結論

エージェントの可用性アラートは、AppDynamicsで信頼性の高い監視を行うための基盤です。エージェントの停止をプロアクティブに検出して対応することにより、継続的な可視性を維持し、インシデントへの対応を加速して、検出されない停止のリスクからビジネスを保護します。1秒おきにダウンタイムが発生する世界では、これらのアラートによって、チームは停止時間を回避し、ユーザが期待する復元力のあるデジタルエクスペリエンスを提供できます。

さらなる支援が必要

質問がある場合や問題が発生している場合は、AppDynamicsサポートに連絡して、エラーメッセージ、構成情報、関連ログなどの詳細を含めることで、トラブルシューティングを迅速に進めることができます。

関連情報

• 正常性ルール
• [アクション（Actions）]
• ポリシー