筆者從open-falcon開源到現在，從事運維監控領域相關工作差不多7年，在做open-falcon和nightingale的社群答疑過程中發現，有大量的小白問題，很多是因為對這個領域缺乏基礎認識，是以，想寫一個針對入門級使用者的系列文章，做一下知識的普及。
另外，監控這個事情，其實也是研發人員走到某個段位之後必須要了解的。因為監控是穩定性體系建設中最重要的一環，普通研發人員往架構師轉變，需要了解更多橫向的知識，比如持續內建、服務治理、穩定性保障等等，是以了解一下監控，也很有必要。
這是一個很公益的事情，希望大家一起參與讨論，分享經驗，為小白領路，功德無量~
監控是保障業務穩定性的重要手段，那怎麼提升穩定性呢？簡單來說，就是減少故障，一個是減少故障的數量，一個是減少單一故障的影響時長，即出現故障後快速止損。減少故障這個方面，更多的要訴諸于魯棒的業務系統架構和穩定的基礎設施，監控在這個方面沒有辦法提供太多助力。對于減少單一故障的影響時長，監控是非常有價值的。
在出現故障時，監控系統可以及時感覺，及時發告警通知相關人員，讓值班的人快速響應，處理故障。處理故障的第一步就是要定位問題，定位問題需要有資料支撐，監控系統的另一個重要職能，就是要提前收集詳實的資料，比如日志資料、名額資料等等。
另外，有人可能會想，監控系統能不能通過資料分析手段，提前預測未來可能發生的故障，不要等到故障發生了才來通知我。這個想法很性感，但是，現實很骨感，據筆者了解，業界目前有這方面的嘗試，但是場景相對有限，姑且可以作為一個噱頭跟不懂的老闆吹牛吧。
監控分很多方向，總體來看，所有影響終端使用者使用體驗的方面，都可以考慮增加監控。比如某個手機app的産品，要監控哪些東西？比如：app本身是不是crash了、app是不是有卡頓、app到服務端的網絡鍊路是不是品質差了、服務端公網出口是不是擁塞了、多個機房之間專線是不是抖動了、服務提供的接口成功率是不是下降了、服務依賴的第三方元件是不是挂了、機器負載是不是太高了、磁盤空間是不是滿了、系統是不是列印了一些錯誤日志、硬體是不是産生了故障事件，等等等等
筆者主要精力在服務端監控，要監控的方向整體如下：
基礎設施類：網絡鍊路、網絡裝置、硬體、作業系統
存儲中間件：mysql、redis、rabbitmq、kafka、tomcat、zookeeper、ceph等等等等
應用層監控：接口qps、成功率、延時等
業務層監控：訂單量、交易支付量、線上使用者量等等
監控大緻分四個方向：名額監控、日志監控、鍊路追蹤、事件監控，即metrics、logging、trace、event。名額監控相關的開源軟體比如：zabbix、prometheus、open-falcon、nightingale，日志監控相關的開源軟體比如：elk、grafana loki，鍊路追蹤相關的開源軟體比如：zipkin、skywalking，事件監控相關的開源軟體比如：呃，筆者沒找到專門針對這個方向的開源軟體。
名額監控主要是監控數值類型的時序資料，比如某個機器的cpu空閑率、某個機器的記憶體使用率、某個接口的qps，這些資料通常是按照一個固定的頻率采集上報給監控系統，上報的時候會帶上名額名字、時間戳、值等資訊。
日志監控主要是收集日志的，比如作業系統日志、各類中間件的日志、業務系統列印的日志，日志收集到中心之後，提供檢索分析能力，可以從日志中提取到一些名額，輔助業務決策，也可以用這些名額做告警。
鍊路追蹤即trace，是說把使用者端觸發的一次請求，配置設定一個requestid，這個請求相關的所有的子產品，都可以用這個requestid串聯起來，然後我們就可以拿着這個requestid，去追蹤這個請求，看這個請求流經的各個子產品的耗時情況、成功失敗情況。
事件監控比較典型的是ipmi吐出的硬體故障事件，或者交換機trap事件，或者在應用程式的邏輯裡遇到一個異常狀況，也可以生成一個事件，所有的事件統一發給事件監控管理系統，在這個系統裡做分類通知、合并降噪等。
其中，名額監控系統通常是最基礎的監控系統，也是筆者最有經驗的一個系統，後續的文章大都是圍繞名額監控的體系來進行講解。
歡迎大家轉發、參與讨論、分享經驗~