你好! 我最近又開始運(yùn)行一些服務(wù)器（??nginx playground???、??mess with dns???、??dns lookup??），所以我一直在考慮監(jiān)控問題。

最初我并不完全清楚如何監(jiān)控這些網(wǎng)站，所以我想快速寫下我是如何做到的。

我根本不打算談如何監(jiān)控大型的、嚴(yán)肅的關(guān)鍵任務(wù)網(wǎng)站，只談微型的不重要的網(wǎng)站。

目標(biāo)：在操作上幾乎不花時(shí)間

我希望網(wǎng)站大部分時(shí)間都能正常工作，但我也希望不用在持續(xù)的運(yùn)營上花費(fèi)時(shí)間。

我最初對(duì)運(yùn)行服務(wù)器非常警惕，因?yàn)樵谖业纳弦环莨ぷ髦校沂?24/7 輪流值班，負(fù)責(zé)一些關(guān)鍵的服務(wù)，在我的印象中，“負(fù)責(zé)服務(wù)器”意味著“在凌晨 2 點(diǎn)被叫起來修理服務(wù)器”和“有很多復(fù)雜的儀表盤”。

所以有一段時(shí)間我只做靜態(tài)網(wǎng)站，這樣我就不用考慮服務(wù)器的問題。

但最終我意識(shí)到，我所要寫的任何服務(wù)器的風(fēng)險(xiǎn)都很低，如果它們偶爾宕機(jī) 2 小時(shí)也沒什么大不了的，我只需設(shè)置一些非常簡單的監(jiān)控來幫助它們保持運(yùn)行。

沒有監(jiān)控很糟糕

起初，我根本沒有為我的服務(wù)器設(shè)置任何監(jiān)控。這樣做的結(jié)果是非常可預(yù)見的：有時(shí)網(wǎng)站壞了，而我卻沒有發(fā)現(xiàn)，直到有人告訴我！

步驟 1：uptime 檢查器

第一步是建立一個(gè) uptime 檢查器。外面有很多這樣的東西，我現(xiàn)在使用的是 ??updown.io?? 和 ??uptime robot??。我更喜歡 updown 的用戶界面和 ??定價(jià)?? 結(jié)構(gòu)（它是按請(qǐng)求而不是按月收費(fèi)），但 uptime 機(jī)器人有一個(gè)更慷慨的免費(fèi)套餐。

它們會(huì)：

1. 檢查網(wǎng)站是否正常
2. 如果出現(xiàn)故障，它會(huì)給我發(fā)電子郵件

我發(fā)現(xiàn)電子郵件通知對(duì)我來說是一個(gè)很好的通知級(jí)別，如果網(wǎng)站宕機(jī)，我會(huì)很快發(fā)現(xiàn)，但它不會(huì)吵醒我或做其它的什么打擾。

步驟 2：端到端的健康檢查

接下來，讓我們談?wù)劇皺z查網(wǎng)站是否正常”到底是什么意思。

起初，我只是把我的健康檢查端點(diǎn)之一變成一個(gè)函數(shù)，無論如何都會(huì)返回 ??200 OK??。

這倒是挺有用的 – 它告訴我服務(wù)器是啟動(dòng)著的！

但不出所料，我遇到了問題，因?yàn)樗鼪]有檢查 API 是否真的在 工作 – 有時(shí)健康檢查成功了，盡管服務(wù)的其他部分實(shí)際上已經(jīng)進(jìn)入了一個(gè)糟糕的狀態(tài)。

所以我更新了它，讓它真正地發(fā)出 API 請(qǐng)求，并確保它成功了。

我所有的服務(wù)都只做了很少的事情（nginx playground 只有一個(gè)端點(diǎn)），所以設(shè)置一個(gè)健康檢查是非常容易的，它實(shí)際上貫穿了服務(wù)應(yīng)該做的大部分動(dòng)作。

下面是 nginx playground 的端到端健康檢查處理程序的樣子。它非常基本：它只是發(fā)出一個(gè) POST 請(qǐng)求（給自己），并檢查該請(qǐng)求是成功還是失敗。

        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)
        }

健康檢查頻率：每小時(shí)一次

現(xiàn)在，我大部分健康檢查每小時(shí)運(yùn)行一次，有些每 30 分鐘運(yùn)行一次。

我每小時(shí)運(yùn)行一次，因?yàn)?nbsp;??updown.io?? 的定價(jià)是按健康檢查次數(shù)計(jì)算的，我正在監(jiān)控 18 個(gè)不同的 URL，而且我想把我的健康檢查預(yù)算保持在 5 美元/年的最低水平。

花一個(gè)小時(shí)來發(fā)現(xiàn)這些網(wǎng)站中的一個(gè)出現(xiàn)故障，對(duì)我來說是可以的 – 如果有問題，我也不能保證能很快修復(fù)它。

如果可以更頻繁地運(yùn)行它們，我可能會(huì)每 5-10 分鐘運(yùn)行一次。

步驟 3：第三步：如果健康檢查失敗，自動(dòng)重新啟動(dòng)

我的一些網(wǎng)站在 ??fly.io?? 上，fly 有一個(gè)相當(dāng)標(biāo)準(zhǔn)的功能，我可以為一個(gè)服務(wù)配置一個(gè) HTTP 健康檢查，如果健康檢查失敗，就重新啟動(dòng)服務(wù)。

“經(jīng)常重啟”是一個(gè)非常有用的策略來彌補(bǔ)我尚未修復(fù)的 bug，有一段時(shí)間，nginx playground 有一個(gè)進(jìn)程泄漏，??nginx?? 進(jìn)程沒有被終止，所以服務(wù)器的內(nèi)存一直在耗盡。

通過健康檢查，其結(jié)果是，每隔一天左右就會(huì)發(fā)生這樣的情況：

• 服務(wù)器的內(nèi)存用完了
• 健康檢查開始失敗
• 它被重新啟動(dòng)
• 一切又正常了
• 幾個(gè)小時(shí)后再次重復(fù)整個(gè)傳奇

最終，我開始實(shí)際修復(fù)進(jìn)程泄漏，但很高興有一個(gè)解決方法可以在我拖延修復(fù) bug 時(shí)保持運(yùn)行。

這些用于決定是否重新啟動(dòng)服務(wù)的運(yùn)行狀況檢查更頻繁地運(yùn)行：每 5 分鐘左右。

這不是監(jiān)控大型服務(wù)的最佳方式

這可能很明顯，我在一開始就已經(jīng)說過了，但是“編寫一個(gè) HTTP 健康檢查”并不是監(jiān)控大型復(fù)雜服務(wù)的最佳方法。 但我不會(huì)深入討論，因?yàn)檫@不是這篇文章的主題。

到目前為止一直運(yùn)行良好！

我最初在 3 個(gè)月前的四月寫了這篇文章，但我一直等到現(xiàn)在才發(fā)布它以確保整個(gè)設(shè)置正常工作。

這帶來了很大的不同 – 在我遇到一些非常愚蠢的停機(jī)問題之前，現(xiàn)在在過去的幾個(gè)月里，網(wǎng)站的運(yùn)行時(shí)間達(dá)到了 99.95%！