公司内部的API接口一般會分為兩大類，一類是直接暴露在公網可以通路的，一類是隻能在區域網路内通路的。
暴露在公網的一般就是業務網關以及一些和第三方公司有着某些合作，進而進行資料互動的接口。
檢查API接口是否存活，第一反應應該就是健康檢查了。
在區域網路環境内搭配 nginx 或注冊中心之類的健康檢查機制，一定程度的保證了隻有健康的執行個體才會進行服務。
把這一塊放到公網環境，判斷一個API接口是否存活，情況就複雜很多了。
域名解析
SSL證書
響應情況
...
舉個老黃待過的兩個公司的實際例子，這兩個公司遇到的都是SSL證書過期，沒有及時更換的問題，直接就是最進階故障。
在這種情況下，其實接口在區域網路内是能正常通路，可以了解成它是存活的，但是放到公網環境，使用者就是不能通路到，這個時候對使用者來說就是故障的。
是以涉及到對外服務API存活的檢查，光一個簡單的健康檢查還是不夠的，還需要站在使用者的層面去考慮。
或許大家會說，這種事情不是運維負責的嗎？怎麼還要我們開發去操心？
這個很大程度是看團隊的，有的團隊都不一定有運維這個角色，都是開發搞定的。
另外，多豐富一點自己的技術棧和技術廣度并不是什麼壞事哈。
下面就簡單介紹一下老黃的處理方案吧。
老黃這邊選擇的處理方案是 【Prometheus + Blackbox + Grafana + Alertmanager + PrometheusAlert】
Prometheus，Grafana 和 Alertmanager 這三個就不過多的介紹了。
下面主要介紹一下 Blackbox 和 PrometheusAlert：
Blackbox 是 Prometheus 官方提供的一種黑盒監測方案，也是本文一個最關鍵的點。
下面是一些常見的應用場景
HTTP 測試，定義 Request Header 資訊，判斷 Http status / Http Respones Header / Http Body 内容
TCP 測試， 業務元件端口狀态監聽，應用層協定定義與監聽
ICMP 測試，主機探活機制
POST 測試，接口聯通性
SSL 證書過期時間
PrometheusAlert 是開源的運維告警中心消息轉發系統，支援主流的監控系統Prometheus、Zabbix，日志系統Graylog2，Graylog3、資料可視化系統Grafana、SonarQube等支援WebHook接口的系統發出的預警消息，支援将收到的這些消息發送到釘釘，微信，飛書，騰訊短信，騰訊電話，阿裡雲短信，阿裡雲電話，華為短信，容聯雲電話等。
換句話就是說，把告警消息通過 PrometheusAlert 發送個體企業微信機器人或釘釘機器人。
整個鍊路大概是這樣的：
BlackBox 負責探測
Prometheus 主動 pull 探測的結果并進行存儲
Prometheus 根據告警規則進行評估，将告警仍到 AlertManager
AlertManager 收到 Prometheus 的消息後，通知給 PrometheusAlert
PrometheusAlert 收到 AlertManager 的消息後，通知到對應的端
下面先用 docker 啟動一個 blackbox-exporter 執行個體
運作後看到的大概就是這個樣子。
這一塊的配置基本不用變更，用預設的即可，主要的配置還是在 Prometheus 那邊。
可以點選上圖的 Configuration 去看預設的配置。
下面就去調整 Prometheus 的配置。
這裡隻以 http 檢測為例來說明。
其中 <code>scrape_configs</code> 裡面是最為重要的，一個是 params ，一個是 relabel_configs， 一個是 file_sd_configs。
剩下的就是一些正常配置了。
然後是 file_sd_configs 裡面一堆可以變化的 yml 檔案，也就是那些對外的域名要進行 http 檢測的。
配置裡面的 labels 是一些輔助資訊，可以按需添加，可以在 grafana 裡面進行展示的。
到這裡，關于 blackbox 的配置基本就差不多了。
接下來是在 grafana 裡面展示，看一下結果。
PS: 這裡用的是 【9965】 這個模闆。
面闆雖然好看，但是我們不能每時每刻都在盯着這個面闆的，是以還是離不開告警這一監控領域的大頭。
下面是告警規則的配置
上面這個主要是3個告警規則，看描述就知道它的作用的，也不用過多的說明了，這些告警表達式是參考 Awesome Prometheus alerts 調整的。
再下一步就到告警消息的配置了。
先用 docker 啟動一個 prometheus-alert 的執行個體
這裡預設帶了很多模闆
這裡選擇自己定義一個告警模闆
這裡的模闆是做了一個顔色的區分，告警的用紅色，恢複的用綠色，由于 Prometheus 和 AlertManager 用的都是 UTC 時間，是以這裡用 GetCSTtime 轉化成中原標準時間。
最後是回到 alertmanager 裡面去配置
最後來看一些實際告警和恢複的例子
如果不想考慮自己搭建的話，不少雲産商也有提供類似的功能，好比阿裡雲有一個叫站點監控的産品也可以幫我們搞定這個問題，不過隻能免費一個月，超過還是需要購買的。
API接口存活的檢查其實也是一門不小的學問，考慮的内容還是不少的。經曆過生産事故，是以對這一塊會特别看重。
目前中小團隊的監控體系應該是離不開事實标準的 Prometheus，是以在其基礎上去拓展會有比較多成熟的可以借鑒的經驗來落地。
https://github.com/prometheus/blackbox_exporter
https://grafana.com/grafana/dashboards/9965
https://awesome-prometheus-alerts.grep.to/rules
https://feiyu563.github.io
如果您認為這篇文章還不錯或者有所收獲，可以點選右下角的【推薦】按鈕，因為你的支援是我繼續寫作，分享的最大動力！
作者：Catcher Wong ( 黃文清 )
來源：http://catcher1994.cnblogs.com/
聲明：
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。如果您發現部落格中出現了錯誤，或者有更好的建議、想法，請及時與我聯系！！如果想找我私下交流，可以私信或者加我微信。