【监控告警】02-Promtheus的学习之路

prometheus采用的是 拉模式为主,推模式为辅 的方式采集数据。

Prometheus 作为一个指标系统天生就不是精确的——由于指标本身就是稀疏采样的,事实上所有的图表和警报都是”估算”,我们也就不必太纠结于图表和警报的对应性,能够帮助我们发现问题解决问题就是一个好监控系统。

当然,有时候我们也得证明这个警报确实没问题,那可以看一眼 `ALERTS` 指标。`ALERTS` 是 Prometheus 在警报计算过程中维护的内建指标,它记录每个警报从 Pending 到 Firing 的整个历史过程,拉出来一看也就清楚了。

【监控告警】02-Promtheus的学习之路_第1张图片

更多关于监控告警项目内容请参考:【监控告警】01-网关的需求与改造

Prometheus 的局限

  • Prometheus 是基于 Metric 的监控,不适用于日志(Logs)、事件(Event)、调用链(Tracing)。

  • Prometheus 默认是 Pull 模型,合理规划你的网络,尽量不要转发。

  • 对于集群化和水平扩展,官方和社区都没有银弹,需要合理选择 Federate、Cortex、Thanos等方案。

  • 监控系统一般情况下可用性大于一致性,容忍部分副本数据丢失,保证查询请求成功。这个后面说 Thanos 去重的时候会提到。

  • Prometheus 不一定保证数据准确,这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断,产生一些反直觉的结果,这个后面会详细展开。二来查询范围过长要做降采样,势必会造成数据精度丢失,不过这是时序数据的特点,也是不同于日志系统的地方。

  • Prometheus 为避免时区混乱,在所有组件中专门使用 Unix Time 和 Utc 进行显示。不支持在配置文件中设置时区,也不能读取本机 /etc/timezone 时区。

PromQL之APISIX

根据APISIX原生监控指标基础上,进行的二次加工和计算

其中,route="448693711467971471" 指的是实际配置在APISIX中的路由ID

1、异常率

sum(apisix_http_status{route="448693711467971471",code="500"}- apisix_http_status{route="448693711467971471",code="500"} offset 5m) / sum(apisix_http_status{route="448693711467971471"} - apisix_http_status{route="448693711467971471"} offset 5m)

2、异常次数

sum(apisix_http_status{route="448693711467971471",code="500"} - apisix_http_status{route="448693711467971471",code="500"} offset 5m)

3、访问次数

sum(apisix_http_status{route="448693711467971471"} - apisix_http_status{route="448693711467971471"} offset 5m)

4、处理时间

histogram_quantile(0.90, sum(rate(apisix_http_latency_bucket{type="upstream",route="448693711467971471"}[1m])) by (le))

HTTP API

通过HTTP API,我们可以利用http请求,向Prometheus传递计算表达式,返回我们想要的结果

具体调用方法如下:

http://192.168.2.80:19090/api/v1/query?query=sum(apisix_nginx_http_current_connections{state="accepted", instance=~"192.168.2.80:9092"})&time=1677178798.683

如果不太确定请求的URL格式,比较简单的查看查询语句的方式是:

在浏览器chrome调试窗口中可以发现真正请求的URL:

【监控告警】02-Promtheus的学习之路_第2张图片

在业务对接APISIX监控时,就遇到了这样的一个需求:业务系统需要获取某个路由的异常次数、异常率、访问次数、响应时间。

此时就可以利用Prometheus提供的HTTP API,URL中传递query参数。 Prometheus接收到计算公式后,会根据公式计算并返回结果。

监控指标

histogram_quantile 的"反直觉"

摘自: Prometheus 常用函数 histogram_quantile 的若干“反直觉”问题

P90/P99 表示什么

有什么实际含义和用处?

经常用来衡量服务响应延迟。

以最常用的 p99 为例,它衡量了 99% 的情况下,能达到的最大服务响应延迟,99%的延迟都低于这个数值,即绝大多数情况下的最差响应情况。

以p90为例,它衡量了 90% 的情况下,能达到的最大服务响应延迟,90%的延迟都低于这个数值,即多数情况下的最差响应情况。

监控统计区间问题

问题描述:

在进行业务测试的过程中,有些指标会出现:在单案例、单场景中正常告警;在多案例、多场景的测试中存在未告警的情况。

之所以出现这样问题的原因 ,是因为这些监控指标的统计区间不一样。

例如:Prometheus判断延迟5s的情况下,虽然触发了报警,但是还没有达到发送到Alertmanger的条件(处于Pending状态),由于案例测试的时间太短了,到了实际生产上,可能就是一个网络抖动的一个场景。

鉴于1分钟的区间数据很快就会恢复,5分钟的话差不多就能避免这个问题。这只是告警,能够保证在接受范围内发出邮件就可以了,如果问题严重的话还是得靠开发人员去解决。

设置的区间范围越短,可以理解为越不灵敏,但是可以规避很多网络问题。区间越长,因为有足够的采样数据,就越灵敏。但是,如果时间长的话,还会有另外一个问题,就是可能会出现即使服务恢复正常了,它还是会报警。因为在区间范围内,还会包含之前的异常数据。所以计算出来的还是异常的。

在设计告警统计区间时,需要考虑多个因素。时间范围的长度应该根据实际情况而定,不能一概而论。如果过短,会导致灵敏度不足,无法及时捕捉问题;如果过长,会导致误报警情况的出现。因此,需要综合考虑时间长度和实际情况,才能制定出最合适的告警统计区间策略,确保系统能够及时准确地发现并解决问题。

告警规则配置

Prometheus 告警规则配置:监控服务器宕机的时间超过1分钟就发送告警邮件。

groups:
- name: Test-001 # 组的名字,在这个文件中必须要惟一
  rules:
  - alert: InstanceDown # 告警的名字,在组中须要惟一
    expr: up == 0 # 表达式, 执行后果为true: 示意须要告警
    # 超过多少工夫才认为须要告警(即up==0须要持续的时间)   这个参数主要用于降噪
    # 很多类似响应时间这样的指标都是有抖动的,通过指定 Pending Duration,我们可以 过滤掉这些瞬时抖动,让 on-call 人员能够把注意力放在真正有持续影响的问题上。
    for: 1m
    labels:
      severity: warning # 定义标签
    annotations:
      summary: "服务 {{ $labels.instance }} 下线了"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."
  - name: Cpu
  rules:
    - alert: Cpu01
      expr: "(1 - avg(irate(node_cpu_seconds_total{mode='idle'}[5m])) by (instance,job)) * 100 > 80"
      for: 1m
      labels:
    service: demo
        severity: info # 自定一个一个标签 info 级别
      annotations:
        summary: "服务 {{ $labels.instance }} cpu 使用率过高"
        description: "{{ $labels.instance }} of job {{ $labels.job }} 的 cpu 在过来5分钟内应用过高,cpu 使用率 {{humanize $value}}."
    - alert: Cpu02
      expr: "(1 - avg(irate(node_cpu_seconds_total{mode='idle'}[5m])) by (instance,job)) * 100 > 90"
      for: 1m
      labels:
    service: demo
        severity: warning # 自定一个一个标签 warning 级别
      annotations:
        summary: "服务 {{ $labels.instance }} cpu 使用率过高"
        description: "{{ $labels.instance }} of job {{ $labels.job }} 的 cpu 在过来5分钟内应用过高,cpu 使用率 {{humanize $value}}."

配置字段含义

Prometheus 告警规则文件,下列字段的含义:

summary: 描述告警的概要信息

description: 用于描述告警的详细信息

$labels.变量可以访问当前告警实例中指定标签的值

$value: 则可以获取当前PromQL表达式计算的样本值

【监控告警】02-Promtheus的学习之路_第3张图片

recording rules

recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式,其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果,这样会比直接查询快,同时也减轻了PromQl的计算压力,同时对可视化查询的时候也很有用,可视化展示每次只需要刷新重复查询相同的表达式即可。

在配置的时候,除却 record: 需要注意,其他的基本上是一样的,一个 groups 下可以包含多条规则 rules RecordingRules 保存在 Group 内, Group 中的规则以规则的配置时间间隔顺序运算,也就是全局中的 evaluation_interval 设置。

groups:
- name: http_requests_total
  rules:
  - record: job:http_requests_total:rate10m
    expr: sum by (job)(rate(http_requests_total[10m]))
    lables:
      team: operations
  - record: job:http_requests_total:rate30m
    expr: sum by (job)(rate(http_requests_total[30m]))
    lables:
      team: operations

Prometheus 时区问题

Prometheus 时区问题的讨论

关于 timezone 的讨论,可以看这个issue

https://github.com/prometheus/prometheus/issues/500

Prometheus 内存问题

随着规模变大,Prometheus 需要的 CPU 和内存都会升高,内存一般先达到瓶颈,这个时候要么加内存,要么集群分片减少单机指标。这里我们先讨论单机版 Prometheus 的内存问题。

原因:

  • Prometheus 的内存消耗主要是因为每隔2小时做一个 Block 数据落盘,落盘之前所有数据都在内存里面,因此和采集量有关

  • 加载历史数据时,是从磁盘到内存的,查询范围越大,内存越大。这里面有一定的优化空间

  • 一些不合理的查询条件也会加大内存,如 Group 或大范围 Rate

我的指标需要多少内存:

How much RAM does Prometheus 2.x need for cardinality and ingestion?

有什么优化方案:

  • Sample 数量超过了 200 万,就不要单实例了,做下分片,然后通过 Victoriametrics,Thanos,Trickster 等方案合并数据。

  • 评估哪些 Metric 和 Label 占用较多,去掉没用的指标。2.14 以上可以看 Tsdb 状态。

  • 查询时尽量避免大范围查询,注意时间范围和 Step 的比例,慎用 Group。

  • 如果需要关联查询,先想想能不能通过 Relabel 的方式给原始数据多加个 Label,一条Sql 能查出来的何必用Join,时序数据库不是关系数据库。

Prometheus 内存占用分析:

通过 pprof分析:

Optimising Prometheus 2.6.0 Memory Usage with pprof

启动参数

Prometheus 启动命令

#启动prometheus软件,指定配置文件设置数据保留时间为90天设置日志级别
nohup ./prometheus --config.file=/software/prometheus-2.33.3.linux-amd64/etc/prometheus.yml  --log.level=debug > /software/prometheus-2.33.3.linux-amd64/prometheus.log 2>&1 & 

#确认9090端口是否启动,此时命令应该有输出。
ss -alntup | grep -i 9090    

生产推荐配置

Prometheus 生产推荐配置

数据采集频率配置:

scrape_interval:     15s      # 每15s采集一次数据,默认1min,经验值为10s-60s
evaluation_interval:  15s      # 每15s做一次告警检测,计算一条规则配置的时间间隔

参考资料:

https://blog.csdn.net/yujia_666/article/details/109311340

https://blog.csdn.net/u012516914/article/details/124905920?spm=1001.2014.3001.5506

你可能感兴趣的:(监控告警,微服务网关,学习方法)