恒生电子基于夜莺、Categraf、VictoriaMetrics 和 VictoriaLogs，构建了覆盖万级节点、数十万应用实例的指标、日志、网络链路一体化监控体系。这个案例的关键不只是规模承载，而是通过 Categraf 二次开发和 eBPF 抓包插件，把原本难以定位的复杂网络问题变成可观测、可告警、可联动分析的事件。
核心要点
- 监控对象覆盖物理机、虚拟机、容器节点、核心业务应用、微服务、中间件和跨域网络链路。
- 传统 Prometheus + Pushgateway 架构在该场景下遇到百万级指标后的维护和性能压力。
- 夜莺配合 Categraf、VictoriaMetrics、VictoriaLogs，用于支撑千万级以上数据规模的实践。
- Categraf 做了二次开发：支持日志写入 VictoriaLogs，并引入 eBPF 插件采集连接行为、时延、重传等网络特征。
- 通过夜莺 Pipeline 联动自定义逻辑，在超时类告警触发后查询 VictoriaLogs 并分析。
- 标签治理重点关注动态 label 和高基数，避免监控系统被不规范标签拖垮。
公司和业务介绍
恒生电子是一家长期服务金融行业的科技公司，业务覆盖交易、资管、投研、运营等多个核心场景。
在日常运维中，我们需要统一管理万级别节点和数十万应用实例，系统类型多、链路长、变更频繁，对监控系统的容量、稳定性和定位效率要求非常高。
我们基于夜莺构建了“指标 + 日志 + 网络链路”一体化监控体系，并且在 Categraf 中增加了 eBPF 抓包插件（后面也在考虑开源）把原本黑盒的网络关系变成可实时追踪的链路，实现复杂网络故障的秒级发现、分钟级定位。
监控需求和痛点
监控对象的量级
- 基础设施：物理机、虚拟机、容器节点（万级），遍布全国各地
- 应用服务：核心业务应用、微服务、中间件（数十万量级）
- 网络链路：跨机房、跨集群、跨业务域调用链路
痛点
- 规模瓶颈：传统 Prometheus + Pushgateway 架构在我们场景里，百万级指标后维护和性能压力明显上升，难以为继。
- 网络不可见：业务报错时只能看到“慢/超时”，看不到“具体哪一跳、哪一段链路”出了问题。我司各个服务运行的环境比较驳杂，对于网络问题的定位非常迫切。
- 告警治理困难：静态规则和固定标签难以覆盖快速变化的业务拓扑，告警噪音较多。需要一个更加动态化的机制。
选型与决策
我们调研并对比过多种方案，最终选择夜莺，核心原因有三点：
-
容量与稳定性 夜莺配合 Categraf + VictoriaLogs + VictoriaMetrics，在我们的实践中可以稳定承载千万级以上数据规模。
-
灵活性 支持动态 label 等灵活配置，能按业务线、环境、集群、租户等维度动态组织监控对象，适配高频变更场景。
-
可观测闭环能力 夜莺的规则、告警、事件流 Pipeline 和通知链路联动顺畅，可以在事件流的不同环节插入自定义的逻辑，把一些固化的故障定位动作自动联动起来，加速故障响应。
与 Prometheus + Pushgateway 的实践对比（基于我们的业务场景）
| 维度 | Prometheus + Pushgateway | 夜莺 + Victoria 存储 + 二开增强 |
|---|---|---|
| 规模承载 | 百万级后压力明显 | 千万级数据可稳定运行 |
| 标签策略 | 静态为主，治理成本高 | 动态 label 灵活扩展 |
| 故障定位 | 指标可见，网络链路弱可视 | 指标+日志+链路关联更完整 |
| 复杂网络问题 | 依赖人工排查 | 借助 eBPF 抓包实现实时跟踪 |
架构介绍
核心思路是：存储层面重度依赖 VictoriaMetrics 和 VictoriaLogs，因为 Victoria 家族的稳定性和性能都很好；告警引擎使用夜莺，因为夜莺的规则配置灵活，容易插入扩展逻辑；采集器使用 Categraf，并对 Categraf 做二次开发，根据我司情况做能力扩展。
Categraf 重点做了两个增强：
- 支持把日志写入 VictoriaLogs。开源的 Categraf 默认是把日志写入 Kafka 和 HTTP 后端，我们扩展了 output，增加了 VictoriaLogs 的支持。
- 引入 eBPF 插件。采集连接行为、时延、重传等网络特征。把指标写入 Remote Write 后端，把日志写入 VictoriaLogs。
在夜莺中配置告警规则，对于一些超时类的告警，会通过 Pipeline 联动我们自己的逻辑，去查询 VictoriaLogs 中的数据并分析。示意图如下：
eBPF 关键指标（名称 + 中文名 + 意义）
| 指标名 | 中文名 | 意义 |
|---|---|---|
performance_radar_health_level |
健康等级 | 0~4，越高风险越高 |
performance_radar_network_avg_time_us |
网络平均响应时间（微秒） | 网络操作平均耗时 |
performance_radar_network_ops_per_sec |
网络操作速率（秒） | 网络吞吐与压力水平，判断“流量增大导致慢”还是“同流量下变慢” |
performance_radar_network_errors |
网络错误次数 | 失败次数趋势，评估影响面是否扩大 |
performance_radar_system_load_percent |
系统负载百分比 | 主机整体压力，区分“网络瓶颈”与“系统整体拥塞” |
这些指标的价值在于把“慢”拆成可判断的信号：健康等级用于总览风险，平均响应时间用于观察时延，操作速率用于判断流量压力，错误次数用于观察失败趋势，系统负载用于区分网络瓶颈和主机整体拥塞。
治理建议
Prometheus、Victoria、Nightingale、Grafana、Zabbix，开源社区有琳琅满目的监控、可观测性相关的项目，大家可能都有在使用，但是不同公司使用的效果千差万别。其中有个关键点，就是治理规范，我司重点关注的是下面两个点。
动态 label
比如 Google，所有的服务都需要带上 job、region 等标签，我们要求统一带上 app（服务名）、env（环境）、cluster（集群）、region（地域）、team（团队）。一个是要求标签 Key 不能胡乱命名，大家都要统一，另一个是要求各个关键标签都要提供。
高基数
指标数据最怕的是高基数和高流失率。比如 requestid、traceid、userid、sessionid 之类的信息，都不应该作为指标标签，否则即便是 VictoriaMetrics，也照样扛不住。
| 治理项 | 具体要求 | 目标 |
|---|---|---|
| 动态 label | 统一 app、env、cluster、region、team 等关键标签 |
让监控对象能按业务、环境和地域组织 |
| 标签命名 | 标签 Key 不能随意命名 | 降低规则、模板和聚合查询复杂度 |
| 高基数控制 | requestid、traceid、userid、sessionid 不作为指标标签 | 避免指标存储和查询压力失控 |
建议与期待
- 提供更完善的 eBPF 插件兼容性/能力矩阵（内核版本、容器场景、权限要求）。
- 增强标签治理工具（高基数预警、动态 label 风险提示、规则质量评分）。
- 加强多集群统一视图与跨域关联分析能力。
- 深化 AI 辅助能力（自动归因建议、告警降噪、处置建议）。
FAQ
Q1: 恒生电子为什么需要 eBPF 网络链路监控？ A: 在复杂金融业务环境中，业务报错时经常只能看到“慢/超时”，但看不到具体哪一跳、哪一段链路出问题。eBPF 插件用于采集连接行为、时延、重传等网络特征，帮助把网络黑盒变成可分析对象。
Q2: Categraf 在这个案例中做了哪些增强？ A: 一是扩展 output，把日志写入 VictoriaLogs；二是引入 eBPF 插件，把网络特征以指标写入 Remote Write 后端，并把相关日志写入 VictoriaLogs。
Q3: 为什么强调动态 label 和高基数治理？ A: 万级节点和数十万应用实例场景下，标签不统一会导致规则和查询难以维护；高基数标签会放大存储和查询压力，甚至让监控系统本身变得不稳定。
小结
恒生电子的实践说明，金融级大规模监控不仅要能存下指标，还要能把指标、日志、网络链路和告警处理流程连接起来。夜莺承担规则、告警、事件流 Pipeline 和通知链路，Categraf 承担采集与扩展，VictoriaMetrics 和 VictoriaLogs 承担存储。再叠加 eBPF 网络观测能力后，复杂网络故障可以从人工猜测走向实时跟踪和联动分析。
夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏。
