小米运维—互联网企业级监控系统实践(1)(3)

Web portal

一个高效的portal，对于提升用户的“使用效率”，加成很大，平时大家都这么忙，能给各位SRE、Devs减轻一些负担，那是再好不过了。

这是host group的管理页面，可以和服务树结合，机器进出服务树节点，相关的模板会自动关联或者解除。这样服务上下线，都不需要手动来变更监控，大大提高效率，降低遗漏和误报警。

open-falcon portal HostGroup

一个最简单的模板的例子，模板支持继承和策略覆盖，模板和host group绑定后，host group下的机器会自动应用该模板的所有策略。

open-falcon template

当然，也可以写一个简单的表达式，就能达到监控的目的，这对于那些endpoint不是机器名的场景非常方便。

open-falcon expression

添加一个表达式也是很简单的。

open-falcon add an expression

Storage

对于监控系统来讲，历史数据的存储和高效率查询，永远是个很难的问题!

数据量大：目前我们的监控系统，每个周期，大概有2000万次数据上报(上报周期为1分钟和5分钟两种，各占50%)，一天24小时里，从来不会有业务低峰，不管是白天和黑夜，每个周期，总会有那么多的数据要更新。

写操作多：一般的业务系统，通常都是读多写少，可以方便的使用各种缓存技术，再者各类数据库，对于查询操作的处理效率远远高于写操作。而监控系统恰恰相反，写操作远远高于读。每个周期几千万次的更新操作，对于常用数据库(MySQL、postgresql、mongodb)都是无法完成的。

高效率的查：我们说监控系统读操作少，是说相对写入来讲。监控系统本身对于读的要求很高，用户经常会有查询上百个meitric，在过去一天、一周、一月、一年的数据。如何在1秒内返回给用户并绘图，这是一个不小的挑战。

open-falcon在这块，投入了较大的精力。我们把数据按照用途分成两类，一类是用来绘图的，一类是用户做数据挖掘的。

对于绘图的数据来讲，查询要快是关键，同时不能丢失信息量。对于用户要查询100个metric，在过去一年里的数据时，数据量本身就在那里了，很难1秒之类能返回，另外就算返回了，前端也无法渲染这么多的数据，还得采样，造成很多无谓的消耗和浪费。我们参考rrdtool的理念，在数据每次存入的时候，会自动进行采样、归档。我们的归档策略如下，历史数据保存5年。同时为了不丢失信息量，数据归档的时候，会按照平均值采样、最大值采样、最小值采样存三份。

// 1分钟一个点存 12小时 
c.RRA("AVERAGE", 0.5, 1, 720) 
 
// 5m一个点存2d 
c.RRA("AVERAGE", 0.5, 5, 576) 
c.RRA("MAX", 0.5, 5, 576) 
c.RRA("MIN", 0.5, 5, 576) 
 
// 20m一个点存7d 
c.RRA("AVERAGE", 0.5, 20, 504) 
c.RRA("MAX", 0.5, 20, 504) 
c.RRA("MIN", 0.5, 20, 504) 
 
// 3小时一个点存3个月 
c.RRA("AVERAGE", 0.5, 180, 766) 
c.RRA("MAX", 0.5, 180, 766) 
c.RRA("MIN", 0.5, 180, 766) 
 
// 1天一个点存5year 
c.RRA("AVERAGE", 0.5, 720, 730) 
c.RRA("MAX", 0.5, 720, 730) 
c.RRA("MIN", 0.5, 720, 730) 

对于原始数据，transfer会打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb写入数据。

Committers

laiwei: https://github.com/laiwei 来炜没睡醒@微博 / hellolaiwei@微信

秦晓辉: https://github.com/ulricqin Ulricqin@微博 cnperl@微信

Contributors

近期我们会把绝大数的组件整理到 http://github.com/open-falcon ， 期待大家一起贡献，推动，做最开放、最好用的企业级监控系统。

TODO

metric的聚合

环比、同比报警判定

流量的突升突降判定

---

---