說到監控，一般都會聊到這三個基本維度：metrics、log和tracing，以及這幾種常用的工具：Prometheus+grafana+alertmanager、ELK、jaeger。
監控通常來展示應用或叢集的執行狀態，配合告警來達到維護系統穩定性的目的。但除此之外，還可以將監控資料用於其他用途。
下面以metrics為例，聊聊除了監控和告警外，還可以用於實現哪些功能。
擴縮容採用的其實也是監控方式。它會實時獲取服務的相關指標，以此來達到擴容範例和縮容範例的目的。
最常見的方式是使用kubernetes提供的HPA資源來實現基於CPU利用率的擴縮容，也可以使用自定義指標，如基於QPS，來實現擴縮容。
開源產品可以參見：prometheus-adapter和KEDA。
相對高階的方式是集合機器學習來實現HPA，相比上述方式的好處是，結合機器學習可以提前預知可能存在的資源波峰，提前進行HPA，避免被動HPA帶來的延遲影響。可以參考騰訊的Crane實現。
這也是一種比較高階的用法。
在實際場景中，大部分業務開發並不清楚自己的服務到底需要多少(CPU、記憶體等)資源，因此通常的做法是在允許的範圍內儘可能多申請資源，但這樣做會導致大量資源浪費。
典型的場景，如可能會給某個用於同步組態檔的服務申請4C8G這樣的資源設定，但該服務實際使用的CPU可能僅為0.1Core，而記憶體可能僅為幾十M。
這種設定處理方式除了會造成資源上的浪費外，還給運維帶來了一定的複雜度。例如，很多公司的開發環境都會分為生產和非生產。非生產環境一般資源都比較有限(雖然開發規範要求生產和非生產要保證一致，但出於成本等因素很難實現統一)，因此經常會出現某些新的應用因為叢集資源不足而無法釋出的問題，此時運維人員不得不與其他業務開發者溝通來釋放出一部分資源，但實際情況是，環境中的很多應用資源利用率極低，但又不能輕易修改其資源設定。
因此比較理想的做法是使用機器學習，根據歷史資源使用率來為應用提供合理的資源設定。這種方式有一定的挑戰性，因為應用的資源並不是一成不變的，其資源使用率會因白天/晚上、工作日/休息天、大促、甚至系統重啟載入等因素而異，因此不能僅僅根據平均值來設定資源設定。可以參考uber的最佳實踐.
使用指標來保證SLA也是一種常見的方式。比如某個雲廠商保證的VM的SLA為x%，那麼我們可以通過node-exporter提供的節點指標來統計節點的線上率等資訊，進而檢查LB是否達到了SLA是的要求。當然也可以將SLA用於內部團隊，用來評估團隊提供的服務是否足夠穩定。
在工作中，有些場景可能會需要知道，如online環境有多少應用？設定了大規格CPU或記憶體的應用有哪些？某個應用的POD的應用ID是啥？
遇到這類問題，通常想法就是登入對應的環境，然後檢視相應的設定。但很多時候會遇到環境授權的問題，大部分只要審批通過即可。但偶爾也會遇到到因為相關審批人請假等原因導致問題定位受阻的情況。這時候應該想到利用監控資料。以metrics為例，這類監控資料涵蓋的資訊相當廣泛，可以包含Iaas層資料(如虛擬機器器，kafka、redis等元件資訊，閘道器資訊)和Paas層資料(容器資料、kubernetes元件資訊)和Saas層資料(應用自定義指標)等，由於metrics不會像Log這樣可能會因為包含隱私資料而被隔離，且由於實際監控告警可能會結合來自不同採集源的metrics，因此一般不會也很難對metrics進行隔離。因此metrics中其實包含了大量有用的資訊。
除了解決某些情況下獲取相關資料的問題，只要有足夠的標籤，metrics還可以提供更多層次的資訊，可以給戰略決策以及工作質量評價等方面提供更高維度的資訊。
針對業務部門，除了通過服務重啟、異常請求等指標反應服務的執行狀態之外，還可以通過如下指標繪製的曲線，從一定時間維度上了解本部門的服務現狀，由此可以摒棄其他因素來直接評價服務開發質量(如加班時長與服務質量並無直接關聯)。
目前應該沒有公司高層會通過這種方式瞭解公司的現狀，但我認為這不失為一種精確瞭解公司現狀的方式。
大多數公司高層瞭解到的關於公司現狀的資訊基本都是通過層層上報獲得的，但層層上報很難避免資訊注水以及部門偏袒等因素。可以通過metrics的相關指標的曲線圖來直接反應公司運營現狀，如：
上面僅給出了部分可能有用的場景(畢竟本人也不是高層。)，但metrics指標所包含的資訊互不影響，又相互關聯，彼此之間有著千絲萬縷的關係。通過梳理相關的資訊，甚至可以得出驚人的資料，例如整個公司最近半年甚至一年的發展現狀，這些資訊甚至直接反應了公司的運營情況。
上面介紹了metrics指標在監控告警之外的一些用途場景，特別是最後一點，這也是我在使用metrics的過程中越來越深刻體會到的一點。
基於上面的介紹，我總結了幾點應該做的事：
本文來自部落格園，作者：charlieroro，轉載請註明原文連結：https://www.cnblogs.com/charlieroro/p/16434344.html