从初创型到独角兽企业,监控架构演进的那些事儿

一、业务背景

\n

运满满创立于2013年,致力于为公路运输行业提供高效管理配货的app。在5年时间内从初创型公司发展到独角兽企业,我们经历了很多次的技术架构调整。

\n

今天给大家分享下不同时期,在运维监控方面做的多次架构升级。希望给大家在技术选型阶段,提供一些参考和借鉴。

\n

二、架构演进

\n

运满满监控整体可以分为三个阶段:全家桶套餐时代、DevOps时代、定制AIOps时代

\n

创业期:全家桶套餐

\n

在2015年以前,公司业务发展的不确定性,服务器数量规模较少。大部分都是靠运维人工监控、每日脚本巡检。

\n

和大部分创业公司一样,当时的运维人员控制在3人以下,每天都在处理各类开发需求,完全没有空闲去开发系统,做整体的监控告警。这个阶段,我们急需一款开源的、功能齐全的、入门成本低的监控系统。

\n

Zabbix是我们当时的选择,简单的配置页面,丰富的agent数据采集,支持短信、邮件及微信告警,在一个星期内,我们就完成了全站的基础监控。

\n

Zabbix开箱即用的使用方式,适合初创型公司。即使是现在,Zabbix还在线上运行,监控网络设备的运行状态。

\n

\"\"

\n

发展期:DevOps时代

\n

到了2016年,随着业务高速发展,研发的需求越来越复杂,同时也暴露出Zabbix的很多缺点。

\n
  1. \n
  2. \n

    Zabbix性能瓶颈,监控数据存储在Mysql中,随着监控数据越来越多,Zabbix响应时间变慢。

    \n\n
  3. \n

    Zabbix只支持metric类型监控,对于日志类监控,支持并不友好。

    \n\n
  4. \n

    Zabbix监控大盘页面不美观,无法满足业务方定制的需求。

    \n\n
\n

基于以上问题,我们开始寻求专业领域内的各类监控。

\n
CAT
\n

CAT(Central Application Tracking)是基于Java开发的实时监控平台,主要包括移动端监控,应用侧监控,核心网络层监控,系统层监控等。

\n

CAT的优点是功能丰富,支持钉钉告警,95线99线计算,可展示代码级别监控,在代码层故障定位提供了强有力的工具。

\n

\"\"

\n
LEPUS
\n

Lepus(天兔)数据库企业监控系统是一套由专业DBA针对互联网企业开发的一款强大的企业数据库监控管理系统。Lepus后端采用Python语言开发,对于运维非常友好,可以很方便地作出一些个性化的修改。

\n

Lepus的优点是无需安装agent,账号集中管理,适合作为数据库的CMDB使用。

\n

\"\"

\n
ELK监控生态
\n

ELK(Elasticsearch,Logstash,Kibana)是Elastic公司提供的三个开源组件。在日常工作中,我们需要进行日志分析场景:直接对日志文件进行grep、awk等正则操作,获取我们想要的信息。在大规模的场景中,日志文件分布在不同的服务器上,且文件非常大,逐台操作性能非常低。比如Nginx日志,Mysql慢查询日志,应用log日志等。ELK提供一整套的解决方案,可以帮助我们快速全站查询。

\n

下图是Mysql慢查询的截图,通过python脚本,可以实时读取Mysql慢查询日志,并写入ES,方便查看线上问题。

\n

\"\"

\n

下图是服务器的dashboard,通过模糊匹配,可以快速查询相关服务器组的性能指标。

\n

\"\"

\n
Open-Falcon
\n

Open-Falcon是小米开源的监控系统,灵活的数据采集,水平扩展能力以及高效的告警策略帮助我们快速监控servers的信息。在实际的环境中,我们仅采用了falcon-agent、falcon-transfer组件,帮助我们采集数据,具体的存储及展示由更专业的组件处理。

\n

\"\"

\n
数据存储及展示
\n

随着业务的发展,数据量越来越大,需要一款通用的时序数据库提供数据存储,当时有Prometheus、OpenTSDB、InfluxDB三大选择。

\n

Prometheus提供了丰富的数据模型和查询语句,容易上手,很容易集成到现有的环境中,但是Prometheus的集群和HA架构并不成熟,需要额外的开发,并不适合。

\n

InfluxDB是在Prometheus之后才提出的,并且提供商业的伸缩和集群化服务,相比Prometheus的metrics存储,InfluxDB还能处理事件类型的数据,对于大部分公司而言,商业化基本不会考虑。

\n

OpenTSDB是一个基于Hadoop和Hbase的分布式事件序列数据库,相比Prometheus和InfluxDB,OpenTSDB的横向扩缩容很容易(需要有丰富的Hadoop/HBase维护经验),同时官方Open-falcon支持OpenTSDB,结合公司现有的技术栈,综合考虑后最终选择了OpenTSDB作为我们的存储。

\n

关于数据展示的选型,在没有自研能力的情况下,Grafana是不二选择。Grafana的告警功能强大方便,同时支持钉钉,Webhook等,满足公司所有的需求。与此同时,我们将Grafana和Docker技术结合,实现了Grafana高可用、自愈和无限扩展能力。

\n

数据库监控

\n

\"\"

\n

Nginx监控

\n

\"\"

\n

专线监控

\n

\"\"

\n

Kubernetes监控
\n\"\"

\n

独角兽期:定制AIOps时代

\n

在2017年底,运满满与货车帮合并,底层数据量翻倍,人员翻倍。我们碰到了以下几个问题:

\n
  1. \n
  2. \n

    问题排查,需要打开多套监控系统,效率低。

    \n\n
  3. \n

    每套监控都有学习成本,对研发不友好。

    \n\n
  4. \n

    一个故障,多套监控工具同时告警形成短信风暴,扰乱视听。

    \n\n
\n

基于以上问题,我们提出了建设一套大而全的监控理念,主要包括以下几个要素:

\n
  • \n
  • \n

    同时支持基础监控与业务监控;

    \n\n
  • \n

    事件日志与metric指标关联:

    \n\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
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值