#yyds干货盘点#Prometheus 之微服务监控概述件 _prometheus

大鹏一日同风起，扶摇直上九万里。这篇文章主要讲述#yyds干货盘点#Prometheus 之微服务监控概述件相关的知识，希望能为你提供帮助。
【#yyds干货盘点#Prometheus 之微服务监控概述件】微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务

微服务监控与传统应用的监控相比，最明显的变化是视角的改变，即把监控从机器视角转换成以服务为中心的视角。与传统监控相比，微服务监控面临着更多难点，包括：

监控对象动态可变，无法进行预先配置。
监控范围非常繁杂，各类监控难以互相融合。
微服务实例间的调用关系非常复杂，故障排查会很困难。
微服务架构仍在快速发展，难以抽象出稳定的通用监控模型。

在实际生产中，微服务监控也面临着不少考验，例如：

在微服务架构里，软件系统通常会被拆分为数十甚至数百个微服务，这种拆分会使监控数据爆炸增长，监控系统必须具备处理和展示这些数据的能力。
监控系统必须保证可靠性，即保证不会因为单点故障而全局失效，监控数据有备份机制，系统各服务的实例均可通过备份数据得到恢复。
监控系统必须支持云上部署及快速水平扩容，这既是云原生的基本要求，也符合企业系统微服务演进的实际情况。

在微服务的视角下，监控可以分为指标监控、链路监控和日志监控。在开源社区，这些监控都有对应的解决方案，比如指标监控有 Prometheus、Influxdb，链路监控有 zipkin、pinpoint，日志监控则有 ELK。

微服务监控的关键指标分三个维度监控场景如下：

数据维度：URL 监控、自定义监控、资源监控、应用性能监控
资源维度：主机监控、产品监控、组件监控、自定义监控、事件监控
代码维度：URL 监控、自定义监控、资源监控、应用性能监控

基于 Prometheus 搭建 Spring Boot 监控的架构。因为在 Spring Boot 内部使用 MeterRegistryPostProcessor 对 Metrics 内部持有全局的 CompositeMeterRegistry 进行合成操作，也就是所有 MeterRegistry 类型的 Bean 都会添加到 Metrics 内部持有的静态 globalRegistry 中，这样就可以使用 Metrics 的静态方法直接进行数据统计。

Micrometer 中有两个最核心的概念，分别是计量器（Meter）和计量器注册表（MeterRegistry）。计量器表示的是需要收集的性能指标数据，而计量器注册表负责创建和维护计量器。每个监控系统有自己独有的计量器注册表实现。模块 micrometercore 中提供的类 SimpleMeterRegistry 是一个基于内存的计量器注册表实现。SimpleMeterRegistry 不支持导出数据到监控系统，主要用来进行本地开发和测试。Micrometer 通过计量器注册表实现类 CompositeMeterRegistry 可以把多个计量器注册表组合起来，从而允许同时发布数据到多个监控系统。

数据的一大价值就是建立业务指标体系，用以监控业务日常运营，并预警业务问题，定位问题原因，这是数据最早的应用形式，前期商业智能主要是做指标体系和相应平台的工作。业务的各类人员都需要了解业务的指标，才能更好地利用指标开展工作，进行数据运营。

运营指标体系一定是结构化的，而不是零散的，结构化的好处主要有两个方面：一是当指标发生异常时，能够通过结构化的指标体系来定位问题；二是当我们要达到某个 KPI 指标时，可以通过指标体系来分解指标，让我们知道可以从哪些方面着手。

结构化的指标体系需要有一个好的指标体系框架，现实工作中，各种指标浩如烟海，而且各个业务还具有不同的特性。对运营商和互联网企业来说，各个业务的指标体系大体可分为三类：收入类指标（Revenue）、用户类指标（User）、业务量类指标（Number），简称“RUN 指标体系”。

业务量类指标主要分为核心业务量指标和普通业务量指标，每个业务都自己的核心业务量，如音乐的试听量、视频播放量、应用商店的安装量、网站的 PV 和 UV、运营商的通话量和移动数据流量、电力企业的用电量、航空公司的客运量等，这些核心业务量是每个业务除了用户类和收入类指标之外最重要指标。核心业务量指标往往都是 KPI 指标之一，体现了用户使用某个产品的主要目的，怎样促进和优化用户使用则是运营人员需要思考的问题，如怎样提高视频的播放量、怎样提高应用的安装量。

除了核心业务量指标外，还有其他常见的普通业务量指标，常见的如搜索量、评论量、分享量、UGC 量、点击量、收藏量等，这些指标往往是很稀疏的，也就是说有这些行为的用户比较少，而有这些行为的用户往往拥有极大的忠诚度或不满意度，这是值得我们重视的。
，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制（通常是基于 HTTP 的 RESTful API 或 RPC）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境中，各个微服务之间是松耦合的。