ENS架構下一次控制燈的調試記錄

正常流程

• • 登入小站，點選管理--磁盤，在硬碟下建立分區并挂載
  • 安全下電，拔掉硬碟和TEC，再上電
  • 硬體端
  • drv_fault_check_init 初始化 并綁定硬體回調 drv_fault_check_callback
  • drv_fault_check_proc 發送告警事件通過ens架構回調給alarm_process子產品中
  • 非硬體端
  • 初始化磁盤挂載檢測任務fault_manage_mount_check_thread線程檢測磁盤狀态
  • fault_check.h 中 FAULT_DATA_COLLECT funcdatacollect; // 注冊函數
  • global_fault_info_init 綁定所有非硬體故障檢測函數
  • fault_check_task_process 中 下段代碼調用檢測函數檢測并傳回不同故障的狀态

  ret = sub_item_fault->item_cfg.funcdatacollect(index, sub_item_fault->item_cfg.sub_fault_id,
                  &status_curr);
             

  • alarm_report函數，通過此函數處理故障資訊并更新狀态，然後寫入故障日志
  • 最後釋出一個警告事件給注冊的其他方法中
  • 去執行 通過ens架構提前注冊好的事件
  • 執行到 process_alarm_event_func 函數中調用hal層提供的接口去執行
  • dev_set_led_color 函數
  • 最終執行的是hal_set_led_color函數 執行切換不同燈的狀态

故障架構

 http://image.huawei.com/tiny-lts/v1/images/[email protected]

• 故障檢測和告警解耦。
• 硬體和非硬體的故障檢測解耦。
• 告警主體歸一。

檢測流程

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);

現在的情況

• 上電後健康訓示燈應該為紅色閃動，而訓示燈還是綠色閃動
• 屏蔽報警沒有做對應的處理

分析問題

• 通過簡單的日志調試（ibma_edge/common.log）
• 發現 g_ext_infs 這個結構體在重新開機的時候，為 nil 空；
• 并且 ret 傳回 非 0
• 當重新開機一個platform服務的時候，發現這個g_ext_infs又重新開機啟動了一個程序，
• 但是在新的程序裡面，這裡，g_ext_infs的機構體為空
• 并且 pfn_set_led_color為空
• 排查發現，py中的hal在這個程序中可能是未初始化。

解決方案

• • 重新調用devm_init()初始化一個新的程序保證硬體那邊可以健康
  • 重寫适配接口，讓屏蔽告警調用取消對應的信号報警