前言:
此时大家对“centos7yumlnmp”大概比较关心,你们都需要了解一些“centos7yumlnmp”的相关知识。那么小编也在网络上网罗了一些对于“centos7yumlnmp””的相关文章,希望咱们能喜欢,看官们一起来学习一下吧!大家好,我是小斐,上接前文,谈了下基于Prometheus监控SNMP搭建和部署:Prometheus + Grafana搭建IT监控报警最佳实践(1),还是看不惯阿里云分享技术没干货,引导去使用阿里云SNMP监控,然后看了下阿里云SNMP监控模版,我觉得不符合自己的需求。相对于授人以鱼,我更喜欢授人以渔,那些讲大道理的人都是光正伟岸的,讲具体怎么做的人,才是真正愿意帮你的,这篇文章展开说明下Prometheus和采集器参数解释,以及疑问解答。
疑问解答为什么不用docker部署?有一定的docker学习成本,因部署较复杂,配置文件和参数需要经常修改,docker需要挂载本地目录配置文件到docker容器中,适合对docker熟悉用户部署,熟悉的用户可以看我知乎。Grafana使用二进制源码安装,systemd服务没有?更换yum(CentOS)或者apt(Ubuntu)安装Linux内核避免?有些内核容器导致snmp_exporter和node_exporter莫名重启,更换推荐内核。模版和参数文件如何获取?直接私信我
添加Grafana使用apt和yum安装方式:
# Ubuntu grafana安装最新稳定版本echo "deb [signed-by=/usr/share/keyrings/grafana.key] stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.listsudo apt-get updatesudo apt-get install grafana-enterprise# CentOS grafana安装最新稳定版本sudo vim /etc/yum.repos.d/grafana.repo[grafana]name=grafanabaseurl=*beta*# 安装sudo yum makecachesudo yum install grafana-enterprise
Prometheus参数说明
Prometheus基础架构:
说明下Prometheus Server服务器配置文件参数,真正分析Prometheus,知其然也知其所以然。什么是Prometheus?我个人的理解,就是保存时间戳的数据指标,然后按照数据指标编写PromQL来实现任意趋势信息。
Prometheus原生内置TSDB存储,数据为时间序列数据,什么是时间序列数据?
是在不同时间上收集到的数据,用于所描述现象随时间变化的情况。这类数据反映了某一事物、现象等随时间的变化状态或程度。
Prometheus 所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB):属于同一指标名称,同一标签集合的、有时间戳标记的数据流。除了存储的时间序列,Prometheus 还可以根据查询请求产生临时的、衍生的时间序列作为返回结果。
指标暴露:pull方式和push方式,这是两种指标抓取的模型,一个是主动,一个被动,参考系是基于Prometheus主动抓取还是被动接收。
总结下(抄来的,很容易懂):
一个团队通常会运行一个或多个 Prometheus 服务器,这些服务器构成了 Prometheus 监控的核心。Prometheus 服务器可以配置为使用服务发现机制(如 DNS、Consul、Kubernetes 等)来自动发现一组指标源(所谓的目标),然后 Prometheus 通过 HTTP 定期从这些目标中以文本格式抓取指标,并将收集到的数据存储在本地时序数据库(TSDB)中。
抓取的目标可以是一个直接暴露 Prometheus 指标的应用程序,也是可以是一个将现有系统(比如 MySQL)的 metrics 指标转换为 Prometheus 指标标准格式的中间应用(也就是我们说的 exporter),然后 Prometheus 服务器通过其内置的 Web UI、其他仪表盘工具(比如 Grafana)或者直接使用其 HTTP API 来提供收集到的数据进行查询。
另外我们还可以配置 Prometheus 根据收集的指标数据生成报警,但是 Prometheus 不会直接把报警通知发送给我们,而是将原始报警转发到 Alertmanager 服务,Alertmanager 是作为单独的服务运行的,可以从多个 Prometheus 服务器上接收报警,并可以对这些报警进行分组、汇总和路由,最后可以通过 Email、Slack、PagerDuty、企业微信、Webhook 或其他通知服务来发送通知。
prometheus.yml配置文件说明:
# 全局配置global: scrape_interval: 15s # 设置数据采集间隔每次15s,如果不设置默认1分钟 evaluation_interval: 15s # 评估告警规则每次15s,如果不设置默认1分钟 scrape_timeout: 10s # 设置全局采集超时默认10s,如果job中设置,忽略全局 external_labels: # 外部系统标签,不是用于metrics数据,高可用集群中,thanos必须使用该标签进行区分不同实例 monitor: "it-monitor"
# 告警插件配置alerting: alertmanagers: # 启用alertmanager - static_configs: # 静态配置alertmanager对象 - targets: # 运行altermanager服务的服务器IP或者FQDN - 172.17.40.51:9093
# 按照设定参数进行扫描加载,用于自定义报警规则,其报警媒介和route路由由alertmanager插件实现rule_files: # 报警规则文件路径,这里使用了*匹配rules目录下的所有报警规则文件 - "/opt/monitor/prometheus/rules/*.yml" # - "second_rules.yml"
# 配置采集数据源信息scrape_configs: - job_name: "prometheus" # 定义job名称 metrics_path: /metrics # 指标数据接口路径 scheme: http # 数据访问接口采用http还是https协议 static_configs: # 静态注册 # 配置目标主机地址 - targets: ["172.17.40.51:9090", "172.17.40.51:9100"] # 重新修改标签的配置 relabel_configs: - source_labels: [ '__address__' ] target_label: 'instance' regex: "(.*):(.*)" replacement: $1
下面重点讲解下采集数据源信息的配置:
服务注册:
被监控的对象或服务在Prometheus中是以一个job方式存在,被监控服务的所有实例在 Prometheus中是一个target的存在,所以被监控服务的注册就是在Prometheus中注册一个job和其所有的target,这个注册分为:静态注册和动态注册。
如监控多个对象或不同服务,job需要如下定义:
# 配置多个job模式scrape_configs: - job_name: "prometheus" # 定义job名称 ...... - job_name: "job_object01" ...... - job_name: "jobs_object02"
每个job中需要定义相关参数和target信息:
# 常规配置scrape_configs: - job_name: "job_object" # 定义job的名称 metrics_path: /metrics # 定义job的指标路径 scheme: http # 定义指标数据通过什么协议抓取:http/https scrape_interval: 10s # 定义抓取时间间隔 scrape_timeout: 10s # 定义抓取超时时间 static_configs: - targets: ["172.17.40.51:9090", "172.17.40.51:9100"] relabel_configs: - source_labels: [ '__address__' ] target_label: 'instance' regex: "(.*):(.*)" replacement: $1
静态注册:静态的将服务的IP和抓取指标的端口号配置在prometheus.yml文件的scrape_configs配置下,如上所示,就是注册一个名为job_object的服务,服务下有两个实例,暴露的抓取地址为:172.17.40.51:9090和172.17.40.51:9100。
动态注册: 动态注册就是在prometheus.yml文件的scrape_configs配置下配置服务发现的地址和服务名,Prometheus会去该地址,根据你提供的服务名动态发现实例列表,在Prometheus中,支持consul,DNS,文件,K8s等多种服务发现机制。基于文件的服务发现:
# 常规配置- job_name: "job_object02" metrics_path: /metrics scheme: http scrape_interval: 10s scrape_timeout: 10s file_sd_configs: - files: - /root/monitor/prometheus/targets/node-*.yml refresh_interval: 2m
file_sd_configs只是服务发现协议的一种,Prometheus支持20多种服务发现协议。
relabel_configs主要是修改标签配置,在服务指标抓取之前,来对标签进行指定规则的重写,标签问题,后续单独开一篇,内容比较多。
至此完成Prometheus配置文件的基础解析,相信你现在也知道如何编写简单的配置文件了。
SNMP配置解析
前文介绍了如何部署SNMP Exporter采集网络设备配置信息,那其实了解SNMP Exporter的原理和生成器的配置文件使用,就可以很简单的完成一个网络设备的监控告警(SNMP),由于现网中还有绝大部分设备不支持telemetry,故还是采用传统的SNMP协议实现监控告警,采集网络设备整体架构如下:
前文已完成部署snmp_exporter,运行snmp_exporter,可以看到snmp_exporter二进制程序读取的配置文件为:--config.file=/opt/snmp_exporter/snmp.yml
系统服务配置文件如下:
[Unit]Description=snmp_exporterAfter=network.target[Service]ExecStart=/opt/snmp_exporter/snmp_exporter --config.file=/opt/snmp_exporter/snmp.ymlRestart=on-failure[Install]WantedBy=multi-user.target
而snmp_exporter采集的指标,采集哪些指标,指标数据如何显示,就在snmp.yml文件定义着;看到这里聪明的你肯定想到了,那我需要采集什么指标直接去修改定义snmp.yml文件就好了,你没有想错,就是这样的,但是想法很美好,现实很骨感,snmp.yml里面的配置文件,真的不是人能看的,复杂且眼花缭乱,要写出这样的配置文件你肯定要累死,故开源作者提供了一个snmp.yml配置文件生成工具进行生成,只需要定义几个参数和你需要监控指标的OID。
那么我们接下来查看下配置文件生成工具如何使用,只要掌握这个工具,也就掌握Prometheus基于SNMP监控的应用。
前文已说明生成器源码通过Git拉下来,编译生成二进制可执行程序 generator,同时生成mibs文件夹,不一定要这个文件夹哦(可任意文件夹),后续通过环境变量设置临时编译查询路径。
配置生成器执行程序已完成编译,mib文件夹(mibs)也生成,现在就是编写generator.yml文件。
generator.yml配置文件结构说明:以华为交换机为例
modules: huawei_sw: # 自定义的模块名 huawei_sw walk: # 通snmpwalk方式遍历下面定义的OID - 1.3.6.1.2.1.2 # 设备指标OID - sysUpTime # 设备指标OID名称 ...... max_repetitions: 25 # 使用SNMP的GET/GETBULK请求对象树,默认25 retries: 3 # 重试失败请求的次数,默认3次 timeout: 5s # SNMP请求超时时间,默认5秒 version: 2 # SNMP版本 v2c 不建议使用v1,v3版本认证麻烦 v2c就够用 auth: # SNMP认证方式 v2c是团体名community v3版本有几个认证参数 community: public # 默认团体名public,建议自定义设置 # 只要指标有source_indexes,那么lookup的指标会以标签的形式插入该指标中 lookups: - source_indexes: [ifIndex] lookup: ifAlias #drop_source_indexes: false # 如果新的索引唯一,可以删除原来的索引 true # 允许按模块覆盖指标 overrides: ifAlias: ignore: true # 查找的指标在不以单独的指标输出到控制台 regex_extracts: # 根据正则表达式和指标值创建新指标 Temp: # 创建新的指标 ifAlias指标名改为Temp指标名称 - regex: '(.*)' # 从ifAlias返回的结果中提取一个值 value: '$1' # 值将被解析为float64数据类型,默认为 $1 #Status: # 创建新的指标ifAlias指标名改为Status指标名称 # - regex: '.*Example' # value: '1' # - regex: '.*' # value: '0' type: DisplayString # 覆盖指标的数据类型 可以理解为数据显示什么类型如String类型就是DisplayString
简单解释:
walk下就是寻找各厂商设备mib库中的OID或者名称,这些OID就是你需要监控的指标。lookups就是把lookup中的OID插入到以source_indexes为索引指标(OID)中。overrides就是把指标名进行修改的操作,如结合指标名和ignore不在控制台输出,结合regex_extracts就是根据规则生成新的指标,结合type可以指定指标输出的数据类型。
这么说可能没有很直观的体感,可以自行实验,或者那天直播讲解下。
那肯定有人问,我这边有很多网络设备,品牌型号以及版本都不一样,我如何定义多个类型的配置呢,其实就是在generator.yml里面定义多个模块即可。
# 定义多个模块modules: huawei_sw: walk: ...... lookups: ...... overrides: cisco_sw: walk: ...... lookups: ...... overrides: sangfor_ad: walk: ...... lookups: ...... overrides: ......
好了,到此就完成了generator.yml的文件编写,接下来执行生成器命令,生成snmp.yml文件。
# snmp.yml配置文件生成[root@snmp generator]# pwd/opt/snmp_exporter/generator[root@snmp generator]# ./generator generate
提示:上面mibs文件夹是放置交换机对应型号的mib库文件,关于网络设备的mib库文件来源,一般厂商都会提供,比如华为官网,思科官网,深信服可直接咨询售后。
将提取的 mib库文件放在 NetSNMP 可以读取的位置。默认读取:$HOME/.snmp/mibs,而我这里自定义了一个mib库文件夹,故需要设置临时环境变量,以提供NetSNMP可寻找到mib库文件:
# 设置NetSNMP临时环境变量export MIBDIRS=/opt/snmp_exporter/generator/mibs# 如果有多个文件夹,用冒号拼接export MIBDIRS=/opt/snmp_exporter/generator/mibs/huawei:/opt/snmp_exporter/generator/mibs/cisco
到此完成了snmp_exporter配置文件snmp.yml的生成,运行程序可看到定义的OID数据采集完成,如下图所示:
点击Submit,如果正常返回数据,那就说明一切OK。
错误提示:
指标值乱码?或者直接显示UTF-8 error等,查看type的数据类型是否设置错误没有数据?snmp_exporter进程状态,以及配置文件检查生成配置文件失败?mib库目录临时变量,模版文件格式出错,看报错提示,查找问题所在
根据上面的架构图,最后就是配置Prometheus去pull数据,网络设备的pull数据的配置方式已经在上一篇文章贴了出来。
简单总结
到此就完成基于Prometheus的监控SNMP的数据,后续在github上分享generator.yml的通用配置文件,方便IT运维和网工朋友们。
下一篇将分享下,Prometheus在Linux主机节点和Windows主机节点的最佳实践,以及在常见网络协议监控这一块的最佳实践。
知乎ID&微信公众号:网络小斐
标签: #centos7yumlnmp