博威尔特夜莺监控用户案例：越南三地工厂、ITSM 工单闭环与 MES

公司和业务介绍

博威尔特是博威集团旗下的越南分公司，隶属于新能源光伏赛道，行业细分属于工厂制造业。我们的 IT 部门是集团共享服务中心，负责越南当地 3 家工厂的 IT 基础设施运维，监控范围涵盖服务器、数据库、网络设备以及产线 MES 电脑等。

作为一家在越南落地的中国制造企业，我们面临的核心挑战不仅仅是"监控什么"，更是"怎么让越南本地 IT 同事把监控真正用起来"。

监控需求与痛点

监控对象

• 基础设施：约 300 台虚拟机、6-8 台物理机，分布在越南 3座工厂
• 数据库：20余台，涵盖 Oracle、MySQL、SQL Server等
• 业务应用：MES 系统服务、中间件进程（CPU/内存）
• 终端设备：数百台产线 MES 电脑
• 网络设备：交换机等网络上下行流量、TCP 连接数

痛点

1. Zabbix 配置复杂，学习成本高：在我来之前，公司主要使用 Zabbix 做监控。Zabbix 的监控项和告警规则配置比较繁琐，而且不同监控对象可能需要安装和配置多种 Agent，对于越南本地 IT 同事来说，学习门槛太高了。

2. 缺乏工单联动，告警处理无闭环：告警发出来之后，没有和公司内部 ITSM 系统打通，无法自动派发工单给越南同事，处理进度也没法追踪。经常出现磁盘或数据库告警被搁置，等到影响生产了才去处理，IT 部门的响应能力被业务部门质疑。

3. 巡检依赖人工，效率低：越南同事每周需要手动逐台巡检服务器，然后记录在 Excel 中，耗时且容易遗漏。

4. 运维数据是黑箱：没有统一的监控大盘，基础设施的运行状态缺乏可视化，出了问题才知道，日常无法提前预判。

5. 国际化能力缺失：作为越南本地公司，急需一个支持多语言（尤其是越南语）的监控系统，让本地同事能看懂界面和告警内容。

选型与决策

我们对比了两种方案：

最终选择夜莺的核心原因：

1. 简单：配置监控和告警门槛低，越南同事可以快速上手。对于产品出海来说，简单就是最大的优势。
2. 开源可二开：我们可以做越南语翻译、对接内部 ITSM、集成知识库等定制开发。
3. 统一体验：我个人之前在其他公司用过 Prometheus + AlertManager 的方案，各组件比较割裂。夜莺做了很好的集成，监控、告警、大盘、资产管理都在一个平台上。
4. 监控对象即台账：夜莺的监控对象管理功能可以直接充当我们的 CMDB，不需要再单独维护一套资产台账。

架构与落地过程

部署架构

采用夜莺官方推荐的高可用部署方案，两台服务器部署夜莺服务端，Prometheus 作为时序数据库存储，Categraf 作为统一采集 Agent。

┌─────────────────────────────────────────────────┐
│                  夜莺服务端（HA 双节点）            │
│          告警引擎 / 监控对象 / 大盘 / 报表          │
├─────────────────────────────────────────────────┤
│                  Prometheus（时序存储）             │
├──────────┬──────────┬──────────┬────────────────┤
│  工厂 A   │  工厂 B   │  工厂 C   │   ──→ ITSM    │
│ Categraf  │ Categraf  │ Categraf  │   ──→ 钉钉    │
│ ~100 VMs  │ ~100 VMs  │ ~100 VMs  │   ──→ 知识库  │
│ 物理机     │ 物理机    │  物理机    │               │
│ 数据库     │ 数据库    │  数据库    │               │
│ MES 电脑  │ MES 电脑  │ MES 电脑   │               │
└──────────┴──────────┴──────────┴────────────────┘

落地步骤

第一步：Agent 标准化打包

我们把主机、物理机、数据库、网络设备和 MES 电脑的 Categraf Agent 参数提前配置好并打包。每种监控对象都有对应的配置模板，越南同事在申请新服务器或设备上线时，按照 SOP 文档部署 Agent 即可，不需要理解复杂的配置逻辑。

第二步：监控对象作为 CMDB 台账

Agent 上报后，设备自动出现在夜莺的监控对象列表中，我们按工厂和业务维度做了分组。这个列表同时就是我们的资产台账，做到了"监控即登记"。

第三步：告警规则预置 + 中越双语

我们提前配置了涵盖主机、数据库、网络等场景的告警规则，告警内容使用中越双语，确保越南同事能看懂告警含义并知道如何处理。

第四步：监控大盘建设

按业务项目维度建立了十余个监控大盘，涵盖：

• 主机：磁盘使用率、内存使用率、CPU 负载
• 数据库：Oracle/MySQL/SQL Server 表空间、连接数
• 网络：上下行流量、TCP 连接数
• MES：服务进程 CPU/内存、关键中间件状态

要求越南同事每天早上打开大盘进行例行巡检，取代了原来的手动巡检。

第五步：ITSM 工单联动（核心亮点）

这是我们二次开发的重点。通过开发对接模块，将夜莺的告警事件自动转发到公司内部 ITSM 系统：

1. 夜莺产生告警 → 自动创建 ITSM 工单
2. 越南同事同时在钉钉收到告警通知
3. 越南同事按照知识库指引处理问题
4. 处理完成后关闭 ITSM 工单
5. 工单处理时效与绩效考核挂钩

这个闭环让告警不再是"看一眼就过"，而是有人跟进、有记录、有考核。

第六步：越南语本地化 + 知识库集成

我们对夜莺进行了多语言二次开发，实现了地道的越南语界面翻译。同时在夜莺页面中集成了公司内部运维知识库的链接入口，越南同事遇到告警可以直接跳转查阅处理方案。

我们的理念是：把夜莺打造成越南 IT 团队的运维监控中心，日常工作从这里开始。只有用起来的系统，才能常用常新，越用越好用。

成果与数据

前后对比

具体收益

• 运维数据透明化：所有基础设施的运行状态不再是黑箱。有报警就踏实——知道系统在被守护着。
• 告警响应提速：之前磁盘告警或数据库报警被拖延处理、影响生产的情况基本消除，IT 部门的口碑也有了改善。
• 本地团队成长：越南同事从之前不重视监控，到现在已经学会了安装 Agent、处理告警、查看和设置监控大盘、配置监控规则。这一点是我们最满意的成果。
• 手动巡检归零：越南同事每周数小时的手动巡检 + Excel 记录工作完全取消，现在大家可以安心喝咖啡了。

经验与避坑

时区与时间同步（最大的坑）

Categraf 采集数据依赖系统时间，所有被监控主机和夜莺服务端之间的时间差异不能太大，否则会频繁报错、数据异常。在越南的环境中，不同工厂的服务器时间设置不一定统一，这个问题尤其突出。

建议：所有主机务必配置 NTP 自动时间同步，部署监控前先把时间问题解决掉。这个看似小事，但能省掉很多排查时间。社区目前也在改进这方面的容错机制。

Agent 标准化是关键

不要让本地同事去理解配置细节，而是提前把不同场景的 Agent 配置打包好，提供傻瓜式 SOP。降低门槛比什么都重要。

让系统真正被使用

上了监控系统不等于有了监控能力。关键是要融入团队的日常工作流程——每天看大盘、告警驱动工单、工单关联考核。不被使用的系统只是一个摆设。

未来计划

1. Agent 自动化部署：将 Categraf 内置到虚拟机镜像模板中，或在 OA 系统申请服务器时根据用途自动生成 Categraf 配置并安装 Agent，实现"上线即监控"。
2. AI 驱动监控规则：引入 AI 能力，根据业务类型和历史数据自动生成和调优监控规则，减少人工配置。
3. 告警自愈：利用夜莺 ibex 模块，实现告警触发后自动执行脚本，比如磁盘空间不足时自动清理日志、数据库日志文件过大时自动归档，从"人工处理告警"走向"告警自动处置"。

建议与期待

1. 拥抱出海，大有可为：中国企业出海是大趋势，监控系统的国际化需求会越来越多。夜莺产品设计人性化、功能简单易上手，这对出海场景是巨大的优势。建议官方加强多语言支持的能力，降低社区贡献翻译的门槛。
2. 内置巡检报表：目前最新版本已经有报表导出功能，建议进一步内置一些常用的巡检报表模板（日报/周报），方便直接使用或稍作修改就能满足需求。
3. 时间同步容错：继续完善 Agent 和服务端之间的时间差异容错能力，对于海外部署场景尤为重要。

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