Sre on PlumePHP

可观测性数据存储选型：TSDB、列式存储、对象存储与成本优化

Thu, 13 Aug 2026 13:00:00 +0800

可观测性的最大隐性成本是存储。 一个中等规模的 K8s 集群每月可能产生数 TB 的 Metrics、数十 TB 的 Logs 和数百 GB 的 Traces。选择合适的存储backend、合理的数据保留策略和压缩方案，能让可观测性成本降低 50-80%。

云原生 APM 与性能剖析：Continuous Profiling 与火焰图

Thu, 13 Aug 2026 12:50:00 +0800

APM 解决的是"哪里慢了"，Profiling 解决的是"为什么慢"。 Metrics 告诉你延迟增加了，Traces 告诉你哪个服务是瓶颈，但只有 Profiling 能精确到某一行代码、某个函数调用、某个锁竞争——找到那 20% 的代码消耗了 80% 的 CPU。

Kubernetes 可观测性实战：集群、Pod、网络、存储全链路监控

Thu, 13 Aug 2026 12:40:00 +0800

Kubernetes 让基础设施变得可编排，但也让故障排查变得多层次。 一个请求失败可能是因为应用代码问题、Pod 资源不足、节点磁盘压力、网络策略拦截、DNS 解析超时、Ingress 配置错误、API Server 响应慢，或者 etcd 存储满了。K8s 可观测性的目标是建立从集群到容器的全链路可视性。

eBPF 可观测性：内核可编程追踪与性能剖析

Thu, 13 Aug 2026 12:30:00 +0800

eBPF 不是在 Linux 内核中添加了一个新功能，而是给内核装上了一个「可编程的虚拟机」。 它不修改内核源码、不加载内核模块，就能安全地在 Kernel Space 执行你的代码——在包到达用户态前拦截、在磁盘写入前审计、在函数调用发生时记录。这是过去只有内核开发者才能做到的事。

SLO、SLI 与错误预算：数据驱动的可靠性工程

Thu, 13 Aug 2026 12:20:00 +0800

「如果没有量化的可靠性目标，你就无法判断一次发布是『太激进』还是『太保守』。」 — Google SRE Book

SLO（Service Level Objective）是 SRE 文化的基石。它将模糊的"系统要稳定"转化为精确的"99.9% 的请求必须在 200ms 内返回"，进而推导出错误预算——告诉你这个月还能承受多少停机时间。

告警设计与事件响应：降噪、分级、值班与事后复盘

Thu, 13 Aug 2026 12:10:00 +0800

好的告警是「不打扰」，坏的通知是「狼来了」。 当 PagerDuty 每天响 50 次，团队 3 周内就会学会忽略所有告警——包括真正重要的那个。告警设计的终极目标是：每一次通知都值得被打断。

日志系统全栈：Loki、EFK、Vector 与日志架构设计

Thu, 13 Aug 2026 12:00:00 +0800

日志是可观测性中被低估最多的支柱。 在 Metrics 显示"支付错误率上升"、Traces 指出"银行 API 超时"后，是日志告诉你"具体是第 3 次重试时连接超时"、“当时的请求参数是什么”、“数据库中对应的订单状态”。一个设计良好的日志系统能让排查时间从小时缩短到分钟。

分布式追踪实战：Jaeger、Tempo 与采样策略

Thu, 13 Aug 2026 11:50:00 +0800

分布式追踪是微服务架构的「X光机」。 当一次用户请求拆分成 50 个服务调用、经过 3 个消息队列、访问 5 个数据库时，没有追踪你就只能盲人摸象。追踪让你看到完整的请求路径、精确到微秒的延迟分布、以及跨服务边界的数据流。

OpenTelemetry 完全指南：标准化可观测性框架

Thu, 13 Aug 2026 11:40:00 +0800

OpenTelemetry 的使命是终结可观测性领域的「数据孤岛」。 在这之前，每家公司可能同时使用 Zipkin、Jaeger、Prometheus、StatsD、Fluentd 等 5+ 种采集方案，每种都有自己的 SDK 和数据格式。OTel 提供了一个统一的标准，让一次埋点就能产出 Metrics、Logs、Traces 三种信号。

Grafana 可视化与仪表盘设计：从数据到洞察

Thu, 13 Aug 2026 11:30:00 +0800

好的仪表盘不是数据的堆砌，而是问题的答案。 一个优秀的 Grafana Dashboard 应该在 5 秒内让观者理解系统状态，在 30 秒内定位到问题方向。

一、Grafana 核心概念

1.1 数据流

Grafana 架构：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Dashboard │ ←── │ Grafana │ ←── │ Data Source │
│ (Panel集合) │ │ Server │ │ (Plugin) │
└─────────────┘ └──────┬──────┘ └──────┬──────┘
 │ │
 ┌────────┴────────┐ │
 ↓ ↓ │
 ┌──────────┐ ┌──────────┐ │
 │ Prometheus│ │ Loki │ │
 └──────────┘ └──────────┘ │
 │
 ┌──────────┐ ┌──────────┐ │
 │ Tempo │ │ InfluxDB │ │
 └──────────┘ └──────────┘ │
 │
 ┌──────────┐ ┌──────────┐ │
 │MySQL/Post│ │Elasticsearch │
 └──────────┘ └──────────┘ │

1.2 组织层级

Grafana 权限模型：
Organization
├── Users（角色：Admin / Editor / Viewer）
│
├── Folders
│ ├── Dashboard 1
│ │ ├── Panel A（Time Series）
│ │ ├── Panel B（Stat）
│ │ └── Panel C（Table）
│ │
│ └── Dashboard 2
│
└── Alert Rules
 ├── Notification Policies
 └── Contact Points

二、仪表盘设计原则

2.1 OLAP 设计原则

OLAP = Overview（概览） → List（列表） → Afferent（关联） → Particulars（详情）

第一层：Overview — 全局健康
 ├── 4 大黄金信号：流量、延迟、错误、饱和度
 ├── 用 Stat/Gauge 展示核心 KPI
 └── 时间范围：1h / 6h

第二层：List — 受影响的服务列表
 ├── 按错误率/延迟排序的服务表格
 ├── 红色 = 异常，黄色 = 警告
 └── 可点击跳转到详情页面

第三层：Afferent — 关联上下文
 ├── Metrics + Logs + Traces 叠加
 ├── Annotation 标记部署/告警事件
 └── 时间范围缩小到相关窗口

第四层：Particulars — 下钻详情
 ├── 单个服务的全维度指标
 ├── 该服务的日志面板
 └── 该服务的追踪面板

2.2 颜色语义

颜色	含义	使用场景
绿色	正常/健康	成功率、健康状态
黄色	警告/注意	接近阈值、资源紧张
红色	异常/错误	错误率上升、服务不可用
蓝色	信息/中性	总量、正常流量
灰色	禁用/无数据	未启用、无指标

不要：用绿色表示"错误"（色盲友好设计）

Prometheus 深度解析：指标采集、PromQL、服务发现、Recording Rule 与 Alertmanager

Thu, 13 Aug 2026 11:20:00 +0800

Prometheus 不仅是一个时序数据库，它是云原生监控的事实标准。 从 Kubernetes 集群到 Spring Boot 应用，从网络设备到自定义业务指标，Prometheus 生态已经覆盖了现代可观测性的每一个角落。

可观测性三大支柱深度解析：指标、日志、追踪

Thu, 13 Aug 2026 11:15:00 +0800

「监控是别人告诉你哪里坏了，可观测性是你自己发现为什么坏了。」 — Charity Majors（Honeycomb CEO）

传统监控（Monitoring）问的是：“系统是不是正常工作？“可观测性（Observability）问的是：“系统为什么是现在这样？“这两个层次的区别，决定了从被动告警到主动探索的根本转变。

专题四：云原生可观测性

Thu, 13 Aug 2026 11:10:00 +0800

「可观测性」不是一个工具，而是一种能力：让系统的内部状态通过输出可被理解。

在现代分布式系统中，可观测性（Observability）已经不再是"锦上添花"的运维手段，而是工程团队的核心基础设施。它直接影响故障排查效率、系统可靠性、资源利用率和业务决策质量。