监控 on Tony老师的博客

Prometheus 监控体系：从零搭建生产级

Sun, 08 Aug 2021 14:00:00 +0800

一套生产级 Prometheus 监控体系，绝不只是"跑起来一个 Prometheus 进程 + 配个 Grafana 面板"那么简单。从 2017 年 Prometheus 2.0 GA 至今，它的存储引擎、查询语言、生态工具链经历了数代演进。一个新项目如果按"开箱即用 demo"的认知去部署，三个月内几乎必然会在指标基数、告警风暴、长存储三件事上踩坑。

本文按"架构 → 数据采集 → 存储与查询 → 告警 → 高可用 → 落地清单"六个层次展开。

可观测性三大支柱：Metrics、Logs、Traces 的工程落地

Mon, 15 Mar 2021 10:00:00 +0800

2017 年 Pinterest 工程团队在 SREcon 上分享其监控平台 Bender 时展示过一组数字：单业务域的时序指标规模动辄上万，传统告警体系面对每天数百条告警已经疲于奔命，但工程师真正关心的"这个请求为什么慢"却往往无解。那个时刻暴露了一个被广泛忽视的事实——传统监控（Monitoring）解决的是"系统是否在运行"，而真正想回答"系统为什么这样运行"，需要的是可观测性（Observability）。

监控与可观测性不是同义词。监控是一组预定义的仪表盘和告警规则，依赖"已知未知"——你必须先想象故障形态。可观测性是一套能从系统外部行为反推内部状态的能力，依赖"未知未知"——即使面对从未发生过的故障，也能从足够丰富的遥测数据中推断根因。

Linux 性能观测：CPU、内存、I/O 基础

Thu, 25 Aug 2016 16:00:00 +0800

线上服务响应慢了，你第一反应是什么？看应用日志？重启？扩容？这些都不是诊断——是赌博。

性能问题的定位需要一套先全局后局部、先假设后验证的工程方法。Brendan Gregg 在 ACM Queue（2012）和 Systems Performance（2013，Prentice Hall）里总结的 USE 方法（Utilization, Saturation, Errors）是入门最快的框架：对每个资源，先查利用率、查饱和度、查错误。

这篇文章用一台典型的 Linux 服务器（4 核 8GB，跑 Nginx + MySQL + 应用进程）走一遍 USE 流程，掌握 top、vmstat、iostat、mpstat、pidstat、free、strace 的基础读法。