我管理一個網路服務，對於我的公司來說，檢測並通知是否有任何服務關閉，以及它執行的任何操作是否需要很長時間才能回應，這一點非常重要。到目前為止，有一個單獨的Web 應用程式（包括前端和後端）只是每15 分鐘請求對這些端點進行隨機操作，但我發現它很複雜，因為它需要為此目的維護整個Web 應用程序，而且我知道許多免費的Web 服務應該可以完成這項工作。
我已經設定了 AWS Healthchecks 來替換輪詢 Web 應用程序，並且非常適合正常運行時間部分，現在我的問題來自回應時間部分。
所有這些API 健康檢查服務似乎都為不太複雜的請求做好了準備，因此API 應該有責任為健康檢查服務提供「狀態」端點，並包含資料庫延遲等「正常」內容，或者應該是「健康檢查器」 「負責執行複雜請求的人？什麼樣的做法比較正確呢？
謝謝！
答案1
您可能不應該透過應用程式的運行狀況檢查路徑來監視資料庫效能 - 可能會發生一些危險情況。假設您在 AWS 中使用 ASG，並使用 LB 運作狀況檢查來確定 ASG 是否應該輪換機器。如果您開始出現資料庫爭用（與您的應用程式無關），您的 ASG 將開始刪除節點。因此，您不僅會擁有效能不佳的資料庫，而且 ASG 也會耗盡。
通常，績效應該在健康狀況之外進行監控。我們大量使用 statsd 並將所有指標、應用程式和資料庫注入其中，以便我們可以基於此繪製圖表並發出警報。
另請記住，當您擴展時，您的運行狀況檢查速度也會擴展- 我們有一些服務每秒接收數千個運行狀況檢查請求，如果每個服務都執行合成昂貴的查詢，我們的數據層將離線。
隨著您添加快取層，邏輯也會變得更加複雜 - 如果資料庫正常但您的 KV 快取不正常，運行狀況檢查端點應該返回什麼？
總的來說，雖然端到端監控對於有效的監控策略至關重要，但我強烈建議對流向資料庫的現有查詢指標進行帶外監控- 這些指標代表真實的用戶性能，並將為您提供可量化的指標您的應用程式運作狀況實際表現如何。