架构
![]()
优点
- 外部依赖少，性能优秀，部署方便
- 完善的数据模型，丰富的插件集成
- 提供强大的查询语言
模块构成
- 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资源
- 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
grafana-cli plugins install grafana-piechart-panel
AlertMagager
