[運用を可視化するためのダッシュボードの構築 | Amazon Builders' Library](https://aws.amazon.com/jp/builders-library/building-dashboards-for-operational-visibility/) - 時系列メトリクス、ログ、トレース、アラームデータ - つねにみてられないので，システムが発信する最も重要なモニタリングデータを常に評価する自動アラームを作成しました ![[Pasted image 20210518211919.png]] ## 高レベルでのダッシュボード ### カスタマーエクスペリエンスダッシュボード ### システムレベルでのダッシュボード ### サービスインスタンスダッシュボード ### サービス監査ダッシュボード ### キャパシティプランニングと予測ダッシュボード ## 低レベルでのダッシュボード 通常、バックエンドマイクロサービス全体でリクエストを調整して、Amazon API を実装します。これらのマイクロサービスは異なるチームが所有でき、各チームがリクエストに関する特定の処理を担当します。たとえば、一部のマイクロサービスは、リクエストの認証と承認、スロットル/制限の実施、使用状況の測定、リソースの作成/更新/削除、データストアからのリソースの取得、非同期ワークフローの開始に特化しています。通常、チームは少なくとも 1 つの専用マイクロサービスに特化したダッシュボードを作成します。このダッシュボードには、各 API のメトリクス、または作業単位（サービスがデータを非同期で処理している場合）が表示されます。 ### マイクロサービス固有のダッシュボード マイクロサービスのダッシュボードは通常、サービスの深い知識を必要とする実装に特化したモニタリングデータを表示します。主にサービスを所有するチームが、これらのダッシュボードを使用します。ただし、Amazon のサービスは高度に計測されており、この計測から来るデータでオペレーターが圧倒されないようにデータを提示する必要があります。このため、これらのダッシュボードには通常、一部のデータが集計形式で表示されます。オペレーターは、集約されたデータの異常を特定すると、通常、他のいろいろなツールを使ってさらに深く掘り下げ、基礎となるモニタリングデータに対してアドホッククエリを実行し、データの集約、リクエストのトレース、関連するまたは相関するデータの開示を行います。 ### インフラストラクチャダッシュボード 私たちのサービスは、通常、メトリクスを発行する AWS インフラストラクチャで実行するため、専用のインフラストラクチャダッシュボードも用意しています。これらのダッシュボードは、Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) コンテナ、AWS Lambda 関数など、システムが実行するコンピューティングリソースが生成するメトリクスに主に焦点を当てています。CPU 使用率、ネットワークトラフィック、ディスク IO、スペース使用率などのメトリクスは、これらのコンピューティングリソースに関連するすべての関連クラスター、Auto Scaling、クォータメトリクスとともに、これらのダッシュボードで一般的に使用されます。 ### 依存関係ダッシュボード マイクロサービスは、コンピューティングリソースだけでなく他のマイクロサービスにも依存していることがよくあります。これらの依存関係を所有するチームがすでに独自のダッシュボードを持っている場合でも、各マイクロサービスの所有者は通常、専用の依存関係ダッシュボードを作成して、上流の依存関係（プロキシやロードバランサーなど）と下流の依存関係（データストア、キュー、ストリームなど）の両方がどのように動作しているかの情報（これらのサービスが測定したもの）を表示します。セキュリティ証明書の有効期限やその他の依存関係の割り当ての使用状況など、他の重要なメトリクスを追跡するためにも使用できます。 ## ダッシュボードの設計 Amazon では、良質なダッシュボードを設計するためには、データの表現に一貫性を持たせることが重要だと認識しています。効果を発揮させるためには、個別のダッシュボードだけでなく、すべてのダッシュボードにおいて、一貫性を実現する必要があります。当社では何年にもわたり、デザインの組合せや構成を、共通なパターンとして特定、適合、改良し続けてきました。それは、最大限に広範な利用者がアクセスできるダッシュボードを提供することで、最終的には当社の企業価値の向上につながると考えているからです。また、これまでの間に、こういったデザイン上の様式を、細かに評価し改善するための手法も獲得してきています。たとえば、新しい利用者がダッシュボードに表示されているデータを素早く理解して使いこなして、そのサービスの仕組みを学ぶことがでれば、そのダッシュボードが正しい情報を適切に表現していることを意味します。 ダッシュボードを設計する時によくある傾向の 1 つとして、ターゲットユーザーの分野の知識を過大評価または過小評価してしまうことがあります。ダッシュボードを、その作成者のセンスに完全に合わせて構築することは簡単です。しかしながら、そのダッシュボードが、ユーザーに価値を提供できるものになるとは限りません。当社では、こういったリスクを排除するために、お客様側の意向を重視しながら作業をすすめるという手法を取っています。 当社は現在までに、ダッシュボードにおけるデータのレイアウトを標準化する、デザイン様式を取り入れてきています。ダッシュボードは、上から下に描画されるものです。そして、ユーザーには、初期（ダッシュボードのローディング時）に表示されるグラフが、最も重要性が高いものと解釈される傾向があります。したがって、当社のデザイン様式では、最重要なデータを、ダッシュボードの最上部に配置することが奨励されています。可用性について集約/要約されたグラフや、エンドツーエンドのレイテンシーをパーセンタイルで表すグラフは、一般的にウェブサービスにとっては、最重要なダッシュボードであることが分かっています。 ここに示すスクリーンショットは、仮想的な Foo という名のサービスのための、ダッシュボードの最上段を表しています。  ### 当社では、最重要なメトリクスには、大きなグラフを使用します。 1 つのグラフに多くのメトリクスが含まれる場合、凡例的なグラフでは、データを縦方向にも横方向にも圧縮して表示するようなことはありません。グラフ内で検索クエリが使用されている場合には、その結果となるメトリクスを、普通のものより大きくできるようにしています。 ### グラフのレイアウトは、想定できる最小の表示解像度に合わせます これによりユーザーは、横方向にスクロールする必要がなくなります。ノートパソコンを使い午前 3 時に電話をかけたオペレーターが、右側にもっとグラフがあることに気付かない限り　横方向のスクロールバーがあることにも気付かないでしょう。 ### タイムゾーンを表示します 日付と時間データを表示するダッシュボードの場合は、必ず、関連するタイムゾーンが視認できるようにしています。異なるタイムゾーンにいるオペレーターが同時に使用するダッシュボードでは、全員に関係がある 1 つのタイムゾーン（UTC）を、デフォルトで表示しています。この手法により、各ユーザーが単一のタイムゾーンを使用してコミュニケーションすることができ、それぞれが頭の中でタイムゾーンを切り替えるための、余計な時間と労力が節約できます。 ### 最小の時間間隔とデータポイントピリオドを使用します 時間間隔とデータポイント期間は、最も一般的なユースケースにおいて妥当な値をデフォルトにしています。ダッシュボードのすべてのグラフは、初期状態では必ず、同一の時間幅と分解能でデータ表示を行います。ダッシュボードにおいて、1 つのセクションにあるすべてのグラフが、共通の横サイズを持つことのメリットを認識しているからです。これにより、グラフ間での時間的な相互関係を、容易に表すことが可能になります。 また、ダッシュボードのローディング時間が遅くならないよう、グラフ上で過多なデータポイントをプロットすることも避けています。加えて、実際のところ、過剰なデータポイントを表示することで、ユーザーが異常値を視認しにくくなるケースも存在します。たとえば、時間分解能が 1 分のデータポイントを 3 時間分、メトリクスごとに 180 個の値を表示するグラフであれば、小型のダッシュボードウィジェットでも明瞭に描画できます。データポイントがこのような数であれば、運用作業を選別しながら進行しているオペレーターに対しても、十分な情報を提供することができます。 ### 時間間隔とメトリクス期間は調整可能にしています 当社のダッシュボードでは、時間間隔とメトリクス期間の両方を、すばやく調整できる制御機能を提供しています。ダッシュボードで使用している、x 方向の一般的な解像度には、次のものがあります。 - 1 時間 x 1 分単位（60 個のデータポイント）– 実行中のイベントを監視するための拡大表示向き - 12 時間 x 1 分単位（720 個のデータポイント） - 1 日間 x 5 分単位（288 個のデータポイント）– 日次トレンドの表示向き - 3 日間 x 5 分単位（864 個のデータポイント） - 1 週間 x 1 時間単位（168 個のデータポイント）– 週次トレンドの表示向き - 1 か月間 x 1 時間単位（744 個のデータポイント） - 3 か月間 x 1 日単位（90 個のデータポイント）– 四半期のトレンド表示向き - 9 か月間 x 1 日単位（270 個のデータポイント） - 15 か月 x 1 日単位（450 個のデータポイント）– 長期的なキャパシティの確認向き  ### グラフにはアラームしきい値で注釈を付けます 自動的なアラームがあるメトリクスをグラフ表示する場合、そのアラームのしきい値が静的であるなら、グラフには水平ラインでの注釈を表示します。人工知能（AI）や機械学習（ML）を使用し生成された予測や推定に基づいていて、アラームのしきい値が動的である場合には、同一のグラフ内に実際の値としきい値、両方のメトリクスを表示します。既知の制限（テスト済み最大値、もしくはハードリソースの上限など）を持つサービスで、1 側面を測定するメトリクスを表示するグラフでは、既知の、もしくはテスト済みの制限がどこかを示す水平ラインにより、注釈を表示しています。ゴールがあるメトリクスの場合には、そのゴールをユーザーがすぐに視認できるよう、水平ラインを追加して表示します。 ### 左と右の両方の y 軸をすでに表示しているグラフ上では、水平ラインを追加表示しません。 このようなグラフで水平ラインを表示すると、どちらの y 軸がそのラインと関係しているかを、ユーザーが理解しづらくなるからです。このような場合、曖昧さを避けるためにグラフを 2 つに分割して表示します。各グラフでは水平軸を 1 つのみ使用し、適切なグラフに対してのみ、水平ラインを追加表示しています。  ### 値の範囲が大きく異なる複数のメトリクスでは、y 軸が過剰にローディングされないようにします 1 つ以上のメトリクスで相違点の視認性を落とすことにならないよう、こういったシチュエーションを避けるようにしています。これは例えば、p0（最小）と p100（最大）のレイテンシーを同一のグラフに表示する場合があたります。このグラフでは、p100 のデータポイントでの値は、p0 のものより数桁分大きくなり得ます。  ### y 軸の境界が、その時のデータポイントにおける値の範囲に合うよう、適切に縮小表示しています データポイントの値に範囲が限られた y 軸を使用しているグラフは、大まかに見ることができ、メトリクスの変化を実際より認識しやすくできます。 ### 単一グラフの過剰なローディングを避けています 1 つのグラフにおいて、統計情報を過多に表示したり、関連のないメトリクスを表示することがないようにしています。たとえば、リクエスト処理のためのグラフを追加する場合、通常は、次に示すようなダッシュボードにおいて、分割した適切なグラフを作成しています。 - 可用性 %（障害/リクエスト × 100） - p10、平均、p90 レイテンシー - p99.9 および最大（p100）レイテンシー ### 各メトリクスもしくはウィジェットの真の意味を、ユーザーが理解していることは前提にしていません これは特に、実装に特化したメトリクスの場合に当てはまります。ダッシュボードのテキスト表示には、十分な情報を提供するようにします。たとえば、グラフの横や下に、説明分を表示するようにしています。オペレーターは、このテキストを読むことで、メトリクスの意味を理解できます。それによりオペレーターは、「正常」な状態がどのように見えるか、そして、グラフが「正常」ではない場合にどのような意味を持つのかを、解釈できるようになります。 このテキスト分には、オペレーターが根本原因を判断する際に使用できる、関連リソースへのリンクを含めています。次に、このリンクの事例をいくつか示します。 - ランブックへのリンク。各分野のエキスパートは、ダッシュボードをランブックとして使用できます。 - 「詳細検証」ダッシュボードへのリンク。 - 異なるクラスターもしくはパーティションでの、同等なダッシュボードへのリンク。 - デプロイパイプラインへのリンク。 - 依存関係に関する情報の問い合わせへのリンク。  ### それが適切な場合には、アラームステータスや基数、および/または時系列グラフのウィジェットを活用します。 ダッシュボードのユースケースによっては、単一の数値（メトリクスにおける最新の値など）やアラームステータスを含むウィジェットを表示する方が、最近のデータポイントに関する複雑な時系列グラフを表示するより適切な場合があります。  ### 希薄なメトリクスを表示するグラフに頼らないようにしています 希薄なメトリクスとは、特定のエラー状態がある場合にのみ、生成されるメトリクスのことです。必要な場合にのみこれらのメトリクスを生成するため、機器サービスにとっては有効なものですが、ダッシュボードのユーザーにとっては、空白もしくはほとんど値のないグラフは混乱を招きやすいものです。通常、ダッシュボードの設計中にこのようなメトリクスが表れた場合、エラー状況が発生しない限りは安全な値（つまりゼロ）を継続的にメトリクスとして出力するように、そのサービスを修正しています。これにより、サービスからのデータの欠落にはテレメトリーを正確に出力していないという意味が含まれることを、オペレーターが容易に理解できるようになります。 ### モードごとのメトリクス表示のためのグラフを追加します これは、システム内での複数モデルの動作を収集したメトリクスを、グラフ表示する場合に行われます。これを行う可能性のある状況には、次が含まれます。 - 可変サイズのリクエストをサポートするサービスでは、リクエスト全体でのレイテンシーを示すグラフを作成する場合があります。さらに、小規模、中規模、そして大規模のリクエストに関するメトリクスを表示するグラフも、作成することがあります。 - そのサービスが、入力パラメータの値（あるいはその組合せ）に対応し、異なる方法でリクエストを実行している場合には、実行の各モードをキャプチャーするメトリクスのためのグラフも追加します。