背景

通过在k8s集群内搭建prometheus对k8s集群进行监控，主要包括以下模块

• node-exporter监控物理机资源
• cadavisor、kube-state-metrics监控容器资源
• kubelete
• apiserver
• etcd
• controller manager
• kube-proxy
• 应用程序容器自身暴露的metrics

但随着集群规模的增大，抓取的监控指标越来越多，prometheus容器开始经常出现oomkilled的问题，导致prometheus几乎不可用，无限增大分配给prometheus容器的内存终究不是最终的解决方案，现将自己解决这个问题的思路给大家分享一下，希望能够对你有所帮助！

解决方案

• 拆分抓取任务

最初数据抓取量不大时，单个prometheus就可以完成对背景介绍中几个模块的数据的抓取，即所有的job都在一个prometheus中进行配置，但随着集群规模的增大，个别job的数据抓取量变得非常庞大，导致oomkilled之后所有的任务都会受到影响，所以可以通过查询每个job的数据量，对抓取任务进行拆分，将他们分散到多个prometheus中去完成任务的抓取

# 查看job数据抓取量
sort_desc(sum(scrape_samples_scraped) by (job))

• 过滤抓取指标

将prometheus拆分成多个之后，监控数据分散在了多个不同的位置，如何方便的查询就又成了一个新的问题，这个就可以使用prometheus的联邦模式（FEDERATION）将多个Prometheus中的监控数据归集到一起，但是需要注意的是，归集时只去抓取需要的监控指标，尽量的精简，全量抓取同样会导致之前的问题，而且这对抓取端与被抓取端来说，都是很大的压力

# 联邦配置，只抓取需要的指标

- job_name: prod-k8s-node
  honor_labels: true
  honor_timestamps: true
  params:
    match[]:
    - node_cpu_seconds_total
    - node_filesystem_avail_bytes
    - node_filesystem_size_bytes
    - node_memory_Cached_bytes
    - node_memory_MemFree_bytes
    - node_memory_MemTotal_bytes
    - node_processes_max_processes
    - node_processes_threads
    - node_systemd_unit_state
    - node_timex_estimated_error_seconds
    - process_max_fds
    - process_open_fds
  scrape_interval: 1m
  scrape_timeout: 1m
  metrics_path: /federate
  scheme: http
  static_configs:
  - targets:
    - 127.0.0.12:9090

• 调整数据落盘时间

prometheus抓取到的监控数据在落盘之前都是存储在内存中的，所以适当的减小数据落盘时间可以减小内存的压力

storage.tsdb.max-block-duration	设置数据块最小时间跨度，默认 2h 的数据量。监控数据是按块（block）存储，每一个块中包含该时间窗口内的所有样本数据（data chunks)
storage.tsdb.min-block-duration	设置数据块最大时间跨度，默认为最大保留时间的 10%

# 通过在promethe启动参数中设置相应参数来调整
./prometheus \
--web.listen-address=:9090 \
--web.external-url=http://0.0.0.0:9090/ \
--web.enable-admin-api \
--storage.tsdb.min-block-duration=1h \
--storage.tsdb.max-block-duration=1h \
--storage.tsdb.retention=30d

总结

以上就是我在处理Prometheus频繁oomkilled问题的解决方案，希望能对你有所帮助，后面会更新背景介绍中几个模块任务的抓取任务配置方式，欢迎关注！

欢迎关注我的个人微信公众号，一个菜鸟程序猿的技术分享和奔溃日常