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