恒生电子实践：基于夜莺+eBPF构建金融级万节点一体化监控体系

恒生电子研发团队 2026-02-27 09:57:40

公司和业务介绍

恒生电子是一家长期服务金融行业的科技公司，业务覆盖交易、资管、投研、运营等多个核心场景。

在日常运维中，我们需要统一管理万级别节点和数十万应用实例，系统类型多、链路长、变更频繁，对监控系统的容量、稳定性和定位效率要求非常高。

我们基于夜莺构建了“指标 + 日志 + 网络链路”一体化监控体系，并且在 Categraf 中增加了 eBPF 抓包插件（后面也在考虑开源）把原本黑盒的网络关系变成可实时追踪的链路，实现复杂网络故障的秒级发现、分钟级定位。

我们调研并对比过多种方案，最终选择夜莺，核心原因有三点：

容量与稳定性
夜莺配合 Categraf + VictoriaLogs + VictoriaMetrics**，在我们的实践中可以稳定承载**千万级以上数据规模。
灵活性
支持动态 label 等灵活配置，能按业务线、环境、集群、租户等维度动态组织监控对象，适配高频变更场景。
可观测闭环能力
夜莺的规则、告警、事件流 Pipeline 和通知链路联动顺畅，可以在事件流的不同环节插入自定义的逻辑，把一些固化的故障定位动作自动联动起来，加速故障响应。

核心思路是：存储层面重度依赖 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，开源社区有琳琅满目的监控、可观测性相关的项目，大家可能都有在使用，但是不同公司使用的效果千差万别。其中有个关键点，就是治理规范，我司重点关注的是下面两个点。

比如 Google，所有的服务都需要带上 job、region 等标签，我们要求统一带上 app（服务名）、env（环境）、cluster（集群）、region（地域）、team（团队）。一个是要求标签 Key 不能胡乱命名，大家都要统一，另一个是要求各个关键标签都要提供。

指标数据最怕的是高基数和高流失率。比如 requestid、traceid、userid、sessionid 之类的信息，都不应该作为指标标签，否则即便是 VictoriaMetrics，也照样扛不住。

夜莺项目开源地址：https://github.com/ccfos/nightingale 欢迎收藏。