筆者在這裡探討的是grafana或類似的監控軟體能做什麼用，
至於安裝與設定，還請去其他地方找。

其中grafana是一個有名的可視化監控工具，
筆者在此介紹，並整理使用的情境，
但因為筆者業務範圍內其實並沒有使用grafana，
使用的頻率非常的少，
所以有任何沒說清楚或說錯的還請提出指正。

在之前與之後提過了邊界效益，跟許多的狀況，
那麼要如何察覺到異狀監控分析呢?

grafana是一個開源的數據可視化和監控工具，常用於分析和監控應用程序、服務、伺服器和網絡設備等的性能和運行狀態。
主要用法是將不同數據來源的信息集成到一個統一的儀表板中，以便輕鬆地可視化數據、創建警報、進行數據查詢和分析。
是一個可視化數據、創建警報、進行數據查詢和分析的工具。

筆者在這裡舉幾個常見的例子，作為分析

系統監控
主要是各種硬體效能CPU使用率、記憶體使用量、網路流量等
而這些監控的數據會是整體的量，
而其中也可以再次細分，
例如
Redis能使用記憶體總記憶體多少、使用的占比多少、還有多少百分比能使用，
網路(Network)的Input與Output效率，
client數量，
能看到很多以前常在課本上看到的各種資訊，
例如常常算的Hit Rate，
每秒執行命令數量，
與各種總體效率相關參數等等。

應用程式監控
例如假設兩隻API
一支專門接受公司外部的資訊
為exterior API 簡稱EXAPI
專門用來篩選資料、驗證防呆、驗證各種惡意資料等等

另一隻專門處理公司內部的資訊
interior API 簡稱INAPI
主要負責處理邏輯，連線DB，讀取寫入更改各種資料庫等等

那麼EXAPI如果因為請求量和頻率過高而導致出現執行緒池(thread pool)不夠，
這種邊界效益就很有可能是正常的，
所以在壓力測試出現這種狀況算是合理。

反過來說，
如果EXAPI因為資源使用過高導致RAM不夠的等等狀況，
這種狀況就會是很不合理，
因為這與最初的定義有所不同。

就像是大門的門衛可能因為太多事情而忙不過來，
但不可能因為個別事情而處理不過來。

而在INAPI，
就通常可以查詢到有哪幾隻API特別的久，
急需優化，
或處理太多事情應該拆分，
某些API是不是呼叫量異常的高，
或是優化過後查看是否真的效能上有優化，
因為實際上效能的優化，有時候會是反直覺的。

也很常用於監控服務器的健康狀態和效能，資料庫等等，
說到底也就是能根據傳入資料整合出多少資訊用。

那麼做到了監控，
在一開始有說過警報，
這一個筆者還蠻有趣，
絕大多數的警報會是寄送email，
在這邊會有多種告警方式，
其中有種是透過Webhook，
他是一個可以透過HTTP協定訂閱事件的方法。

那麼既然是HTTP協定訂閱事件，
那麼就可以觸發API或是一些呼叫，
甚至直接重啟服務，
讓他觸發警報就自動解決，
但這個設置的調配就得自己考量，
別最後處於無限回圈，
那就是本末倒置了。