簡單聊聊運維監控的其他用途
說到監控，一般都會聊到這三個基本維度：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的最佳實踐.
提供業務資料
SLI、SLO和SLA
使用指標來保證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還可以提供更多層次的資訊，可以給戰略決策以及工作質量評價等方面提供更高維度的資訊。
部門維度
針對業務部門，除了通過服務重啟、異常請求等指標反應服務的執行狀態之外，還可以通過如下指標繪製的曲線，從一定時間維度上了解本部門的服務現狀，由此可以摒棄其他因素來直接評價服務開發質量(如加班時長與服務質量並無直接關聯)。
- 服務釋出次數：從該指標可以判斷某個服務是處於快速迭代開發階段，還是處於穩定維護階段
- 服務的重啟次數和異常比率：可以將這些指標用在開發環境和生產環境中，從特定角度判斷服務的執行狀況(一般http服務不會返回非200的狀態碼，如果處理錯誤，可將自定義錯誤碼放到body中)。
公司維度
目前應該沒有公司高層會通過這種方式瞭解公司的現狀，但我認為這不失為一種精確瞭解公司現狀的方式。
大多數公司高層瞭解到的關於公司現狀的資訊基本都是通過層層上報獲得的，但層層上報很難避免資訊注水以及部門偏袒等因素。可以通過metrics的相關指標的曲線圖來直接反應公司運營現狀，如：
- 部門所有服務的釋出次數曲線：以此可以判斷部門服務的迭代開發情況，甚至以此可以判斷各部門的加班情況
- 部門服務的總異常比率：由此可以判斷部門服務的開發質量
- 從閘道器上訪問的TopN(以及倒數TopN)的Qps服務：由此可以判定當前最有價值以及最小价值的服務或部門
- 服務存在和消亡指標：結合服務釋出指標，可以近似判定公司是不是存在無效擴招。如歷史服務相關指標並未增加，但卻擴招了大量人員。
上面僅給出了部分可能有用的場景(畢竟本人也不是高層。)，但metrics指標所包含的資訊互不影響，又相互關聯，彼此之間有著千絲萬縷的關係。通過梳理相關的資訊，甚至可以得出驚人的資料，例如整個公司最近半年甚至一年的發展現狀，這些資訊甚至直接反應了公司的運營情況。
總結
上面介紹了metrics指標在監控告警之外的一些用途場景，特別是最後一點，這也是我在使用metrics的過程中越來越深刻體會到的一點。
基於上面的介紹，我總結了幾點應該做的事：
- 業務的相關指標最好有部門維度、專案維度以及應用維度的標籤
- 最好對指標進行租戶隔離，避免資訊洩露。單個或少量指標基本是沒有隱患的，但大量指標可能會彙總出重要資訊
- 可以為部門或高層提供一個能夠訪問相應許可權的指標的方式，