怎樣監測微型的網站服務

導讀	最終我意識到，我所要寫的任何伺服器的風險都很低，如果它們偶爾當機 2 小時也沒什麼大不了的，我只需設定一些非常簡單的監控來幫助它們保持執行。

你好! 我最近又開始執行一些伺服器（nginx playground、mess with dns、dns lookup），所以我一直在考慮監控問題。

最初我並不完全清楚如何監控這些網站，所以我想快速寫下我是如何做到的。

我根本不打算談如何監控大型的、嚴肅的關鍵任務網站，只談微型的不重要的網站。

我希望網站大部分時間都能正常工作，但我也希望不用在持續的運營上花費時間。

我最初對執行伺服器非常警惕，因為在我的上一份工作中，我是 24/7 輪流值班，負責一些關鍵的服務，在我的印象中，“負責伺服器”意味著“在凌晨 2 點被叫起來修理伺服器”和“有很多複雜的儀表盤”。

所以有一段時間我只做靜態網站，這樣我就不用考慮伺服器的問題。

但最終我意識到，我所要寫的任何伺服器的風險都很低，如果它們偶爾當機 2 小時也沒什麼大不了的，我只需設定一些非常簡單的監控來幫助它們保持執行。

起初，我根本沒有為我的伺服器設定任何監控。這樣做的結果是非常可預見的：有時網站壞了，而我卻沒有發現，直到有人告訴我！

第一步是建立一個 uptime 檢查器。外面有很多這樣的東西，我現在使用的是 updown.io 和 uptime robot。我更喜歡 updown 的使用者介面和 定價 結構（它是按請求而不是按月收費），但 uptime 機器人有一個更慷慨的免費套餐。

它們會：

1. 檢查網站是否正常


2. 如果出現故障，它會給我發電子郵件

我發現電子郵件通知對我來說是一個很好的通知級別，如果網站當機，我會很快發現，但它不會吵醒我或做其它的什麼打擾。

接下來，讓我們談談“檢查網站是否正常”到底是什麼意思。

起初，我只是把我的健康檢查端點之一變成一個函式，無論如何都會返回 200 OK。

這倒是挺有用的 – 它告訴我伺服器是啟動著的！

但不出所料，我遇到了問題，因為它沒有檢查 API 是否真的在 工作 – 有時健康檢查成功了，儘管服務的其他部分實際上已經進入了一個糟糕的狀態。

所以我更新了它，讓它真正地發出 API 請求，並確保它成功了。

我所有的服務都只做了很少的事情（nginx playground 只有一個端點），所以設定一個健康檢查是非常容易的，它實際上貫穿了服務應該做的大部分動作。

下面是 nginx playground 的端到端健康檢查處理程式的樣子。它非常基本：它只是發出一個 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("(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 分鐘執行一次。

我的一些網站在 fly.io 上，fly 有一個相當標準的功能，我可以為一個服務配置一個 HTTP 健康檢查，如果健康檢查失敗，就重新啟動服務。

“經常重啟”是一個非常有用的策略來彌補我尚未修復的 bug，有一段時間，nginx playground 有一個程式洩漏，nginx 程式沒有被終止，所以伺服器的記憶體一直在耗盡。

透過健康檢查，其結果是，每隔一天左右就會發生這樣的情況：

1. 伺服器的記憶體用完了


2. 健康檢查開始失敗


3. 它被重新啟動


4. 一切又正常了


5. 幾個小時後再次重複整個傳奇

最終，我開始實際修復程式洩漏，但很高興有一個解決方法可以在我拖延修復 bug 時保持執行。

這些用於決定是否重新啟動服務的執行狀況檢查更頻繁地執行：每 5 分鐘左右。

這可能很明顯，我在一開始就已經說過了，但是“編寫一個 HTTP 健康檢查”並不是監控大型複雜服務的最佳方法。 但我不會深入討論，因為這不是這篇文章的主題。

我最初在 3 個月前的四月寫了這篇文章，但我一直等到現在才釋出它以確保整個設定正常工作。

這帶來了很大的不同 – 在我遇到一些非常愚蠢的停機問題之前，現在在過去的幾個月裡，網站的執行時間達到了 99.95%！

原文來自：