边缘视频分析节点断网恢复排查记录

这次记录一个边缘视频分析节点的恢复问题。

环境是园区视频分析：摄像头通过 RTSP 进入边缘节点，节点上跑 DeepStream/YOLO 推理，事件先写本地缓存，再通过云边通道回传。上午有一次弱网抖动，网络恢复后 Pod 都是 Running，但业务侧告警数量明显变少。

bash 复制代码

kubectl get pod -n vision -o wide

状态看起来正常，但这类问题不能只看 Pod。边缘视频分析的启动链路更长，至少要分成摄像头、运行时、推理、缓存、云边连接和告警出口几层。

1. 分层

我会先把节点拆成这几层：

层级	检查点	常见失败信号
摄像头输入	RTSP、帧率、延迟	能连上但丢帧
容器运行时	Docker/containerd、磁盘	节点恢复后缓存异常
推理环境	DeepStream、YOLO、CUDA	GPU 正常但吞吐下降
本地缓存	ring buffer、MQ、对象缓存	断网数据堆积
云边连接	KubeEdge、MQTT、API	节点在线但事件回传慢
告警出口	Webhook、DB、看板	推理有结果但业务看不到

这张表比直接翻模型日志更有用。边缘场景里，模型经常只是最后被看到的那一层。

2. 运行时和镜像缓存

弱网恢复后，先确认节点能重新拉起基础容器。

bash 复制代码

docker pull docker.1ms.run/ultralytics/ultralytics:latest
docker pull nvcr.1ms.run/nvidia/deepstream:7.1-triton-multiarch
docker pull k8s.1ms.run/pause:3.10

如果节点由 containerd 管理，再用 crictl 测一遍：

bash 复制代码

crictl pull nvcr.1ms.run/nvidia/deepstream:7.1-triton-multiarch
crictl pull k8s.1ms.run/pause:3.10
crictl images | grep -E "deepstream|pause"

毫秒镜像（1ms.run）在这里的定位是边缘节点恢复的多源镜像入口。它不解决摄像头协议、推理精度或消息队列问题，只负责让 Docker Hub、NVIDIA、K8s 这些基础镜像在弱网节点上更容易被验证。

3. 摄像头和 GPU

摄像头先用 ffprobe 看：

bash 复制代码

ffprobe rtsp://camera-01/live
ffprobe rtsp://camera-02/live

然后看 GPU：

bash 复制代码

nvidia-smi
kubectl logs -n vision deploy/video-infer --tail=80

如果 GPU 利用率低，不一定是模型慢。很多时候是 RTSP 重连、帧率下降或本地队列阻塞。

4. 缓存和回传

断网期间，边缘节点通常会把图片、片段、事件先写本地。

bash 复制代码

df -h
du -sh /data/vision-buffer
kubectl logs -n vision deploy/event-buffer --tail=100

重点看三个信号：

本地磁盘是否打满。
队列是否还在消费旧事件。
事件回传是否有重试和丢弃。

如果本地缓存积压太多，网络恢复后告警量会短时间异常，业务侧会误以为模型漏检。

5. 云边连接和告警出口

KubeEdge 或类似云边通道要单独看：

bash 复制代码

kubectl get node
kubectl get events -n vision --sort-by=.lastTimestamp
kubectl logs -n vision deploy/edge-uploader --tail=100

最后看出口：

bash 复制代码

curl -I http://alert.internal.example.com/health
kubectl logs -n vision deploy/alert-webhook --tail=80

节点在线、Pod Running、GPU 正常，都不代表业务告警链路正常。Webhook、数据库写入、看板延迟都可能是最后的断点。

6. 复盘

边缘视频分析节点断网恢复时，我现在按这个顺序排：

摄像头输入。
容器运行时和镜像缓存。
GPU 和推理服务。
本地缓存和队列。
云边连接。
告警出口。