コンソールとダッシュボード

Prometheus のようなシステムがアプリケーションの豊富なインストルメンテーションを可能にするため、特にダッシュボードにできるだけ多くのデータを表示したくなることがあります。しかし、これは、専門家でさえ意味を読み取るのが困難なほど情報が多すぎるコンソールにつながる可能性があります。

すべてのデータを表現しようとするのではなく、運用コンソールでは、最も可能性の高い障害モードと、それらを区別するためにコンソールをどのように使用するかを考えてください。サービスの構造を活用してください。たとえば、オンラインサービングシステムに多数のサービスツリーがある場合、下位のサービスでのレイテンシは一般的な問題です。すべてのサービスの情報を 1 つの大きなダッシュボードに表示するのではなく、各サービスが通信するサービスに関するレイテンシとエラーを含む個別のダッシュボードを構築します。これにより、トップから問題のあるサービスまで下っていくことができます。

次のガイドラインは非常に効果的であることがわかりました。

• コンソールには 5 つ以上のグラフを配置しないでください。
• 各グラフには 5 つ以上のプロット（線）を配置しないでください。積み上げ/エリアグラフの場合は、これよりも多くても問題ありません。
• 提供されているコンソールテンプレートの例を使用する場合は、右側のテーブルに 20 ～ 30 エントリを超えるのを避けてください。

これらを超える場合は、重要度の低い情報の可視性を低下させ、一部のサブシステムを新しいコンソールに分割することを検討すると良いでしょう。たとえば、分解されたデータではなく集計されたデータをグラフ化したり、右側のテーブルに移動したり、めったに使用されないデータは完全に削除したりすることもできます。いつでも 式ブラウザ で確認できます。

最後に、一連のコンソールが複数のマスターにサービスを提供することは困難です。オンコール時（何が壊れているか？）に知りたいことは、機能開発時（コーナーケース X に何人がヒットするか？）に知りたいこととは非常に異なる傾向があります。そのような場合は、2 つの別々のコンソールセットが役立つ場合があります。