可观测技术存储选型指南:场景驱动的决策框架
前面 7 篇分别深入剖析了 TSDB、日志、调用链、RUM、Profiling 和 eBPF 等各个可观测性领域的存储架构。本篇将这些知识融会贯通,提供一份面向场景的存储选型决策框架。不同团队的规模、技术栈、预算和需求层次各不相同——没有"最佳"存储,只有"最适合你的"存储。本篇可以作为实用参考工具书,帮助你在具体场景下快速筛选方案。
Continue reading →前面 7 篇分别深入剖析了 TSDB、日志、调用链、RUM、Profiling 和 eBPF 等各个可观测性领域的存储架构。本篇将这些知识融会贯通,提供一份面向场景的存储选型决策框架。不同团队的规模、技术栈、预算和需求层次各不相同——没有"最佳"存储,只有"最适合你的"存储。本篇可以作为实用参考工具书,帮助你在具体场景下快速筛选方案。
Continue reading →可观测性架构在过去五年经历了从"分治"到"统一"的深刻转变。各信号(指标、日志、追踪、Profiling)从独立的专用后端走向共享存储与统一数据模型,而 eBPF 作为新一代采集手段,为这一转变提供了前所未有的数据深度与广度。本文将聚焦四个维度:eBPF 采集存储设计、统一存储架构(LGTM 分治 vs ClickHouse 统一)、OpenTelemetry 统一数据模型、以及对象存储与存算分离的演进方向。
Continue reading →前面几篇讲 OOM 追踪时,所有 eBPF 内核态程序都是用 C 写的。这很自然——C 是 eBPF 的"母语",verifier、CO-RE、libbpf 整个工具链都是围绕 C 设计的。但如果你关注过 eBPF 生态,会发现一个明显的趋势:越来越多的人开始用 C 以外的语言写 eBPF。Rust 的 Aya 框架已经被 Solana 验证器、Kubernetes Gateway API 用在生产环境;而 Zig 也在尝试用 comptime、显式分配和一流的 C 互操作带来新的开发体验。
Continue reading →持续性能分析(Continuous Profiling)是可观测性的重要支柱之一。与传统的采样 Profiling 不同,持续 Profiling 以固定频率全时采集应用和内核的调用栈快照,生成火焰图,帮助团队发现性能瓶颈、内存泄漏和资源热点。本文聚焦 Profiling 数据的存储架构:从 Google pprof 数据模型与火焰图构建算法开始,详细分析 Pyroscope 从 V1(TSDB+Parquet)到 V2(Metastore+Segments)的架构演进、Parca 与 FrostDB 的列式存储创新、Datadog/Splunk 等商业方案,最后通过对比表格呈现各方案的差异化选择。
Continue reading →前端监控(Real User Monitoring, RUM)与后端监控的根本差异在于数据模型:RUM 采集的是带海量高基数属性的事件流——每个用户访问产生 session_id、user_id、page_url 等上百个维度,传统时序数据库(TSDB)的 label-set 模型在此场景下会剧烈退化。
Continue reading →调用链(Distributed Tracing)存储是可观测性体系中技术分歧最大的领域之一。不同于时序和日志有相对收敛的存储模式(TSDB 与 ClickHouse-like),调用链系统的存储方案因索引策略的根本分歧而分化为三条路径。
Continue reading →引言 日志是可观测性三大支柱中数据量最大、存储成本最高的信号。与指标(Metrics)的固定数值结构不同,日志的变长文本和半结构化特性使得存储设计面临独特挑战:既要支持全文检索,又要控制存储成本。
Continue reading →引言 时序数据库(TSDB)是可观测性存储的基石。如果说上一篇是宏观的"存储地图",那本篇就是深入地图中的"核心城区"——四大主流 TSDB 的存储引擎。无论你是刚开始接触 Prometheus 还是正在调研 VictoriaMetrics,理解底层存储引擎的设计哲学,能帮你更高效地用对它们。
Continue reading →引言 可观测性(Observability)已成为云原生时代的基础设施核心。Metrics、Logs、Traces、RUM、Profiling 五大信号各自产生海量数据,而它们的存储效率直接决定了平台的成本边界和查询性能。而在采集侧,eBPF 技术正在重塑数据获取方式。这一切的背后,存储架构的演进是支撑可观测性规模化落地的基石。
Continue reading →前几篇文章展示了如何使用 eBPF 追踪 OOM 事件。但这还不够——我们只是在"看",不能"管"。内核的 OOM Killer 选谁杀谁,由 oom_badness() 算法决定,用户无法干预。
Continue reading →