IT可观测性架构：从三支柱数据特征到存储层技术选型

可观测性三支柱的数据分化

云原生架构的推进使可观测性（Observability）从单纯的"监控"演进为三支柱体系：Metrics（指标）、Logs（日志）、Traces（链路追踪）。三者并非简单的数据类型区分，而是采集频率、数据维度、关联模式上的根本性分化。

Metrics以高频低维为特征。一个典型的微服务实例每15秒采集一次，暴露的指标涵盖CPU利用率、内存占用、GC次数、HTTP请求QPS、连接池活跃数等，单实例指标数量在8000至15000之间。一个包含1000个实例的中型集群，每日产生的Metrics数据点约55亿条。数据维度有限（通常10-20个标签），但写入频率极高。

Logs走的是另一条路径。日志事件频率低——一个实例每分钟产生数十至数百条结构化日志——但维度极高。一条日志的Schema可能包含trace_id、span_id、服务名、方法、状态码、耗时、请求体摘要等30-50个字段，且非结构化文本内容占比较大。

Traces介于两者之间。链路追踪的Span产生频率取决于请求量，中频特征明显。关键在于关联性：一个Trace由多个Span组成，Span之间存在父子关系，跨服务调用形成有向无环图（DAG）。数据维度中等，但拓扑关系的存储和查询复杂度高。

三支柱数据特征对比

数据类型	采集频率	维度数量	单条大小	关联模式	典型查询场景
Metrics	5-60s	10-20标签	50-200字节	标签组合	实时看板、趋势分析、告警
Logs	事件驱动	30-50字段	500-5000字节	trace_id关联	全文检索、字段过滤、聚合统计
Traces	请求驱动	15-30字段	200-1000字节	父子Span树	链路重建、延迟分析、瓶颈定位

三者的存储引擎需求截然不同。Logs天然适配倒排索引（Elasticsearch、Loki），Traces需要图遍历能力（Jaeger、Tempo），而Metrics的核心诉求是高吞吐顺序写入与时间范围聚合查询——这正是时序数据库的设计目标。

Metrics层的写入与查询架构

在Metrics层，写入路径的工程挑战集中在吞吐量与延迟的平衡上。Prometheus默认15秒抓取一次指标，通过远程写入（Remote Write）将数据推送到后端存储。一个1000实例的集群，抓取间隔内产生的数据点在800万至1500万之间，后端需要在下一个抓取周期到来前完成写入。

写入模式具备典型的时间序列特征：同一指标的时间线（由标签组合唯一标识）按时间递增追加写入，几乎无更新操作。这一特征使得LSM-Tree（Log-Structured Merge Tree）成为存储引擎的优选——顺序写入、批量合并、按时间范围组织数据文件。

查询模式可分为三类，各对存储引擎提出不同要求：

实时看板查询：查询最近1小时数据，按时间窗口降采样后返回。延迟要求在200ms以内。这类查询命中最新数据，缓存命中率极高，关键在于最新值缓存与最近时间段数据的快速定位。

容量规划查询：查询最近7-30天数据，按1小时或1天降采样，计算趋势。数据量大但聚合粒度粗，瓶颈在扫描范围而非计算复杂度。列式存储在此场景下优势明显——只需读取聚合涉及的字段列，而非整行数据。

根因分析查询：查询特定时间点、特定指标、特定标签组合的数据。时间范围窄（几分钟到几小时），但标签过滤条件复杂。这要求标签索引能够高效定位特定时间线。

通用指标与自研业务指标的存储差异

传统基础设施监控聚焦于通用指标：CPU利用率、内存使用率、磁盘I/O、网络吞吐。这些指标由操作系统或运行时提供，采集标准统一（如node_exporter的metrics），Schema固定，标签维度有限。

自研业务指标的复杂度显著更高。一个电商系统的业务指标包括：各商品类目QPS、支付成功率、优惠券核销率、库存预警阈值、用户行为漏斗转化率。这些指标的标签维度可能包含店铺ID（基数上万）、商品类目（数百）、用户分群（数十），标签组合的基数远超基础设施指标。

标签基数膨胀直接影响存储引擎的索引效率。当标签组合数达到百万级时，倒排索引的内存占用和查询剪枝代价显著上升。时序数据库在此场景下的设计策略是通过标签列的列式存储+位图索引，在控制内存占用的同时支持多标签组合过滤。

TDengine在处理这类场景时采用超级表（STable）+子表（Subtable）两级模型：每条时间线对应一个子表，标签作为子表的元数据而非数据行的一部分。这种设计将标签存储与指标数据物理分离，标签变更不影响已写入的数据，标签基数增长不会线性放大存储空间。对于微服务场景，一个超级表可以描述"服务实例JVM指标"，每个实例对应一个子表，标签包括集群名、命名空间、服务名、实例IP，均为低基数标签。

PromQL兼容与查询层适配

Prometheus的PromQL已成为Metrics查询的事实标准语言。一个完整的可观测性平台通常需要支持以下PromQL查询模式：

• 即时查询（Instant Query）：返回某个时间点的指标值
• 范围查询（Range Query）：返回时间范围内的数据点序列
• 聚合运算：sum、avg、max、min、histogram_quantile
• 向量匹配：基于标签的向量间运算

时序数据库要承担Metrics后端角色，需要实现PromQL到原生SQL的转换或直接支持PromQL语法。TDengine提供了PromQL兼容接口，通过remote_read/remote_write适配器与Prometheus生态集成，使得上层Grafana看板和告警规则无需修改即可切换后存储。

从架构层面看，Metrics层的存储选型并非孤立决策。一个完整的可观测性平台需要Metrics、Logs、Traces三层数据的关联查询能力——从Metrics异常触发告警，通过Traces定位到具体请求链路，再通过Logs查看详细上下文。这种关联查询的效率，取决于各层数据是否共享相同的标签体系（如service_name、instance标识），以及存储引擎是否支持跨数据类型的联合查询。

结语

可观测性三支柱的数据特征分化决定了存储层的异构性。Metrics层对高吞吐写入和时间聚合查询的诉求，与Logs层对全文检索的需求、Traces层对拓扑遍历的需求本质不同。在存储选型上，没有单一引擎能同时最优化三类负载。工程实践中更务实的路径是：Metrics层采用专门的存储引擎，通过标准的远程读写协议与采集层解耦，在查询层实现跨数据源的关联。时序数据库在Metrics层的角色，不仅是一个存储后端，更是连接采集层与可视化层的查询枢纽，其架构设计直接决定了可观测性平台的扩展上限。