微服务监控体系

1. 微服务架构的本质，是把整体的业务拆分成很多有特定明确功能的服务，通过很多分散的小服务之间的配合，去解决更大，更复杂的问题。对被拆分后的服务进行分类和管理，彼此之间使用统一的接口来进行交互。

2.微服务面临的问题

• 微服务架构整个应用分散成多个服务，定位故障点非常困难
• 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。
• 服务数量非常多，部署、管理的工作量很大。
• 分散在各个服务器上的日志怎么处理？
• 如何快速定位问题？

我们发现，以前在单应用下的日志监控很简单，在微服务架构下却成为了一个大问题，如果无法跟踪业务流，无法定位问题，我们将耗费大量的时间来查找和定位问题，在复杂的微服务交互关系中，我们就会非常被动

监控 - 发现故障的征兆

统一监控指标体系：logging+Tracing+Metrics

微服务的可观测性应该由日志（logging），分布式调用链追踪(Tracing)，Metrics指标三大块组成。

1. (logging)日志收集使用ELK技术栈

Logging:用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。

ELK由Elasticsearch、Logstash和Kibana三部分组件组成

Elasticsearch+Logstash+Kibana

Elasticsearch，简称es，是一个高度可扩展的开源全文搜索和分析引擎，

可快速、实时地存储、搜索和分析大量数据。它通常作为底层引擎，为具有复

杂搜索特性和需求的应用程序提供动力。es可以很方便的完成文档存储工作，

根据用户的需求对字段进行索引，使得文档的内容可以被快速地搜索到。

Logstash是一个开源数据收集引擎，具有实时流水功能，可将来自不同数据源的数据统一起来，并将数据规范化后传输到需要的目标中。



Kibana用于Elasticsearch检索数据的开源分析和可视化平台。可以使用Kibana搜索、查看或者与存储在Elasticsearch索引中的数据交互。同时可以轻松地执行高级数据分析，可视化展示数据。

 

2.(Tracing)调用链追踪用OpenTracing/Zipkin

在微服务架构中通常是一般使用业务来划分服务的，使用(Restful API)调用,对外暴露接口，可能会需要很多个服务协同才能够完成一次接口调用的功能，如果链路上任何一个服务模块出现问题，都会导致接口调用的失败。随着业务的不断扩张和需求的不断丰富，服务之间相互调用会愈加复杂

Tracing:用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器

基础数据采集＋数据存储＋前端展示几个部分

路追踪系统中有两个重要的概念：

1. Trace。一个Trace认为是一次完整的链路，内部包含ｎ多个span，span表示一次具体的调用，每个span内部都包含有一些属性，Trace与span是一对多的关系，可以理解为，Trace是一批存在父子关系的span封装完成后的数据结构。
2. span。Trace中的每一个节点都是一个span。span可以理解为封装了服务调用的开始时间、结束时间以及相关的应用数据的数据结构。span与span之间存在父子关系。

链路追踪系统最重要的功能如下：

• 故障快速定位。通过跟踪调用链请求的流经，一次请求的逻辑可以完整清晰的用时序图或是树形图展示出来，结合业务日志快速定位错误问题。
• 调用链路性能分析。在调用链的各个功能服务添加调用耗时信息，能够分析系统的性能瓶颈，通过响应的手段进行性能上的优化。
• 数据分析。形成调用链后查看具体每条业务数据对应的请求链路问题，经过了哪些服务，汇总分析应用于很多的场景。
• 生成服务调用拓扑图。通过可视化系统模块和他们之间的相互调用关系来理清系统的拓扑关系，并显示当前请求状态的请求量。

学术界给出了一个OpenTracing规范，它是一个轻量级的标准化层，它位于应用程序／类库和追踪或日志分析程序之间。

。

 

Zipkin是一款开源的分布式实时数据追踪系统（Distributed Tracking System）通过Zipkin可以很方便地追踪请求的调用链路，整个调用链上各个服务的处理耗时，响应状态，服务间的调用关系都可以方便地在Zipkin中进行查询。Zipkin对于分析整个系统的性能瓶颈，定位故障也都有很大的帮助。

Collector+Storage+query+ui

 

3.Metrics监控使用Promethus和Grafana。

Metrcs:用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP 请求个数可被定义为一个计数器，新请求到来时进行累加

微服务架构中组件繁多，各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。因此如果做一个大而全的监控系统来监控各个组件是不大现实的，而且扩展性会很差。一般的做法是让各个组件提供报告自己当前状态的接口（metrics接口），这个接口输出的数据格式应该是一致的。然后部署一个指标采集器组件，定时从这些接口获取并保持组件状态，同时提供查询服务。最后还需要一个UI，从指标采集器查询各项指标，绘制监控界面或者根据阈值发出告警。

RedisExporter和MySQLExporter，这两个组件分别提供了Redis缓存和MySQL数据库的指标接口。微服务则根据各个服务的业务逻辑实现自定义的指标接口。然后采用Prometheus作为指标采集器，Grafana配置监控界面和邮件告警。这样一套微服务监控系统就搭建起来了：