Prometheus监控

架构

优点

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

模块构成

• 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 

AlertMagager