其他分享
首页 > 其他分享> > ENS框架下一次控制灯的调试记录

ENS框架下一次控制灯的调试记录

作者:互联网

正常流程

 

故障架构

 

 

 

 

检测流程

 

 

 

  1. 驱动侧启动,拉起驱动故障检测进程。
  2. OM侧ensd进程启动,ensd进程加载故障检测动态库并进行故障检测模块的初始化,在这个过程中会初始化非硬件相关的故障检测线程,同时会加载驱动提供的硬件故障检测动态库,该动态库初始化的过程中会和驱动故障检测进行连接;同时ensd进程加载告警处理动态库并进行告警处理模块的初始化,在这个过程中会初始化告警屏蔽处理线程。
  3. 故障检测模块中会进行相关非硬件故障的检测,发现故障时会通过告警上报接口上报给告警处理模块,告警处理模块生成相应的告警。
  4. 驱动侧的故障检测进程对硬件进行检测,发现故障会将故障上报给ensd进程中的故障检测模块进行处理,改模块会将故障上报给告警模块处理。

3、 各检测项实现
这边只列出硬件无关的故障检测项,硬件相关的在驱动侧实现。

  1. 磁盘挂载
    通过脚本mount_check.sh实现
  2. NFS
    通过脚本nfs_operate.sh生成的nfs_status_info文件实现NFS的故障检测功能
  3. 磁盘空间
    通过linux的df和awk命令来判断磁盘空间是否占满,目前检测的目录有: ‘/’、‘/tmp’、‘/home/data’、‘/home/log’、‘/opt’、‘/var/lib/docker’。
  4. 证书过期

 

告警

 

  1. ensd进程中硬件故障检测任务和非硬件故障检测任务将检测的故障上报给告警任务,告警任务处理故障生成告警并保存。
  2. WEB发起告警查询请求,ESP请求告警模块,查询当前活动告警,得到结果后将结果返回给WEB

 

故障检测模块和告警模块之间的接口

 

UINT32 report(const void *info),其中info的结构为:
typedef struct {
    UINT32 data_len;            // 报文长度
    UINT32 owner;               // 上报的模块标识
    UINT32 item_num;            // 告警个数
} ALARM_MSG_INFO_HEAD;

typedef struct {
    UINT16 fault_id;            // 为LV1中告警id, 对应FAULT_LV2_MAPPING_STRU的fault_id_out
    UINT16 sub_fault_id;        // 子告警id
    UINT16 fault_level;         // 告警级别 FAULT_LEVEL_ENUM :紧急告警  严重告警 轻微告警
    UINT16 reserved;            // 4字节对齐
    time_t raise_time_stamp;    // 告警时间戳(元年到告警产生的秒数)
    char fault_name[64];        // 告警名称
    char resource[32];          // 告警实体
} ALARM_MSG_FAULT_INFO;

 

驱动故障检测动态库提供的接口(驱动提供)

  1. 初始化接口
    INT32 drv_fault_check_init();

  2. 设置故障上报回调函数接口
    typedef INT32(*DRV_FAULT_CHECK_PROC)(UINT8 *data, UINT32 data_len);
    INT32 drv_fault_check_register_callback(DRV_FAULT_CHECK_PROC);

 

现在的情况

 

分析问题

 

解决方案

标签:框架,检测,硬件,故障,ENS,模块,fault,告警,调试
来源: https://www.cnblogs.com/gongxianjin/p/15470837.html