基于grafana+elk等开源组件的 云服务监控大屏架构

本套大屏,在某云服务大规模测试环境,良好运行3年+.
本文主要展示这套监控大屏的逻辑架构.不做具体操作与配置的解释.

监控主要分为三部分:

1. 数据展示部分
2. 数据存储
3. 数据采集

1. 数据展示

数据展示方面主要使用grafana

2. 数据存储

根据数据种类和特性和用途的不同,本套监控采用了几种数据存储

1. elasticsearch
2. postgresql
3. prometheus
4. influxdb
5. loki
6. 可以使用其他任何grafana支持的数据源

3.数据采集和处理

1. logstash 数据处理,处理后的数据写入elasticsearch
2. kafka 主要是其他团队的数据, 会提供一条kafka日志流, 我们通过logstash读取后进行处理,写入elasticsearch
3. beats-metricbeat 主要读取虚拟机(服务器)的基本指标数据,包括cpu,内存,网络资源,磁盘,进程等指标,写入elasticsearch
4. beats-filebeat 主要读取各个云服务产生的有格式化的日志,通过logstash进行格式化解析, 变成各种指标写入elasticsearch, 主要用于对服务流量访问日志的获取解析展示.
5. file
6. telegraf 实现的功能跟3完全一样,但是对接的存储是influxdb, 最开始就是用3 metricbeat来采集数据,写入elastic进行展示, 后来当虚拟机数量提升, 指标数量较高,es的存储有点跟不上了,因为es主要是为搜索服务的,同样的指标量会占用大量存储资源, 通过调研选用了telegraf, 存储占用大幅下降,还有展示页面的加载速度大幅提升.原来只能展示1小时,选到3小时就会比较卡,选择24小时的范围基本无法展示. 换了telegraf采集+influxdb存储之后,选24小时范围的查询毫无压力,存储时间也超过3个月
7. promtail 主要功能为日志搜集, 使用loki存储, 实现日志转储,关键字查询的功能. 因为各个服务的机器给日志存储留用空间较小.并且是大规模环境,频繁进行性能压测,日志打印刷新非常快速. 基本十几分钟就会达到配置的日志存储上限,这时候会把旧的日志刷掉. 测试发现问题后,找开发定位非常麻烦. 又要重新复现. 用这个组件之后,目前可以把所有服务的日志,统一在loki服务器上存储1个月, 直接按照组件名+服务器id+时间 +关键词过滤,可以很快的查到相关日志.
8. python script 某些自定义的数据,使用开源组件采集不便, 自己使用脚本采集, 然后 通过写入文件,logstash解析,进入elasticsearch ,或 直接写入关系型数据库. 通过grafana进行展示.
9. agent-server 某些云服务,自己实现了prometheus的拉取接口, 暴露自己的监控指标,这部分直接部署prometheus对这些云服务agent-server进行拉取.