# 禮鼎進度
### 2023/03/20 會議記錄
1. 評估influx與pg的用量，來決定現場db的資源（event handler）
* influx group by造成消耗
* 部份資料寫入mm中
* dashboard（先做）
* 告警觸發（寄信）
* 統計資料（count）快取在mm
* dashboard查詢是用now-1m
* db規格3/23（四）回復，採用現行程式
2. 效能處理（1000個併發，event handler）
* 資產->（1000筆資料）->ec->拆份成1000個單筆，丟進各個rule的channel->若“觸發”每個channle會將統計資訊寫入redis，寫入rmq->（ec結束）
* worker->（多工）->rmq上收資料->restful api通知event handler
* event-handler -> 檢查alarm_name,alarm_status (PG)(可放MM) -> 去拿中文的deviceId label (PG) (可放MM) -> 去拿中文的tagId label (PG) (可放MM) -> 打寄信API(可背景執行，不等待) -> 把狀態寫回DB(PG)(更新MM)(寫DB) -> 寫influxdb (給dashboard用)
* dashboard (time-1m)
* rawdata: 進主頁面後的第一個表格，內容是最近一個月最後一次該告警的狀態。語法類似 select * where time < ? and time > ?，是透過 uuid 下去判斷，為了增加返回速度。
* count: 計算頁面中的告警中的數量和已解除的數量，語法類似 select count(distinct(uuid)) where time < ? and time > ? 。
* history：新需求，告警trigger和release要同一張表格。查詢語法與第一個rawdata類似。
* staticbytime：influxdb 查詢 後group by time。
* layout：這邊是要返回設備id和paths的需求，這邊有用到了last()和group by，是下次可以優化的地方。

4. ec與eh多工時，資料順序問題
* 確保相同ruleId的順序為一定。
* worker 根據 ruleId 建立 channel。

6. 程式更新或crash時，如何保證資料不丟失
* event-handler: 確認都寫完DB處理完之後，再回ack

7. 聯合測試，先提供測試案例

### 2023/03/20
1. 上週版本發佈
* rule-engine： v-1.2.0.15
* redis失效時的狀態處理
* event-handler： v-1.0.8.8
* 跑馬燈API
* time=now-5m
* dashboard格式調整(改回confrim,unconfirm)，移除多餘欄位
* building_id 錯位修正
* layout 返回值不匹配修正

2. 本週開發工項：
* event-handler:
* api history區分觸發時間與解除時間
* retenion policy
* alarm_status狀態修正(triggered/confirmed/released)
* 預計週二下班送測
3. 服務相依與啟動順序
* 相依服務：
* rule-engine： pg、redis、rmq
* event-handler： pg、influx
* worker： rmq
* 啟動順序
* rule-engine->worker->event-center
4. 事故分析
* 3/16（四）告警不正常多次觸發與解除
* 原因： 因odbc的資料採集是秒送而非數值有變動才發送，rule-engine發送給event-handler時採用多工傳輸，若相同資料連續發送會造成誤觸發
* 解決方法： 由資產協助處理，相同數據不發送
* 處理完成時間： 3/16（四）
* 3/17（五）告警未正常解除
* 原因： rule-engine是將告警狀態存在記憶體中，並同步備份至redis，當程式更新或重啟時，會由redis中的記錄回復告警的狀態。由於現場的redis配置錯誤，造成告警狀態回復出錯，導至告警無法解除。
* 解決方法： 更新現場的redis參數，並新增告警狀態無法復原的處理，發佈v-1.2.0.15
* 處理完成時間： 3/17（五）

### 2023/03/13
1. 跑馬燈返回資訊中的位置資訊的格式
2. 跑馬燈的api由誰來介接
3. now-5m的需求今日送測
4. 效能測試

測試場景：
1. 單一設備點位觸發(1個alarm)
查看日誌時間紀錄，資產發送數據後，ec和event-handler各共花費約1s

2023-03-09T08:09:52 start
2023-03-09 08:09:52 ec-worker
2023-03-09 08:09:52 event-handler

2. 觸發消防2F共844個alarms
2-1. 循序處理
查看日誌時間紀錄，ec處理時間共花費約2s，event-handler完成844個alarm觸發，共花費約1m44s

2023-03-09 07:10:46 start
2023-03-09 07:11:33 ec-worker
2023-03-09 07:12:30 event-handler

2-2.併發處理
查看日誌時間紀錄，ec和event-handlerr完成844個alarm觸發，各共花費約2s

2023-03-09 09:06:53 start
2023-03-09 09:06:55 ec-worker
2023-03-09 09:06:55 event-handler

5. rmq堆積問題

## 2023/02/20
### 02/17 （五）現場測試問題記錄

#### 1. 告警有觸發但無解除
初步排查：
1. 告警的觸發記錄在14：50多分後就無收到該裝置的資料
2. 2/20（一）上午有用API打模擬資料進去，告警有正常被解除
3. 2/20（一）上午和資產與edge討論後，先以stage進行同樣驗證，看是否有同樣問題
#### 2. 告警整度過慢採集到Dashboard需40秒
1. 看現場DB中的記錄，該筆告警資料從GRPC收到到rule engine判斷完送出約幾十ms
2. 在stage與object測過效能，1萬點到Rule engine判斷完送出約幾ms至幾十ms，到告警完成約2秒
3. event handler目前使用rmq接收後在發透過restful api通知event handler，故速度較慢，之後會改由直接由rmq取得來增進效能

### 派工巡檢整合
1. 前端已經開始動工
2. 後端介接規格已討論完畢，預計本週送測

---------------

12/26
現場狀況
1. 告警匯入
- 消防；環工
- 匯入完成
- 機電
- 尚有部份錯誤，排查中
- 與資產API反查name與id的對應，返回異常
- excel填寫可能有誤
- 路徑名稱有誤（F1 -> 1F）
- 告警UI應該顯示Name，但有時會出現id
- 可能原因，返查API太慢
- 資產位置有改變，導致查不到
- 資產資料串接 （GRPC）
- 現場收不到資料
- 未配制告警GRPC的位置
- 週五已配置，尚未檢查
2. 開發狀況
- 非同步下載，尚待廣榆康復串接UI
- 調整告警未解除發信邏輯
- 效能測試討論
- Bug修復
4. 測試狀況
- 60個測項
- 通過： 52 失敗： 8
- High Bug： 8

12/12 下午更新到禮鼎環境
- 首頁加速
- 批量刪除

12/12 可以開發完成，找機會再更新
- 異步上傳

後續優化
- 匯入中斷
- 異步批量刪除
- 匯入時間優化，目前一筆平均3秒

60個testcase
- 目前測約20個
- 全跑完約2天半

## Event Handler

|Resource|Admin|Editor|Operator|Viewer|None|
|:-:|:-:|:-:|:-:|:-:|:-:|
|Alarm|CRUD|RU|R|R|None|
|Operator|enable/disable/confirm/import/export|enable/disable/confirm/import/export|confirm/download|download|None|
|Manual|Release|Release|Release|None|None|