3. 遥测与可观测性数据模型
在数据中心网络可观测性工程中，“数据模型”决定了你能问出什么问题、能以多快速度得到答案、以及答案能否被关联到具体设备、接口、邻居或某一条业务流。很多团队把遥测简单理解为“把计数器推出去”，结果在排障时发现：有指标却没有上下文，有日志却没有时间对齐，有流记录却无法定位到具体接口。根本原因在于没有区分六类可观测性数据的语义边界，也没有理解 EOS 内部如何组织这些数据。
六类数据的语义差异
指标（Metrics）是随时间变化的数值序列，典型如接口 inOctets、outUcastPkts、队列丢弃计数、CPU 利用率、BGP 前缀数。它的核心特征是“可聚合、可比较、可设阈值”，适合趋势分析和容量规划，但单个指标本身不携带因果信息。
日志（Logs）是离散的、带时间戳的文本或结构化记录，例如 %LINEPROTO-5-UPDOWN、BGP 邻居状态变化、ACL 命中日志。日志的价值在于“发生了什么”，但高频日志会带来采集与存储压力，且字段不统一时难以聚合。
事件（Events）是系统对状态跃迁的显式抽象，比日志更结构化。EOS 中事件通常与告警对象、状态模型绑定，例如接口从 up 变为 down、BGP 邻居从 Established 变为 Idle。事件是“指标 + 状态”的桥梁，适合触发自动化动作。
流记录（Flow Records）描述五元组或七元组级别的会话统计，如 IPFIX/sFlow 输出的源目 IP、端口、协议、字节数、包数、TCP 标志。它回答“谁在和谁通信、流量多大”，是流量工程与安全分析的基础，但采样率与聚合粒度会直接影响精度。
追踪（Traces）在数据中心网络中通常指带路径信息的逐跳或逐段观测，例如带 In-band Network Telemetry（INT）的报文在每跳携带的队列深度、转发延迟、出口端口。追踪回答“这条流经过了哪些设备、在哪一跳变慢”，是把指标与拓扑关联起来的关键。
拓扑数据（Topology）描述节点与链路的连接关系，包括 LLDP 邻居、BGP-LS、IS-IS/OSPF 链路状态、MLAG 对等关系。拓扑本身变化慢，但它是所有其他数据的“坐标系”：没有拓扑，指标无法定位到链路，事件无法判断影响范围。
EOS 内部的数据组织：Sysdb、状态模型、计数器与告警对象
Arista EOS 的可观测性能力建立在其内部数据架构之上。理解这套组织方式，才能正确选择 Telemetry 订阅路径、gNMI 路径或 eAPI 命令。
Sysdb 是 EOS 的系统数据库，本质是一个内存中的层次化键值/路径树，保存着设备当前的状态与配置。几乎所有 EOS 进程（如 Fib、Bgp、Intf、Lag）都会把自身状态写入 Sysdb 的对应路径。例如接口状态位于 /Sysdb/interface/status/eth/...，BGP 邻居状态位于 /Sysdb/bgp/...。Sysdb 是“当前真相”的汇聚点，也是 gNMI/OpenConfig 路径映射的底层来源之一。
状态模型（State Model）是对 Sysdb 中状态数据的结构化封装，通常以 OpenConfig 或 EOS 原生 YANG 模型呈现。它把散落在不同进程的状态组织成可订阅、可查询的树，例如 /interfaces/interface/state/counters、/network-instances/network-instance/protocols/protocol/bgp/neighbors/neighbor/state。状态模型的价值在于：路径稳定、字段语义明确、支持 on-change 订阅，适合做事件驱动采集。
计数器（Counters）是高频更新的数值型状态，通常由硬件 ASIC 或转发面直接维护，例如接口字节/包计数、队列丢弃、ACL 命中、ECMP 哈希分布。计数器在 Sysdb 中也有对应路径，但由于更新频率高，实践中更常用 show interfaces counters、show queue counters 或 Telemetry 的 counter 订阅方式采集。需要注意：计数器是单调递增的，做速率计算时必须做差分并处理回绕。
告警对象（Alert Objects）是 EOS 对“需要关注的状态”的显式建模，通常与事件、阈值、严重级别绑定。例如接口 down、BGP 邻居震荡、光模块收光功率越界、队列持续丢弃。告警对象不是原始计数器，而是经过判断后的状态结论，适合直接接入告警平台或触发自动化脚本。
如何选择采集路径
理解了上述组织方式后，采集策略就清晰了。对于高频计数器，优先使用 EOS Telemetry 的 counter 订阅或 gNMI Subscribe 的 sample 模式，采样间隔按业务敏感度设置，例如核心链路 10 秒、边缘链路 60 秒。对于状态跃迁类数据，使用 on-change 订阅，避免轮询带来的延迟与开销。对于日志与事件，通过 Syslog 或 EOS 事件流导出，并在采集端做字段解析与时间对齐。对于流记录与追踪，通常由独立采集器处理，再与指标、拓扑做关联分析。
一个常见的实践误区是：把所有数据都塞进同一个采集管道。正确做法是按数据模型分层：指标进时序库，日志进日志库，事件进告警平台，流记录进流量分析系统，拓扑进图数据库或 CMDB，追踪数据与指标做关联存储。这样在排障时才能快速完成“从告警到接口、从接口到流、从流到路径”的闭环定位。
show sysdb 或 show openconfig paths 确认实际可用路径，避免订阅到空节点。最后需要强调：六类数据模型不是孤立的。指标告诉你“哪里异常”，事件告诉你“何时跃迁”，日志告诉你“具体原因”，流记录告诉你“谁受影响”，追踪告诉你“路径哪一跳”，拓扑告诉你“影响范围”。EOS 的 Sysdb、状态模型、计数器与告警对象，正是把这六类数据从设备内部有序导出、并保持语义一致的底层支撑。掌握这套组织方式，才能设计出既高效又可关联的遥测采集方案。