如何監測微型的網站服務

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

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

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

目標：在操作上幾乎不花時間

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

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

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

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

沒有監控很糟糕

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

步驟 1：uptime 檢查器

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

它們會：

1. 檢查網站是否正常
2. 如果出現故障，它會給我發電子郵件

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

步驟 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("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%！

via: https://jvns.ca/blog/2022/07/09/monitoring-small-web-services/

作者：Julia Evans 選題：lujun9972 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive