可观测性系列 on Mi&Bee Blog

监控采集点点记录

Mon, 20 Feb 2017 00:00:00 +0000

MYSQL的监控

MySQL权限经验原则

权限控制主要是出于安全因素，因此需要遵循一下几个经验原则：

只授予能满足需要的最小权限，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。
创建用户的时候限制用户的登录主机，一般是限制成指定IP或者内网IP段。
初始化数据库的时候删除没有密码的用户。安装完数据库的时候会自动创建一些用户，这些用户默认没有密码。
为每个用户设置满足密码复杂度的密码。
定期清理不需要的用户。回收权限或者删除用户。

eg:

监控系统企业架构演进史-初入Prometheus

Thu, 12 Dec 2019 00:00:00 +0000

Prometheus是一个开源的监控与时间序列数据库系统,在近年来得到了越来越广泛的应用。官方的架构图如图所示：

Eyes On You：从SRE理念到Prometheus监控体系落地实践

Sat, 20 Jun 2020 00:00:00 +0000

在互联网业务分布式、高并发、多云部署的大背景下，SRE（网站稳定性工程） 成为保障服务可用性的核心角色，而监控体系则是SRE的“眼睛”。本文从SRE核心理念出发，拆解现代监控体系的痛点、技术栈选型、Prometheus核心原理与告警实战，还原一套可落地的企业级监控建设思路。

监控系统企业架构演进史-跨地域混合云

Mon, 12 Oct 2020 00:00:00 +0000

前情概述：

在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。

监控系统企业架构演进史-拨测监控

Sat, 12 Dec 2020 00:00:00 +0000

前情概述：

在《监控系统企业架构演进史-跨地域混合云》中，监控系统已经逐步成熟且企业化发展。这一章节简单讲述一下期间的拨测能力搭建，以下是这套系统的发展史，在监控平台搭建的过程中，内部监控采集还不足以满足企业业务需求，在计划发展apm之前，异地拨测的黑匣子监控也纳入了该系统的一个子功能。

互联网公司黑盒拨测监控系统架构设计与落地实践

Tue, 31 Aug 2021 00:00:00 +0000

在互联网服务的全链路监控体系中，白盒监控侧重主动挖掘潜在隐患、提前预判风险，黑盒监控则以故障为核心导向，快速感知已发生的线上问题。二者协同才能构建完整的监控闭环。而多数互联网企业长期存在公网服务、用户侧最后一公里的监控盲区，用户侧故障往往只能被动等待报障后才启动排查，黑盒拨测监控系统正是为解决这一行业痛点而生。

从瓶颈破局到平台化治理——互联网公司监控平台架构演进全历程

Mon, 10 Jan 2022 00:00:00 +0000

在互联网业务高速扩张、多云部署、资产指数级增长的背景下，监控平台是保障服务稳定性的核心基建。本文完整复盘某大型互联网公司监控平台2019-2021年的演进之路，从解决老旧监控性能瓶颈，到跨云分布式监控落地，再到云原生平台化治理，呈现监控体系从0到1搭建→规模化扩展→平台化治理的完整蜕变。

混合云跨地域监控系统治理：自治+统一双核心架构实践

Mon, 10 Jan 2022 00:00:00 +0000

在企业业务全球化、混合云规模化部署的背景下，跨IDC、跨国内外、多云异构的监控治理成为稳定性保障的核心难题。传统监控方案要么依赖高成本专线改造、侵入业务架构，要么无法兼顾节点自治与全局统一，同时监控系统作为非营收类基建，还需严格控制资源占用且不允许能力降级。

Eyes On You：海量多云异构下的监控平台2022产品化演进之路

Mon, 20 Jun 2022 00:00:00 +0000

在多云部署、全球化组网、服务规模指数级增长的互联网业务场景中，监控平台早已超越“指标采集+告警通知”的基础定位，成为保障全链路稳定性的核心基建。本文基于大型互联网企业监控平台的真实演进历程，拆解2022年监控平台从规模化覆盖向产品化、易用化、智能化升级的完整规划与落地思路。

可观测技术存储架构总览：从 Gorilla 到 Parquet 的演进

Sun, 14 Jun 2026 00:00:00 +0000

引言

可观测性（Observability）已成为云原生时代的基础设施核心。Metrics、Logs、Traces、RUM、Profiling 五大信号各自产生海量数据，而它们的存储效率直接决定了平台的成本边界和查询性能。而在采集侧，eBPF 技术正在重塑数据获取方式。这一切的背后，存储架构的演进是支撑可观测性规模化落地的基石。

时序数据库存储架构深度对比：InfluxDB、Prometheus、VictoriaMetrics、TimescaleDB

Tue, 16 Jun 2026 00:00:00 +0000

引言

时序数据库（TSDB）是可观测性存储的基石。如果说上一篇是宏观的"存储地图"，那本篇就是深入地图中的"核心城区"——四大主流 TSDB 的存储引擎。无论你是刚开始接触 Prometheus 还是正在调研 VictoriaMetrics，理解底层存储引擎的设计哲学，能帮你更高效地用对它们。

日志存储架构：从倒排索引到弱索引的范式转移

Thu, 18 Jun 2026 00:00:00 +0000

引言

日志是可观测性三大支柱中数据量最大、存储成本最高的信号。与指标（Metrics）的固定数值结构不同，日志的变长文本和半结构化特性使得存储设计面临独特挑战：既要支持全文检索，又要控制存储成本。

分布式调用链存储架构对比：Jaeger、Tempo、SkyWalking 与商业方案

Sat, 20 Jun 2026 00:00:00 +0000

调用链（Distributed Tracing）存储是可观测性体系中技术分歧最大的领域之一。不同于时序和日志有相对收敛的存储模式（TSDB 与 ClickHouse-like），调用链系统的存储方案因索引策略的根本分歧而分化为三条路径。

前端监控(RUM)时序存储架构：Sentry、Datadog RUM 与 Grafana Faro

Mon, 22 Jun 2026 00:00:00 +0000

前端监控（Real User Monitoring, RUM）与后端监控的根本差异在于数据模型：RUM 采集的是带海量高基数属性的事件流——每个用户访问产生 session_id、user_id、page_url 等上百个维度，传统时序数据库（TSDB）的 label-set 模型在此场景下会剧烈退化。

持续性能分析(Profiling)存储架构：从 pprof 到 Pyroscope V2 与 Parca

Wed, 24 Jun 2026 00:00:00 +0000

持续性能分析（Continuous Profiling）是可观测性的重要支柱之一。与传统的采样 Profiling 不同，持续 Profiling 以固定频率全时采集应用和内核的调用栈快照，生成火焰图，帮助团队发现性能瓶颈、内存泄漏和资源热点。本文聚焦 Profiling 数据的存储架构：从 Google pprof 数据模型与火焰图构建算法开始，详细分析 Pyroscope 从 V1（TSDB+Parquet）到 V2（Metastore+Segments）的架构演进、Parca 与 FrostDB 的列式存储创新、Datadog/Splunk 等商业方案，最后通过对比表格呈现各方案的差异化选择。

eBPF 采集存储与可观测性统一架构趋势

Sat, 27 Jun 2026 00:00:00 +0000

可观测性架构在过去五年经历了从"分治"到"统一"的深刻转变。各信号（指标、日志、追踪、Profiling）从独立的专用后端走向共享存储与统一数据模型，而 eBPF 作为新一代采集手段，为这一转变提供了前所未有的数据深度与广度。本文将聚焦四个维度：eBPF 采集存储设计、统一存储架构（LGTM 分治 vs ClickHouse 统一）、OpenTelemetry 统一数据模型、以及对象存储与存算分离的演进方向。

可观测技术存储选型指南：场景驱动的决策框架

Wed, 01 Jul 2026 00:00:00 +0000

前面 7 篇分别深入剖析了 TSDB、日志、调用链、RUM、Profiling 和 eBPF 等各个可观测性领域的存储架构。本篇将这些知识融会贯通，提供一份面向场景的存储选型决策框架。不同团队的规模、技术栈、预算和需求层次各不相同——没有"最佳"存储，只有"最适合你的"存储。本篇可以作为实用参考工具书，帮助你在具体场景下快速筛选方案。

eBPF 可观测性入门：从 OOM Killer 监控开始

Wed, 10 Jun 2026 00:00:00 +0000

eBPF（Extended Berkeley Packet Filter）最初是网络包过滤工具，经过近十年发展，已经成为 Linux 内核最强大的可观测性框架。它允许你在不修改内核源码、不加载内核模块的前提下，安全地注入并执行自定义程序。

用 eBPF + Go 构建 OOM Killer 事件追踪器

Thu, 11 Jun 2026 00:00:00 +0000

bpftrace 适合快速探查和临时调试，但如果要构建持续运行的生产级监控工具，就需要完整的 eBPF 程序了。典型的架构分两层：

内核态：用 C 编写 eBPF 程序，挂载到 hook 点，采集事件数据
用户态：用 Go（或 Rust / libbpf C）编写 loader，加载 eBPF 程序并读取事件

这个模式在行业里已经非常成熟——Pixie、Parca、Cilium 等开源项目都遵循这个架构。

eBPF 内存可观测性进阶：容器追踪与 Rust Aya 实践

Fri, 12 Jun 2026 00:00:00 +0000

前两篇文章覆盖了 eBPF 基础概念和 OOM Killer 事件追踪。这篇文章进入更深的层次：容器级别的 OOM 定位、内存分配速率的实时追踪，以及用 Rust Aya 框架来实现同样的功能。

容器级 OOM 定位

在 Kubernetes 环境中，“某个 Pod OOM 了"实际上是一个模糊的描述。Pod 由多个容器组成，容器可能属于不同的 cgroup。eBPF 可以穿透这一层，精确地定位到"是哪个容器里的哪个进程"导致了 OOM。

BPF OOM 内核补丁深度解析：用 eBPF 自定义 OOM 策略

Sat, 13 Jun 2026 00:00:00 +0000

前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看"，不能"管"。内核的 OOM Killer 选谁杀谁，由 oom_badness() 算法决定，用户无法干预。

eBPF系列之：DeepFlow 扩展协议解析实践（MongoDB协议与Kafka协议）

Sat, 25 Nov 2023 00:00:00 +0000

概述：

MongoDB 目前使用广泛，但是缺乏有效的可观测能力。 DeepFlow 在可观测能力上是很优秀的解决方案，但是却缺少了对 MongoDB 协议的支持。该文是为 DeepFlow 扩展了 MongoDB 协议解析，增强 MongoDB 生态的可观测能力，简要描述了从协议文档分析到在 DeepFlow 内实现代码解析的过程拆解。

eBPF系列之：Pixie浅剖析

Fri, 10 Feb 2023 00:00:00 +0000

部署过程和指令参考：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收集数据，这些数据存储在节点本地。

eBPF 开发语言之争：C、Rust 与 Zig 全链路对比

Fri, 26 Jun 2026 00:00:00 +0000

前面几篇讲 OOM 追踪时，所有 eBPF 内核态程序都是用 C 写的。这很自然——C 是 eBPF 的"母语"，verifier、CO-RE、libbpf 整个工具链都是围绕 C 设计的。但如果你关注过 eBPF 生态，会发现一个明显的趋势：越来越多的人开始用 C 以外的语言写 eBPF。Rust 的 Aya 框架已经被 Solana 验证器、Kubernetes Gateway API 用在生产环境；而 Zig 也在尝试用 comptime、显式分配和一流的 C 互操作带来新的开发体验。