小米運維—互聯網企業級監控系統實踐
# Introduction
</h2>
<p>
監控系統是整個運維環節，乃至整個產品生命周期中最重要的一環，事前及時預警發現故障，事后提供翔實的數據用于追查定位問題。監控系統作為一個成 熟的運維產品，業界有很多開源的實現可供選擇。當公司剛剛起步，業務規模較小，運維團隊也剛剛建立的初期，選擇一款開源的監控系統，是一個省時省力，效率 最高的方案。之后，隨著業務規模的持續快速增長，監控的對象也越來越多，越來越復雜，監控系統的使用對象也從最初少數的幾個SRE，擴大為更多的 DEVS，SRE。這時候，監控系統的容量和用戶的“使用效率”成了最為突出的問題。
</p>
<p>
監控系統業界有很多杰出的開源監控系統。我們在早期，一直在用zabbix，不過隨著業務的快速發展，以及互聯網公司特有的一些需求，現有的開源的監控系統在性能、擴展性、和用戶的使用效率方面，已經無法支撐了。
</p>
<p>
因此，我們在過去的一年里，從互聯網公司的一些需求出發，從各位SRE、SA、DEVS的使用經驗和反饋出發，結合業界的一些大的互聯網公司做監控，用監控的一些思考出發，設計開發了小米的監控系統：open-falcon。
</p>
<h4>
open-falcon的目標是做最開放、最好用的互聯網企業級監控產品。
</h4>
<h2>
# Highlights and features
</h2>
<ul>
<li>
<strong>強大靈活的數據采集</strong> ：自動發現，支持falcon-agent、snmp、支持用戶主動push、用戶自定義插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
</li>
<li>
<strong>水平擴展能力</strong> ：支持每個周期上億次的數據采集、告警判定、歷史數據存儲和查詢
</li>
<li>
<strong>高效率的告警策略管理</strong> ：高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調用
</li>
<li>
<strong>人性化的告警設置</strong> ：最大告警次數、告警級別、告警恢復通知、告警暫停、不同時段不同閾值、支持維護周期
</li>
<li>
<strong>高效率的graph組件</strong> ：單機支撐200萬metric的上報、歸檔、存儲（周期為1分鐘）
</li>
<li>
<strong>高效的歷史數據query組件</strong> ：采用rrdtool的數據歸檔策略，秒級返回上百個metric一年的歷史數據
</li>
<li>
<strong>dashboard</strong> ：多維度的數據展示，用戶自定義Screen
</li>
<li>
<strong>高可用</strong> ：整個系統無核心單點，易運維，易部署，可水平擴展
</li>
<li>
<strong>開發語言</strong> ： 整個系統的后端，全部golang編寫，portal和dashboard使用python編寫。
</li>
</ul>
<h2>
# Architecture
</h2>
<p>
<img src="https://simg.open-open.com/show/d0f2f6384e1c5c4dc7e63196e3b01f76.png" alt="小米運維—互聯網企業級監控系統實踐" width="700" height="474" /> 備注：虛線所在的aggregator組件還在設計開發階段。
</p>
<div>
<p>
每臺服務器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用于自發現的采集單機的各種數據和指標，這些指標包括不限于以下幾個方面，共計400多項指標。
</p>
<p>
– CPU相關
</p>
<p>
– 磁盤相關
</p>
<p>
– IO
</p>
<p>
– Load
</p>
<p>
– 內存相關
</p>
<p>
– 網絡相關
</p>
<p>
– 端口存活、進程存活
</p>
<p>
– ntp offset（插件）
</p>
<p>
– 某個進程資源消耗（插件）
</p>
<p>
– netstat、ss 等相關統計項采集
</p>
<p>
– 機器內核配置參數
</p>
</div>
<p>
只要安裝了falcon-agent的機器，就會自動開始采集各項指標，主動上報，不需要用戶在server做任何配置（這和zabbix有很大 的不同），這樣做的好處，就是用戶維護方便，覆蓋率高。當然這樣做也會server端造成較大的壓力，不過open-falcon的服務端組件單機性能足 夠高，同時都可以水平擴展，所以自動多采集足夠多的數據，反而是一件好事情，對于SRE和DEV來講，事后追查問題，不再是難題。
</p>
<p>
另外，falcon-agent提供了一個proxy-gateway，用戶可以方便的通過http接口，push數據到本機的gateway，gateway會幫忙高效率的轉發到server端。
</p>
<p>
falcon-agent，可以在我們的github上找到 （https://github.com/open-falcon/agent）
</p>
<h2>
# Data model
</h2>
<p>
Data Model是否強大，是否靈活，對于監控系統用戶的“使用效率”至關重要。比如以zabbix為例，上報的數據為hostname（或者ip）、metric，那么用戶添加告警策略、管理告警策略的時候，就只能以這兩個維度進行。舉一個最常見的場景：
</p>
<p>
hostA的磁盤空間，小于5%，就告警。一般的服務器上，都會有兩個主要的分區，根分區和home分區，在zabbix里面，就得加兩條規則；如果是hadoop的機器，一般還會有十幾塊的數據盤，還得再加10多條規則，這樣就會痛苦，不幸福，不利于自動化。
</p>
<div>
<p>
open-falcon，采用和opentsdb相同的數據格式：metric加多組key value tags，舉兩個例子：
</p>
# Introduction
</h2>
<p>
監控系統是整個運維環節，乃至整個產品生命周期中最重要的一環，事前及時預警發現故障，事后提供翔實的數據用于追查定位問題。監控系統作為一個成 熟的運維產品，業界有很多開源的實現可供選擇。當公司剛剛起步，業務規模較小，運維團隊也剛剛建立的初期，選擇一款開源的監控系統，是一個省時省力，效率 最高的方案。之后，隨著業務規模的持續快速增長，監控的對象也越來越多，越來越復雜，監控系統的使用對象也從最初少數的幾個SRE，擴大為更多的 DEVS，SRE。這時候，監控系統的容量和用戶的“使用效率”成了最為突出的問題。
</p>
<p>
監控系統業界有很多杰出的開源監控系統。我們在早期，一直在用zabbix，不過隨著業務的快速發展，以及互聯網公司特有的一些需求，現有的開源的監控系統在性能、擴展性、和用戶的使用效率方面，已經無法支撐了。
</p>
<p>
因此，我們在過去的一年里，從互聯網公司的一些需求出發，從各位SRE、SA、DEVS的使用經驗和反饋出發，結合業界的一些大的互聯網公司做監控，用監控的一些思考出發，設計開發了小米的監控系統：open-falcon。
</p>
<h4>
open-falcon的目標是做最開放、最好用的互聯網企業級監控產品。
</h4>
<h2>
# Highlights and features
</h2>
<ul>
<li>
<strong>強大靈活的數據采集</strong> ：自動發現，支持falcon-agent、snmp、支持用戶主動push、用戶自定義插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
</li>
<li>
<strong>水平擴展能力</strong> ：支持每個周期上億次的數據采集、告警判定、歷史數據存儲和查詢
</li>
<li>
<strong>高效率的告警策略管理</strong> ：高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調用
</li>
<li>
<strong>人性化的告警設置</strong> ：最大告警次數、告警級別、告警恢復通知、告警暫停、不同時段不同閾值、支持維護周期
</li>
<li>
<strong>高效率的graph組件</strong> ：單機支撐200萬metric的上報、歸檔、存儲（周期為1分鐘）
</li>
<li>
<strong>高效的歷史數據query組件</strong> ：采用rrdtool的數據歸檔策略，秒級返回上百個metric一年的歷史數據
</li>
<li>
<strong>dashboard</strong> ：多維度的數據展示，用戶自定義Screen
</li>
<li>
<strong>高可用</strong> ：整個系統無核心單點，易運維，易部署，可水平擴展
</li>
<li>
<strong>開發語言</strong> ： 整個系統的后端，全部golang編寫，portal和dashboard使用python編寫。
</li>
</ul>
<h2>
# Architecture
</h2>
<p>
<img src="https://simg.open-open.com/show/d0f2f6384e1c5c4dc7e63196e3b01f76.png" alt="小米運維—互聯網企業級監控系統實踐" width="700" height="474" /> 備注：虛線所在的aggregator組件還在設計開發階段。
</p>
<div>
<p>
每臺服務器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用于自發現的采集單機的各種數據和指標，這些指標包括不限于以下幾個方面，共計400多項指標。
</p>
<p>
– CPU相關
</p>
<p>
– 磁盤相關
</p>
<p>
– IO
</p>
<p>
– Load
</p>
<p>
– 內存相關
</p>
<p>
– 網絡相關
</p>
<p>
– 端口存活、進程存活
</p>
<p>
– ntp offset（插件）
</p>
<p>
– 某個進程資源消耗（插件）
</p>
<p>
– netstat、ss 等相關統計項采集
</p>
<p>
– 機器內核配置參數
</p>
</div>
<p>
只要安裝了falcon-agent的機器，就會自動開始采集各項指標，主動上報，不需要用戶在server做任何配置（這和zabbix有很大 的不同），這樣做的好處，就是用戶維護方便，覆蓋率高。當然這樣做也會server端造成較大的壓力，不過open-falcon的服務端組件單機性能足 夠高，同時都可以水平擴展，所以自動多采集足夠多的數據，反而是一件好事情，對于SRE和DEV來講，事后追查問題，不再是難題。
</p>
<p>
另外，falcon-agent提供了一個proxy-gateway，用戶可以方便的通過http接口，push數據到本機的gateway，gateway會幫忙高效率的轉發到server端。
</p>
<p>
falcon-agent，可以在我們的github上找到 （https://github.com/open-falcon/agent）
</p>
<h2>
# Data model
</h2>
<p>
Data Model是否強大，是否靈活，對于監控系統用戶的“使用效率”至關重要。比如以zabbix為例，上報的數據為hostname（或者ip）、metric，那么用戶添加告警策略、管理告警策略的時候，就只能以這兩個維度進行。舉一個最常見的場景：
</p>
<p>
hostA的磁盤空間，小于5%，就告警。一般的服務器上，都會有兩個主要的分區，根分區和home分區，在zabbix里面，就得加兩條規則；如果是hadoop的機器，一般還會有十幾塊的數據盤，還得再加10多條規則，這樣就會痛苦，不幸福，不利于自動化。
</p>
<div>
<p>
open-falcon，采用和opentsdb相同的數據格式：metric加多組key value tags，舉兩個例子：
</p>
{
metric: load.1min,
endpoint: open-falcon-host,
tags: srv=falcon,idc=aws-sgp,group=az1,
value: 1.5,
timestamp: date +%s,
counterType: GAUGE,
step: 60
}
{
metric: net.port.listen,
endpoint: open-falcon-host,
tags: port=3306,
value: 1,
timestamp: date +%s,
counterType: GAUGE,
step: 60
}
通過這樣的數據結構，我們就可以從多個維度來配置告警，配置dashboard等等。
備注：endpoint是一個特殊的tag。
</div>
# Data collection
</h2>
<p>
transfer，接收客戶端發送的數據，做一些數據規整，檢查之后，轉發到多個后端系統去處理。在轉發到每個后端業務系統的時候，transfer會根據一致性hash算法，進行數據分片，來達到后端業務系統的水平擴展。
</p>
<p>
transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無狀態的，掛掉一臺或者多臺不會有任何影響，同時transfer性能很高，每分鐘可以轉發超過500萬條數據。
</p>
<p>
transfer目前支持的業務后端，有三種，judge、graph、opentsdb。judge是我們開發的高性能告警判定組 件，graph是我們開發的高性能數據存儲、歸檔、查詢組件，opentsdb是開源的時間序列數據存儲服務。可以通過transfer的配置文件來開 啟。
</p>
<div>
<p>
transfer的數據來源，一般有三種：
</p>
<p>
1. falcon-agent采集的基礎監控數據
</p>
<p>
2. falcon-agent執行用戶自定義的插件返回的數據
</p>
<p>
3. client library：線上的業務系統，都嵌入使用了統一的perfcounter.jar，對于業務系統中每個RPC接口的qps、latency都會主動采集并上報
</p>
</div>
<p>
說明：上面這三種數據，都會先發送給本機的proxy-gateway，再由gateway轉發給transfer。
</p>
<h2>
# Alerting
</h2>
<p>
報警判定，是由judge組件來完成。用戶在web portal來配置相關的報警策略，存儲在MySQL中。heartbeat server 會定期加載MySQL中的內容。judge也會定期和heartbeat server保持溝通，來獲取相關的報警策略。
</p>
<p>
heartbeat sever不僅僅是單純的加載MySQL中的內容，根據模板繼承、模板項覆蓋、報警動作覆蓋、模板和hostGroup綁定，計算出最終關聯到每個endpoint的告警策略，提供給judge組件來使用。
</p>
<p>
transfer轉發到judge的每條數據，都會觸發相關策略的判定，來決定是否滿足報警條件，如果滿足條件，則會發送給alarm，alarm再以郵件、短信、米聊等形式通知相關用戶，也可以執行用戶預先配置好的callback地址。
</p>
<p>
用戶可以很靈活的來配置告警判定策略，比如連續n次都滿足條件、連續n次的最大值滿足條件、不同的時間段不同的閾值、如果處于維護周期內則忽略 等等。
</p>
<h2>
# Query
</h2>
<p>
到這里，數據已經成功的存儲在了graph里。如何快速的讀出來呢，讀過去1小時的，過去1天的，過去一月的，過去一年的，都需要在1秒之內返回。
</p>
<p>
這些都是靠graph和query組件來實現的，transfer會將數據往graph組件轉發一份，graph收到數據以后，會以rrdtool的數據歸檔方式來存儲，同時提供查詢RPC接口。
</p>
<p>
query面向終端用戶，收到查詢請求后，會去多個graph里面，查詢不同metric的數據，匯總后統一返回給用戶。
</p>
<h2>
# Dashboard
</h2>
<div>
<p>
dashboard首頁，用戶可以以多個維度來搜索endpoint列表，即可以根據上報的tags來搜索關聯的endpoint。
</p>
# Data collection
</h2>
<p>
transfer，接收客戶端發送的數據，做一些數據規整，檢查之后，轉發到多個后端系統去處理。在轉發到每個后端業務系統的時候，transfer會根據一致性hash算法，進行數據分片，來達到后端業務系統的水平擴展。
</p>
<p>
transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無狀態的，掛掉一臺或者多臺不會有任何影響，同時transfer性能很高，每分鐘可以轉發超過500萬條數據。
</p>
<p>
transfer目前支持的業務后端，有三種，judge、graph、opentsdb。judge是我們開發的高性能告警判定組 件，graph是我們開發的高性能數據存儲、歸檔、查詢組件，opentsdb是開源的時間序列數據存儲服務。可以通過transfer的配置文件來開 啟。
</p>
<div>
<p>
transfer的數據來源，一般有三種：
</p>
<p>
1. falcon-agent采集的基礎監控數據
</p>
<p>
2. falcon-agent執行用戶自定義的插件返回的數據
</p>
<p>
3. client library：線上的業務系統，都嵌入使用了統一的perfcounter.jar，對于業務系統中每個RPC接口的qps、latency都會主動采集并上報
</p>
</div>
<p>
說明：上面這三種數據，都會先發送給本機的proxy-gateway，再由gateway轉發給transfer。
</p>
<h2>
# Alerting
</h2>
<p>
報警判定，是由judge組件來完成。用戶在web portal來配置相關的報警策略，存儲在MySQL中。heartbeat server 會定期加載MySQL中的內容。judge也會定期和heartbeat server保持溝通，來獲取相關的報警策略。
</p>
<p>
heartbeat sever不僅僅是單純的加載MySQL中的內容，根據模板繼承、模板項覆蓋、報警動作覆蓋、模板和hostGroup綁定，計算出最終關聯到每個endpoint的告警策略，提供給judge組件來使用。
</p>
<p>
transfer轉發到judge的每條數據，都會觸發相關策略的判定，來決定是否滿足報警條件，如果滿足條件，則會發送給alarm，alarm再以郵件、短信、米聊等形式通知相關用戶，也可以執行用戶預先配置好的callback地址。
</p>
<p>
用戶可以很靈活的來配置告警判定策略，比如連續n次都滿足條件、連續n次的最大值滿足條件、不同的時間段不同的閾值、如果處于維護周期內則忽略 等等。
</p>
<h2>
# Query
</h2>
<p>
到這里，數據已經成功的存儲在了graph里。如何快速的讀出來呢，讀過去1小時的，過去1天的，過去一月的，過去一年的，都需要在1秒之內返回。
</p>
<p>
這些都是靠graph和query組件來實現的，transfer會將數據往graph組件轉發一份，graph收到數據以后，會以rrdtool的數據歸檔方式來存儲，同時提供查詢RPC接口。
</p>
<p>
query面向終端用戶，收到查詢請求后，會去多個graph里面，查詢不同metric的數據，匯總后統一返回給用戶。
</p>
<h2>
# Dashboard
</h2>
<div>
<p>
dashboard首頁，用戶可以以多個維度來搜索endpoint列表，即可以根據上報的tags來搜索關聯的endpoint。
</p>
</div>
用戶可以自定義多個metric，添加到某個screen中，這樣每天早上只需要打開screen看一眼，服務的運行情況便盡在掌握了。
當然，也可以查看清晰大圖，橫坐標上zoom in/out，快速篩選反選。總之用戶的“使用效率”是第一要務。
# Web portal
</h2>
<p>
一個高效的portal，對于提升用戶的“使用效率”，加成很大，平時大家都這么忙，能給各位SRE、Devs減輕一些負擔，那是再好不過了。
</p>
<div>
<p>
這是host group的管理頁面，可以和服務樹結合，機器進出服務樹節點，相關的模板會自動關聯或者解除。這樣服務上下線，都不需要手動來變更監控，大大提高效率，降低遺漏和誤報警。
</p>
# Web portal
</h2>
<p>
一個高效的portal，對于提升用戶的“使用效率”，加成很大，平時大家都這么忙，能給各位SRE、Devs減輕一些負擔，那是再好不過了。
</p>
<div>
<p>
這是host group的管理頁面，可以和服務樹結合，機器進出服務樹節點，相關的模板會自動關聯或者解除。這樣服務上下線，都不需要手動來變更監控，大大提高效率，降低遺漏和誤報警。
</p>
</div>
一個最簡單的模板的例子，模板支持繼承和策略覆蓋，模板和host group綁定后，host group下的機器會自動應用該模板的所有策略。
當然，也可以寫一個簡單的表達式，就能達到監控的目的，這對于那些endpoint不是機器名的場景非常方便。
添加一個表達式也是很簡單的。
# Storage
</h2>
<div>
<p>
對于監控系統來講，歷史數據的存儲和高效率查詢，永遠是個很難的問題！
</p>
<p>
1. 數據量大：目前我們的監控系統，每個周期，大概有2000萬次數據上報（上報周期為1分鐘和5分鐘兩種，各占50%），一天24小時里，從來不會有業務低峰，不管是白天和黑夜，每個周期，總會有那么多的數據要更新。
</p>
<p>
2. 寫操作多：一般的業務系統，通常都是讀多寫少，可以方便的使用各種緩存技術，再者各類數據庫，對于查詢操作的處理效率遠遠高于寫操作。而監控系統恰恰相 反，寫操作遠遠高于讀。每個周期幾千萬次的更新操作，對于常用數據庫（MySQL、postgresql、mongodb）都是無法完成的。
</p>
<p>
3. 高效率的查：我們說監控系統讀操作少，是說相對寫入來講。監控系統本身對于讀的要求很高，用戶經常會有查詢上百個meitric，在過去一天、一周、一月、一年的數據。如何在1秒內返回給用戶并繪圖，這是一個不小的挑戰。
</p>
</div>
<p>
open-falcon在這塊，投入了較大的精力。我們把數據按照用途分成兩類，一類是用來繪圖的，一類是用戶做數據挖掘的。
</p>
<div>
<p>
對于繪圖的數據來講，查詢要快是關鍵，同時不能丟失信息量。對于用戶要查詢100個metric，在過去一年里的數據時，數據量本身就在那里 了，很難1秒之類能返回，另外就算返回了，前端也無法渲染這么多的數據，還得采樣，造成很多無謂的消耗和浪費。我們參考rrdtool的理念，在數據每次 存入的時候，會自動進行采樣、歸檔。我們的歸檔策略如下，歷史數據保存5年。同時為了不丟失信息量，數據歸檔的時候，會按照平均值采樣、最大值采樣、最小 值采樣存三份。
</p>
<p>
“`
</p>
<p>
// 1分鐘一個點存 12小時
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 1, 720)
</p>
</div>
<div>
<p>
// 5m一個點存2d
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 5, 576)
</p>
<p>
c.RRA(“MAX”, 0.5, 5, 576)
</p>
<p>
c.RRA(“MIN”, 0.5, 5, 576)
</p>
</div>
<div>
<p>
// 20m一個點存7d
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 20, 504)
</p>
<p>
c.RRA(“MAX”, 0.5, 20, 504)
</p>
<p>
c.RRA(“MIN”, 0.5, 20, 504)
</p>
</div>
<div>
<p>
// 3小時一個點存3個月
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 180, 766)
</p>
<p>
c.RRA(“MAX”, 0.5, 180, 766)
</p>
<p>
c.RRA(“MIN”, 0.5, 180, 766)
</p>
</div>
<div>
<p>
// 1天一個點存5year
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 720, 730)
</p>
<p>
c.RRA(“MAX”, 0.5, 720, 730)
</p>
<p>
c.RRA(“MIN”, 0.5, 720, 730)
</p>
<p>
“`
</p>
</div>
<p>
對于原始數據，transfer會打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb寫入數據。
</p>
<h2>
# Committers
</h2>
<ul>
<li>
laiwei: https://github.com/laiwei 來煒沒睡醒@微博 / hellolaiwei@微信
</li>
<li>
秦曉輝: https://github.com/ulricqin Ulricqin@微博 cnperl@微信
</li>
</ul>
<h2>
# Contributors
</h2>
<ul>
<li>
近期我們會把絕大數的組件整理到 http://github.com/open-falcon ， 期待大家一起貢獻，推動，做最開放、最好用的企業級監控系統。
</li>
</ul>
<h2>
# TODO
</h2>
<ul>
<li>
metric的聚合
</li>
<li>
環比、同比報警判定
</li>
<li>
流量的突升突降判定
</li>
</ul>
<h2>
# License
</h2>
<div>
<p>
Copyright 2014-2015 Xiaomi, Inc.
</p>
<p>
Licensed under the Apache License,
</p>
<p>
Version 2.0:
</p>
</div>
<p>
http://www.apache.org/licenses/LICENSE-2.0
</p>
</div>
# Storage
</h2>
<div>
<p>
對于監控系統來講，歷史數據的存儲和高效率查詢，永遠是個很難的問題！
</p>
<p>
1. 數據量大：目前我們的監控系統，每個周期，大概有2000萬次數據上報（上報周期為1分鐘和5分鐘兩種，各占50%），一天24小時里，從來不會有業務低峰，不管是白天和黑夜，每個周期，總會有那么多的數據要更新。
</p>
<p>
2. 寫操作多：一般的業務系統，通常都是讀多寫少，可以方便的使用各種緩存技術，再者各類數據庫，對于查詢操作的處理效率遠遠高于寫操作。而監控系統恰恰相 反，寫操作遠遠高于讀。每個周期幾千萬次的更新操作，對于常用數據庫（MySQL、postgresql、mongodb）都是無法完成的。
</p>
<p>
3. 高效率的查：我們說監控系統讀操作少，是說相對寫入來講。監控系統本身對于讀的要求很高，用戶經常會有查詢上百個meitric，在過去一天、一周、一月、一年的數據。如何在1秒內返回給用戶并繪圖，這是一個不小的挑戰。
</p>
</div>
<p>
open-falcon在這塊，投入了較大的精力。我們把數據按照用途分成兩類，一類是用來繪圖的，一類是用戶做數據挖掘的。
</p>
<div>
<p>
對于繪圖的數據來講，查詢要快是關鍵，同時不能丟失信息量。對于用戶要查詢100個metric，在過去一年里的數據時，數據量本身就在那里 了，很難1秒之類能返回，另外就算返回了，前端也無法渲染這么多的數據，還得采樣，造成很多無謂的消耗和浪費。我們參考rrdtool的理念，在數據每次 存入的時候，會自動進行采樣、歸檔。我們的歸檔策略如下，歷史數據保存5年。同時為了不丟失信息量，數據歸檔的時候，會按照平均值采樣、最大值采樣、最小 值采樣存三份。
</p>
<p>
“`
</p>
<p>
// 1分鐘一個點存 12小時
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 1, 720)
</p>
</div>
<div>
<p>
// 5m一個點存2d
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 5, 576)
</p>
<p>
c.RRA(“MAX”, 0.5, 5, 576)
</p>
<p>
c.RRA(“MIN”, 0.5, 5, 576)
</p>
</div>
<div>
<p>
// 20m一個點存7d
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 20, 504)
</p>
<p>
c.RRA(“MAX”, 0.5, 20, 504)
</p>
<p>
c.RRA(“MIN”, 0.5, 20, 504)
</p>
</div>
<div>
<p>
// 3小時一個點存3個月
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 180, 766)
</p>
<p>
c.RRA(“MAX”, 0.5, 180, 766)
</p>
<p>
c.RRA(“MIN”, 0.5, 180, 766)
</p>
</div>
<div>
<p>
// 1天一個點存5year
</p>
<p>
c.RRA(“AVERAGE”, 0.5, 720, 730)
</p>
<p>
c.RRA(“MAX”, 0.5, 720, 730)
</p>
<p>
c.RRA(“MIN”, 0.5, 720, 730)
</p>
<p>
“`
</p>
</div>
<p>
對于原始數據，transfer會打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb寫入數據。
</p>
<h2>
# Committers
</h2>
<ul>
<li>
laiwei: https://github.com/laiwei 來煒沒睡醒@微博 / hellolaiwei@微信
</li>
<li>
秦曉輝: https://github.com/ulricqin Ulricqin@微博 cnperl@微信
</li>
</ul>
<h2>
# Contributors
</h2>
<ul>
<li>
近期我們會把絕大數的組件整理到 http://github.com/open-falcon ， 期待大家一起貢獻，推動，做最開放、最好用的企業級監控系統。
</li>
</ul>
<h2>
# TODO
</h2>
<ul>
<li>
metric的聚合
</li>
<li>
環比、同比報警判定
</li>
<li>
流量的突升突降判定
</li>
</ul>
<h2>
# License
</h2>
<div>
<p>
Copyright 2014-2015 Xiaomi, Inc.
</p>
<p>
Licensed under the Apache License,
</p>
<p>
Version 2.0:
</p>
</div>
<p>
http://www.apache.org/licenses/LICENSE-2.0
</p>
</div>
</div>
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！