Dashbords基礎設施

1）為什麼需要它

單一狀態圖：從群集和網絡到數據庫和隊列。
快速RCA和後模擬：一捆指標↔日誌↔跟蹤。
按服務和平臺劃分的SLO：控制可用性和潛在性。
FinOps透明度：服務、tenant'am和環境的數量/成本。
合規性/安全性：補丁/漏洞、訪問、異常狀態。

方法：用於查詢的金信號（latency, traffic, errors, saturation）, RED （Rate, Errors, Duration）,用於資源的USE （Utilization, Saturation, Errors）。

2）好達什伯德的原則

有效性（Actionable）：每個面板都回答「接下來要做什麼」。
分層：概述→域→深潛→。
模式/變量：「cluster」，「namespace」，「service」，「tenant」，「env」。
單位：ms代表潛伏期、%、RPS、operation/s、字節。
一致性計時器：默認為1-6小時，快速預設5m/15m/24h。
Drilldown：從面板到logi （Loki/ELK）和軌道（Tempo/Jaeger）。
所有權：dashboard上列出了所有者,SLO, runbook,呼叫聯系人。

3）文件夾結構和角色

00_Overview是平臺的頂層概述。
10_Kubernetes-集群，nods，workloads，NRA/VPA，容器。

20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.

30_Storage_DB-PostgreSQL/MySQL，Redis，Kafka/RabbitMQ，對象存儲。
40_CICD_Runner-piplines，代理商，文物，註冊。
50_Security_Compliance-漏洞、補丁、RBAC、審核事件。
60_FinOps_Cost-服務成本/tenant/群集,處置。
99_Runbooks指向指令和SLO卡的鏈接。

角色：Platform-SRE（完全訪問），Service-Owner（其空間），Security/Compliance，Finance/FinOps，僅查看。

4）平臺（Landing）審查行車)

目的：≤30秒內了解一切是否正常。

• SLO平臺（API邊緣可用性）：目標值、實際值、錯誤時代、burn-rate。
• 主要入口點的p50/p95/p99潛伏期。
• 4xx/5xx錯誤和具有回歸的頂端。
• 資源飽和（CPU，RAM，網絡，磁盤）-每個群集的p95。
• 事件/Alerta（活動）和最新版本。
• 成本/小時（接近）和每周趨勢。

變量模式：「env」，「region」，「cluster」，「tenant」。

5） Kubernetes： 集群和worcloads

1.集群/nods

CPU/Memory, pressure （memory/cpu）, IO驅動器,inode。

子系統： kube-api, etcd,控制器；kubelet health.

2.Worcloads

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.

HPA目標與實際指標。

3.群集內的網絡路徑

eBPF/Netflow: top talkers, drops, retransmits.

4.事件K8s

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

Latency p95 histogram_quantile (0. 95, sum by (le, service) (rate(http_request_duration_seconds_bucket[5m])))

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6）邊緣、網格和DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast：按區域分配流量,failover事件。
• DNS： Resolve的潛伏期,NXDOMAIN/SERVFAIL速率,熱門速率。
• CDN/WAF：規則鎖定，異常流量（機器人/刮板）。

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7）數據庫和storage

PostgreSQL/MySQL：qps，latency，鎖定waits，repliclag，備份/失敗。
Redis：命中率,evictions,記憶,緩慢的命令。
Kafka/RabbitMQ：按消費者組，rebalances，unacked消息排列。
對象存儲：查詢,錯誤,egress, lat p95。

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8） CI/CD和文物

管道概述：成功/運行時間,排隊等候。
部署健康：版本，金絲雀/藍綠色狀態，熱身時間。
圖像記錄：大小，最後推和。

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9）安全和合規性

補丁和漏洞：具有關鍵CVE的註釋/映像比例,平均「補丁時間」。
RBAC和秘密：不成功的訪問嘗試，訪問秘密。
審核事件：關鍵組件的輸入/更改,drift。
WAF/DLP/PII修訂版：規則鎖定，掩蓋錯誤。

10）徽標和軌道： 端到端概述

Logs錯誤摘要（Loki/ELK）： top exceptions,新簽名。
「使用過濾器跳至日誌」按鈕（LogQL/ES查詢）。
曲目：頂部慢速間諜,無跟蹤上下文的查詢百分比。

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11） FinOps： 成本和報廢

服務/tenant/集群成本（根據計費/出口商）。
熱/冷節點：idle resource, rightsizing推薦（CPU/Mem）。
Data egress, L7查詢及其成本。
動態：每周/每月，預測。

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• 效率系數：「RPS/$」或「SLO-分鐘/$」。

12）SLO，錯誤和burn-rate

每個領域的dashboard上的SLO卡：目標，時期，錯誤（預算）。
Burn-rate alerta（兩個速度：快速/慢速）。

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13）成像標準

面板計時器：系列時間系列，KPI stat，top-N表，潛伏期熱圖。
傳說和Units：強制性的；縮短的標簽，SI格式。
顏色區域：SLO/threshold（統一）上的綠色/黃色/紅色。
面板說明：我們測量什麼,源,運行手冊鏈接,所有者。

14）面板模板（快速啟動）

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.

Top endpoints by error/latency.

Drilldown到logi 「trace_id=$trace」。

(B) Node Health

CPU/Memory/Disk/Network-Nods p95，熱列表。
壓力,throttling, drop包。

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.

備用狀態/最後成功。

(D) Kafka Lag

按組排列，消費率vs生產，重建。

(E) Cost & Util

按服務計算的成本/小時,idle%, rightsizing hints,預測。

15）變量和標簽（推薦集）

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16）與Alerting和事件管理集成

Alertmanager/Grafana-alert中的規則，其中引用了所需的dashbord和已經替換的變量。
P1/P2通過SLO標準，自動定位到呼叫。
圖上發布/事件註釋。

17） dashbords質量： 支票清單

• 所有者和聯系人。
• SLO/thresholds已被記錄。
• 變量工作並限制查詢量。
• 所有帶有槍支和傳奇的面板。
• Drilldown進入標記/軌跡。
• 面板堆放在2-3個「屏幕」中（每公裏沒有滾動）。
• 請求響應時間≤2 -3 c（緩存,downsample）。
• 沒有「死」面板和破碎度量。

18）行車記錄儀本身的性能和成本

用於重聚的downsampling/recording規則。
緩存（query-frontend/Repiter）和範圍/步驟限制。
測試機庫：TSDB/群集上的負荷在典型的 dashboard請求中。
標簽重組（低基數），放棄通配符。

19）實施計劃（叠代）

1.第一周：Landing+K8s/Edge評論，基本的SLO，業主。
2.第2周：DB/Queues，博客和跟蹤集成（drilldown），burn-rate alerta。
3.第3周：FinOps-dashbords，版權指南，價值報告。
4.第4周+：安全/合規性，SLO卡的自動發生，行車碼的回歸測試。

20）迷你常見問題

需要多少dashbord?

每個域（K8s、Edge、DB、Queues、CI/CD、Security, Cost）至少有1條評論+。其余的是成熟。

更重要的是-度量標準或邏輯?

癥狀指標和SLO，原因日誌。通過「trace_id」和一致性標簽捆綁在一起。

如何不在面板上「淹死」？
等級，顯式所有者，度量衛生，定期咆哮和刪除「死板」。

底線

基礎設施行車記錄儀不是「美麗的圖形」，而是管理工具：SLO控制，快速RCA和有意識的FinOps。標準化變量，視覺模式和所有者；向Log/Trail提供驅動,並自動化burn-rate alerta。這將使整個平臺具有可預測性，反應速度和成本透明度。