第335篇系统监控与运维——日志/告警/远程更新的方案设计

郑伟强dev

46人浏览 · 2026-09-02 04:01:14

郑伟强dev · 2026-09-02 04:01:14 发布

上篇聊了安全设计，功能安全和信息安全是机器人的安全底线。今天聊的话题是：机器人部署出去之后，怎么管？很多团队把精力都放在开发阶段，产品一交付就"眼不见心不烦"。结果客户打电话来说机器人不动了，你连日志都拿不到，只能派人到现场排查——一次出差的成本够你做好几套监控系统了。系统监控和运维能力，是机器人产品成熟度的重要标志。

机器人运维和传统服务器运维有本质区别。服务器挂在云端，你可以SSH上去查日志、重启服务。机器人在客户现场的局域网里，你大概率访问不到。而且机器人有物理实体，远程操作需要格外小心——你不能像重启服务器一样随意重启一台正在搬运货物的AGV。

日志系统——出了问题有据可查

日志是排查问题的第一手材料。机器人日志系统的设计要考虑几个问题：日志量（传感器数据量很大，不能全记）、存储限制（嵌入式设备磁盘有限）、检索效率（出问题时能快速定位）。

日志分级是基础操作：DEBUG、INFO、WARN、ERROR、FATAL。关键是每一级该记什么要有团队共识。我们团队的规范是：DEBUG记算法中间结果（开发时用，发布时关闭），INFO记状态变化（节点启停、模式切换、任务开始结束），WARN记异常但可恢复的情况（传感器数据延迟、定位精度下降），ERROR记功能失败（路径规划失败、通信中断），FATAL记系统级故障（硬件驱动崩溃、安全系统触发）。

ROS2的日志框架rclcpp::Logger提供了标准的日志功能，但生产环境还需要做增强：日志要带时间戳和节点标识，方便跨节点排查；要支持日志轮转（log rotation），避免磁盘写满；要能远程上报，不能只存在本地。

// ROS2日志增强示例
RCLCPP_INFO(this->get_logger(),
  "Task %s started, battery: %.1f%%, map_version: %s",
  task_id.c_str(), battery_level, map_version.c_str());
// 关键信息：任务ID、电量、地图版本
// 出问题时可以快速还原当时的运行环境

日志上报用什么方案？轻量级方案是rsyslog或者Filebeat，把日志文件推送到中心的Elasticsearch。ROS2生态里也有人用ros2bag录制关键话题数据，回传后离线回放分析。带宽受限时，只上报结构化日志（文本+关键指标），原始传感器数据存在本地，需要时再远程拉取。

监控与告警——知道机器人"不舒服"了

日志是事后分析用的，监控是实时感知系统健康状态用的。

机器人的监控指标分三类：硬件指标（CPU温度、内存使用率、电池电压、磁盘剩余空间）、软件指标（节点存活状态、话题发布频率、消息延迟）、业务指标（任务完成率、定位精度、导航成功率）。

告警规则的设计要避免两个极端：太灵敏导致"告警风暴"（运维人员被无数误报淹没，真正的告警反而被忽略），太迟钝导致问题已经严重了才告警。实践经验是分级告警：WARNING级别推送给值班工程师的IM工具，CRITICAL级别自动触发降级策略同时电话通知负责人。

# 告警规则示例（Prometheus格式）
groups:
- name: robot_health
  rules:
  - alert: HighCPUTemperature
    expr: cpu_temp_celsius > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "机器人CPU温度过高: {{ $value }}°C"
  - alert: NavigationFailureRate
    expr: nav_failure_rate > 0.1
    for: 10m
    labels:
      severity: critical

数据采集用什么方案？机器人端用轻量级的Prometheus Node Exporter采集系统指标，ROS2话题里加一个诊断节点（diagnostics）采集业务指标。数据推送到云端用Grafana做可视化看板。如果机器人数量超过几十台，建议上一个时序数据库（TDengine或InfluxDB），查询性能比直接查Prometheus好很多。

OTA远程更新——不停机升级软件

机器人部署到客户现场后，软件更新是不可避免的。修bug、加功能、优化性能——都需要远程推送新版本。OTA（Over-The-Air）更新系统的设计要考虑三个核心问题：怎么分发更新包、怎么保证更新不中断服务、更新失败了怎么回滚。

更新包的分发方式取决于网络环境。有公网连接的机器人可以直接从云端拉取更新包；只在内网的机器人需要通过本地网关或者U盘导入。我们团队做过一个方案：在内网部署一个本地更新服务器，云端先把更新包推送到本地服务器，机器人从本地服务器拉取——这样既不需要公网直连机器人，又利用了内网的高带宽。

不中断服务更新是最理想的状态，但对机器人来说往往不现实——你不能在机器人正在搬运货物的时候替换它的导航模块。常见的做法是"下载-准备-确认"三步走：先后台下载更新包，然后在机器人空闲时安装，安装完成后等待管理员确认再切换到新版本。

回滚机制是OTA的生命线。每次更新前自动备份当前版本，如果新版本启动后自检失败，自动回滚到上一版本。更稳妥的做法是A/B分区方案：系统盘分成两个分区，当前运行的在A分区，新版本安装到B分区。启动时通过Bootloader选择从哪个分区启动。A分区始终保持不变，B分区出问题了直接切回A。嵌入式设备（比如机器人的MCU固件）用这种方案特别合适。我见过一个团队没有做回滚机制，一次OTA推送了一个有bug的固件，二十多台机器人集体变砖，只能派人到现场一台一台用USB线刷回来。代价惨痛。