Instanaのイベント、チョットワカル#1

こんにちは。
Instana Observability Advent Calendar 2023
6日目を担当します古川です！

はじめに

Instanaとは？　　

次世代型のサービス監視ソリューションです。
APM(Application Performance Management)やObservabilityを実現するツールです。
そもそもInstanaをよく知らないという方は、ぜひこちらの動画をご覧ください。

今日は、いくつかあるInstanaの機能のうち、イベント機能にフォーカスします。

背景

自身の普段の業務の中で、Instanaのユーザさんから
「Instanaのイベント、何をどう使ったら良いのか、いまいち分からない。。。」
「従来型の監視（閾値監視やリソース監視など）は経験あるけど、Instanaのイベントは
　なぜそのような定義になっているかよく分からない。。。」
そんな声をしばしば頂きます。　　

ということで、そんなお悩みを持つ方が「Instanaのイベント、チョットワカル」
と思えるような記事があれば良いなと思い、この記事を書くことにしました。

対象とする読者の方

・Instanaを検討中の方、利用開始してまもない方
・「イベント」「アラート」「組み込みメトリクス」などの各種用語や設定項目を前に挫折してしまった方。心が折れそうな方。

ゴール

Instanaのイベント、チョットワカル

（そもそも）Instanaが目指したい世界観

クラウドの世界にベストプラクティスがあるように、
監視の世界にもベストプラクティスがあります。

「O’REILLY社 入門 監視 ―モダンなモニタリングのためのデザインパターン」を読むと、
こんなフレーズが目に入ります。

• できるだけユーザに近いところから監視を始める
• とにかくユーザ視点を優先した可視化が必要です
• データベースサーバのCPU使用率が急上昇しても、ユーザが影響を受けていないなら、 それは本当に問題でしょうか　　

ざっくりまとめると、これからの監視では、　　
システムの振る舞い（CPU/メモリ使用率が増加した等）よりも、 サービスのユーザにどんな影響が起きているかにフォーカスしましょう
ということです。　
※決して前者が不要ということではありません。あくまでも、後者をより大切にしましょう、という話です。　　

なぜならば、ユーザ体験はビジネスに直結するからです。

ECサイトを想像してください。　　
サイトが重かったり、決済がうまくできなかったりという問題が起きれば、
買い物したくなくなりますよね？（私も経験あります）
これはサイト運営者からすれば、ビジネスチャンスを逃していることになります。

よりビジネス価値のあるサービスを提供していくためにも、監視のベストプラクティスを活用していきましょうということです。

そして、もれなくInstanaにも、このベストプラクティスが適用されていることを　　
忘れないでください。

では、前置き長くなりましたが、本題のイベント機能について見てきましょう。

イベントとは？　アラートとは？

イベント

Instanaの監視対象であるアプリケーションやインフラストラクチャーで発生した問題や事象のことです。Instanaでは、各種イベントを以下3つのイベントタイプに分類して管理しています。　

イベントタイプ

• インシデント
• 問題
• 変更
  上から順に緊急度が高いものです。　　
  では、各イベントタイプをもう少し詳しく見ていきましょう。
  より分かりやすい説明のために、変更→問題→インシデントの順で解説します。

変更　　

デプロイ、構成変更、サーバの起動/停止など、監視対象のシステムで起きた事象です。
問題ではなく、あくまで事象なので、そんなに気にしなくて良いイベントです。以下は変更を表すマークです。

問題　　

通常と異なるシステム/サービスの振る舞いが検知された時に作成されます。　　

例

• ガベージコレクションの頻度が高い。
• レイテンシが急激に増加している。　　

例えば、従来型の監視だと、リソース監視の監視項目として、CPU使用率が80%超えたらアラートを発報するといった項目が設定されると思います。この場合、当然、その閾値を超えたときにアラートが発報されます。

では、もしCPU使用率79.9%が1週間続いていた場合、どうなるでしょうか？　　
もちろんアラートは発報されません。　　

この状態を放置すると、将来的に問題が起きる可能性があることは容易に想像できるかと思います。あるいは既に問題が起きているのに、自分たちが気づいていないだけ…かもしれません。　

こういった問題を回避するために、「通常の振る舞いと比べてどうか」を把握する仕組みがInstanaには具備されています。

ITリソースの状態だけでなく、サービスのUXに悪影響を及ぼすようなイベントを問題として扱います。

問題はさらに、

• クリティカル(赤）
• 警告（黄）
  に分類されます。クリティカルの方が緊急性が高いです。例として、以下は問題（警告）を表すマークです。
  
  クローズされると、マークが灰色になります。

インシデント　　

主にエッジサービス(※1)のKPI(※2)に異常が発生した場合に作成されるものです。また、最も緊急度が高いイベントです。冒頭のベストプラクティスを強く意識した概念であることがお分かりいただけるかと思います。
※1. エッジサービス：アプリのエンドユーザに直接影響するサービス
※2. KPI：スループット、トラフィックの待ち時間、応答時間、エラー率（＝ゴールデンシグナル) 　

補足:

• ゴールデンシグナルは、Googleさんが提唱したSREという手法を実現するために利用する指標の一つです。SREとは、一言で言うと、サービス/システムの信頼性を高めるためのエンジニアリング手法です。
• ゴールデンシグナルの詳細はこちら

また、インシデントでは、Instanaが検知したイベント（問題、変更）のうち、関連する複数のイベントが一つに集約されています。これによって、迅速に影響範囲/原因を特定したり、大量のアラートを防止することが可能です。

インシデントも問題と同様に

• クリティカル(赤）
• 警告（黄）
  の2つに分類されます。

以下は、インシデント（クリティカル）を表すマークです。

クローズされると、マークが灰色になります。

インシデントを始めとした、緊急度の高いイベントには迅速に対応する必要があります。
これをシステム運用担当者に素早く知らせるための手段としてアラートが存在します。

アラート

• Instanaが検知した重要なイベント（インシデントやクリティカルな問題）をメールやチャットツールなどを介して、システム運用担当者らにお知らせする機能です。
• アラート・チャネルを通じて、Instanaのユーザにアラートを発報します。
  • アラート・チャネルには、Slack、Teamsなどが設定できます。

おわりに

ここまで、イベントやアラートの概念について記載しました。　　
また改めて続きを書きたいと思いますが、チョットワカルようになりましたか…？
少しでも皆さんのお役に立てれば嬉しく思います！　　
スライドや画像なども、改めてアップしていきたいと思います。（2023/12/09 アップロード済み）

ではでは、第一弾はこの辺りにしたいと思います。続きをお楽しみに！

改版履歴

2023/12/07 初版
2023/12/09 以下を追加・修正

• Instanaの画面キャプチャを追加
• '問題'の章に、閾値監視とInstanaによる監視の違いに関する説明を追加。