中间件使用：prometheus

Prometheus由go语言编写的基于时序数据库的监控告警系统，已加入CNCF基金会，是CNCF推荐使用的监控告警系统。Prometheus可以看做微服务监控告警的解决方案，通过部署exporter可以监控中间件的状态，微服务的运行状态，通过alertmanager进行告警。自研的中间件可以通过暴露/metrics接口纳入prometheus的监控，通过grafana模板可视化展示。

时序/监控数据的特点是：

• 增：需要频繁的进行写操作，而且是按时间排序顺序写入
• 删：不需要随机删除，一般情况下会直接删除一个时间区块的所有数据
• 改：不需要对写入的数据进行更新
• 查：需要支持高并发的读操作，读操作是按时间顺序升序或降序读，数据量非常大，缓存不起作用

prometheus特点：

• 多维度数据模型-由指标键值对标识的时间序列数据组成（底层的数据结构是时序数列，可以对指标添加标签便于筛选）
• PromQL，一种灵活的查询语言。（在查询的时候组合条件进行筛选）
• 不依赖分布式存储; 单个服务器节点是自治的。部署方便
• 以HTTP方式，通过pull模式拉取时间序列数据
• 支持通过中间网关推送时间序列数据
• 通过服务发现或者静态配置，来发现目标服务对象
• 支持多种多样的图表和界面展示

架构：

组件：

• Prometheus server：用于抓取和存储时间序列数据
• client libraries：暴露监控指标的代码库
• exporter：监控目标的服务
• push gateway：根据prometheus的告警请求管理告警，可配置邮件，slack，web hook等方式
• service discovery：发现被监控服务的方式，包括静态文件，k8s，consul等
• 各种支持工具如可视化工具grafana

简单的工作原理：
客户端安装exporter监控中间件或服务集成依赖包，暴露监控指标，prometheus定期从客户端pull数据，通过grafana或api clinet进行查询。可配置告警规则，prometheus将符合规则的指标发往alertmanager，由alertmanager决定是否告警以及何时告警。

在项目的应用：

• 对微服务的改造：

  • 通过actuator和prometheus，对外暴露/actuator/prometheus接口，以供prometheus拉取监控数据
  • 不想对外暴露监控接口，通过spring security保护/actuator/**接口，即为每个服务添加filter，prometheus访问时，需要提供basic auth。注意区分servlet和webflux应用

• 服务发现：

  • 微服务架构中一个服务通常有多个副本，因此prometheus中通过IP:port无法获取每个服务的指标。如果微服务用docker部署，prometheus得到的是一个时刻某一容器的监控指标，无法获取全部容器指标
  • 因此采用eureka-consul进行服务发现，可以从eureka获取注册的所有服务。此时需要将prometheus部署到服务网络，通过内部ip:port访问到所有容器

• Prometheus server：

  • 监控SIT/QA/UAT环境：

    • 通过一个prometheus监控不同环境，通过标签（job_name）进行区分。不可行。因为prometheus需要加入sit，qa，uat服务的docker网络，一个prometheus无法同时加入多个网络。
    • Push gateway，架构复杂，需要保证pushgateway的高可用；无法主动获取各个服务的状态
    • 最终采取方案：每个环境均搭建prometheus ，grafana共用一个，在grafana通过选取不同的数据源展示不同环境的数据。使用到的数据库和中间件如mysql，redis，zookeeper，kafka，canal使用单独的prometheus进行监控

prometheus部署

使用流程

1. Grafana中下载spring boot，Mysql，Redis等模板
2. 下载对应exporter，修改配置
3. Prometheus修改配置，添加exporter监控
4. Grafana导入模板，配置prometheus中对应的exporter数据源

监控的目的：

• 目前我们做的监控比较少，仅有的是健康检查，以及在portainer里docker容器的系统信息，业务指标如应用的qps没有监控。prometheus可以搭建基础的监控服务，需要的监控可以在prometheus集中展示。
• 大部分时间服务都是正常运行的，不出事的话显得监控没什么意义，一旦出了问题，监控可以看出现故障时刻的监控指标。如交易数过多，内存，cpu使用情况。
• 事前预警，事后追踪
• 性能优化

不适用场景：
如果需要100％的准确度，例如按请求计费、出报表，Prometheus不是一个好的选择，它不适合做基础的数据库，因为收集的数据可能不够详细和完整。它在这种情况下，最好使用其他系统如es来收集和分析数据，使用Prometheus进行其余监控。

prometheus数据模型：
从根本上存储的所有数据都是时间序列: 具有时间戳的数据流只属于单个度量指标和该度量指标下的多个标签维度。除了存储时间序列数据外，Prometheus还可以生成临时派生的时间序列作为查询的结果。
每一个时间序列数据由metric度量指标名称和它的标签labels键值对集合唯一确定。这个metric度量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收http请求的总计数）。 metric度量指标可能包含ASCII字母、数字、下划线和冒号，他必须配正则表达式a-zA-Z_:* 。
labels开启了Prometheus的多维数据模型：对于相同的度量名称，通过不同标签列表的结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks的http请求，打上method=POST的标签，则形成了具体的http请求)。这个查询语言在这些度量和标签列表的基础上进行过滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列。

• counter 是表示单个单调递增计数器的累积度量，其值只能在重启时增加或重置为零。Eg：请求数
• gauge是一个度量指标，它表示一个既可以递增, 又可以递减的值。Eg：cpu内存占用
• histogram，对观察结果进行采样（通常是请求持续时间或响应大小等），并将其计入可配置存储桶中。它还提供所有观察值的总和。
• summary是采样点分位图统计(通常是请求持续时间和响应大小等)。虽然它还提供观察的总数和所有观测值的总和，但它在滑动时间窗口上计算可配置的分位数。

关于alertmanager的使用可参考：
https://segmentfault.com/a/11...