3、故障检测与诊断：基于日志的异常检测、基于指标的异常检测（CPU/内存/磁盘）、基于时间序列的预测模型
故障检测，说白了就是给边缘节点做「体检」。你想想看，一个边缘节点可能部署在工厂车间、路边机柜，甚至荒郊野外。出了问题不能总指望人跑过去看。所以，自动化的检测手段就是第一道防线。
我个人习惯把故障检测分成三个层次：日志层、指标层、预测层。这三层不是互斥的，而是层层递进的关系。下面我一个个说。
3.1 基于日志的异常检测
日志是最直接的信号。我见过很多团队，日志收集了一堆，但只在出事后才翻出来看。这其实浪费了日志最大的价值——实时告警。
日志异常检测的核心思路很简单：正常日志长什么样，不正常的就报警。但难点在于，边缘节点的日志量可能不大，但模式很杂。
我在项目中遇到过这样的情况：一个边缘网关每天凌晨会定时同步数据，日志里会出现「sync completed」字样。但有一天，日志变成了「sync timeout after 3 retries」。这就是典型的异常模式。
常用的方法有两种：
- 关键词匹配：适合已知的故障模式。比如「error」、「failed」、「timeout」、「OOM」这些词。简单粗暴，但有效。
- 日志模板聚类：适合未知的异常。把日志按模板归类，如果某个模板的日志量突然暴增或骤降，说明有问题。
重要原则：边缘节点的日志不要全量上传到中心。我建议在节点本地做第一层过滤，只上报异常日志和摘要信息。否则带宽扛不住。
给你看一个简单的日志异常检测脚本思路：
# 伪代码：边缘节点本地日志检测
def check_logs(log_file):
error_keywords = ['error', 'failed', 'timeout', 'OOM', 'panic']
anomalies = []
with open(log_file, 'r') as f:
for line in f:
for kw in error_keywords:
if kw in line.lower():
anomalies.append(line.strip())
# 如果异常日志超过阈值，触发告警
if len(anomalies) > 5:
trigger_alert('log_anomaly', anomalies[:10])
return anomalies小技巧：别只盯着错误日志。有时候「正常日志突然消失」也是大问题。比如心跳日志没了，说明进程可能挂了。
3.2 基于指标的异常检测（CPU/内存/磁盘）
日志是定性分析，指标是定量分析。CPU、内存、磁盘这三样，是边缘节点的「生命体征」。
为什么会这样？因为边缘节点的硬件配置通常不高。我见过很多设备只有2核CPU、4G内存。稍微跑个复杂点的模型，资源就吃紧了。
基于指标的检测，我一般用两种策略：
3.2.1 静态阈值法
最简单，也最常用。给每个指标设一个硬上限：
| 指标 | 警告阈值 | 严重阈值 | 说明 |
|---|---|---|---|
| CPU使用率 | > 80% | > 95% | 持续超过5分钟 |
| 内存使用率 | > 85% | > 95% | 注意OOM风险 |
| 磁盘使用率 | > 80% | > 90% | 日志分区尤其注意 |
| 磁盘IO等待 | > 30% | > 50% | 可能磁盘性能瓶颈 |
避坑指南：我曾经吃过一次亏——给所有节点用了统一的阈值。结果发现，有的节点CPU长期跑在70%是正常的，有的节点跑到50%就卡死了。后来我改成按节点类型配置不同阈值，问题才解决。
3.2.2 动态基线法
静态阈值有个硬伤：它不知道业务的「潮汐」规律。比如白天业务高峰CPU 90%可能正常，凌晨CPU 50%反而异常。
动态基线法就是解决这个问题的。它通过历史数据学习出「正常范围」，然后实时对比。
具体做法：
- 收集过去7天或30天的指标数据
- 按时间窗口（比如每小时）计算均值和标准差
- 当前值偏离均值超过3倍标准差，视为异常
# 伪代码：动态基线检测
def dynamic_baseline_detect(current_value, history_values):
mean = np.mean(history_values)
std = np.std(history_values)
threshold = 3 * std
if abs(current_value - mean) > threshold:
return True # 异常
return False嗯，这里要注意：动态基线需要一定的历史数据积累。新上线的节点，前24小时建议先用静态阈值兜底。
3.3 基于时间序列的预测模型
日志和指标检测都是「事后」的。预测模型的目标是「事前」——在故障发生前就发现苗头。
我个人觉得，这是边缘自愈里最有价值、也最难做的一层。
时间序列预测，说白了就是根据过去的数据，猜未来几分钟或几小时会怎样。常用的模型有：
- ARIMA：经典统计模型，适合周期性明显的指标
- Prophet：Facebook开源，对节假日、周期性有很好的支持
- LSTM：深度学习模型，适合复杂模式，但边缘节点不一定跑得动
在边缘场景下，我建议优先用轻量级的模型。Prophet 就是个不错的选择，它不需要大量训练数据，而且能自动处理缺失值。
给你看一个实际案例：
# 使用 Prophet 预测磁盘使用率
from prophet import Prophet
import pandas as pd
# 假设有过去30天的磁盘使用率数据
df = pd.DataFrame({
'ds': timestamps, # 时间戳
'y': disk_usage # 磁盘使用率
})
model = Prophet()
model.fit(df)
# 预测未来24小时
future = model.make_future_dataframe(periods=24, freq='H')
forecast = model.predict(future)
# 如果预测值超过90%，提前告警
if forecast['yhat'].iloc[-1] > 90:
trigger_alert('disk_prediction', '磁盘将在24小时内达到90%')核心观点：预测模型不是要100%准确。它的价值在于给你一个「提前量」。哪怕只有30分钟的提前预警，也足够触发一些自愈动作了，比如清理缓存、迁移负载。
你想想看，如果等到磁盘真的满了才告警，那时候应用已经写不了日志了，甚至可能直接崩溃。但如果你提前预测到，就可以从容地做清理或扩容。
最后说一句：这三种检测手段，我建议你组合使用。日志检测抓「显性故障」，指标检测抓「资源瓶颈」，预测模型抓「潜在风险」。三管齐下，才能做到真正的全面覆盖。
我的习惯：在边缘节点上，我会把日志检测和指标检测做成常驻的轻量级服务，每30秒跑一次。预测模型则每1小时跑一次，因为它的计算开销大一些。这样既保证了实时性，又不会占用太多资源。
这张图把三层架构串起来了。从日志到指标再到预测，每一层解决不同的问题。实际部署时，我建议从第一层开始，逐步叠加。别一上来就上预测模型，先把日志和指标检测跑稳了再说。