文章目錄html
grafana 是一個開源的時序性統計和監控平臺,支持例如 elasticsearch、graphite、influxdb 等衆多的數據源,並以功能強大的界面編輯器著稱。咱們在前端監控方面引入 grafana 後取得了一些不錯的反饋,可是不少用戶因爲以前沒有接觸過 grafana 常常會來詢問 grafana 的相關問題,所以但願本文對你們在 grafana 使用方面有所幫助。前端
grafana 的權限分爲三個等級:Viewer、Editor 和 Admin,Viewer 只能查看 grafana 已經存在的面板而不能編輯,Editor 能夠編輯面板,Admin 則擁有所有權限例如添加數據源、添加插件、增長 API KEY。git
對於普通用戶來講,Viewer 權限已經足夠,本文接下來的內容主要和 Editor 權限有關。因爲篇幅有限,本文做爲範例的數據源爲 graphite,同時也只介紹最經常使用的 Graph 圖表的配置方法。github
這裏有一個常見的 grafana 誤區,由於常常有用數值類型的 count_ps 來順便獲取每秒打點數量的狀況,注意在這種狀況下,一段時間內的打點總量須要使用 count_ps 的 avg 平均值來乘以這段時間的秒數來計算,而不是經過界面上的 Total 直接讀取。web
這是由於,在界面上一條曲線可以展現的點的數量是有限的,grafana 會根據你的窗口寬度來決定返回的點數,由於像一天
這樣的時間段確定沒辦法在界面上展現每一秒的點,畢竟總量爲86400個點就算帶魚屏也不可能擠得下。對於沒法展現的點,grafana 默認是使用 avg 平均值的行爲來修正返回點的值,舉個栗子,以下圖:chrome
上圖時間範圍是一天,上部分爲曲線面板的值,下部分爲 麪餅圖表的值,而且上部分圖標的曲線爲 count 類型(十秒聚一次),能夠看到 avg 平均值爲 683,那麼總量應該爲 682 乘以 6 (若是是count_ps 這裏則是60) 乘以 60 (一小時60分鐘)再乘以 24 (一天24小時)獲得589萬,與圖片中下部分的582萬相近,所以上部分 total 的117萬是一個完徹底全讓人誤解的值,能夠認爲它毫無心義進而直接無視掉。數據庫
上文中咱們計算出來的589萬和界面上的582萬其實也有一點偏差,不過這是能夠接受的,由於 statsd 通常狀況下是 UDP 的形式(它其實有 TCP 的形式),因此若是想要徹底正確的數據,那麼最好把打點相關的數據也入庫,從數據庫裏後置查詢出來的纔是徹底可靠。swift
模板變量可以動態地控制面板中的查詢語句,是十分重要的功能。常常能夠在面板的左上角發現它們,以下圖:後端
模板變量支持 $name
和 [[name]]
的寫法,針對 graphite 數據源主要使用前者,例如:stats.timers.fe.test.$key.count_ps
api
grafana 界面上齒輪按鈕 -> Templating -> 點擊 New,便可出現相似以下的界面:
本段主要介紹 Query 類型的寫法。
Never
,On Dashboard Load
和On Time Range Change
On Time Range Change
,不然 On Dashboard Load
就足夠了,Query 類型千萬不要選 Never,不然變量只會在你點進來編輯變量時纔會更新模板變量中的 Query 其實也支持模板變量,例如stats.timers.fe.test.$key.*
這樣的語句,會在 $key 變量變化時自動刷新值,是否是有一點 MVVM 的感受。這個功能用來聯動多個模板變量能夠大幅度減小 grafana 一次查詢的時間。
模板變量甚至能夠用在 grafana 的跳轉中,這是連文檔中都沒有說起的一個隱藏玩法,在 Link
或者 Dashboard
裏 URL 中任意位置填入 $name ,那麼在用戶點擊該連接跳轉時 grafana 一樣會替換該變量來讓你跳到正確的連接去。這和其餘系統整合起來可以作到很不錯的用戶體驗,例如跳轉到 kibana 那邊去查詢日誌。
kibana 和 grafana 的時間範圍格式並不同,可使用這篇文章 中的 chrome 插件來解決。
另外,Custom 模板變量能夠容許用戶在變量下拉框中自行輸入值,也是一個常常用到的值,配合模板變量會和當前連接中的 querystring 部分的var-${name}
同步,配合起來能夠輕鬆地從第三方系統中跳轉到正確的 grafana 面板中來
以 Editor 權限的帳號進入到任意麪板中,點擊某個圖表繼而點擊小彈窗中的 Edit 按鈕,便可進入圖表的編輯器界面。對於編輯器本文只介紹圖表的重要配置,Metrics,Legend 和 Display
toggle editor mode
能夠控制編輯模式,關閉則須要手動輸入查詢語句,開啓則是如上圖的能夠在界面上動態增刪改的模式。Panel data source
必定要選對,不然查不到對應的路徑,而且頗有可能冒出來 Mock 數據讓人一臉懵逼。開啓動態編輯模式時能夠在點擊上圖中每一個框框,這時 grafana 會自動加載該位置在數據源中的值,而且你也能夠在這裏選擇模板變量來動態控制。
點擊尾巴上的加號,會冒出來對應數據源的函數,能夠作一些高級的功能,這個也是本文下半部分的重點,稍後再作介紹。graphite 的函數比較多,其餘數據源會少一些。
Legend 主要控制曲線的名稱和值的展現,比較簡單,這裏列出一下他們的含義
Display 控制圖表的點和線的展現,有一些比較重要的參數
All serires
(展現該時間點的全部線段的值)和 single
(只展現鼠標指着的那一條線段)以 graphite 爲例子,打點路徑中的 KEY 只支持大小寫字母、數字、中劃線和下劃線,這會致使前端的路徑(常常包含 # 和 :path)存不下來,所以咱們只能提早轉譯,例如將 # 轉譯爲 ANCHOR,將 :path 轉譯爲 PATH ,再將 / 轉譯爲 -,這樣在變量模板中展現的就是比較怪異的前端路徑,不過好在咱們有函數,能夠在界面上把它替換回來。
點擊編輯界面 Metrics 面板中編輯模式的加號,添加 aliaSub
函數,並依此填入上圖的三種的替換規則,在界面上就能夠看到以下圖的正常路徑了:
aliaSub 只是其中一個簡單的 alias 函數,用來處理曲線的名稱,更多的函數是被用來處理單個查詢的聚合、多條曲線的聚合、展現不一樣時間線、計算和過濾,本節會介紹其中一些常常用到的函數。
例如,假設 stats_count.fe.test.*
有幾十個匹配值,那麼這個查詢就會在圖表中展現幾十條曲線,此時如何獲取全部曲線的總值呢?不須要在打點時多打一份總量數據,直接使用 sumSeries
函數便可,sumSeries(stats_count.fe.test.*)
想要在這個時間段內同時展現前一天的的曲線?timeShift(Query, '-1d')
便可
若是數值類型中出現了異常的值,例如平均爲 1秒 的狀況下出現了幾百萬秒的狀況,那麼就能夠經過衆多的過濾函數在界面上直接過濾掉而不是去修改打點代碼,removeAboveValue(Query, 10000)
便可
sumSeries 函數只能簡單地將多條數據的最終值加起來,若是不是末尾位置的就不行了,並且也不支持除了 sum 外的功能,例如 avg 平均,使用 groupByNode 就能夠動態地對指定位置的多個數值類型進行聚合了,以下圖:
假設咱們有以下幾條打點:
stats.timers.fe.test.error1.count
stats.timers.fe.test.error2.count
stats.timers.fe.test.error3.count
stats.timers.fe.test.success.count
複製代碼
此時想要計算 success 的成功比例,如何作呢?
在這種相較複雜的狀況下,就不能只靠一個 Query 來解決了,首先咱們建立兩個 Query,以下:
stats.timers.fe.test.*.count (Query 序列號爲 #A)
stats.timers.fe.test.success.count (Query 序列號爲 #B)
複製代碼
再建立第三個 Query,值爲 asPercent(#B, sumSeries(#A)
,顧名思義,首先將 #A 的查詢聚合起來獲得總值,再用 asPercent 來進行除法便可。
經過如上的幾個例子,能夠看到函數強大的功能,即便是很複雜的在之前須要用後端代碼來實現的部分,均可以經過多條Query和多個函數的互相嵌套來在界面上簡單地實現。
每一個數據源都有對應的函數開發文檔,例如 graphite。grafana 正是憑藉着對衆多數據源以及函數的支持,才能在一個網頁界面上完成這麼多強大的功能。
grafana 在 4.0 版本後增長了報警功能,不過 grafana 的報警屬於數據源的後置查詢,實時性不大能知足需求,咱們公司有一個開源的 banshee ,就是爲了解決這個問題。
banshee 使用了三西格馬定律,支持基於閾值和趨勢的報警,同時提供開放的 API 和 webhook 並默認集成了 Slack。banshee 和數據源位於同一個位置(statsd 的後端),所以能夠保證時效性,也由於報警的獨立性質因此對 grafana 版本沒有任何要求。
grafana 依賴的若是是時序性數據庫,那麼每個 KEY 都會對應一個文件來存儲數據,例如 stats.timers.fe.test.*
至關於 stats/timers/fe/test
文件夾下的全部文件,所以必須注意打點路徑不要有過多的組合,好比將省份和市做爲 KEY 時的組合很容易就能佔到 1G 以上的數據致使磁盤爆掉。
爲了不組合過多致使路徑污染,請儘可能保證每一個 KEY 中格式化掉點,例如替換成下劃線,另外打點路徑能夠儘可能多加一點前綴,例如將stats.timers.fe.test.*
改成 stats.timers.fe.test.v1.*
,這樣一旦污染後,清理數據時能夠直接把 v1 整個文件夾刪除而不是刪除 test 這個根路徑,用以保留你的歷史正常的打點數據。
通常推薦使用 API KEY 來查詢 grafana 的數據,Admin 權限帳號能夠在界面中生成上文三種權限的 API KEY,不過 grafana 默認會開啓 Basic Auth,使用帳號密碼便可經過 grafana 的鑑權,例如http://${account}:${password}@${grafana_host}/api/org
。
固然,最好是擁有數據源的讀權限來直接讀取數據。
有時候用戶確實沒有 grafana 的帳號,但他就是想看面板,怎麼辦?此時就得 grafana 的匿名模式出馬了。
grafana 配置文件中有 auth.anonymous
配置段,enabled
控制開關,org_name
控制開啓匿名模式的組織,org_role
控制匿名者的權限。組織開啓匿名意味着非登陸用戶可以直接跳過 grafana 無權限地查詢數據源,所以請保證數據源的安全,例如限定內網訪問。
本文介紹了 grafana 相對高級的一些使用技巧,除了能夠看到 grafana 的強大功能之外,也應該注意到 grafana 只是一個時序性很強的統計監控平臺,一些非時序性質的功能例如報錯的聚合和報錯的日誌等應該交給更專業的去作,例如 sentry 和 ELK。