同样是查指标，三套存储都得支持。但 BanyanDB、ES、JDBC 底层差别大，查询实现差很远——BanyanDB 靠预聚合点查最快，ES 靠倒排能全文搜，JDBC 靠分表合并最慢但好部署。这篇逐行对比它们的查询 DAO。...
链路追踪能告诉你慢在哪一段，但说不清那段代码为什么慢。Profiling 在普通监控之外对运行中的进程做 CPU、内存、锁的栈采样，生成火焰图，把根因从端点级推到代码行级。SkyWalking 有四套——Thread Profiling 采线程栈、eBPF 在内核态看 on/off-CPU、pprof 给 Go、async-profiler 给 Java 出 JFR，这篇对比它们的原理和适用场景。...
Agent 和 OAP 之间靠什么对话？这篇逐字段拆 apm-protocol 的 26 个 proto：SegmentObject/SpanObject 的每个字段、Command 下发机制、采样限流策略、Compat 向后兼容。重点讲为什么用 gRPC client-streaming 而不是 HTTP、为什么用 traceId.hashCode() 做确定性采样、为什么 Command 搭在数据流回程上。...
SkyWalking 的数据字典。这篇把 Source 全家族（56 个子类）、Scope 全表（98 个 ID）、Metrics 全家族（18 个聚合函数）、DataTable 多值指标一次讲透。重点回答四个为什么：为什么 Source 要分这么多子类、为什么 Scope 用整数 ID 分区、为什么 combine 和 calculate 要分两步、DataTable 这种 HashMap 怎么存进列式存储。...
OAP 多节点怎么协调、怎么动态改配置、怎么自监控？这篇讲集群协调（Zookeeper/etcd/k8s 三套实现）、动态配置中心（Watcher 机制 + 热更新）、Prometheus 自监控、Exporter 数据外发、AI 基线/URI 识别接入、管理面。重点讲为什么用 lease+keepAlive 而不是写死 key、为什么配置变更要先比较再回调 watcher。...
数据存好了怎么取出来给 UI 看？指标异常了怎么告警？这篇讲查询层（默认 GraphQL，兼容 PromQL/LogQL/TraceQL/Zipkin 四套协议让 Grafana 直连）和告警系统（规则用 MQE 表达式、内存滑窗求值、状态机控制触发/静默/恢复、九种 hook 输出）。重点讲为什么告警在内存 Window 算而不是回查存储，以及查询和告警为什么共用一套 MQE 语法。...
SkyWalking 自研了 BanyanDB 而不是直接用 Elasticsearch，为什么？因为 APM 的 metric 是时序数据，ES 存三份、压缩用 LZ4、没有 Gorilla 编码，浪费 3-10 倍磁盘。这篇对比 BanyanDB 和 ES 两套存储实现，讲透列存、Gorilla 编码、SeriesID、segment TTL、TopN 预聚合这些 ES 做不到的设计。理解它就理解了"领域专用存储在特定场景碾压通用存储"这个判断。...
Source 进来后，指标怎么从"一条一条的原始事件"变成"存进数据库的聚合点"？答案是 StreamProcessor + Worker 链：L1 内存聚合攒批、按 hash 分片到集群节点、L2 缓存做增量合并、降采样到小时天、最后批量落盘。这篇拆解四种 StreamProcessor、单条 metric 的完整 Worker DAG、L1/L2 缓存策略、集群分片机制、PersistenceTimer 的马桶式批量写入。是 OAP 性能设计最核心的一篇。...
SkyWalking 没硬编码指标聚合，而是发明了四门 DSL：OAL 算指标、MAL 算 meter、LAL 算日志、MQE 做查询表达式。这篇讲它们怎么用 ANTLR 解析 + Javassist 运行时生成字节码，把声明式规则变成运行中的处理类。重点拆 OAL——一行 from(Service.latency).longAvg() 怎么变成一个 JVM class，为什么 SkyWalking 要为一类指标发明一门语言。...
OAP 怎么收数据？答案是一堆 receiver 插件，每个对应一种协议。这篇先讲贯穿所有 receiver 的共同机制（共享服务器 + Source/Dispatcher 总线），再按协议大类分组讲每个插件：原生 gRPC、OTLP、Zipkin、Envoy ALS、Kafka 拉取。读完你分得清 trace/jvm/log/meter/otel/zipkin/envoy 各自怎么进来、差别在哪、什么时候用 push 什么时候用 pull。...