一、业务背景
\n运满满创立于2013年,致力于为公路运输行业提供高效管理配货的app。在5年时间内从初创型公司发展到独角兽企业,我们经历了很多次的技术架构调整。
\n今天给大家分享下不同时期,在运维监控方面做的多次架构升级。希望给大家在技术选型阶段,提供一些参考和借鉴。
\n二、架构演进
\n运满满监控整体可以分为三个阶段:全家桶套餐时代、DevOps时代、定制AIOps时代
\n创业期:全家桶套餐
\n在2015年以前,公司业务发展的不确定性,服务器数量规模较少。大部分都是靠运维人工监控、每日脚本巡检。
\n和大部分创业公司一样,当时的运维人员控制在3人以下,每天都在处理各类开发需求,完全没有空闲去开发系统,做整体的监控告警。这个阶段,我们急需一款开源的、功能齐全的、入门成本低的监控系统。
\nZabbix是我们当时的选择,简单的配置页面,丰富的agent数据采集,支持短信、邮件及微信告警,在一个星期内,我们就完成了全站的基础监控。
\nZabbix开箱即用的使用方式,适合初创型公司。即使是现在,Zabbix还在线上运行,监控网络设备的运行状态。
\n \n发展期:DevOps时代
\n到了2016年,随着业务高速发展,研发的需求越来越复杂,同时也暴露出Zabbix的很多缺点。
\n- \n
- \n
Zabbix性能瓶颈,监控数据存储在Mysql中,随着监控数据越来越多,Zabbix响应时间变慢。
\n\n - \n
Zabbix只支持metric类型监控,对于日志类监控,支持并不友好。
\n\n - \n
Zabbix监控大盘页面不美观,无法满足业务方定制的需求。
\n\n
基于以上问题,我们开始寻求专业领域内的各类监控。
\nCAT
\nCAT(Central Application Tracking)是基于Java开发的实时监控平台,主要包括移动端监控,应用侧监控,核心网络层监控,系统层监控等。
\nCAT的优点是功能丰富,支持钉钉告警,95线99线计算,可展示代码级别监控,在代码层故障定位提供了强有力的工具。
\n \nLEPUS
\nLepus(天兔)数据库企业监控系统是一套由专业DBA针对互联网企业开发的一款强大的企业数据库监控管理系统。Lepus后端采用Python语言开发,对于运维非常友好,可以很方便地作出一些个性化的修改。
\nLepus的优点是无需安装agent,账号集中管理,适合作为数据库的CMDB使用。
\n \nELK监控生态
\nELK(Elasticsearch,Logstash,Kibana)是Elastic公司提供的三个开源组件。在日常工作中,我们需要进行日志分析场景:直接对日志文件进行grep、awk等正则操作,获取我们想要的信息。在大规模的场景中,日志文件分布在不同的服务器上,且文件非常大,逐台操作性能非常低。比如Nginx日志,Mysql慢查询日志,应用log日志等。ELK提供一整套的解决方案,可以帮助我们快速全站查询。
\n下图是Mysql慢查询的截图,通过python脚本,可以实时读取Mysql慢查询日志,并写入ES,方便查看线上问题。
\n \n下图是服务器的dashboard,通过模糊匹配,可以快速查询相关服务器组的性能指标。
\n \nOpen-Falcon
\nOpen-Falcon是小米开源的监控系统,灵活的数据采集,水平扩展能力以及高效的告警策略帮助我们快速监控servers的信息。在实际的环境中,我们仅采用了falcon-agent、falcon-transfer组件,帮助我们采集数据,具体的存储及展示由更专业的组件处理。
\n \n数据存储及展示
\n随着业务的发展,数据量越来越大,需要一款通用的时序数据库提供数据存储,当时有Prometheus、OpenTSDB、InfluxDB三大选择。
\nPrometheus提供了丰富的数据模型和查询语句,容易上手,很容易集成到现有的环境中,但是Prometheus的集群和HA架构并不成熟,需要额外的开发,并不适合。
\nInfluxDB是在Prometheus之后才提出的,并且提供商业的伸缩和集群化服务,相比Prometheus的metrics存储,InfluxDB还能处理事件类型的数据,对于大部分公司而言,商业化基本不会考虑。
\nOpenTSDB是一个基于Hadoop和Hbase的分布式事件序列数据库,相比Prometheus和InfluxDB,OpenTSDB的横向扩缩容很容易(需要有丰富的Hadoop/HBase维护经验),同时官方Open-falcon支持OpenTSDB,结合公司现有的技术栈,综合考虑后最终选择了OpenTSDB作为我们的存储。
\n关于数据展示的选型,在没有自研能力的情况下,Grafana是不二选择。Grafana的告警功能强大方便,同时支持钉钉,Webhook等,满足公司所有的需求。与此同时,我们将Grafana和Docker技术结合,实现了Grafana高可用、自愈和无限扩展能力。
\n数据库监控
\n \nNginx监控
\n \n专线监控
\n \nKubernetes监控
\n
独角兽期:定制AIOps时代
\n在2017年底,运满满与货车帮合并,底层数据量翻倍,人员翻倍。我们碰到了以下几个问题:
\n- \n
- \n
问题排查,需要打开多套监控系统,效率低。
\n\n - \n
每套监控都有学习成本,对研发不友好。
\n\n - \n
一个故障,多套监控工具同时告警形成短信风暴,扰乱视听。
\n\n
基于以上问题,我们提出了建设一套大而全的监控理念,主要包括以下几个要素:
\n- \n
- \n
同时支持基础监控与业务监控;
\n\n - \n
事件日志与metric指标关联:
\n\n - \n
告警接口统一;
\n\n - \n
支持多种语言接入。
\n\n
监控架构图如下:
\n \n在数据采集阶段,保留了Open-Faclon、CAT、 客户端SDK、Logstash等入口,通过Kafka进行汇聚,引入大数据实时计算平台Flink,提炼metric指标,并最终入库。
\n在告警方面,开发了Alert Manager组件,对接多种告警渠道:钉钉、短信、微信等,并且自动创建Jira,告警闭环。
\n我们的最终目标是实现AI自愈的功能,比如自动降级、限流、流量切换等,目前该部分的功能还在探索中。
\n\n
作者简介
\n叶圣贤,满帮集团运满满公司技术保障部负责人。长期关注运维、DB、容器等领域,推崇DevOps理念,善于开发工具解决日常运维工作,提高运维效率。
\n