問題切り分け支援およびアナリスト

問題切り分け支援は、エンジンでありストーリー ジェネレータです。 問題切り分け支援は、ビジーなシステム内で発生した最も意味のあるイベントを識別し、これらのイベントに関するわかりやすい情報(ストーリー)を提供します。 これらのストーリーは、見出し付きで問題または異常として表示されます。 問題切り分け支援が生成するストーリーは信頼性が高く、インテリジェントであるため、ユーザは監視するドメインの状態を完全に把握できます。
apmdevops106
問題切り分け支援は、エンジンでありストーリー ジェネレータです。 問題切り分け支援は、ビジーなシステム内で発生した最も意味のあるイベントを識別し、これらのイベントに関するわかりやすい情報(ストーリー)を提供します。 これらのストーリーは、見出し付きで問題または異常として表示されます。 問題切り分け支援が生成するストーリーは信頼性が高く、インテリジェントであるため、ユーザは監視するドメインの状態を完全に把握できます。
問題切り分け支援の動作の仕組み
問題切り分け支援は、システム内のイベントに関する問題と異常を作成します。 問題切り分け支援は、以下のイベント タイプに対応します。
  • ストール
  • エラー
  • アラート
  • 不安定な応答時間
問題および異常は、1 つ以上のイベントの側面を説明するものです。 たとえば、側面には次のものがあります。
  • WHAT は、疑わしい原因(WHY)を含む、イベントのサマリを提供します。 この問題は、Experience ビューおよび分析ノートブックの問題および異常に対して見出しとして表示されます。
  • WHERE は、イベントが発生した場所を特定します。通常は、ホストおよびエージェント名などの情報です。 WHERE は、利用可能な場合、より詳細な情報が含まれる場合があります。
  • WHO は、影響を受ける、または影響を受ける可能性があるトランザクションを特定します。 この要素は、影響を受けるトランザクションの数も特定します。
  • WHEN は、イベントの発生(通常は、ストール イベント、エラー イベント、または不安定が発生し終了する時間)を記録します。
  • WHY は、イベントが発生した理由を説明します。 たとえば、以下のステートメントは、高いコール率の問題について説明します。
    Potential high call ratio from ViewOrders|service to 138.0.0.1_7080|getService 2 in the order of 214980
以下の図および対応する手順は、問題切り分け支援の動作の仕組みについて説明します。
問題切り分け支援アーキテクチャ
問題切り分け支援アーキテクチャ
  1. APM システム内のイベントは、差異強度、エラー、ストール、APM アラートなどとして発生します。 イベントには、問題発生の原因の可能性があるものが含まれます。
  2. イベント ジェネレータは、異なるソースからイベント データを収集し、データをイベント プロセッサに送信します。
  3. イベント コンテキスチュアライザは、クラスタ全体で、ジェネレータからイベントを受信し、イベントを処理し、関連イベントがあればコンテキストに収集します。 コンテキスト情報には、左端のコンポーネントの潜在的な影響、およびコンポーネントを通過するすべてのトランザクションが含まれます。
    コンテキスチュアライザは、このコンテキスト情報をエディタに渡します。
  4. エディタは、より詳細な分析を行うために、異なるコンテキストを追跡し、特定のイベント コンテキストごとに 1 つのレポーターを割り当てます。
  5. レポーターは、システムで利用可能な異なるタイプのアナリストを認識し、各アナリストを使用してコンテキストを実行します。 アナリストは、イベント タイプ、パターン、および潜在的な影響のコンテキストを分析し、次に、各アナリストがステートメントを作成します。 アナリストは連携して、ステートメントからのエビデンスの記録およびストーリーの作成を行い、次に、データを APM データベースに格納します。 ストーリーが 62 日よりも古いものの場合、データベースからパージされます。
  6. ストーリーは、Experience ビューおよび分析ノートブック上の問題および異常として表示されます。
注:
Enterprise Manager は、問題切り分け支援コンポーネントに関するメトリックを生成および収集します。 これらのサポータビリティ メトリックは、Enterprise Manager の稼働状況を評価する際に役立ちます。
アナリスト
アナリストは、病気のある特定のクラスを診断する方法を把握している医療専門家のようなものです。 問題切り分け支援は、アナリストの以下の主要なタイプを使用します。 アナリストの各タイプには、他の特定のアナリストが含まれています。
イベント アナリスト
は、特定のイベント タイプを検索して、エビデンスとなるイベント ステートメントを作成します。 イベント アナリストの例を以下に示します。
  • 差異分析アナリストは、差異強度をチェックします。
  • エラー アナリストは、コンテキスト内のエラー イベントをチェックします。
  • リソース イベント アナリストは、システム リソースのアラート イベントを監視します。
パターン アナリスト
は、コンテキスト内の特定のパターンを検索し、パターン ステートメントを作成します。 これらのステートメントは、ストーリー サマリの一部です。 パターン アナリストの例を以下に示します。
  • デフォルトのアナリストは、コンテキスト内の最大深度コンポーネントを特定します(関係マップごとに)。 デフォルトのアナリストは、「ゾーン識別子」とも呼ばれます。
  • 高コール率アナリストは特定のコンテキスト内の最大深度コンポーネントを検索します(関係マップごとに)。 このアナリストは、コンポーネントが任意のバックエンド タイプ ノードを通常ではない回数コールするかどうかを確認します。
アナリストからのステートメントは、ストーリー サマリになります。
ストーリーの例: デフォルト アナリスト(ゾーン識別子)
この例では、デフォルト アナリスト(またはゾーン識別子)ストーリーについて説明します。 このアナリストは、他の特定のアナリストがパターンを検出するかどうかに関係なく、常に動作します。 デフォルト アナリストは、可能性の高いゾーンを識別します。 ゾーンは、フロントエンド、バックエンド、またはそれらの間の内部コンポーネントになる場合があります。 たとえば、デフォルト アナリストからのステートメントはこの見出しのようになります。
Problem isolated to {type} {component}
{type} は、フロントエンド、ビジネス トランザクション、内部コンポーネント、またはバックエンドになる場合があります。
{component} は、ゾーンに関係するコンポーネント名です。
たとえば、システム内で以下のコンポーネントを考慮します。
  • フロントエンド F
  • バックエンド B
  • 内部コンポーネント M
これらのコンポーネントはすべて、ビジネス トランザクションを所有することで関連付けられます: F->M->B。
以下のイベント シーケンスは、トランザクション フローで発生します。
  1. フロントエンド F のみに関連付けられているイベントが発生します。
    デフォルト アナリスト ストーリーは、フロントエンド F に分離されているイベントをレポートします。
  2. 内部コンポーネント M のイベントが発生します。
    これらの 2 つのイベントは同じトランザクション フロー内にあるため、デフォルト アナリストはこれらを関連付けます。 アナリストの状態: 内部コンポーネント M から分離された問題
  3. バックエンド B に対してイベントが発生します。
    デフォルト アナリストは、3 つのイベントと状態をすべて組み合わせます: 問題はバックエンド B に特定されました
Experience ビューおよび分析ノートブック上の異常および問題の見出しを参照します。この見出しには、次のようなタイプおよびコンポーネントが含まれます。
Problem isolated to internal component AxisServlet|service
この見出しは、デフォルト アナリスト ストーリーについて説明します。 たとえば、詳細に、ACME アプリのフロントエンドおよびバックエンド トランザクション間のゾーンにある問題が記述される場合があります。
ストーリーの例: 高コール率
この例では、問題切り分け支援が高コール率ストーリーをレポートする方法について説明します。 高コール率ストーリーは、クライアント コンポーネントが発行するそれ自体のトランザクションが多すぎる場合に発生し、その発生元の重複するトランザクションは停止します。 たとえば、呼び出し元から呼び出し先の率が、結果として、呼び出し元では数が少なく、呼び出し先で数が多い、たとえば、1:20 になります。 この数は、呼び出し元への 1 つのコールが結果として呼び出し先への 20 のコールになることを示しています。 パターン アナリストは、データベースまたは Web サービス クライアントなどのバックエンド ノード/コンポーネントの高コール率ストーリーをレポートします。
以下の問題の状況は、高コール率の問題を示している可能性があります。
  • コール スタック内のコンポーネントの「前」で遅延が高いが、コンポーネントの遅延が低い場合は、コンポーネント、またはコンポーネントの前で高コール率を使用していること示しています。
  • 「バーコード」パターンの長い遅延トランザクション: コンポーネント A は、短い間隔でコンポーネント B を何度もコールします。 この動作の結果は、通常、B の通常の遅延、A の大幅な遅延になります。
Experience ビューおよび分析ノートブック上の異常および問題を参照し、高コール率の見出しを確認します。 たとえば、異常および問題は以下の見出しを表示します。
Potential high call ratio from {culprit.name} to {calledComp.name} in the order of {ratio}
この見出しは、高コール率ストーリーについて説明します。 たとえば、詳細に、ニューヨークにあるデータベースへのクライアント接続の遅延の問題が記述される場合があります。
例: アナリストが高コール率ストーリー内の最大深度コンポーネントを特定する方法
以下の例は、パターン アナリストが高コール率ストーリー内で最大深度コンポーネントを探す方法を示しています。
  1. 差異分析がアラートをトリガします - トランザクションの速度が低下し、ストーリーの一部になります。
  2. トランザクションからのコール パスで、イベントが発生します。 アナリストは、コンテキスト内の最大深度コンポーネントを検索します。
  3. 1 つのコンポーネントは、デッド エンドです。 コンポーネントは、バックエンドをコールしないため、アナリストによって無視されます。
  4. 1 つのコンポーネントがバックエンドをコールします。 アナリストは、履歴データを使用して、呼び出し元コンポーネントの Responses Per Interval の数を、バックエンド コールの Responses Per Interval の数と比較します。 比率が高い(たとえば、> 1:50)場合、トランザクションのコール率は異常に高く、アプリのパフォーマンスに悪影響を及ぼす可能性があります。
    その他のコンポーネントでも、データベースへのコール率が高い場合があります。 アナリストは、フロントエンドからのコール パスで、コンポーネントが存在するまで、高い率の診断は行いません。 アナリストはアプリ全体には関わりませんが、識別されたストーリーを検出します。
最大深度コンポーネントの例: 高コール率のストーリー
最大深度コンポーネントの例: 高コール率のストーリー
リソース イベント アナリスト サポート
問題切り分け支援は、リソース イベント アナリストを使用し、以下のように、CPU やメモリなどのリソース イベントのアラートを監視します。
  1. アプリケーションで問題、もしくはシステム リソースの問題が発生します。
  2. リソース イベントが、指定された問題または異常の疑いがあるものとして一覧表示されます。
リソース アナリストは、CA APM および CA APM Infrastructure Agent のエージェントをサポートします。 補助問題切り分けは、インフラストラクチャ エージェントによってレポートされるインフラストラクチャ情報のコンテキストをアプリケーションに提供します。 インフラストラクチャ エージェントから送信されるアラートは、補助問題切り分けストーリー(エビデンス)に含まれます。 例:
  1. CPU 使用率がサーバ上で高くなっています。
  2. インフラストラクチャ エージェントは、この問題をレポートします。
  3. 補助問題切り分けは、このリソースの問題を影響を受けるアプリケーションに関連付けます。
以下の前提条件の手順は、リソース イベント アナリストに適用されます。
  1. CA APM インフラストラクチャ エージェント モニタリングが有効になっており、アラートがインフラストラクチャ コンポーネントにマップされていることを確認します。
  2. マップ ビューでは、アプリケーション コンポーネントを表示する
    アプリケーション レイヤ
    を選択します。
  3. マップ上のアプリケーション コンポーネントをクリックします。
    対応するインフラストラクチャ コンポーネントを含む相関値が存在している必要があります。
詳細: