来源：
《微服务架构实战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
