IT运维监控解决方案介绍

现状

•小公司/ 创业团队< 500台服务器规模

开源方案：Zabbix、Nagios、Cacti…

云服务提供商：监控宝、oneAlert等

•BAT级别> 10万台服务器

投入大量的人力，内部自研，与业务严重耦合没法作为产品推出

•中间阶层

无从可选

 

早期，选用Zabbix

•Zabbix是一款开源的企业级监控系统

•对其进行二次开发、封装、调优...

•为什么选择Zabbix

•Cacti

•Collectd

•RRDtool

•Nagios

•openTSDB

 

Zabbix实践思路

•测试ZabbixNode

•Zabbix代码优化

•使用模式优化

•独立部署多套Zabbix，通过API整合

 

Zabbix遇到的问题

•随着公司业务规模的快速发展

•用户“使用效率”低下，学习成本很高

•不具备水平扩展能力，无法支撑业务需求

•告警策略的维护、变更代价太大，导致运维人员深陷其中，无法自拔

•不利于自动化，不利于与运维平台等基础设施整合

------------------------------------------------------------------------------------------------

Open-Falcon

Open-Falcon是小米运维团队设计开发的一款互联网企业级监控系统

•提供最好用、最人性化的互联网企业级监控解决方案

•项目主页：http://open-falcon.com

•Github: https://github.com/xiaomi/open-falcon

•QQ讨论组：373249123

•微信公众号：OpenFalcon

 

社区贡献

•交换机监控

•https://github.com/gaochao1/swcollector

•Windows监控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/windows_collect

•Agent宕机监控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/agent_monitor

•Redis/memcached/rabbitmq监控

https://github.com/iambocai/falcon-monit-scripts

•MySQL 监控方案

https://github.com/open-falcon/mymon

 

典型案例

美团

•生产环境广泛应用，1万+agent

•集成服务树、支持ping监控、多机房架构支持、报警第二接收人支持

•正在开发openTSDB接口、query增加正则功能

赶集

•深度定制，用于大数据部门平台服务监控与自动运维，生产环境已上线

京东金融

•深度调研open-falcon

•正在开发测试drrs（一种分布式的time series data 存储组件）并适配falcon

 

内部 

agent
•负责机器数据采集
•自发现各项监控指标
•发送数据给transfer
•发送心跳信息给hbs
•执行自定义插件
•业务数据不要用插件采集！
•数据收集采用推还是拉的方式？

transfer
•对接收到的数据做合法性校验
•转发数据给graph和judge
•为什么要做这个统一的接入端？
•为什么要对数据做分片？
•数据分片方案，用一致性hash还是路由表？

judge
•对接收到的数据按照阈值进行判定
•达到阈值的数据产生相应的event
•触发式判定or 轮询？
•为什么要使用内存？

graph
•操作rrd文件，对数据进行存储和查询
•将多次操作合并后再flush磁盘
•将要flush到磁盘的数据，打散到每个时间片，降低IO消耗
•为什么用rrd而不是opentsdb之类的？

hbs
•提供接口给agent查询机器所需监控的端口、进程、要执行的插件列表等信息
•接收agent汇报的状态信息并写入数据库
•缓存用户配置的告警策略
•为什么要用hbs缓存策略列表？

query

•利用一致性hash算法，查询多个graph的数据并汇聚
•需要使用与transfer相同的hash算法及配置

各web端
•Dashboard负责绘图、展示、仪表盘等
•Uic负责管理组合人的对应关系
•Alarm-dashboard负责展示当前未恢复的告警
•用户在portal中配置告警策略
•Portal中的hostgroup一般是从CMDB中同步过来的！

Aggregator
目标：集群监控
•针对某个hostgroup的多个counter进行计算
•分子：$(c1) + $(c2) -$(c3)
•分母：可以是$# 或者数字或者$(d1) + $(d2) -$(d3)
计算结果
•封装成一个metricItem，再次push回open-falcon
为什么这么实现
•归一化的问题解决方案
•复用整个open-falcon的绘图展现、告警逻辑

Gateway——跨数据中心

接驳服务树（CMDB）
•开源服务器管理组件（服务树）
•监控对象通过服务树来管理
•服务器进出节点、监控自动变更

历史数据高可用
rrd-on-hbase
•绘图数据存储在hbase中，解决高可用的问题
•历史数据提供更详细粒度的查看
drrs（@京东金融）
•Distributed Round Robin Server
•面向中心公司，轻量级的历史数据存储方案，解决数据扩容的问题

智能告警
同比、环比
•Dashboard数据展示支持同比、环比
•告警判定引入同比、环比作为参考
动态阈值
•通过对历史数据的学习，生成动态的告警阈值
关联分析
•精准告警
•故障定位

SDK
七层
•Nginx
•统计cps、200、5xx、4xx、latency、availability、throughput
语言支持Java/C++/PHP/Python
•内置统计每个接口的cps、latency
•内置统计业务关注的指标的能力
框架支持
•resin、spring、flask…
统计类型
•Gauge/ Meter / Timer / Counter / Histogram

云监控
•服务端Host在公有云上
•无需客户安装、运维服务端
•支持namespace隔离、quota限额
•从根本上对不同用户的数据进行隔离
•优化监控的添加、管理、查看流程
•提升用户体验、提高用户使用效率

其他
•Callback功能增强，推进故障自动处理
•插件的管理支持多种方式（不仅限于git）
•Dashboard 增加用户登录认证
•告警排班/ 告警升级（@金山云）

Open-Falcon部署实践
•初始阶段
•所有的组件部署在一台物理机上即可
机器量级~ 500
•graph、judge、transfer三个组件拆分出来部署在1台服务器上
机器量级~ 1000
•graph、judge、transfer 增加到2~3个实例
•query拆分出来，部署2个实例
•dashboard 拆分出来部署
机器量级~ 10K
•graph、judge、transfer 增加到20个实例，graph尽量使用ssd磁盘
•query增加到5个实例
•dashboard 拆分出来，增加到3个实例

 

希望对您运维管理有帮助。

---

以上内容部分来自网络， 希望对您系统架构设计，软件研发有帮助。 其它您可能感兴趣的文章：

构建高效的研发与自动化运维
互联网数据库架构设计思路
移动开发一站式解决方案
某大型电商云平台实践
企业级应用架构模式N-Tier多层架构
某企业社交应用网络拓扑架构图
IT基础架构规划方案一(网络系统规划)
餐饮连锁公司IT信息化解决方案一

如有想了解更多软件研发 , 系统 IT集成 , 企业信息化，项目管理 等资讯，请关注我的微信订阅号：

 

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。