

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ダッシュボードのベストプラクティス
<a name="v12-dash-bestpractices"></a>

****  
このドキュメントトピックは、Grafana **バージョン 12.x をサポートする Grafana** ワークスペース向けに設計されています。  
Grafana バージョン 10.x をサポートする Grafana ワークスペースについては、「[Grafana バージョン 10 での作業](using-grafana-v10.md)」を参照してください。  
Grafana バージョン 9.x をサポートする Grafana ワークスペースについては、「[Grafana バージョン 9 での作業](using-grafana-v9.md)」を参照してください。  
Grafana バージョン 8.x をサポートする Grafana ワークスペースについては、「[Grafana バージョン 8 での作業](using-grafana-v8.md)」を参照してください。

このセクションでは、Grafana ダッシュボードを構築および保守する方法について、Grafana 管理者およびユーザー向けのベストプラクティスに関する情報を提供します。

作成できるさまざまな種類のダッシュボードの詳細については、Grafana Labs ウェブサイトのブログ記事をの「[Grafana ダッシュボード: 作成できるさまざまなタイプの包括的ガイド](https://grafana.com/blog/2022/06/06/grafana-dashboards-a-complete-guide-to-all-the-different-types-you-can-build/?pg=webinar-getting-started-with-grafana-dashboard-design-amer&plcmt=related-content-1)」を参照してください。

**注記**  
このセクションでは、モニタリングとダッシュボードのメンテナンスの戦略を作成するのに役立ちます。お使いのシステムを一番理解しているのはユーザーです。このセクションを使用して理解を深めてください。最終的には、システムに最適な戦略を作成するのはユーザーの責任です。

## 一般的なオブザーバビリティ戦略
<a name="v12-dash-common-observability-strategies"></a>

サーバーファームなど、監視対象が多い場合は、監視するのに十分な重要性を判断する戦略が必要です。このページでは、監視対象を選択する一般的な方法をいくつか説明します。

論理戦略を使用すると、均一なダッシュボードを作成し、オブザーバビリティプラットフォームをより簡単に拡張できます。

**戦略のガイドライン**
+ USE メソッドはマシンの満足度を、RED メソッドはユーザーの満足度を示します。
+ USE は問題の原因を報告します。
+ RED はユーザーエクスペリエンスを報告し、問題の症状を報告する可能性が高くなります。
+ 両方を監視することは、システムを理解するために重要です。ベストプラクティスとして、原因ではなく症状に注意してください。通常、アラートは RED ダッシュボードで設定されます。

**USE メソッド**

USE は、以下を表します。
+ **[使用率]** — ノード CPU 使用率など、リソースがビジー状態である時間の割合。
+ **[飽和]** — リソースが実行する必要がある作業の量。多くの場合、キューの長さやノード負荷です。
+ **[エラー]** – エラーイベントの数。

この方法は、CPU、メモリ、ネットワークデバイスなどのインフラストラクチャのハードウェアリソースに最適です。詳細については、Brendan Gregg のブログ記事「[USE メソッド](http://www.brendangregg.com/usemethod.html)」を参照してください。

**RED メソッド**

RED は、以下を表します。
+ **[レート]** – 1 秒あたりのリクエスト数
+ **[エラー]** – 失敗したリクエスト数。
+ **[期間]** – これらのリクエストにかかる時間、レイテンシー測定値の分布。

この方法は、サービス、特にマイクロサービス環境に最も適しています。各サービスについて、コードを計測して、各コンポーネントのこれらのメトリクスを公開します。RED ダッシュボードは、アラートや SLA に適しています。適切に設計された RED ダッシュボードは、ユーザーエクスペリエンスのプロキシです。

詳細については、Tom Wilkie のブログ記事「[RED メソッド: サービスの計測方法](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services)」を参照してください。

**4 つのゴールデンシグナル**

[Google SRE ハンドブック](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/#xref_monitoring_golden-signals)によると、ユーザー向けシステムの 4 つのメトリクスしか測定できない場合は、この 4 つのメトリクスに重点を置いてください。

このメソッドは RED メソッドに似ていますが、飽和が含まれています。
+ **[レイテンシー]** – リクエストの処理にかかる時間。
+ **[トラフィック]** – システムにどれだけの需要があるか。
+ **[エラー]** – 失敗したリクエストのレート。
+ **[飽和]** — システムがどれだけ「飽和」状態であるか

## ダッシュボード管理成熟度モデル
<a name="v12-dash-management-maturity-model"></a>

*ダッシュボード管理の成熟度*とは、ダッシュボードエコシステムの設計と効率性を指します。ダッシュボードの設定を定期的に見直して、現在の状況と改善方法を判断することをお勧めします。

大まかに言うと、ダッシュボードの成熟度は低、中、高と定義できます。

 このトピックのコンテンツの多くは、KubeCon 2019 トーク「[スリープ配信オンコール用のフールプルーフ Kubernetes ダッシュボード](https://www.youtube.com/watch?v=YE2aQFiMGfY)」から取得されました。

**低 – デフォルト状態**

この段階では、一貫性のあるダッシュボード管理戦略はありません。ほぼすべてがここから開始します。

ここに位置しているとどのように認識できるのでしょうか？
+ 誰でもダッシュボードを変更できます。
+ 多くのダッシュボードがコピーされているが、ダッシュボードの再利用はほとんどまたはまったくありません。
+ 永久に残る 1 回限りのダッシュボード。
+ バージョンコントロールなし (バージョンコントロールのダッシュボード JSON)。
+ ダッシュボードのブラウジングが多く、適切なダッシュボードを検索します。つまり、必要なダッシュボードを探すために多くの時間を無駄にすることになります。
+ 適切なダッシュボードに誘導するアラートはありません。

**中 – 系統的なダッシュボード**

この段階では、系統的なダッシュボードでダッシュボードの使用を管理し始めます。戦略を立てたかもしれませんが、改善できる点がいくつかあります。

 ここに位置しているとどのように認識できるのでしょうか？ 
+ テンプレート変数を使用してスプロールを防止します。例えば、ノードごとに個別のダッシュボードは必要ありません。クエリ変数を使用できます。さらに、データソースをテンプレート変数にすることもできます。これにより、異なるクラスター間で同じダッシュボードを再利用したり、バックエンドを監視したりできます。

  アイデアについては、「[変数](v12-dash-variables.md)」の例のリストを参照してください。
+ [オブザーバビリティ戦略に従った系統的なダッシュボード](#v12-dash-common-observability-strategies)。
+ 次のレベルにドリルダウンした階層ダッシュボード。
+ ダッシュボードの設計には、サービス階層が反映されます。例えば、サービスごとに 1 行のRED メソッドを使用できます。ダッシュボードをスクロールダウンすると、行の順序にデータフローが反映される可能性があります。
+ 大きさが異なる場合にサービスダッシュボードを分割することで比較します。集約されたメトリクスが重要な情報を枯渇させないようにしてください。
+ 可能な場合は色を効果的に使用し、軸を正規化する表現豊かなグラフを作成します。
  + 効果的な色の例: 青は良好、赤は問題があることを意味します。[しきい値](v12-panels-configure-thresholds.md)はそれに役立ちます。
  + 軸の正規化の例: CPU 使用率を比較する場合は、マシンのコア数が異なる可能性があるため、生の数値ではなくパーセンテージで測定します。CPU 使用率をコア数で正規化すると、CPU の数を知らなくても、すべてのコアが 100% で使用されていることを信頼できるため、認識負荷が軽減されます。
+ 誘導ブラウジングは推測を減らします。
  + テンプレート変数を使用すると、ランダムにまたは目的なくブラウズするのが難しくなります。
  + ほとんどのダッシュボードは、アラートによってリンクする必要があります。
  + ブラウジングはリンクで指示されます。詳細については、「[ダッシュボードリンクの管理](v12-dash-manage-dashboard-links.md)」を参照してください。
+  バージョン管理されたダッシュボード JSON。

**高 – 最適化使用**

この段階では、一貫性のある思慮深い戦略でダッシュボード管理の使用を最適化できています。メンテナンスが必要ですが、結果には価値があります。
+ スプロールを積極的に減らします。
  + 既存のダッシュボードを定期的に確認し、関連性があることを確認します。
  + マスターダッシュボードリストに追加された承認済みダッシュボードのみが対象です。
  + ダッシュボードの使用を追跡します。[[使用率のインサイト]](v12-dash-assess-dashboard-usage.md) を活用できます。
+ 設計上の一貫性を確保します。
+ スクリプティングライブラリを使用してダッシュボードを生成し、パターンとスタイルの一貫性を確保します。
  + grafonnet (Jsonnet)
  + grafanalib (Python)
+ ブラウザでは編集機能を提供しません。ダッシュボードビューワーでは、変数を使用してビューを変更します。
+ ダッシュボードの閲覧は例外であり、ルールではありません。
+ 本番環境のインスタンスではなく、その目的専用の別の Grafana インスタンスで実験とテストを実行します。テスト環境のダッシュボードが有用であることが証明されたら、そのダッシュボードをメイン Grafana インスタンスに追加します。

## ダッシュボードを作成するためのベストプラクティス
<a name="v12-dash-best-practices-for-creating-dashboards"></a>

このセクションでは、Grafana ダッシュボードを作成するときに従うべきいくつかのベストプラクティスについて説明します。

**[開始する前に]**

 ダッシュボードを作成する前に考慮すべき原則をいくつかご紹介します。

**ダッシュボードはストーリーを伝えたり、質問に答えたりするべきである**

ダッシュボードでどのようなストーリーを伝えようとしていますか？ 大規模から小規模、または一般的から特定まで、データの論理的な進行を作成してみてください。このダッシュボードの目標は何ですか？ (ヒント: ダッシュボードに目標がない場合は、ダッシュボードが本当に必要かどうかを自分に問いかけてみてください)

グラフはシンプルに保ち、尋ねる質問への回答に集中してください。例えば、質問が「どのサーバーに問題があるか」である場合、すべてのサーバーデータを表示する必要はありません。問題のあるデータのみを表示します。

**ダッシュボードは認知負荷を軽減し、付加すべきでない**

*認知負荷*とは、基本的には何かを理解するためにどれだけ多くのことを考える必要があるかということです。ダッシュボードの解釈を容易にします。他のユーザーと未来のあなた (午前 2 時に何が壊れたかを理解しようとしているとき) は、それを有用に思うでしょう。

 自分に問いかけてください。
+ 各グラフが正確に何を表すかわかりますか？ それは明白ですか、それともそれについて考える必要がありますか？
+ それを他の誰かに見せると、その人物がそれを理解するのにどのくらい時間がかかりますか？ わからなくなる場合があるでしょうか？

**監視戦略を持つ**

新しいダッシュボードを簡単に作成できます。ダッシュボードの作成を最適化し、計画に従うのは難しいですが、その価値はあります。この戦略は、ダッシュボードスキーム全体を管理し、個々のダッシュボード設計に一貫性を持たせるべきです。

詳細については、「[一般的なオブザーバビリティ戦略](#v12-dash-common-observability-strategies)」と「[ダッシュボード管理の成熟度レベル](#v12-dash-management-maturity-model)」を参照してください。

**書き留める**

戦略または設計ガイドラインを作成したら、時間の経過に伴う一貫性を維持するために書き留めます。

**従うべきベストプラクティス**
+ 新しいダッシュボードを作成するときは、意味のある名前をつけましょう。
  + 再生または実験目的でダッシュボードを作成する場合は、名前に `TEST`または `TMP`という単語を入力します。
  + ダッシュボード名に自分の名前またはイニシャルを含めるか、タグとして含めて、ダッシュボードの所有者を知らせることを検討してください。
  + 一時実験ダッシュボードは、完了したら削除するようにします。
+ 関連するダッシュボードを多数作成する場合は、ナビゲーションを容易にするためにそれらを相互参照する方法を検討してください。詳細については、このセクション後半の「[ダッシュボードを管理するためのベストプラクティス](#v12-dash-best-practices-for-managing-dashboards)」を参照してください。
+ Grafana はデータソースからデータを取得します。[データソースに接続する](AMG-data-sources.md) 全般、および特定のデータソースに関する基本的な理解が重要です。
+ 不要なダッシュボードの更新を避けて、ネットワークまたはバックエンドの負荷を軽減します。例えば、データが 1 時間ごとに変更される場合、ダッシュボードの更新レートを 30 秒に設定する必要はありません。
+ 異なる単位または範囲の時系列を表示するときは、左右の Y 軸を使用します。
+ ダッシュボードとパネルにドキュメントを追加します。
  + ダッシュボードにドキュメントを追加するには、[テキストパネルの視覚化](v12-panels-text.md)をダッシュボードに追加します。ダッシュボードの目的、便利なリソースリンク、ユーザーがダッシュボードを操作するために必要な手順などを記録します。
  + パネルにドキュメントを追加するには、パネル設定を編集し、説明を追加します。追加したテキストは、パネルの左上隅にある小さな `i` 部分にカーソルを合わせると表示されます。
+ [テンプレートと変数](v12-dash-variables.md)を使用して、ダッシュボードを再使用して一貫性を強化します。
+ グラフデータのスタックには注意してください。視覚化は誤解を招き、重要なデータを覆い隠す可能性があります。ほとんどの場合、オフにすることをお勧めします。

## ダッシュボードを管理するためのベストプラクティス
<a name="v12-dash-best-practices-for-managing-dashboards"></a>

 このページでは、Grafana ダッシュボードを管理するときに従うべきいくつかのベストプラクティスについて説明します。

**[開始する前に]**

ダッシュボードの管理を開始する前に考慮すべき原則をいくつかご紹介します。

**戦略的オブザーバビリティ**

[一般的なオブザーバビリティ戦略](#v12-dash-common-observability-strategies)はいくつかあります。これらを調査し、そのうちの 1 つを採用するか、自分で戦略を考えるかを決定すべきです。いずれにせよ、計画を立て、書き留めて、それに従います。

必要に応じて、変化するニーズに戦略を適応させます。

**成熟度レベル**

ダッシュボードの成熟度レベルは？ 現在のダッシュボード設定を分析し、[ダッシュボード管理成熟度モデル](#v12-dash-management-maturity-model)と比較します。現時点の状況を理解することは、希望する場所にたどり着く方法を決定するのに役立ちます。

**従うべきベストプラクティス**
+ ダッシュボードのスプロールは避けてください。つまり、ダッシュボードの制御されない成長は避けてください。ダッシュボードのスプロールは、適切なダッシュボードを見つける時間に悪影響を及ぼします。ダッシュボードの複製と「単一の項目」の変更 (元のタグを保持することが最悪のシナリオです) が最も簡単なスプロールです。
  + ダッシュボードを定期的に確認し、不要なダッシュボードを削除します。
  + 一時的なダッシュボードをテストなどの目的に作成する場合、名前のプレフィックスに `TEST:` を付けます。完了したらダッシュボードを削除します。
+ 大きな変更のないダッシュボードをコピーすることはお勧めしません。
  + ドキュメントの変更、バグ修正、メトリクスの追加など、元のダッシュボードの更新を見逃す可能性があります。
  + 多くの場合、テンプレートパラメータを設定してビューをカスタマイズするためにコピーが行われています。代わりに、マスターダッシュボードへのリンクを維持し、[URL パラメータ](v12-panels-configure-data-links.md#v12-panels-data-link-variables)を使用してビューをカスタマイズしてこれを行うべきです。
+ ダッシュボードをコピーする必要がある場合は、名前を明確に変更し、ダッシュボードタグをコピー*しないでください*。タグは、検索中に使用されるダッシュボードの重要なメタデータです。タグをコピーすると、誤一致が発生する可能性があります。
+ ダッシュボードまたは相互参照ダッシュボードのダッシュボードを維持します。これには、いくつかの方法があります。
  + ダッシュボードリンク、パネル、またはデータリンクを作成します。リンクは、他のダッシュボードまたは外部システムに移動できます。詳細については、「[ダッシュボードリンクの管理](v12-dash-manage-dashboard-links.md)」を参照してください。
  +  [ダッシュボードリストパネル](v12-panels-dashboard-list.md)を追加します。その後、タグまたはフォルダ検索を実行して、表示内容をカスタマイズできます。
  + [テキストパネル](v12-panels-dashboard-list.md)を追加し、マークダウンを使用して表示をカスタマイズします。