2019獨角獸企業重金招聘Python工程師標準>>>

關鍵詞： 監控 、dashboard、PHP、graphite、statsd、whisper、carbon、grafana、influxdb、Python 本文檔適用人員：研發和運維員工 提綱：

監控平臺要做到什么程度？為什么要自己做？

幾個通用技術問題

• 繪圖所依賴的數據如何收集？如何加工？如何存儲？
• 圖形如何繪制，各種指標如何疊加？
• 拓撲關系如何繪制？

技術選型哲學 最終選了statsd+graphite 數據的采集 數據存儲的粒度 天機的技術選型 一，監控平臺要做到什么程度？為什么要自己做？ 運維監控滿滿都是著各種開源系統以及它們的 Dashboard：

• Zabbix
• Nagios
• Centreon
• Logstash
• Ganglia+Cacti

以及各種業務指標趨勢的 Dashboard。 我們認為，監控不能只是各種數據的采集和羅列，不僅僅是弄若干個報表并進一步配置成儀表盤， 而是有一定智能，仿照我們日常的排查問題思路，建立一定規則，自動檢查，深度檢查，友情提示。 隨手舉一個例子：

規則：模仿我們發現問題后先檢查數據庫主從同步是否有問題的習慣

天機系統發現成單金額或驗證券數或短信發送條數環比大幅下降后，啟動檢查規則， 自動逐一檢查各種從庫的主從同步情況。 如果發現主從延遲超過閾值，則天機 DashBoard 應浮出兩條紅色警告提示（可點擊進入）： 5分鐘銷售數據環比下降50% 某某從庫DBXXXX與主庫DBYYYY的同步延遲了300秒 如果發現主從同步失敗導致了同步停止，則應浮出兩條紅色警告提示（可點擊進入）： 5分鐘驗證券數環比下降40% 某某從庫DBXXXX與主庫DBYYYY的同步停止，失敗原因為：blabla

就這樣，只有自己動手，才能把我們日常分析問題、定位問題的經驗變成一條條系統規則，還是那句話： 自動化才是王道。 二，幾個通用技術問題
大致想來，李丹劉奎還需要解決這么幾個基礎問題： 2.1.繪圖所依賴的監控原始數據如何收集？如何加工？如何存儲？ 不同運維指標和業務指標的時間粒度大小不一，1秒、1分鐘、5分鐘…… 數據是業務方自行上報？還是主動采集？考慮一下可伸縮性：如果是數以百計物理機、成千上萬個虛擬機或容器的數以萬計指標呢？如果采集頻率非常高呢？ 拿到原始數據后，原始數據至少還要經過 min/max/sum/count/mean/media……等計算才能變為可視化圖表要展示的維度。 這些東西又怎么存儲？ 2.2.圖形如何繪制，各種指標如何疊加？ 在使用 Centreon 時，我們就抱怨不能把多個維度的指標自由組合后疊加在一張圖上看。是的，Centreon 能在一張圖上展示某個主機的它定義好的幾個指標，如下圖所示： 圖1 centreon圖例 但我們希望還能把不同主機的不同指標按我們的意愿放在一張圖上繪制，也就是可配置的，這樣有利于排查問題，能快速看出趨勢變化和關聯關系。 其次，繪圖得快，而且運維看的都是近乎實時的度量數據，怎么才能足夠快。 2.3.拓撲關系如何繪制？ 拓撲關系很重要，最好能自動可視化，畢竟一圖勝過千言萬語。 隨手舉個例子：

數據庫拓撲關系

在監控系統里登記了 DB 的IP和分組后，其實已經可以探測到 DB 之間的主從關系（包括級聯關系）了，能自動繪制出登記的所有數據庫服務器之間的關系。舉例如下： 圖2 自動繪制數據庫拓撲

三，技術選型哲學 選型兩個重要觀點：

不重復制造輪子；

既然找輪子，那這個輪子就應該只做一件事，且把它做到最好。

可供選擇的方案有：

grafana + influxdb

statsd + graphite

collectd + graphite

grafana + graphite

3.1.StatsD 2013年 eBay 云談及 OpenStack 的監控和報警時，提及了 statsd 和 graphite，如下圖所示： 圖3 ebay云的監控報警 StatsD 是一個 NodeJs 的 daemon 程序，簡單輕巧，使用 UDP 協議，專門用來收集數據，收集完數據就發送到其他服務器進行處理。 3.2.Graphite

Graphite?是一個企業級的監控工具，用 Python 編寫，采用 django 框架，sqlite 數據庫存儲，自有簡單文本協議通訊，繪圖功能強大。最初由?Chris Davis 在 Orbitz 工作時，作為一個輔助項目開發的，最終成了一個監控基礎工具，如他所言，Graphite provides real-timevisualization?andstorage?of numeric time-series data，重點解決：

• 實時可視化
• 時間序列數據的存儲

嚴格地說，Graphite 只是一個根據數據繪圖的工具，數據收集通常由第三方工具或插件完成，它自帶了 carbon 和 whisper，還可根據其協議選用別的數據源供其繪圖。官方描述，預計用Ceres?替代 Whisper。

圖4 graphite圖例

簡單的文本協議和強大的繪圖功能使得它可以方便地擴展到任何需要監控的系統上。豆瓣、Google、GitHub、Instagram、Uber等公司都用它。

3.3.CollectD

C語言開發的 collectd 是一個較為古老的工具，像 statsd 一樣它也做周期性收集統計數據，collectd 還管數據存儲。它能夠通過插件支持檢測各種各樣的系統信息，如數據庫、UPS。

要想查看 collectd 收集的信息，還需要安裝 web 界面或者 Cacti，于是工作模式就是：

collectd 作為守護進程運行，每隔 10 秒收集信息，而 Cacti 每隔5分鐘運行一個 PHP 腳本來收集信息（兩者的時間間隔可配置）。

3.4.Influxdb InfluxDB?是一個開源分布式時序、事件和指標數據庫。使用 Go 語言編寫，無需外部依賴。其設計目標是實現分布式和水平伸縮擴展。向這個時間序列數據庫插入數據，每條數據都會自動附加上兩個字段，一個時間，一個序列號（用來作為主鍵的）。
特點：

• schemaless（無結構），可以是任意數量的列
• Scalable
• min, max, sum, count, mean, median 一系列函數，方便統計
• Native HTTP API， 內置http支持，使用http讀寫
• Powerful Query Language，類似SQL
• Built-in Explorer，自帶管理工具

管理界面如下圖所示： 圖5 influxdb圖例

3.5.Grafana

grafana 則類似 ES Kibana 的可視化面板，有著非常漂亮的圖表和布局，目前支持?Graphite、Influxdb 和 Opentsdb） +?influxdb（分布式時序、事件和指標數據庫）等配搭。

grafana 與 influxdb 整合后的效果如下圖所示： 圖6 grafana+influxdb整合圖例 四，最終選了statsd+graphite 最終李丹和劉奎選擇的方案是： statsd（采集） + graphite（繪制， whisper 負責存儲）。 搭建了 Graphite 之后，你可以在它自帶的管理站點上看到所有指標的歷史數據，可以選時間范圍，如下圖所示： 圖7 graphite管理站點圖例 graphite 管理界面里的圖形，請求格式如下所示： http://graphite系統域名/render/?width=586&height=308&_salt=1410088306.115&target=stats.timers.mysql.172_16_999_999-3306.aborted_clients.upper_90 如果我們的監控系統要把多個指標拼到一個圖形上渲染，則請求格式如下所示：

http://監控系統域名/db/createImage/target/%5B%22stats.timers.mysql.172_16_999_991-3306.com_select_persecond.upper%22%2C%22stats.timers.mysql.172_16_999_992-3306.com_select_persecond.upper%22%2C%22stats.timers.mysql.172_16_999_993-3306.com_select_persecond.upper%22%5D/from/-1hour.html?width=492&n=0.8623758849623238

從而繪制出如下圖形，這就是我在前面2.2小節說想要的特性： 圖8 三個主機的指標繪制在一起 Graphite 分為三個組件：

carbon?- aTwisted?daemon that listens for time-series data

whisper?- a simple database library for storing time-series data (similar in design toRRD)

graphite webapp?- ADjango?webapp that renders graphs on-demand usingCairo

它的 High Level 圖如下所示： 圖9 graphite high level 從上圖看出，Carbon 接到度量數據后，寫入?Whisper 庫里，Graphite Webapp 去 Whisper 讀取數據，系統應該也做了一份緩存，所以你發送數據給 Carbon，立即就可以在 Webapp 中繪圖，這也是為什么在磁盤 I/O 反應不過來的時候，Webapp 的圖形仍能以接近實時的方式顯示的原因。 下面兩張圖能幫助大家進一步理解 Graphite 里 Carbon 和 Whisper 如何協同的。

圖10 graphite 邏輯圖

圖11 Graphite 數據流轉圖

五，數據的采集 采集數據共有兩種方式：Get_Data 和 Push_Data。

• 天機平臺主動拉數據，主要集中在數據庫的主從同步、數據庫的拓撲關系等這樣的關系型數據采集上。
• 其他場景下，基本都需要采集單點狀態的數據，則由客戶端腳本（即 agent）獲取數據后，再推送到天機平臺。

采集到的數據會走 UDP 協議發給 StatsD，由 StatsD 解析、提取、計算處理后，周期性地發送給 Graphite。 數據推送到 Graphite 時，時間周期為1分鐘，采集1分鐘內的業務數據按照 metric_path value timestamp\n 的格式發送。需要注意的是每次發送的數據必須以 \n 結尾，不能省略。 六，數據存儲的粒度 首先，我們需要知道 statsD 默認10秒一個周期，可以通過修改 config.js 的 flushInterval 屬性變更。 其次，Graphite 里有一個retention（保留）的概念，即明確數據精度以及丟棄多久之前的數據，在?/opt/graphite/conf/ storage-schemas.conf?配置文件里定義。retention 定義的表達式為 frequency:history，每一個 retention 之間用英文逗號分隔。 默認是按10秒一個數據的方式，存一天的數據，一天前的數據就沒了，如下面的配置所言： [default_1min_for_1day]pattern = .*retentions = 10s:1d 可以自定義 retentions，注意表達式里每一個時間間隔必須是第一個的倍數，也就是說，第一個是10s，那么第二個只能是10s的整數倍，以此類推。 天機的數據庫監控的粒度為： [stats]pattern = ^stats.*retentions = 10s:1d,30s:7d,1m:28d,15m:5y 依次解釋一下： 10s:1d——1天以內的數據是10秒為一個值， 30s:7d——大于1天小于7天內的數據是以30秒為一個值， 1m:28d——大于7天小于28天內的是以1分鐘為一個值， 15m:5y——大于28天小于5年的，是以15分鐘為一個值， 大于5年的數據丟棄。 當把10秒的數據降為1分鐘數據時，默認是算平均值，但你也可以按合計值、最大值、最小值等，反正都在 storage-aggregation.conf 里配置。 天機的業務指標監控的粒度為： [business_monitoring]pattern = ^business_monitoring\.retentions = 1m:5y 為什么這么定義？因為天機要能繪制任意時間段里粒度為1分鐘的業務指標曲線圖，所以 Graphite 不能縮小精度。 七，天機的技術選型 涉及到的開發語言有： php，node.js，python，javascript 涉及相關的框架和服務： Yii，graphite，StatsD，D3js（數據可視化JS框架），pt-query-digest（分析MySQL慢查日志） 最后，天機系統的目標是以最有效率的方式查找到事故點，為此要做到數據一體化和自動化。 -over- 參考資料： StatsD plugin metrics explanation： http://cookbook.logstash.net/recipes/statsd-metrics/
Understanding StatsD and Graphite：? http://blog.pkhamre.com/2012/07/24/understanding-statsd-and-graphite/ Measure Anything, Measure Everything： http://codeascraft.com/2011/02/15/measure-anything-measure-everything/ InfluxDB 開源分布式時序、事件和指標數據庫 開源監控利器grafana-博客園

窩窩的解決方案介紹列表：

#研發解決方案#基于StatsD+Graphite的智能監控解決方案

#研發中間件介紹#定時任務調度與管理JobCenter

#研發解決方案介紹#Recsys-Evaluate（推薦評測）

#研發解決方案介紹#Tracing（鷹眼）

#研發解決方案介紹#基于持久化配置中心的業務降級

#研發中間件介紹#異步消息可靠推送Notify

#研發解決方案介紹#IdCenter（內部統一認證系統）

#研發解決方案介紹#基于ES的搜索+篩選+排序解決方案

#數據技術選型#即席查詢Shib+Presto，集群任務調度HUE+Oozie

轉載于:https://my.oschina.net/guoenzhou/blog/380030

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的#研发解决方案介绍#基于StatsD+Graphite的智能监控解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。