微服务监控告警:Prometheus

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

微服务监控告警

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

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

prometheus的Metrics案例:
微服务监控告警:Prometheus_第1张图片
influxDB不仅可以做监控,还可以对业务进行一些分析

1 四种主要监控方式

微服务监控告警:Prometheus_第2张图片
prometheus主要是Metrics方式(可以对离散数据进行聚合运算,还可以打标签)和Healthchecks方式结合

  • 适用场景
    微服务监控告警:Prometheus_第3张图片
  • Metrics监控架构
    微服务监控告警:Prometheus_第4张图片
    Alerts可以对接邮件、微信等,可以做去重、分组、路由

2 时间序列

一系列时间点连起来就形成时间序列
微服务监控告警:Prometheus_第5张图片
如图产生了一个时间序列矩阵,本质就是不同时间点产生不同的值,存储在数据库中,给出的红框案例为四个时间序列,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监控数据。
微服务监控告警:Prometheus_第6张图片
Exporters是用来间接采集的,如果不能直接采集就只能通过Exporters来间接采集,如Redis、Mysql等都可以做Exporters

  • 存储设计

以一个时间间隔作为一个时间块,一开始为mutable,在内存中,如果满了就变为Immutable,每两个小时产生一个mutable:
微服务监控告警:Prometheus_第7张图片
查询时,根据时间定位到块

每一个块的数据:
微服务监控告警:Prometheus_第8张图片

4 实践

  • 四个黄金指标

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

  • Cardinality(基数)

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

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

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

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

  • 高可用

做HA,两个Prometheus来实现,而数据可以交给远程存储,因为本地的15天就会过期;如果规模太大,还可以加上联邦集群,不同团队使用不同的Prometheus,由上层两个Prometheus进行聚合:
微服务监控告警:Prometheus_第9张图片

5 ZMon:分布式监控平台

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

适合大规模,使用拉模式,基于KairosDB实现,其架构如下:
微服务监控告警:Prometheus_第10张图片
可以看作是一个任务队列,使用消费者生产者模型,左侧产生任务,交给Redis,由右边的Worker处理完后,存储到DB或Redis

你可能感兴趣的:(微服务)