ダッシュボード
ダッシュボードは、オブザーバビリティソリューションの重要な部分です。データの厳選された可視化を作成することができます。データの履歴を確認し、他の関連データと並べて表示することができます。また、コンテキストを提供することもできます。ダッシュボードは、全体像を理解するのに役立ちます。
多くの場合、人々はデータを収集してアラームを作成し、そこで止まってしまいます。しかし、アラームは一時点のみを示し、通常は単一のメトリクスまたは小さなデータセットに限られます。ダッシュボードは、時間の経過に伴う動作を確認するのに役立ちます。
実践的な例: CPU 高使用率のアラームを考える
マシンが望ましい値以上の CPU 使用率で動作していることがわかりました。対応が必要でしょうか？また、どのくらい迅速に対応すべきでしょうか？判断の助けとなる要素は何でしょうか？
- このインスタンス/アプリケーションの通常の CPU 使用率はどのようなものですか？
- これは一時的な急上昇ですか、それとも CPU 使用率が増加傾向にあるのでしょうか？
- パフォーマンスに影響を与えていますか？影響がない場合、影響が出るまでにどのくらいの時間がありますか？
- これは定期的に発生する現象ですか？また、通常は自然に回復しますか？
データの履歴を確認する
次に、CPU の履歴時系列チャートを含むダッシュボードを考えてみましょう。 この単一のメトリクスだけでも、これがスパイクなのか、上昇傾向なのかを確認できます。 また、どれくらいの速さで上昇しているかも確認でき、対応の優先順位を決定することができます。
ワークフローへの影響を確認する
しかし、このマシンは何をしているのでしょうか？全体的な文脈において、これはどの程度重要なのでしょうか？ここで、ワークフローのパフォーマンス（応答時間、スループット、エラー、またはその他の指標）の可視化を追加したとします。これにより、高い CPU 使用率が、このインスタンスがサポートしているワークフローやユーザーに影響を与えているかどうかを確認できます。
アラームの履歴を確認する
過去1ヶ月間にアラームが何回トリガーされたかを示す可視化を追加することを検討してください。さらに過去に遡って、これが定期的に発生しているかどうかを確認することも組み合わせてみましょう。例えば、バックアップジョブがスパイクを引き起こしているのでしょうか？再発のパターンを知ることで、根本的な問題を理解し、アラームの再発を完全に止めるための長期的な決定を下すのに役立ちます。
コンテキストを追加する
最後に、ダッシュボードにコンテキストを追加します。このダッシュボードが存在する理由、関連するワークフロー、問題が発生した場合の対処方法、ドキュメントへのリンク、連絡先などの簡単な説明を含めてください。
これで ストーリー ができました。これにより、ダッシュボードのユーザーは何が起こっているかを把握し、影響を理解し、適切なデータに基づいた判断を行い、どのようなアクションをどの程度の緊急性で取るべきかを決定することができます。
すべてを一度に可視化しようとしないでください
アラーム疲れについてよく話題になります。 識別可能なアクションや優先順位のない多すぎるアラームは、チームに過負荷をかけ、非効率につながる 可能性があります。 アラームは、あなたにとって重要で、アクションを起こせるものに対してのみ設定すべきです。
ダッシュボードはこの点でより柔軟です。 アラームのように注意を要求しないため、まだ重要かどうか確信が持てないものや、探索をサポートするものを可視化する自由度が高くなります。 ただし、やりすぎないようにしましょう！良いものでも多すぎると問題が生じる可能性があります。
ダッシュボードは、あなたにとって重要なものの全体像を提供すべきです。 データの取り込みを決定する場合と同様に、ダッシュボードに何が重要かを考える必要があります。 ダッシュボードについて、以下のことを考えてみてください：
- 誰がこれを見るのか？
- 彼らのバックグラウンドと知識は何か？
- どの程度のコンテキストが必要か？
- 彼らはどのような質問に答えようとしているのか？
- このデータを見た結果、彼らはどのようなアクションを取るのか？
ダッシュボードのストーリーがどうあるべきか、どの程度の情報を含めるべきかを判断するのは難しい場合があります。 では、ダッシュボードの設計をどこから始めればよいでしょうか？ KPI 駆動型 または インシデント駆動型 の 2 つの方法を見てみましょう。
ダッシュボードの設計：KPI 駆動型
これを理解する一つの方法は、KPI から逆算することです。これは通常、非常にユーザー主導型のアプローチです。 レイアウト については、通常、上から下へと作業し、ダッシュボードを下に移動するか、より下位レベルのダッシュボードに移動するにつれて、より詳細な情報を得ることができます。
まず、KPI を理解することが重要です。KPI の意味を理解することで、どのように可視化したいかを決定するのに役立ちます。 多くの KPI は単一の数字として表示されます。例えば、特定のワークフローを正常に完了する顧客の割合は何パーセントで、どのくらいの時間がかかるでしょうか？しかし、どの期間で測定するのでしょうか？1 週間の平均では KPI を満たしていても、その中でも短い期間で基準を超えることがあるかもしれません。これらの違反は重要ですか？顧客体験に影響を与えますか？もしそうなら、異なる期間と時間チャートを使用して KPI を確認することを検討するかもしれません。また、すべての人が詳細を見る必要はないかもしれないので、KPI の内訳を別のダッシュボードに移動し、別の対象者向けにすることも考えられます。
次に、それらの KPI に何が寄与しているかを考えます。それらのアクションが発生するために、どのようなワークフローが実行される必要がありますか？これらを測定できますか？
主要なコンポーネントを特定し、それらのパフォーマンスの可視化を追加します。KPI が違反した場合、ワークフローのどこに主な影響があるかを素早く確認できるようにする必要があります。
さらに掘り下げることもできます - それらのワークフローのパフォーマンスに何が影響しているでしょうか？深さのレベルを決定する際は、対象者を忘れないでください。
注文数を KPI とする e コマースシステムの例を考えてみましょう。 注文を行うためには、ユーザーは以下のアクションを実行できる必要があります：商品の検索、カートへの追加、配送先の詳細の追加、注文の支払いです。 これらの各ワークフローについて、主要なコンポーネントが機能しているかどうかを確認することを検討するかもしれません。例えば、RUM や Synthetics を使用してアクションの成功に関するデータを取得し、ユーザーが問題の影響を受けているかどうかを確認します。スループット、レイテンシ、アクション失敗率の測定を検討して、各アクションのパフォーマンスが期待通りかどうかを確認するかもしれません。また、基盤となるインフラストラクチャの測定を検討して、パフォーマンスに何が影響を与えているかを確認するかもしれ ません。
ただし、すべての情報を同じダッシュボードに配置しないでください。繰り返しになりますが、ユーザー対象を考慮してください。
ドリルダウンを可能にし、適切なユーザーに適切なコンテキストを提供するダッシュボードの層を作成します。
ダッシュボードの設計：インシデント駆動型
多くの人にとって、インシデント解決はオブザーバビリティの主要な目的です。ユーザーやオブザーバビリティのアラームによって問題が通知され、迅速に修正を見つけ、問題の根本原因を特定する必要があります。
最近のインシデントを振り返ってみましょう。共通のパターンはありますか？会社にとってどれが最も影響が大きかったですか？繰り返し発生するものはどれですか？
この場合、インシデントの深刻度を理解し、根本原因を特定して修正しようとする人々のためのダッシュボードを設計しています。
特定のインシデントを思い出してください。
- 報告されたインシデントをどのように確認しましたか？
- 何をチェックしましたか？エンドポイント？エラー？
- 問題の影響とそれに伴う優先度をどのように理解しましたか？
- 問題の原因を調べるために何を見ましたか？
アプリケーションパフォーマンスモニタリング (APM) は、エンドポイントやワークフローの定期的なベースラインテストに Synthetics を、実際の顧客体験には RUM を使用することで役立ちます。これらのデータを使用して、影響を受けているワークフローとその程度を迅速に可視化できます。
時間経過によるエラー数や上位のエラーを表示する可視化は、適切な領域に焦点を当て、エラーの具体的な詳細を示すのに役立ちます。ここでは、ログデータとエラーコードや理由の動的な可視化を使用することが多いです。
できるだけ迅速に詳細にアクセスするために、フィルタリングやドリルダウンの機能があると非常に便利です。オーバーヘッドを抑えつつ、これを実装する方法を考えてください。例えば、フィルタリングして詳細に迫ることがで きる単一のダッシュボードを用意するなどです。
レイアウト
ダッシュボードのレイアウトも重要です。
通常、ユーザーにとって最も重要な可視化は、左上または自然なページナビゲーションの 開始点 に合わせて配置します。
レイアウトを使用してストーリーを伝えることができます。例えば、上から下へのレイアウトを使用し、下にスクロールするほど詳細が表示されるようにすることができます。あるいは、左右の表示を使用して、左側に上位レベルのサービスを配置し、右に移動するにつれてその依存関係を表示することも有効かもしれません。
動的なコンテンツの作成
多くのワークロードは、需要に応じて拡大または縮小するように設計されており、ダッシュボードはこれを 考慮する必要があります。 例えば、インスタンスをオートスケーリンググループに配置し、特定の負荷に達すると追加のインスタンスが追加されるような場合があります。
特定の ID で指定された特定のインスタンスからのデータを表示するダッシュボードでは、新しいインスタンスからのデータを見ることができません。 リソースとデータにメタデータを追加することで、特定のメタデータ値を持つすべてのインスタンスを取得するようにビジュアライゼーションを作成できます。 これにより、実際の状態を反映させることができます。
動的なビジュアライゼーションの別の例として、現在発生している上位 10 個のエラーとそれらの最近の履歴での動向を見つけられるようにすることが挙げられます。 どのようなエラーが発生するかを事前に知ることなく、テーブルやチャートを表示できるようにしたいものです。
原因よりも症状を先に考える
症状を観察する際、ユーザーや システムへの影響を考慮しています。多くの根本的な原因が同じ症状を引き起こす可能性があります。これにより、未知の問題を含む、より多くの問題を捉えることができます。原因を理解するにつれて、下位レベルのダッシュボードはより具体的になり、問題の迅速な診断と修正に役立ちます。
先週ユーザーに影響を与えた特定の JavaScript エラーを捉えるのではなく、中断されたワークフローへの_影響_を捉え、最近の履歴における JavaScript エラーの上位カウントや、最近急激に増加したエラーを表示しましょう。
上位/下位 N を使用する
ほとんどの場合、運用メトリクスをすべて同時に可視化する必要はありません。EC2 インスタンスの大規模なフリートはその良い例です。数百台のサーバーファ ーム全体のディスク IOPS や CPU 使用率を同時に表示する必要も価値もありません。これは、最高（または最悪）のパフォーマンスを示すリソースを見るよりも、メトリクスを掘り下げるのに多くの時間を費やすというアンチパターンを生み出します。
ダッシュボードを使用して、任意のメトリクスの上位 10 個または 20 個を表示し、それが明らかにする症状に焦点を当てます。
CloudWatch メトリクスでは、任意の時系列の上位 N を検索できます。例えば、次のクエリは CPU 使用率が最も高い上位 20 個の EC2 インスタンスを返します：
SORT(SEARCH('{AWS/EC2,InstanceId} MetricName="CPUUtilization"', 'Average', 300), SUM, DESC, 10)
このアプローチ、または CloudWatch Metric Insights を使用して、ダッシュボードで最高または最低のパフォーマンスを示すメトリクスを特定します。
しきい値付き KPI を視覚的に表示する
KPI には警告またはエラーのしきい値を設定し、ダッシュボードでは水平アノテーションを使用してこれを表示できます。これはウィジェット上に高水位線として表示されます。これを視覚的に表示することで、ビジネスの成果やインフラストラクチャが危険にさらされている場合に、人間のオペレーターに事前の警告を与えることができます。
水平アノテーションは、十分に開発されたダッシュボードの重要な部分です。
コンテキストの重要性
人々はデータを簡単に誤解する可能性があります。彼らの背景や現在のコンテキストが、データの見方に影響を与えます。
そのため、ダッシュボードには必ず テキスト を含めるようにしてください。このデータは何のためのものか、誰のためのものか？それは何を意味するのか？アプリケーションに関するドキュメント、サポート担当者、トラブルシューティングのドキュメントへのリンクを含めてください。テキスト表示を使用してダッシュボードの表示を分割することもできます。左側に配置して左右のコンテキストを設定したり、水平方向に全幅で配置してダッシュボードを垂直に分割したりすることができます。
IT サポート、オンコールの運用担当者、またはビジネスオーナーへのリンクを用意することで、問題が発生した際に支援を受けられる人々に素早く連絡を取るための手段を提供できます。
チケットシステムへのハイパーリンクもダッシュボードに追加すると非常に便利です。