CDN監控系統（一）
監控系統不僅僅是爲了告警，在人工智能裏面 只有 反饋收斂機制的系統才能不斷進化智能。監控系統要能反饋形成閉環，不斷正反饋。避免問題 而不是發現問題 ：
- 針對開發，需要完善代碼，日誌、接口、甚至開發管理。
- 針對運營，如何快速發現、排查、解決問題，避免問題（devops aiops）。
介紹系統 避免直接從軟件開始介紹 而是從業務 到 要解決的問題 以及如何閉環，軟件只是工具，意識和思想更加重要。
最早在討論監控系統的願景中，希望能做以下要求：
-
避免泛洪
針對告警要嚴格審覈，不需要立即處理的堅決不要告警，（注意監控告警和監控運營的區別，可以放到運營平臺後續分析處理） -
自動化分析
除了告警以外，最好是能提供更多方便排查的信息。比如cache 出現域名 5xx 狀態碼告警，需要聯動大數據平臺或者工具：（不一定要立即做到以下過程，但至少第一步需要做到）- 找到該類型 5xx 最多的 top 機器
- 在 top機器 根據日誌 判斷 5xx 的來源（源返回？緩存節點返回？負載均衡節點返回？哪一個環節出的問題。節點軟件最好調用公有的錯誤狀態碼返回接口，並在該接口中置一些調試信息，輸出到訪問日誌，可以方便迅速定位）
-
區別錯誤預防和錯誤告警
比如 服務軟件 影響併發數的一個重要參數是 listen baklog 隊列大小，可以使用 ss -nlp |grep nginx 查看。如果 第三列 太小 是有問題的。不應該把baklog 放入 監控 而是需要跑一個上線前的預檢測：- 監聽併發數是否太低（隱藏的問題併發太大時 偶爾建聯不成功）；
- 日誌或者輸出文件有沒有回滾（包括引用的第三方庫是否暗藏日誌，可以用工具https://github.com/zengxiaobai/systemtap-scripts iostatic.stap 查看庫是否在某個角落偷偷打印日誌）可能導致磁盤滿
- check_service 自重啓 上報告警, 開機自重啓
- check_core 和clean core，可能導致磁盤滿
現在開始接監控系統，對告警結合網上的描述有些總結很好：
告警收斂（PS： 收斂的基本策略：減少輸入、 分類、包含、屏蔽、合併）
- 分組 最基本的管理方式
- 抑制 主機掛了引起服務掛了告警 只需報主機掛了
- 靜默 當發生告警1和告警2 時，靜默告警3 和告警4
- 延時 類似任務週期合併策略
告警系統的高可用性
當沒有告警時 怎麼確定是真的正常 還是 告警系統掛了？https://blog.csdn.net/qq_39015563/article/details/84749241
告警系統和運營系統結合使用
監控指標
機器級別
- cpu
cpu 使用率和負載 - mem
可用mem空間 和swap是否關閉 - disk
磁盤可用空間 和 iowait - eth_IO
網卡出入流量，千兆（不超過 1G）和萬兆網卡（不超過 10G）
網卡流量變化太快
上下行流量（下行流量過高）
網絡級別
- ping
ping loss 或者 ping 太久 - port
端口 是否聯通 - tcp_conn
time_wait等 端口耗盡
系統級別
- 進程數
軟件級別
- 服務狀態
systemctl status xxx - 服務響應異常、時間長
- core 監控
- 軟件版本
- 配置文件丟失
- 攻擊
- 其他業務指標 （如 分頻道狀態碼、流量、攻擊、單機狀態碼等等）
