コンセプト

Instanaは、アプリケーションのサービス品質の管理に役立つ3つの主要なタイプのイベントを検出します。

Issue

Issueは、エンティティが異常な状態になった場合に作成されるイベントです。 これらは、サービス品質の低下から複雑なインフラストラクチャの問題、ディスクの飽和まで、さまざまな不健康な状況を検出するために構築された機械学習アルゴリズムとヘルスシグネチャによって検出されます。

Incident

インシデントは最高レベルのイベントです。 これらは、検出されたサービスが影響を受けるときに作成され、ダイナミックグラフを活用してコンテキストを提供することにより、関連するすべてのイベントを関連付けます。

Change

Changeとは、サーバーの起動/停止、展開、システムの構成変更など、あらゆる名前を表すイベントです。 さらに分けられます:

  • 変更–コンポーネントの構成が変更されました。
  • オフライン/オンライン-管理下にあるコンポーネントの存在を追跡します。

Issue

Issueは、通常とは異なる何かが発生した場合にトリガーされるイベントです。

ディスクの飽和やElasticsearchクラスターのスプリットブレイン状態などの重要なインフラストラクチャのIssueは、最終結果がデータ損失となる可能性が高いため、インシデントをトリガーします。

Issueの例:

event_details_example

この例では、1台のLinuxマシンのCPUスチール時間が疑わしいため、Issueとしてマークされています。 Issue自体はアラートをトリガーしません。Instanaはそれが発生したことを単に指摘します。 このシステムが接続されているサービスの動作が悪い場合、このIssueはインシデントの一部になります。 この方法論は、イベントとパフォーマンスのIssueを手動で相関させる必要がないため、Instanaの大きな利点のひとつです。 何かがしばらくCPUを過度に使用しているからといって、それ自体に問題があるわけではありません。 サービスが影響を受ける場合にのみ、これは関連情報になります。

Instanaは、Issueが最初に発生した時刻と、条件が存在しなくなった時刻(開始時刻と終了時刻)を記録します。 この場合、CPUスチールが約5分半(07:08:37から07:10:54まで)で17%の制限を超えたことがわかります。 Issueの行をクリックすると、画面の右側に詳細が表示されます。 CPUスチールの増加は、17:10頃に明らかになります。

View Built-in Event」リンクを使用すると、このIssueのイベントとアラート設定の対応する定義に直接移動できます。 これは、特定のIssueがどの基準で作成されたかを理解するのに役立ちます。

注:

  • まれなトラフィック(15分ごとに1回の呼び出しなど)を受信するアプリケーション、サービス、またはエンドポイントは、Issueを検出するための十分な基盤があるとは見なされません。
  • Issueの重大度は、その存続期間中に変化する可能性があります。 これは、この特定のIssueが到達した最高の重大度を表します。

インシデント

インシデントは、エッジサービスと重要なインフラストラクチャに影響を与える状況を理解するのに役立ちます。これは、それらの動作と正常性を自動的に学習し、それらが異常になったときにアラートを送信することによります。 エッジサービスは、監視対象アプリケーションの外部の顧客や他のシステムが実際にアクセスするものです。 それらはアプリケーションの外部成果物です。

incidents_view

インシデントは、Instanaがエッジサービスで重要なパフォーマンス表示(KPI)に違反したか、重要なインフラストラクチャの問題を検出するとすぐに作成されます。 詳細については、Monitoring Microservicesブログ投稿のパートIIをご覧ください。

Instanaは、検出されたアプリケーションサービスのKPIを追跡します。 それらのKPIは次のとおりです。

  • ロード(呼び出し/秒)
  • 待ち時間(ミリ秒単位の応答時間)
  • エラー(エラー率)

Instanaは、サービスごとにこれらのKPIを自動的に測定し、これらのKPIに機械学習を適用して、サービスの正常性を把握します。 検出される典型的な問題は次のとおりです。

  • エラー率は通常よりも高い
  • サービスのパフォーマンスが遅い
  • 突然の負荷低下があります

KPIは、サービスおよびアプリケーション全体のすべてのトレースをキャプチャして分析することにより決定されます。 トレースは、ステータスコードや例外などのエラーを自動的にキャプチャして、問題が発生したかどうかを確認します。 トレースは、各サービスおよび基礎となるコンポーネントで費やされた時間も測定します。 Google Dapperアーキテクチャに基づいて、トレースはスパンで構成されるツリーであり、スパンは基本的な作業単位です。 マイクロサービスの世界では、ひとつのスパンは通常、データベースなどのサービスまたはコンポーネントへのひとつのリクエストに相当します。 このようにして、Instanaはアプリケーションのエンドツーエンドのトレースだけでなく、個々のサービスとコンポーネントのパフォーマンスに関する情報も自動的に取得します。

サービスの状態が影響を受ける場合、Instanaは新しいインシデントを作成し、Issueとイベントのダイナミックグラフを走査することにより、他のすべてのインシデントと関連付けます。

その結果、サービスとイベントの影響に関する状況の包括的な概要が得られます。

Change

Changeは、サーバーの起動または停止、展開、システムの構成変更など、何でもかまいません。

Instanaは、監視対象の各テクノロジに固有の関連する構成を追跡することで変更を認識し、何かがオンラインになる(Instanaによって監視される)か、オフラインになる(Instanaによって監視されなくなる)かを監視します。

すべての変更は記録され、通常、持続時間はわずか1秒です(開始時刻と終了時刻の差)。 Issueと同様に、Changeイベントも関連性のあるインシデントに関連付けられているため、システムがオフラインになったからといってアラートを控えることができます。 営業日の終わりに負荷が減少し、不要になったためにオフになったのかもしれません。

change_details_example

用語

Issue

Instanaが発生したテクノロジーに固有の特性を使用して、疑わしいとマークされたイベント。

インシデント

人間が調査する必要があるパフォーマンスの低下に関連したIssue。

Change

環境内のすべての変更。これには、デプロイメント、構成の変更、サーバーの起動または停止が含まれますが、これらに限定されません。

使用法

インシデントを分析する方法

インシデントの例を見てみましょう。サービスの応答が突然通常より遅くなります。これを「平均レイテンシーの突然の増加」と呼びます。 インシデントは警告として黄色でマークされます。 これは自動的に行われ、しきい値の構成オプションはありません。これは、Instanaのもうひとつの大きな利点です。 このインシデントがまだアクティブである限り、色が表示されます。 解決されると、グレーで表示されますが、ドリルダウンは引き続き可能です。 表の行をクリックすると、エクスペリエンスが開始されます。incidents_expanded

インシデント詳細ビュー(画面の右側部分)は、3つの部分に編成されています。

  1.  ヘッダーには、インシデントの重要な事実に関する基本情報が含まれています。

    • 始まる時間;
    • 終了時間(まだ進行中の場合は現在);
    • まだアクティブなイベントの数。
    • 関係する変更の数。
    • 影響を受けるエンティティの数。

インシデントの開始日、利用可能な場合は終了日、アクティブなイベントの数、このインシデントに属する変更の数、および影響を受けるエンティティの数を確認できます。

incident_KPIs

  2.  番目のセクションは、時間の経過とともに発生するインシデントの視覚的表現を提供します。 チャートには、開始から終了までの完全な時間枠とすべてのイベントが開始時間でソートされて表示されます。 折りたたまれたビューは、7つのイベントに制限されています。 インシデントに一度に7つ以上のイベントが含まれている場合は、展開ボタンを押して完全なビューを表示します。 いずれかのバーをクリックすると、その問題の詳細ビューが開きます。

incident_population

  3.  番目のセクションには、セクション2のグラフビューの詳細が含まれています。開始時間でソートされたすべてのイベントのリストにより、ユーザーは各イベントのすべての利用可能な情報を見ることができます。 これを行うには、クリックして展開します。

expanded_incident_event

詳細はイベントを理解するのに役立ち、その後、視覚化のために対応するメトリックがプロットされた複数のチャートが続きます。 イベントがまだアクティブな場合、チャートは新しい着信メトリック値のレンダリングを継続します。 このイベントはサービスに影響すること、および/またはこのイベントがインシデントをトリガーしたことを強調する2つのフラグがあります。 使用可能な場合、フラグはリスト内の各イベントの先頭に配置されます。

イベントに焦点を当てる場合、詳細セクションには、ポイント3のインシデントイベントリストに記載されているのと同じ情報が表示されます。

検索機能—インシデントを見つける

Instanaが発見したイベントの検索は、ダイナミックフォーカス機能に依存しています。 ひとつをクリックするか、上部のイベントバーチャートで複数のバーを選択すると、イベントテーブルには、選択したバーに含まれるイベントのみがリストされます。 これにより、現在の時間間隔を変更せずにイベントを詳細に検査できます。

さらに、検索ボックスを使用して、概要テーブルの「タイトル」列または「オン」列(インシデントが発生したサービスの名前)に表示されるデータで特定のアイテムを検索できます。 この例では、検索クエリは event.text:” Error rate” です。 結果は、タイトルに「エラー率」というフレーズを含むすべてのイベントのリストです。

incident_view_search

コンフィギュレーション

Instanaには、トレースとインフラストラクチャの問題の異常を検出するために、事前定義された一連のヘルスルールがあり、当社の専門家によって構築および管理されています。 個々の定義済みルールは、環境に合わない場合は無効にできます。

さらに、ユーザーはInstanaで独自のカスタムルールを構成し、カスタムの問題をトリガーできます。

この機能は、Team SettingsメニューのEvents & Alertsセクションにあります。

イベントの概要

イベントページには、現在利用可能なイベントのリストを示す概要が表示されます。 Instanaですぐに使用できる組み込みイベントと、ユーザー定義のカスタムイベントの両方をリストします。

events-overview

最初の列のシンボルは、重大度(インシデント、クリティカルまたは警告)、状態(アクティブまたは無効)、およびイベントの種類(問題またはインシデント)を示します。 このリストは、上記のドロップダウンを使用して、または全文検索によってフィルタリングできます。 イベントはいつでも無効にできます。 ただし、削除できるのはカスタムイベントのみです。

組み込みイベント

組み込みイベントは、統合されたアルゴリズムに基づいて事前定義されたヘルスイベントであり、監視対象システムのヘルスをリアルタイムで把握するのに役立ちます。 組み込みイベントが監視対象システムに関係ない場合、これらは個別に無効にできます。 Instanaの専門家が監視対象システムの健全性に関するより良い洞察を可能にする新しいルールに継続的に取り組んでいるため、組み込みイベントの数は常に増加しています。

組み込みイベントリファレンス

エンティティタイプごとのすべての組み込みイベントの包括的なリストについては、組み込みイベントリファレンスを参照してください。

カスタムイベント

カスタムイベントを使用すると、ユーザーは特定のエンティティの個々のメトリックに基づいて問題またはインシデントを作成できます。 [イベント概要]ページの上部にある[新しいイベント]をクリックして、新しいカスタムイベントを作成できます。 「新しいイベント」フォームには、イベントの詳細、条件、スコープのXNUMXつのセクションがあります。

イベントの詳細

create-event-01条件設定

create-event-02

カスタムイベントのトリガーに使用できるメトリックを提供する3つのデータソースがあります。

  • 組み込みメトリック: これらは、対応するエンティティがインスツルメントされるときに常に使用可能なメトリックです。 たとえば、JVMが監視されている場合(エンティティ= JVM)、Instanaは常に使用メモリ量などの組み込みメトリックを提供します。
  • カスタムメトリック: これらは、監視対象アプリケーションによって明示的に公開されるメトリックです。 たとえば、アプリケーションがDropwizardメトリックを公開する場合、これらのメトリックはここにあります。
  • システムルール: 現在、Instanaは次のXNUMXつのシステムルールを提供しています。
    • オフラインイベントの検出:このルールは、エンティティ(JVMやホストなど)がダウンしているときにアクティブになります。
    • 一致するエンティティが実行されていないホスト:このルールは、カスタムイベントのスコープ内にあるホスト上で実行されている一致するエンティティ(JVMやプロセスなど)がない場合にアクティブになります。

メトリックタイプに応じて、カスタムイベントをトリガーする条件を定義するさまざまなオプションがあります。 たとえば、5分間の時間枠内のエラー数が10を超える場合、イベントを構成できます。

範囲

create-event-3

通常、アプリケーションまたはシステムランドスケープのすべてのエンティティでイベントをトリガーするのは望ましくありませんが、特定のエンティティセットに制限する必要があります。 スコープを使用すると、イベントが評価されるエンティティを定義できます。

    • アプリケーションパースペクティブ: アプリケーションパースペクティブを参照してください。
    • 選択されたエンティティ: ダイナミックフォーカスクエリを定義します。 イベントが評価されるとき、そのクエリに一致するエンティティのみが考慮されます。
    • 利用可能なすべてのエンティティ: 制限なし。アプリケーションまたはシステムランドスケープのすべてのエンティティのイベントを評価します。