Abstract: Preface This article may not record the implementation process of each step in detail, but to a certain extent, it can lead the small partners to a broader vision, connect each link, and present different effects to you. Business scale 8 platforms, 100+ servers, 10+ clusters, grouping, microservices, 600+ users, N+ problems. With the development of distributed microservice container technology, traditional monitoring systems face many problems: How containers monitor microservices, how to monitor cluster performance, and how to perform Analyzing and computing how to manage a large number of configuration scripts on the agent side are the thorny problems faced by traditional monitoring. So how to solve the current problems encountered, GPE was born, and will be analyzed later.
foreword
This article may not record the process of each step in detail, but to a certain extent, it can lead the small partners to a broader vision, connect each link, and present different effects to you.
Business scale
- 8 platforms
- 100+ servers
- 10+ cluster groupings
- Microservices 600+
- UserN+
face problems
With the development of distributed microservice container technology, traditional monitoring systems face many problems:
- How containers are monitored
- How to monitor microservices
- How to analyze and calculate cluster performance
- How to manage a large number of configuration scripts on the agent side
These are the thorny problems that traditional monitoring has to face, so how to solve the problems currently encountered, GPE turned out, and will focus on the analysis later.
System monitoring
- Target group: system logs, servers, containers, system software operation indicators
- Log Architecture: ELK (Elasticsearch+Logstash+Kibana+Redis)
- Monitoring Architecture: GPE (Grafana+Prometheus+Exporter+Consul)
- Alarm method: email, SMS, DingTalk and custom webhook, monitoring center 7x24 hours
ELK log
With the prevalence of distributed microservices and the division and refinement of functional modules, the importance of logs is self-evident, whether for development or operation and maintenance, but how to store, analyze, locate and view logs, one hundred companies may have Two hundred ways to do it. Some records rarely log, some log levels are not divided, some write text and then leave it alone, some throw it to the MySql database and have no record, and only turn over until the user complains or is found to have a problem. Turn over.
那么如何正确优雅的记录日志呢？相信大家对于ELK并不陌生，可能不少小伙伴都接触过，对于中小型互联网创业公司来说，使用ELK搭建日志分析系统的确是一个不错的选择。
架构图
核心组件
ELK由Elasticsearch、Logstash和Kibana三剑客组成，当然了以上是最基本的组件，为了使的架构流程更加丰满，我们加入了Redis做缓冲队列，配置了sendmail做异常日志告警。
ElasticSearch
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口等。
Logstash
Logstash数据分析工具，它可以对系统生成的的日志进行采集、分析，存储。2013 年，Logstash 被 Elasticsearch 公司收购，ELK Stack 正式成为官方用语。
kibana
Kibana是一个开源的分析与可视化平台，用来搜索、查看存储在Elasticsearch索引中的数据。
工作流程
- logstash(shipper) 实时监控并过滤收集每个服务的日志信息
- logstash(shipper) 把收集来的日志(INFO 、DEBUG 、RROR 、WARN等)分别发送到Redis
- logstash(indexer) 按照日志分类分别从Redis读取日志信息并发送给ElasticSearch
- logstash(indexer) 过滤出RROR日志通过邮件或者其它webhook方式告警开发运维人员
- Kibana读取ElasticSearch数据结合自定义搜索进行页面展示
GPE监控
我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。
ELK主要收集分析预警的是我们平台系统中各个服务的业务日志，一般通过日志组件(log4j 、log4j2 、logback)来收集并写入文本。但是对于系统本身以及一些应用软件的监控预警，这套方案显然是不合适的，这里推荐一下GPE三剑客，当然了GPE是我自己意淫出来的组合。
架构图
核心组件
Grafana、Prometheus、Exporter(一系列插件)，自定义的三剑客，当然了为了使得整合监控程序更加流畅完整，我们加入了注册中心Consul做服务发现，实现动态添加服务，使用邮件、钉钉以及webhook实现异常告警。
GPE组件只是其中的一种实现方式罢了，Grafana配合InfluxData提供Telegraf也可以收集很多Metrics，实现更为丰富的大屏监控预警。
Grafana
Grafana 是一个开箱即用的可视化工具，具有功能齐全的度量仪表盘和图形编辑器，有灵活丰富的图形化选项，可以混合多种风格，支持多个数据源特点。
Prometheus
Prometheus是一个开源的服务监控系统，它通过HTTP协议从远程的机器收集数据并存储在本地的时序数据库上。
- 多维数据模型（时序列数据由metric名和一组key/value组成）
- 在多维度上灵活的查询语言(PromQl)
- 不依赖分布式存储，单主节点工作.
- 通过基于HTTP的pull方式采集时序数据
- 可以通过push gateway进行时序列数据推送(pushing)
- 可以通过服务发现或者静态配置去获取要采集的目标服务器
- 多种可视化图表及仪表盘支持
如架构图所示，Prometheus通过安装在远程机器上的exporter来收集监控数据。
Consul
Consul有多个组件，但是整体来看，它是你基础设施中用于发现和配置服务的一个工具。它提供如下几个关键功能：
- 服务发现： Consul的某些客户端可以提供一个服务，例如api或者mysql，其它客户端可以使用Consul去发现这个服务的提供者。使用DNS或者HTTP，应用可以很容易的找到他们所依赖的服务。
- 健康检查： Consul客户端可以提供一些健康检查，这些健康检查可以关联到一个指定的服务（服务是否返回200 OK），也可以关联到本地节点（内存使用率是否在90%以下）。这些信息可以被一个操作员用来监控集群的健康状态，被服务发现组件路由时用来远离不健康的主机。
- 键值存储： 应用可以使用Consul提供的分层键值存储用于一些目的，包括动态配置、特征标记、协作、leader选举等等。通过一个简单的HTTP API可以很容易的使用这个组件。
- 多数据中心： Consul对多数据中心有非常好的支持，这意味着Consul用户不必担心由于创建更多抽象层而产生的多个区域。