绝了!用 Prometheus 打造云原生监控,真的巨好用?

数字化转型背景下,随着轻量化的容器化技术和微服务应用的深度融合,业务复杂度随之上升。基于Prometheus的容器云监控体系成为目前主流容器监控事实标准,本文主要介绍Prometheus云原生监控体系,涵盖指标采集、数据存储、可视化展示,告警入库等功能,结合生产实践供大家参考。

一、监控对象

Prometheus监控范围覆盖IT基础设施层通用的服务器、中间件、数据库、容器/集群、服务可用性的指标,根据实际生产业务场景需要选择IaaS层、PaaS层、SaaS层监控指标包含但不限于以下内容。

监控对象

类型

监控内容

采集频率

IaaS层

物理机

服务器状态
主机/内存可用/使用率
CPU空闲/负载率
磁盘读写/IO/空间使用
文件系统空间/使用
带宽利用率

网络流量/重传/丢包/拥塞
网络时延等

秒级/分钟级

虚拟机

秒级/分钟级

PaaS层

数据库

集群状态

连接数(活跃/最大/当前/)

数据实例/对象/表空间/慢查询

Buffer/死锁
内存使用

负载

分钟级

中间件

状态

连接/请求数

会话数

分钟级

容器

运行时间

集群状态/网络流量
Node数量/状态/利用率
Pod数量/状态/重启次数等

Container数量/状态/利用率

资源对象使用情况

秒级

SaaS层

应用服务

服务可用性(http/https/tcp探测)

会话数/连接数/请求数
应用响应时间
进程状态
4XX/5XX 状态码占比

秒级/分钟级

1、采集探针

根据采集对象区分,需要在不同节点上部署采集探针,根据采集对象的不同需要在各节点上部署的探针也会有所区别;其中服务器是每个节点需要部署,其它采集对象如数据库、中间件、进程、容器等根据各节点上实际情况部署对应采集探针。

常见采集探针部署实例:

2、采集指标

以服务器基础资源采集node_exporter为例,采集探针通过标准的http协议暴露指定端口9100,通过pull或者pushgateway模式拉取、推送指标数据至Prometheus Server层。

基础资源指标示例:curl localhost:9100/metrcis

# TYPE node_cpu_seconds_total counternode_cpu_seconds_total{cpu="0",mode="idle"} 5.76669737e+06node_cpu_seconds_total{cpu="0",mode="iowait"} 4.48node_cpu_seconds_total{cpu="0",mode="irq"} 0node_cpu_seconds_total{cpu="0",mode="nice"} 1055.58node_cpu_seconds_total{cpu="0",mode="softirq"} 2413.11# TYPE node_disk_info gaugenode_disk_info{device="dm-0",major="252",minor="0"} 1node_disk_info{device="nbd0",major="43",minor="0"} 1node_disk_info{device="nbd1",major="43",minor="32"} 1node_disk_info{device="nbd10",major="43",minor="320"} 1node_disk_info{device="nbd11",major="43",minor="352"} 1node_disk_info{device="nbd12",major="43",minor="384"} 1node_disk_info{device="nbd13",major="43",minor="416"} 1
MySQL 数据库指标实例:curl localhost:9104/metrics
# TYPE mysql_global_variables_sync_master_info gaugemysql_global_variables_sync_master_info 10000# TYPE mysql_global_variables_sync_relay_log gaugemysql_global_variables_sync_relay_log 10000# TYPE mysql_global_variables_sync_relay_log_info gaugemysql_global_variables_sync_relay_log_info 10000# TYPE mysql_global_variables_table_definition_cache gaugemysql_global_variables_table_definition_cache 1400# TYPE mysql_global_variables_table_open_cache gaugemysql_global_variables_table_open_cache 2000# TYPE mysql_global_variables_table_open_cache_instances gaugemysql_global_variables_table_open_cache_instances 16# TYPE mysql_global_variables_thread_cache_size gaugemysql_global_variables_thread_cache_size 9# TYPE mysql_global_variables_thread_stack gaugemysql_global_variables_thread_stack 262144# TYPE mysql_global_variables_tmp_table_size gaugemysql_global_variables_tmp_table_size 1.6777216e+07# TYPE mysql_global_variables_transaction_alloc_block_size gaugemysql_global_variables_transaction_alloc_block_size 8192

3、Prometheus Server 服务端配置

1)服务器监控

  - job_name: 'node'   metric_path:/metrics   scheme: http   scrape_interval: 30s   scrape_timeout: 20s    file_sd_configs:     - files: ['/prom/targets/node.yml']      refresh_interval: 30s

配置说明:其中Job_name代表一系列采集 target 集合,scrape_timeout表示抓取超时判断,它的设定应小于scrape_interval,否则会报逻辑错误。抓取对象采用基于文件的服务发现机制file_sd_configs,其中files表示文件内容如下,refresh_interval表示刷新频率。

- labels:    system: 演示平台    serverType: 虚拟机  targets:   - 192.168.0.1:9100  - 192.168.0.2:9100  - 192.168.0.3:9100  - 192.168.0.4:9100
说明:labels 字段用键值对形式标识时序数据,便于后续检索使用,targets 字段是实际监控对象集合,暴露端口默认为9100,可根据情况在采集侧指定为任何合法端口。

二、监控可视化

Grafana 作为 Prometheus 的可视化组件,提供了丰富的客户化面板,如时序面板(折线图、散点图、面积图等)、表格、仪表板、链路图、统计数据、柱状图、饼状图等多维度呈现监控指标。

1、数据源

对接 prometheus 数据源

2、资源概览图

基础资源概览图呈现当前监控对象整体概览,CPU负载,内存使用率,磁盘使用率等核心关键指标信息

K8s 的 pod 资源概览信息

基于命名空间的资源对象统计信息

支持基于时间范围的检索

3、用户权限管理

Grafana用户权限部分有 user,team,role,org的概念,

  • org 对应类似租户的概念,可以对接不同数据源,是一个比较大的概念。
  • role 根据需要分为admin,editor,viewer 三种不同操作权限。
  • team 是用户组的概念,一组相同权限用户组成的概念组。
  • user 是基本用户概念,与team、role、org 关联

三、告警管理

1、告警规则

示例:内存使用率过高

====================================================== - alert: 内存使用过高    expr: 100 -(node_memory_MemAvailable_bytes{project='xx'} / node_memory_MemTotal_bytes{project='xx'}) * 100 > 98    for: 5m     labels:      severity: 紧急      type: 服务器    annotations:      summary: '{{$labels.mountpoint}} 内存使用率过高!'      description: '{{$labels.mountpoint }} 内存使用大于98%(目前使用:{{ printf "%.2f" $value }}%)'
- alert: 磁盘使用过高 expr: 100-(node_filesystem_free_bytes{fstype=~'ext4|xfs'}/node_filesystem_size_bytes {fstype=~'ext4|xfs'}*100) > 92 for: 5m labels: severity: 严重 type: 服务器 annotations: summary: '{{$labels.mountpoint}} 磁盘分区使用率过高!' description: '{{$labels.mountpoint }} 磁盘分区使用大于92%(目前使用:{{ printf "%.2f" $value }}%)'=========================================================
  • alert 为告警名称
  • expr 为告警表达式,就是具体的规则定义
  • for 为告警等待时长,多久判定为告警
  • lables 是自定义告警标签,如本例中告警级别和告警类型,可以通过路由机制,过滤不同标签发送指定组接收
  • annotations 告警描述,发送告警的具体信息

2、告警状态

Prometheus 告警状态有三种状态:Inactive、Pending、Firing。

  • Inactive:非活动状态,表示正在监控,但是还未有任何警报触发。
  • Pending:表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音,所以等待验证,一旦所有的验证都通过,则将转到 Firing 状态。
  • Firing:将警报发送到 AlertManager,它将按照配置将警报的发送给所有接收者。一旦警报解除,则将状态转到 Inactive,如此循环。

3、告警发送

Promehteus支持多种主流类型告警媒介,如邮箱、钉钉、企业微信、运营商短信等,也可以使用webhook自定义接口来实现。

告警信息示例如下:

==========异常告警==========[告警系统]:**运维系统[告警对象]:服务器[告警级别]:一般[告警时间]:2023-07-13&nbsp08:58:52[告警实例]:127.0.0.1:9100[告警内容]:内存使用大于85%(目前使用:85.42%)[来自***运维系统准生产测试]

还不过瘾?还想系统了解监控体系及可观测系统?10月26-27日,GOPS 全球运维大会 2023 · 上海站,云原生、可观测性、SRE,运维转型,就来 GOPS 就对啦!

长按图片二维码更精彩

近期好文:

数字化浪潮,数据中心场景下的数字孪生该如何探索与实践

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118。

点个“在看”,一年不宕机

标签

发表评论