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。这将使整个平台具有可预测性，反应速度和成本透明度。