イベントとインシデント

コンセプト

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

Issue

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

Incident

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

Change

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

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

Issue

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

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

Issueの例：

この例では、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が到達した最高の重大度を表します。

インシデント

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

インシデントは、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イベントも関連性のあるインシデントに関連付けられているため、システムがオフラインになったからといってアラートを控えることができます。営業日の終わりに負荷が減少し、不要になったためにオフになったのかもしれません。