可观测性系列
企业监控架构演进 9 篇文章
MYSQL的监控
MySQL权限经验原则
权限控制主要是出于安全因素，因此需要遵循一下几个经验原则：
- 只授予能满足需要的最小权限，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。
- 创建用户的时候限制用户的登录主机，一般是限制成指定IP或者内网IP段。
- 初始化数据库的时候删除没有密码的用户。安装完数据库的时候会自动创建一些用户，这些用户默认没有密码。
- 为每个用户设置满足密码复杂度的密码。
- 定期清理不需要的用户。回收权限或者删除用户。
eg:
Prometheus是一个开源的监控与时间序列数据库系统,在近年来得到了越来越广泛的应用。
官方的架构图如图所示：
在互联网业务分布式、高并发、多云部署的大背景下，SRE（网站稳定性工程） 成为保障服务可用性的核心角色，而监控体系则是SRE的“眼睛”。本文从SRE核心理念出发，拆解现代监控体系的痛点、技术栈选型、Prometheus核心原理与告警实战，还原一套可落地的企业级监控建设思路。
前情概述：
在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。
前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。
在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。
前情概述：
在《监控系统企业架构演进史-跨地域混合云》中，监控系统已经逐步成熟且企业化发展。 这一章节简单讲述一下期间的拨测能力搭建，以下是这套系统的发展史，在监控平台搭建的过程中，内部监控采集还不足以满足企业业务需求，在计划发展apm之前，异地拨测的黑匣子监控也纳入了该系统的一个子功能。
在互联网服务的全链路监控体系中，白盒监控侧重主动挖掘潜在隐患、提前预判风险，黑盒监控则以故障为核心导向，快速感知已发生的线上问题。二者协同才能构建完整的监控闭环。而多数互联网企业长期存在公网服务、用户侧最后一公里的监控盲区，用户侧故障往往只能被动等待报障后才启动排查，黑盒拨测监控系统正是为解决这一行业痛点而生。
在互联网业务高速扩张、多云部署、资产指数级增长的背景下，监控平台是保障服务稳定性的核心基建。本文完整复盘某大型互联网公司监控平台2019-2021年的演进之路，从解决老旧监控性能瓶颈，到跨云分布式监控落地，再到云原生平台化治理，呈现监控体系从0到1搭建→规模化扩展→平台化治理的完整蜕变。
在企业业务全球化、混合云规模化部署的背景下，跨IDC、跨国内外、多云异构的监控治理成为稳定性保障的核心难题。传统监控方案要么依赖高成本专线改造、侵入业务架构，要么无法兼顾节点自治与全局统一，同时监控系统作为非营收类基建，还需严格控制资源占用且不允许能力降级。
在多云部署、全球化组网、服务规模指数级增长的互联网业务场景中，监控平台早已超越“指标采集+告警通知”的基础定位，成为保障全链路稳定性的核心基建。本文基于大型互联网企业监控平台的真实演进历程，拆解2022年监控平台从规模化覆盖向产品化、易用化、智能化升级的完整规划与落地思路。
可观测存储技术 8 篇文章
引言
可观测性（Observability）已成为云原生时代的基础设施核心。Metrics、Logs、Traces、RUM、Profiling 五大信号各自产生海量数据，而它们的存储效率直接决定了平台的成本边界和查询性能。而在采集侧，eBPF 技术正在重塑数据获取方式。这一切的背后，存储架构的演进是支撑可观测性规模化落地的基石。
引言
时序数据库（TSDB）是可观测性存储的基石。如果说上一篇是宏观的"存储地图"，那本篇就是深入地图中的"核心城区"——四大主流 TSDB 的存储引擎。无论你是刚开始接触 Prometheus 还是正在调研 VictoriaMetrics，理解底层存储引擎的设计哲学，能帮你更高效地用对它们。
引言
日志是可观测性三大支柱中数据量最大、存储成本最高的信号。与指标（Metrics）的固定数值结构不同，日志的变长文本和半结构化特性使得存储设计面临独特挑战：既要支持全文检索，又要控制存储成本。
调用链（Distributed Tracing）存储是可观测性体系中技术分歧最大的领域之一。不同于时序和日志有相对收敛的存储模式（TSDB 与 ClickHouse-like），调用链系统的存储方案因索引策略的根本分歧而分化为三条路径。
前端监控（Real User Monitoring, RUM）与后端监控的根本差异在于数据模型：RUM 采集的是带海量高基数属性的事件流——每个用户访问产生 session_id、user_id、page_url 等上百个维度，传统时序数据库（TSDB）的 label-set 模型在此场景下会剧烈退化。
持续性能分析（Continuous Profiling）是可观测性的重要支柱之一。与传统的采样 Profiling 不同，持续 Profiling 以固定频率全时采集应用和内核的调用栈快照，生成火焰图，帮助团队发现性能瓶颈、内存泄漏和资源热点。本文聚焦 Profiling 数据的存储架构：从 Google pprof 数据模型与火焰图构建算法开始，详细分析 Pyroscope 从 V1（TSDB+Parquet）到 V2（Metastore+Segments）的架构演进、Parca 与 FrostDB 的列式存储创新、Datadog/Splunk 等商业方案，最后通过对比表格呈现各方案的差异化选择。
可观测性架构在过去五年经历了从"分治"到"统一"的深刻转变。各信号（指标、日志、追踪、Profiling）从独立的专用后端走向共享存储与统一数据模型，而 eBPF 作为新一代采集手段，为这一转变提供了前所未有的数据深度与广度。本文将聚焦四个维度：eBPF 采集存储设计、统一存储架构（LGTM 分治 vs ClickHouse 统一）、OpenTelemetry 统一数据模型、以及对象存储与存算分离的演进方向。
前面 7 篇分别深入剖析了 TSDB、日志、调用链、RUM、Profiling 和 eBPF 等各个可观测性领域的存储架构。本篇将这些知识融会贯通，提供一份面向场景的存储选型决策框架。不同团队的规模、技术栈、预算和需求层次各不相同——没有"最佳"存储，只有"最适合你的"存储。本篇可以作为实用参考工具书，帮助你在具体场景下快速筛选方案。
eBPF 技术 7 篇文章
eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。
bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层：
- 内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据
- 用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件
这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。
前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。
容器级 OOM 定位
在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。
前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。
概述：
MongoDB 目前使用广泛，但是缺乏有效的可观测能力。
DeepFlow 在可观测能力上是很优秀的解决方案，但是却缺少了对 MongoDB 协议的支持。
该文是为 DeepFlow 扩展了 MongoDB 协议解析，增强 MongoDB 生态的可观测能力，简要描述了从协议文档分析到在 DeepFlow 内实现代码解析的过程拆解。
部署过程和指令参考：pixie install
Pixie平台主要由以下组件组成：
Pixie Edge Module 边缘模块(PEM): Pixie’s agent, installed per node. PEMs use eBPF to collect data, which is stored locally on the node. Pixie的代理，安装在每个节点上。PEM使用eBPF收集数据，这些数据存储在节点本地。
前面几篇讲 OOM 追踪时，所有 eBPF 内核态程序都是用 C 写的。这很自然——C 是 eBPF 的"母语"，verifier、CO-RE、libbpf 整个工具链都是围绕 C 设计的。但如果你关注过 eBPF 生态，会发现一个明显的趋势：越来越多的人开始用 C 以外的语言写 eBPF。Rust 的 Aya 框架已经被 Solana 验证器、Kubernetes Gateway API 用在生产环境；而 Zig 也在尝试用 comptime、显式分配和一流的 C 互操作带来新的开发体验。