Prometheus监控

2019独角兽企业重金招聘Python工程师标准>>>

Prometheus是基于时间序列数据库的开源监控告警方案，采用主动拉取模式进行数据采样，并提供强大的查询语法。CNCF基金会第二成员，亦是K8S中的主流监控方案。

架构

优点

外部依赖少，性能优秀，部署方便
完善的数据模型，丰富的插件集成
提供强大的查询语言

模块构成

Server：核心服务模块，采样并存储时间序列数据（默认管理面板端口9090）
- Retrieval 采样模块
- Storage 存储模块
- PromQL 查询模块
PushGateway(可选组件)：数据网关代理模块，采样数据临时存储，与server通信
Export：数据导出模块，导出服务监控数据。
Alertmanager：告警模块。接受prometheus上出发alertrules的告警，合并去重聚合处理，并发送出去（支持企业微信，邮箱，钉钉，webhook等等）
Grafna：比Prometheus原生UI更强大的可视化界面（类似于Kibana的可视化分析平台），更专注于服务器及应用性能的分析，如CPU、内存、流量等等的图表分析

时间序列

若干标签关联下的指标采样值，随着时间维度的推进，构成一条时间序列
命名规范：应用名称 _ 监测对像 _ 数值类型 _ 单位，比如http_request_total
所有指标值采用float64类型存储

图表类型

Counter：计数值，只增不减
Gauge：常规数值，可增可见
Histogram：直方图
- xxx_bucker{le="上边界"}：时间序列分桶聚合
- xxx_sum：值累计
- xxx_count：次数累计
Summery：类似于Histogram，支持quantiles（即按百分比取采样值）
- xxx{quantile="边界"}：
- xxx_sum：值累计
- xxx_count：次数累计

Exporter

常用Exporter

cAdvisor：K8S默认所有主机部署cAdvisor（高版本不再默认），用于提供容器相关的性能指标数据
node_exporter：主机层次的指标数据，cpu、内存、磁盘等
nginx_exporter：nginx指标输出

自动监控

已实现采样接口逻辑的资源，可通过annotation标签自动将其加入监控

Pod资源
- prometheus.io/scrape=true
- prometheus.io/path=/metric
- prometheus.io/port=8080
Service资源
- prometheus.io/probe
Endpoint资源
- prometheus.io/scrape
- prometheus.io/path
- prometheus.io/port

配置

主配置

global: #服务端全局配置
  scrape_interval: 10s #采集周期
  scrape_timeout: 10s
  evaluation_interval: 10s #rule计算周期

rule_files: #报警规则设置
  - "/etc/prometheus-rules/*.rules"

scrape_configs: #监控资源配置
  - job_name: 'prometheus' #server自身监控
    static_configs:
      - targets: ['localhost:9090'] #默认采集路径是/metrics上开放的端口服务
 - job_name: node #主机资源监控
   static_configs:
     - targets: ['localhost:9100']
 - job_name: 'kubernetes-node-exporter'
   tls_config:
     ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
   bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
   kubernetes_sd_configs:
     - role: node
   relabel_configs:
     - source_labels: [__address__]
       regex: '(.*):10250'
       replacement: '${1}:10255'
       target_label: __address__

关于relabel_configs配置

用于在目标被采集之前重写其标签集合
目标采集前自动追加的标签
- job：值为job_name
- _ address _：采集目标的主机端口地址
relabel期间额外提供了__meta_前缀的标签（服务发现机制提供的标签）
relabel操作结束后自动追加的标签
- instance：设置为__address__标签值（如果relabel期间未配置）
- _ scheme _：采集请求的协议
- _ metrics_path _：采集请求的路径
- _ param< name >：设置为采集请求url参数中的name字段值
relabel操作结束后__前缀的标签被自动清除

标签操作

replace：针对source_labels正则匹配，赋值target_label为replacement值（正则匹配失败则不操作）
keep：丢弃source_labels正则不匹配的采集目标
drop：丢弃source_labels正则匹配的采集目标
labelmap：映射正则匹配标签的值到replacement指定的标签上
labeldrop：剔除掉正则匹配的标签
labelkeep：仅保留正则匹配的标签

相关配置字段

action：指定标签操作类型（默认replace）
separator：配置分隔符（默认为；）
source_labels：指定源标签（可多个标签通过分隔符级联）
target_label：指定目标标签用于结果存储
regex：指定正则（针对source_labels去匹配，默认为 (.*)）
replacement：replace操作中替换掉正则匹配的部分（默认为$1）

告警配置

groups:
- name: test-rule
  rules:
  - alert: KubeCPUOvercommit
	expr: sum(kube_resourcequota{job="kube-state-metrics",resource="requests.cpu",type="hard"})
	  / sum(node:node_num_cpu:sum) > 1.5
	for: 5m
	labels:
	  severity: warning
	annotations:
	  message: Overcommited CPU resource request quota on Namespaces.

查询语言

http_requests_total{method=”POST”, code="200"} #标签过滤
count(http_requests_total) #时间序列统计
rate(http_requests_total[1m]) #最近一分钟每秒请求量

安装

服务编排方案 采用开源方案：https://github.com/giantswarm/kubernetes-prometheus

针对国内具体场景做了调整：https://github.com/maifusha/kubernetes-prometheus (feature/optimize分支)

调整监控仪表盘
增加了企业微信通知的支持
升级部分服务组件版本，修复Bug
修改各组件服务开放模式为ClusterIP
各服务组件数据持久化调整至宿主机/data目录
其他等等

Helm编排方案

变更配置不方便，尤其是Prometheus系统栈配置较多
适合于快速启动的测试

功能使用

Prometheus

status->targets：反映监控目标的数据采集健康状态
配置重载：请求/-/reload接口

Grafana

修改默认账号admin:admin
安装饼图插件

	grafana-cli plugins install grafana-piechart-panel