如何監測微型的網站服務
你好! 我最近又開始運行一些服務器（??nginx playground???、??mess with dns???、??dns lookup??），所以我一直在考慮監控問題。
最初我并不完全清楚如何監控這些網站，所以我想快速寫下我是如何做到的。
我根本不打算談如何監控大型的、嚴肅的關鍵任務網站，只談微型的不重要的網站。
目標：在操作上幾乎不花時間
我希望網站大部分時間都能正常工作，但我也希望不用在持續的運營上花費時間。
我最初對運行服務器非常警惕，因為在我的上一份工作中，我是 24/7 輪流值班，負責一些關鍵的服務，在我的印象中，“負責服務器”意味著“在凌晨 2 點被叫起來修理服務器”和“有很多復雜的儀表盤”。
所以有一段時間我只做靜態網站，這樣我就不用考慮服務器的問題。
但最終我意識到，我所要寫的任何服務器的風險都很低，如果它們偶爾宕機 2 小時也沒什么大不了的，我只需設置一些非常簡單的監控來幫助它們保持運行。
沒有監控很糟糕
起初，我根本沒有為我的服務器設置任何監控。這樣做的結果是非?？深A見的：有時網站壞了，而我卻沒有發現，直到有人告訴我！
步驟 1：uptime 檢查器
第一步是建立一個 uptime 檢查器。外面有很多這樣的東西，我現在使用的是 ??updown.io?? 和 ??uptime robot??。我更喜歡 updown 的用戶界面和 ??定價?? 結構（它是按請求而不是按月收費），但 uptime 機器人有一個更慷慨的免費套餐。
它們會：
- 檢查網站是否正常
- 如果出現故障，它會給我發電子郵件
我發現電子郵件通知對我來說是一個很好的通知級別，如果網站宕機，我會很快發現，但它不會吵醒我或做其它的什么打擾。
步驟 2：端到端的健康檢查
接下來，讓我們談談“檢查網站是否正?！钡降资鞘裁匆馑肌?/p>
起初，我只是把我的健康檢查端點之一變成一個函數，無論如何都會返回 ??200 OK??。
這倒是挺有用的 – 它告訴我服務器是啟動著的！
但不出所料，我遇到了問題，因為它沒有檢查 API 是否真的在 工作 – 有時健康檢查成功了，盡管服務的其他部分實際上已經進入了一個糟糕的狀態。
所以我更新了它，讓它真正地發出 API 請求，并確保它成功了。
我所有的服務都只做了很少的事情（nginx playground 只有一個端點），所以設置一個健康檢查是非常容易的，它實際上貫穿了服務應該做的大部分動作。
下面是 nginx playground 的端到端健康檢查處理程序的樣子。它非?；荆核皇前l出一個 POST 請求（給自己），并檢查該請求是成功還是失敗。
func healthHandler(w http.ResponseWriter, r *http.Request) {
// make a request to localhost:8080 with `healthcheckJSON` as the body
// if it works, return 200
// if it doesn't, return 500
client := http.Client{}
resp, err := client.Post("http://localhost:8080/", "application/json", strings.NewReader(healthcheckJSON))
if err != nil {
log.Println(err)
w.WriteHeader(http.StatusInternalServerError)
return
}
if resp.StatusCode != http.StatusOK {
log.Println(resp.StatusCode)
w.WriteHeader(http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusOK)
}
健康檢查頻率：每小時一次
現在，我大部分健康檢查每小時運行一次，有些每 30 分鐘運行一次。
我每小時運行一次，因為 ??updown.io?? 的定價是按健康檢查次數計算的，我正在監控 18 個不同的 URL，而且我想把我的健康檢查預算保持在 5 美元/年的最低水平。
花一個小時來發現這些網站中的一個出現故障，對我來說是可以的 – 如果有問題，我也不能保證能很快修復它。
如果可以更頻繁地運行它們，我可能會每 5-10 分鐘運行一次。
步驟 3：第三步：如果健康檢查失敗，自動重新啟動
我的一些網站在 ??fly.io?? 上，fly 有一個相當標準的功能，我可以為一個服務配置一個 HTTP 健康檢查，如果健康檢查失敗，就重新啟動服務。
“經常重啟”是一個非常有用的策略來彌補我尚未修復的 bug，有一段時間，nginx playground 有一個進程泄漏，??nginx?? 進程沒有被終止，所以服務器的內存一直在耗盡。
通過健康檢查，其結果是，每隔一天左右就會發生這樣的情況：
- 服務器的內存用完了
- 健康檢查開始失敗
- 它被重新啟動
- 一切又正常了
- 幾個小時后再次重復整個傳奇
最終，我開始實際修復進程泄漏，但很高興有一個解決方法可以在我拖延修復 bug 時保持運行。
這些用于決定是否重新啟動服務的運行狀況檢查更頻繁地運行：每 5 分鐘左右。
這不是監控大型服務的最佳方式
這可能很明顯，我在一開始就已經說過了，但是“編寫一個 HTTP 健康檢查”并不是監控大型復雜服務的最佳方法。 但我不會深入討論，因為這不是這篇文章的主題。
到目前為止一直運行良好！
我最初在 3 個月前的四月寫了這篇文章，但我一直等到現在才發布它以確保整個設置正常工作。
這帶來了很大的不同 – 在我遇到一些非常愚蠢的停機問題之前，現在在過去的幾個月里，網站的運行時間達到了 99.95%！
