来源：
《微服务架构实战160讲》

微服务监控告警

prometheus是多维度（标签）的，使用拉模式，黑盒白盒都支持，对DevOps友好，适用中小规模

支持的Metric种类：计数器、测量仪、直方图、汇总图

prometheus的Metrics案例：

influxDB不仅可以做监控，还可以对业务进行一些分析

1 四种主要监控方式

prometheus主要是Metrics方式（可以对离散数据进行聚合运算，还可以打标签）和Healthchecks方式结合

适用场景
Metrics监控架构

Alerts可以对接邮件、微信等，可以做去重、分组、路由

2 时间序列

一系列时间点连起来就形成时间序列

如图产生了一个时间序列矩阵，本质就是不同时间点产生不同的值，存储在数据库中，给出的红框案例为四个时间序列，request_total、errors_total是时间序列的名称，path和method是标签，不同标签，时间序列也不同

3 架构设计

一般情况是拉取（Jobs/Exporters），对于短周期可以使用推（Short-lived jobs）到push网关再去拉，也可以pull其他PrometheusServer，这也就是集群

拉取的话就需要知道要拉取的服务地址，即需要服务发现，所以有了ServiceDiscovery

Retrieval模块定时拉取数据，并通过Storage模块保存数据，而PromQL为Prometheus提供查询语法，PromQL模块通过解析语法树，调用Storage模块查询接口获取监控数据。

右侧是告警和页面展现：
Prometheus将告警推送到alertmanger，然后通过alertmanger对告警进行处理并执行相应动作。
数据展现除了Prometheus自带的WebUI，还可以通过Grafana等组件查询Prometheus监控数据。

Exporters是用来间接采集的，如果不能直接采集就只能通过Exporters来间接采集，如Redis、Mysql等都可以做Exporters

存储设计

以一个时间间隔作为一个时间块，一开始为mutable，在内存中，如果满了就变为Immutable，每两个小时产生一个mutable：

查询时，根据时间定位到块

每一个块的数据：

4 实践

四个黄金指标

延迟、流量/吞吐、错误、饱和度（衡量资源使用情况）

Cardinality（基数）

为Label的可能取值，新增一个 Label 值=新增一个时间序列

经验值：单实例 Cardinality <= 10个

以下属性不适合做 Label：
• Email Email 地址
• 用户名
• IP 地址
• HTTP Path HTTP Path

一般关注 10 个最大的 metrics，而高Cardinality场景，如要监控ip等，用 Log系统

高可用

做HA，两个Prometheus来实现，而数据可以交给远程存储，因为本地的15天就会过期；如果规模太大，还可以加上联邦集群，不同团队使用不同的Prometheus，由上层两个Prometheus进行聚合：

5 ZMon：分布式监控平台

Prometheus是基于团队的，每个团队自己搭建一个，而Zmon是基于整体的

适合大规模，使用拉模式，基于KairosDB实现，其架构如下：

可以看作是一个任务队列，使用消费者生产者模型，左侧产生任务，交给Redis，由右边的Worker处理完后，存储到DB或Redis