grafana-platform-dashboard

Grafana プラットフォームダッシュボード

プラットフォーム運用ダッシュボードを設計し、オペレーターがまずテナントに影響するリスクを確認し、その後、情報過多にならないようサービス固有の健全性を詳しく確認できるようにします。

クイックスタート

ユーザーからプラットフォームダッシュボードの更新や信頼性チェックを依頼された場合に、このスキルを使用します。

1. ダッシュボードの対象を確認します。

oc --context <ctx> get grafanadashboard -A | rg -i '<dashboard-name-or-theme>'

2. ダッシュボードと JSON をエクスポートします。

skills/grafana-platform-dashboard/scripts/grafanadashboard_roundtrip.sh export \
  --context <ctx> \
  --namespace <ns> \
  --name <grafanadashboard-name> \
  --out-dir /tmp/<workspace>

3. JSON を編集し、すべての PromQL を検証します。

skills/grafana-platform-dashboard/scripts/promql_scan_thanos.sh \
  --context <ctx> \
  --dashboard-json /tmp/<workspace>/<name>.json

4. 安全に本番環境へ適用します。

skills/grafana-platform-dashboard/scripts/grafanadashboard_roundtrip.sh apply \
  --context <ctx> \
  --namespace <ns> \
  --name <grafanadashboard-name> \
  --json /tmp/<workspace>/<name>.json

ワークフロー

1) プラットフォームの契約に基づいてスコープを確定する

パネルを編集する前に、platform-contract.md のプラットフォーム契約を使用します。

1. L1 のコマンドビューは、テナントに影響が及ぶ前の重要なシグナルに限定します。
2. まずゲートに準拠したコンポーネント（重要な CO ゲート、ノード、MCP、コア API／etcd／ingress）を使用します。
3. サービス固有のセクション（Crossplane、Keycloak）は L1 より下に配置します。

2) 情報アーキテクチャを徹底する

layout-guidelines.md を使用します。

1. L1：重要な情報のみ、即時のアクション、最小限のパネル数にします。
2. L2：依存関係のドメインごとにプラットフォームサービスを配置します。
3. L3：詳細な調査用（将来の GPU ダッシュボードなど）とし、L1 には含めません。

3) 既知のライブラリからクエリを作成する

promql-library.md を使用します。

1. 動作確認済みのクエリを起点にし、ラベルの変更は最小限にします。
2. 装飾的なチャートよりも、件数やアクションテーブルを優先します。
3. 依頼された場合は、アラートのノイズ（ArgoCD／GitOps など）を明示的にフィルタリングします。

4) 適用前に検証する

編集後は必ずスキャンスクリプトを実行します。

skills/grafana-platform-dashboard/scripts/promql_scan_thanos.sh \
  --context <ctx> \
  --dashboard-json <file.json> \
  --output <scan.tsv>

合格基準：すべてのクエリで success が報告され、エラーや解析エラーが 0 件であること。

5) 適用して同期を確認する

検証に成功してから適用します。

skills/grafana-platform-dashboard/scripts/grafanadashboard_roundtrip.sh apply ...
oc --context <ctx> -n <ns> get grafanadashboard <name> \
  -o jsonpath='{.status.conditions[?(@.type=="DashboardSynchronized")].status}{"|"}{.status.conditions[?(@.type=="DashboardSynchronized")].reason}{"\n"}'

6) オペレーター向けの要約で締めくくる

以下を報告します。

1. 変更内容（パネル名と目的）。
2. 検証結果（クエリ数と失敗数）。
3. 同期ステータスと残存リスク。
4. 次のステップ：本番環境での変更を GitOps 管理のソースに反映します。

設計ルール

1. テナントへの影響を予測する重要な指標を最初に配置します。
2. すべての赤色のパネルから、取るべきアクションが分かるようにします。
3. 曖昧なパネル名は避けます（たとえば、「platform pods」を具体的な名前空間の範囲に置き換えます）。
4. L1 のノイズを抑え、詳細は下位レベルまたは専用のダッシュボードに移します。
5. GPU の詳細な診断は専用の GPU ダッシュボードに配置し、L1 には混在させません。

参考資料

1. プラットフォーム契約
2. PromQL パネルライブラリ
3. レイアウトガイドライン
4. references/grafana-platform-dashboard.feature — 実行可能な仕様：契約に基づいてスコープと情報アーキテクチャを確定し、既知のライブラリからクエリを作成して、適用前に検証し、同期を確認します（soc-qk4b）