談到監控，有各類各樣的監控軟件，有各類各樣的存儲數據的格式，最流行的莫過於將相關的監控數據存儲在mysql中，建一個表，而後按照時間來進行監控，這種方式最大的缺點就是不能靈活的按照各類維度來統計數據。mysql
強大的監控，一眼看過去，就能知道是啥出了問題；強大的監控，易於使用，不用處處找啊找，躲貓貓瞭解一下。。。
nginx
有一種監控方式，分爲黑盒監控和白盒監控，看起來和測試好像。。。所謂的黑盒測試和白盒測試。。。想起來我養的兩隻狗，稱之爲黑白雙煞。。。
程序員
黑盒監控，主要關注的現象，通常都是正在發生的東西，例如出現一個告警，某文件系統不可寫入，那麼這種監控就是站在用戶的角度能看到的監控，重點在於能對正在發生的故障進行告警。
web
白盒監控，主要關注的是緣由，也就是系統內部暴露的一些指標，例如redis的info中顯示redis slave down，這個就是redis info顯示的一個內部的指標，重點在於緣由，多是在黑盒監控中看到redis down，而查看內部信息的時候，顯示redis port is refused connection。redis
什麼是因？什麼是果？種果得果，種因得因。。。
sql
白盒監控，有不少種，有中間件，有存儲，有web服務器例如redis可使用info暴露內部的指標信息；例如mysql可使用show variables暴露內部指標信息；例如httpd可使用mod_status來暴露內部信息。。。
數據庫
白盒監控，對於應用系統來講，就稱之爲應用的埋點。。。糾結了很久，什麼叫埋點，埋葬一個葬花人麼。。。簡單能夠理解爲，經過編程的方式，來收集相關的數據，例如請求的成功率，請求的失敗率，將相關的數據收集以後，統一發給監控系統，若是符合報警規則，則進行報警。。。
編程
嗬，埋點。。。在應用系統中，增長metric的時候，主要根據監控系統的client sdk來進行設置。。。聽起來感受好酷，實際瞭解了一下，其實。。。也就那樣，一點都很差玩。。。
服務器
一個監控系統的構建，若是沒事就發出來告警，這種狗屎監控，留着有何用？？？信噪好比此之高，怎麼玩。。。適當下降心理指望？一不當心就是一個故障，一不當心就是一個鍋。。。
微信
下降SLO來改進服務，優化服務質量，或者。。。全名運維，本身拉的屎本身吃，讓開發本身來運維吧。。。運維，或許也只是一個擦屁股的玩意兒。。。
探針？prober。。。在不少時候，咱們須要探針來檢測一些東西，例如進程在不在呀，例如磁盤分區是否可寫呀。。。
探針？斷了怎麼辦。。。
上次碰到一個告警，某某主機的文件系統不可寫，總體流程以下：prober是一個進程，在須要測試的分區上寫入一個文件，成功以後，刪除文件。。。
收到告警，那就處理唄，上去這個主機，找到這個分區，寫入一個文件。。。嗬，能夠寫入。。。查看測試文件，發現還在。。。流程沒走完？這屬於誤報。。。
好吧，既然是誤報，那就重啓一下prober，從新進行探測一次。。。嗬，竟然沒成功。。。這。。。觸碰到了知識盲區。。。
查看一下檢測的進程，發現還在。。。最後發現有一個子進程，其實也就是touch文件的進程變成了殭屍進程。。。因此，不管怎麼重啓都是不能解決的。。
查看一下殭屍進程的父進程，還好還好，不是pid爲1的進程，殺掉殭屍進程的父進程，一切OK。。。
探針。。。斷了怎麼辦，萬萬沒想到。。。竟然變成了殭屍進程
長尾效應。。。在監控中，常常須要查看各類監控指標的rate，能夠是流量，能夠是各類請求的數量，那麼在統計這種數據的時候，須要注意長尾效應，畢竟若是百分之九九的請求響應速度爲1ms，剩下的百分之一的請求爲5s，看看平均值，嗬。。。相差的太多了。。。從而在一些監控系統中，須要統計百分之五請求的成功率，百分之五十的成功率，百分之九十的成功率。。。固然，把請求分爲成功率和失敗率是一種更好的作法。。。畢竟慢慢的失敗比很快的失敗要好的多咯？？？
監控，怎麼和開發人員配合？
把開發人員拉到一邊說。。。兄弟，你加班加點開發的BUG看看一天告警一百個。。。你來運維試試？
把開發人員拉到一邊說。。。兄弟，你開發的系統性能很高啊，你看看這CPU，這內存使用量，這文件系統，這吞吐量。。。可是這個前臺界面的響應時間不高啊，從web頁面到nginx這個響應時間還行，可是從nginx獲得請求和響應的時間有點長哇，是否是數據庫的性能不足了？是由於數據庫裏面的數據太多了麼？要分庫分表嘛。。。我有分庫分表的方法，可是應用方面要進行改造。。。我能夠給你增長一個redis cache。。。要不要試一把~
監控，怎麼和產品配合？
把產品拉到開發旁邊，指着dashboard說，看看這個日活量，看看這個活動的增加用戶說，看看這個點贊數。。。大家的需求是根據屁股決定麼？關門放程序員。。。
某人被提高爲管理者，今後咱們失去了一個優秀的運維人員，增長了一個傻逼的管理者。。。Emmm。。。這個話頗有道理。。。
have you tell Prometheus which Alertmanager
it will be talking to. You will need to expand your prometheus
隨時隨地進行功能測試的時候，是否在這個功能測試中須要加入重試機制？？？功能測試自己故障怎麼辦？網絡抖動怎麼辦？。。。某些service test仍是須要的。。。
本文分享自微信公衆號 - SRE運維實踐（gh_319dd73ec076）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。