问

UC2.0手动点恢复告警失败后台看没有异常pod

U-Center 2.0

10小时前提问

0关注
0收藏，35浏览

zhiliao_DTkhwT

zhiliao_DTkhwT 四段

粉丝：1人关注：0人

问题描述：

UC2.0手动点恢复告警失败后台看没有异常pod

3 个回答

按时间按赞数

zhiliao_Gixe

zhiliao_Gixe 四段

粉丝：2人关注：9人

排查步骤：

1. 检查告警状态：
# 进入U-Center运维平台，查看告警详情，确认告警是否处于“未恢复”或“确认”状态。

2. 检查告警处理流程：
# 确认该告警是否关联了自动化处理策略或工单流程，手动恢复可能被流程拦截。
# 在U-Center管理界面，检查“告警设置”->“告警处理”中的相关配置。

3. 检查数据库与Redis状态：
# 登录U-Center后台，检查核心数据库和Redis服务是否正常，告警恢复操作依赖数据更新。
# 使用 `kubectl get pods -n uc` 查看 `uc-mysql` 和 `uc-redis` 相关Pod状态是否为Running。
# 检查数据库连接：进入mysql pod执行 `mysql -u<user> -p` 测试连接。

4. 查看告警服务日志：
# 重点检查告警引擎（alarm-engine）和告警服务（alarm-service）Pod的日志。
# kubectl logs -f <alarm-engine-pod-name> -n uc --tail=100
# kubectl logs -f <alarm-service-pod-name> -n uc --tail=100
# 在日志中搜索“恢复”、“recover”、“fail”等关键词，定位错误信息。

5. 检查网络与权限：
# 确认U-Center前端与后端服务（如alarm-service）之间的网络通信正常。
# 检查执行恢复操作的用户是否具备“告警恢复”的操作权限。

需要补充的信息：
1. 告警恢复失败时，前端界面是否有具体的错误提示？
2. 是单个告警恢复失败，还是批量告警恢复失败？
3. U-Center的具体版本号是多少（例如：E0706）？

暂无评论

刘浩存

刘浩存七段

粉丝：8人关注：1人

从现象“手动点恢复告警失败”看，虽然后台Pod状态显示“没有异常”，但核心处理告警的应用层逻辑可能已经卡住了。

你可以尝试按照以下思路来排查：

第一步：检查告警源头状态

检查原始告警状态：在告警列表中直接查看这条告警，确认其状态是否仍为“告警中”。如果已恢复，手动操作自然会失败。
检查恢复Trap：如果告警来自设备Trap，登录设备确认它是否已正常发出了恢复Trap。若未发出，平台就无法收到。

第二步：排查关键Pod与日志

Pod状态正常不代表其内部服务完全健康，建议检查以下关键Pod的日志：

alarm-calculator：处理告警生成与恢复的核心服务。你可以使用 kubectl logs -n <命名空间> <alarm-calculator-pod名称> 查看其日志，看是否有报错。也可尝试重启此Pod（kubectl delete pod -n <命名空间> <alarm-calculator-pod名称>）进行快速恢复。
imcfaultdm：负责处理设备Trap和接口信息的进程。可通过 kubectl exec 进入容器或用 systemctl status imcfaultdm 检查其状态，必要时重启。
itom-central-ucd：这是部署IOM等组件时可能遇到的Pod，若相关，请检查其日志。
查看所有Pod：使用 kubectl get pods -n <命名空间> 全面检查所有Pod的状态，确保没有Pending、CrashLoopBackOff等异常。

第三步：检查业务逻辑配置

检查Trap浏览：登录系统后台，进入 “告警” > “Trap管理” > “Trap浏览” 页签，搜索相关Trap。如未找到，说明平台未收到恢复信息。
检查过滤/升级规则：在“Trap管理”中检查“过滤规则”和“转发规则”，确认没有规则错误地过滤掉了恢复Trap。