饿了么监控体系：从架构的减法中演进而来

分享概要

1、背景

2、遇到的问题

3、场景化

4、系统设计

大家好！很荣幸有这样的机会和大家交流，今天分享的主题为《饿了么监控体系的演进》。

我差不多是2015年中加入饿了么，主要是负责饿了么整个监控平台的搭建，从0开始搭建这套监控系统。

今天主要从以下四块给大家讲一下，整个过程我们遇到了哪些问题，怎么来解决这些问题，以及用怎么样的设计来支撑起这个系统。

一、背景

其实整个饿了么监控系统在演进过程中主要分为如下3个阶段：

• 第一阶段：主要由Statsd/Graphite/Grafana负责业务层的监控，ETrace负责全链路监控，Zabbix负责服务器层面的监控，ELog负责分布式日志搜索；
• 第二阶段：整个饿了么也从单IDC演进成异地多活架构，所以对监控也提出了更高的要求，基于这个我们也自研LinDB，以支持多活架构下的监控，Zabbix慢慢被ESM/InfluxDB/Grafana所替换，使用ELK替换原来的日志方案；
• 第三阶段：主要做一个减法，即把原来StatsD/Graphite/ETrace/ESM/InfluxDB统一到了EMonitor+LinDB这样的平台，以提供给用户一套统一的监控平台，日志开始使用阿里云的SLS；

二、遇到的问题

在这过程中我们主要遇到了哪些问题，然后我们怎么去解决这些问题。

之前也介绍了原来有多套监控系统，当出现问题的时候，需要从多套监控系统里面回来切换，其实这种上下文的切换是很影响定位问题的时间，一旦故障时间很长的话就意味着故障的影响范围也会变大。

那我们怎么来解决这个问题呢？