数据采集

原则

  • 监控是基础设施，目的是为了解决问题，要减少不必要的指标采集

  • 需要处理的告警才发出来

    Prometheus的局限

  • Prometheus是基于Metrics的监控，不适用于日志、事件、调用链(Trace)

  • Prometheus默认是pull模型
  • 监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功

  • Prometheus不一定保证数据准确

    • rate , histogram_quantile 等函数会做统计和推断
    • 查询范围过长要做降采样

      常用exporter

  • cAdvisor 集成于kubelet中

    1.   - job_name: kubernetes-nodes-cadvisor
    2.     kubernetes_sd_configs:
    3.     - role: node
    4.     relabel_configs:
    5.     - action: labelmap
    6.       regex: __meta_kubernetes_node_label_(.+)
    7.     - target_label: __metrics_path__
    8.       replacement: /metrics/cadvisor
    9.     scheme: https
    10.     tls_config:
    11.       ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    12.       insecure_skip_verify: true
    13.     bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • kubelet https采集，10255非认证端口，10250为认证端口

    1.   - job_name: kubernetes-nodes-kubelet
    2.     kubernetes_sd_configs:
    3.     - role: node
    4.     relabel_configs:
    5.     - action: labelmap
    6.       regex: __meta_kubernetes_node_label_(.+)
    7.     scheme: https
    8.     tls_config:
    9.       ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    10.       insecure_skip_verify: true
    11.     bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • apiserver 6443端口，关心请求数、延迟等

    1.   - job_name: kubernetes-apiservers
    2.     kubernetes_sd_configs:
    3.     - role: endpoints
    4.     relabel_configs:
    5.     - action: keep
    6.       regex: default;kubernetes;https
    7.       source_labels:
    8.       - __meta_kubernetes_namespace
    9.       - __meta_kubernetes_service_name
    10.       - __meta_kubernetes_endpoint_port_name
    11.     scheme: https
    12.     tls_config:
    13.       ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    14.       insecure_skip_verify: true
    15.     bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • scheduler: 10251端口

  • controller-manager: 10252端口。
  • etcd 如etcd写入读取延迟，存储容量等
  • docker 需要开启experiment实验特性，配置metrics-addr，如容器创建耗时等指标
  • kube-proxy: 默认127暴露，10249端口，写入iptables规则的耗时等指标
  • kube-state-metrics: K8S 官方项目，采集pod、deployment等资源的元信息。
  • node-exporter: Prometheus 官方项目，采集机器指标如 CPU、内存、磁盘。
  • process-exporter: 采集进程指标
  • 其他业务的exporter，如我们的服务自己暴露了metrics，由prometheus自己去抓取 ```yaml

    kong服务使用prometheus暴露metrics

  • job_name: prometheus static_configs:
    • targets:
      • kong.kong:8001

基于springboot暴露的metrics

  • job_name: ‘cmdbPrometheus’ scrape_interval: 5s metrics_path: ‘/actuator/prometheus’ static_configs:
    • targets:
      • ‘cmdb-service.sky:8582’

```

黄金指标

  • 延迟
  • 流量
  • 错误数
  • 饱和度

实际操作中可以使用Use或Red方法作为指导，Use用于资源，Red用于服务

  • Use方法：Utilization、Saturation、Errors。如 Cadvisor 数据
  • Red 方法：Rate、Errors、Duration。如 Apiserver 性能指标

Prometheus采集中常见的服务分三种：

  • 在线服务：web服务、数据库等，一般关心请求速率，延迟和错误率即RED方法
  • 离线服务：如日志处理、消息队列等，一般关注队列数量、进行中的数量，处理速度以及发生的错误即USE方法

  • 批处理任务：按计划运行的任务，如持续集成就是批处理任务，对应K8s中的job或cronjob，一般关注所花的时间、错误数等，使用pushgateway

    采集LB后面的RS的Metrics

  • RS 的服务加 Sidecar Proxy，或者本机增加 Proxy 组件，保证 Prometheus 能访问到。

  • LB 增加 /backend1 和 /backend2请求转发到两个单独的后端，再由 Prometheus 访问 LB 采集。

    Prometheus大内存的问题

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

单机版

  • Prometheus 的内存消耗主要是因为每隔2小时做一个 Block 数据落盘，落盘之前所有数据都在内存里面，因此和采集量有关。
  • 加载历史数据时，是从磁盘到内存的，查询范围越大，内存越大。这里面有一定的优化空间。
  • 一些不合理的查询条件也会加大内存，如 Group 或大范围 Rate。

优化方案：

  • 如果sample超过200万，不要使用单例，做下分片，然后通过Victoriametrics，Thanos，Trickster等方案合并数据
  • 评估哪些Metrics和Label占用较多，去掉没用的指标。
  • 查询时尽量避免大范围的查询
  • 如果需要关联查询，先想想能不能通过relabel的方式给原始数据加多个Label，一条sql能查出来不要用join

内存占用分析：

  • pprof

    容量规划

  • 单机Prometheus，计算本地磁盘使用量

  • 如果是Remote-write,和已有的Tsdb共用即可
  • 如果是Thanos方案，本地磁盘可以忽略（2H）,计算对象存储的大小就可以

估算本地磁盘大小: 磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小

保留时间(retention_time_seconds)和样本大小(bytes_per_sample)不变的情况下，如果想减少本地磁盘的容量需求，只能通过减少每秒获取样本数(ingested_samples_per_second)的方式。

  • 减少时间序列的数量
  • 增加采集样本的时间间隔

    考虑到Prometheus会对时间序列进行压缩，因此减少时间序列的数量效果更明显

以上磁盘容量并没有把WAL文件算进去，wal文件(raw DATA)在prometheus官方文档中说明至少会保存3个 Write-Ahead-Log Files，每一个最大为128M

Prometheus为了防止丢失暂存在内存中的还未被写入磁盘的监控数据，引入了WAL机制。WAL被分割成默认大小为128M的文件段（segment），之前版本默认大小是256M，文件段以数字命名，长度为8位的整形。WAL的写入单位是页（page），每页的大小为32KB，所以每个段大小必须是页的大小的整数倍。如果WAL一次性写入的页数超过一个段的空闲页数，就会创建一个新的文件段来保存这些页，从而确保一次性写入的页不会跨段存储。

如果使用thanos方案，本地磁盘只保留2H 热数据。Wal 每2小时生成一份Block文件，Block文件每2小时上传对象存储，本地磁盘基本没有压力。

对Apiserver性能的影响

如果你的 Prometheus 使用了 kubernetes_sd_config 做服务发现，请求一般会经过集群的 Apiserver，随着规模的变大，需要评估下对 Apiserver性能的影响，尤其是Proxy失败的时候，会导致CPU 升高。

慢查询问题

Prometheus 提供了自定义的 Promql 作为查询语句，在 Graph 上调试的时候，会告诉你这条 Sql 的返回时间，如果太慢你就要注意了，可能是你的用法出现了问题。

评估 Prometheus 的整体响应时间，可以用这个默认指标 prometheus_engine_query_duration_seconds{}

一般情况下响应过慢都是 PromQL 使用不当，或指标规划有问题

  • 大量使用koin
  • 范围查询是大的时间范围step却很小，导致查询到的数量过大
  • rate 会自动处理 counter 重置的问题，不要拿出来全部元素在程序中自己做rate计算

    Prometheus重启慢与热加载

    Prometheus重启时需要把WAL中的内容Load到内存里，保留时间越久、WAL文件越大，重启时间越长。

Prometheus提供了热加载能力，不过需要开启 web.enable-lifesysle 配置，更改完配置后，curl下reload接口即可。

Prometheus的预测能力

Prometheus的Deriv和Predict_linear方法可以满足预测，就可以基于设置合理的报警规则。

容器日志与事件

日志处理

  • 日志采集与推送：一般是Fluentd/Fluent-Bit/Filebeat等采集推送到 ES、对象存储、kafaka，日志就该交给专业的 EFK 来做，分为容器标准输出、容器内日志。

  • 日志解析转 metric：可以提取一些日志转为 Prometheus 格式的指标，如解析特定字符串出现次数，解析 Nginx 日志得到 QPS 、请求延迟等。常用方案是 mtail 或者 grok

    日志采集

  • sidecar 方式：和业务容器共享日志目录，由 sidecar 完成日志推送，一般用于多租户场景。

  • daemonset 方式：机器上运行采集进程，统一推送出去。

    知识链接

  1. 监控神器Prometheus用不对，也就是把新手村的剑