prometheus监控

序章:做本专题讲座的内容简介
　　1.prometheus的整体框架图
　　　　this diagram illustrate the architecture of prometheus and some of its ecosystem components:
　　　　见图:普罗米修斯原理架构图
　　2.我们来谈谈监控对运维的重要性和地位
　　　　运维是什么?说白了就是管理服务器,保证服务器给线上产品提供稳定运行的服务环境(大米运维 系列课程 第一阶段有详细阐述运维在企业中的定位)
　　　　监控是什么?说白了就是用一种形式去盯着观察服务器,把服务器的各种行为表现都显示出来,用以发现问题和不足
　　　　报警是什么?监控和报警这两个词一定要分开说,分开理解!监控是监控,报警是报警。
　　　　监控是把行为表现展示出来,用来观察的报警则是当监控获取的数据发生异常并且到达了某个临界点的时候,采用各种途径来通知用户通知管理员通知运维人员甚至通知老板
　　　　很多时候总是把监控和报警混子一起说,这是不正确的,需要纠正
　　　　服务器集群->监控系统->报警系统->运维人员
　　3.我们先来谈谈监控都有哪些组成部分和流程
　　　　监控本身看的是数据,数据从哪里来
　　　　数据不是凭空从天上掉下来的,也不是研发人员主动给你的,只能是从运维数据采集来
　　　　数据采集本身就是一门大学问,不仅仅是为监控提供服务/分析用户行为/安全策略
　　　　数据采集是什么?数据采集的方式
　　　　服务器/网络设备/用户数据->产生行为和状态->数据采集=数据采集软件,数据采集脚本,数据采集硬件->监控系统
　　4.我们来看一个用prometheus+grafana的一个数据监控采集成图
　　　　prometheus数据采集后的成图
　　　　(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance) //(sum(increase(node_cpu[1m])) by (instance)))) * 100
　　　　execute -inset metric at cursor-
　　　　集联grafana这个强力的绘图工具后,更加美观和直观
　　　　prometheus+grafana成图
　　　　其实上下两个图都是来自于同一份采集数据,既不冲突 又大大提供利用率
　　5.我们来谈谈报警
　　　　报警跟监控 严格来说 是需要分开对待的 因为报警 也有专门的报警系统
　　　　报警系统 包括几种主要的展现形式: 短信报警,邮件报警,电话报警(语音播报),通讯软件
　　　　不像监控系统 比较成型的报警系统 目前大多数都是收费的 商业化
　　　　报警系统中 最重要的一个概念之一 就是对报警阈值的理解
　　　　阈值(trigger value),是监控系统中 对数据到达某一个临界值的定义
　　　　例如: 通过监控发现,当前某一台机器的CPU突然升高,到达了99%的使用率,99就是作为一次报警的触发阈值
　　6.我们来看一眼 本章节给大家即将讲到的一款 优秀的美国商业报警系统
　　　　pagerduty的年头不短了,在企业中,尤其是外企,出镜率非常高
　　　　虽然是收费监控,但是费用对于一个企业来说很便宜,甚至对于个人用户来说其实也不算高
　　　　pagerduty拥有短信,电话,邮件,所有的报警机制
　　　　pagerduty还有非常实用的必要的运维管理制度和报警升级等等扩展功能往后我们会陆续介绍的
　　　　pagerduty的优点非常多,使用率非常高(外企几乎清一色的使用,国内企业很多也在使用)
　　　　但是有优点就肯定也有不足
　　　　pagerduty有几个小问题 需要提高
　　　　对中文的支持不好 或者说几乎不友好 (指的是语音播报方面)=>那咱们为啥不多提高自己的英文能力
　　　　站点主要在美国和海外 网速有时候不太给力=>可以走代理的方式 加快速度
　　　　其他的问题 基本上没有了
　　7.最后 我们来谈谈prometheus相比其他老款监控的不可被替代的巨大优势,以及一些不足有待提高的地方
　　　　监控数据的精细程度 绝对的第一 可以精确到1~5秒的采集精度 我们来算算采集精度
　　　　集群部署的速度 监控脚本的制作 (指的是熟练之后) 非常快速 大大缩短监控的搭建时间成本
　　　　周边插件丰富 大多数都不需要自己开发了 
　　　　本身基于数学计算模型,大量的实用函数 可以实现很复杂规则的业务逻辑监控(例如QPS的曲线 弯曲 凸起 下跌的 比例等等模糊概念)
　　　　可以嵌入很多开源工具的内部 进行监控 数据更准时 更可信 (其他监控很难做到这一点)
　　　　本身是开源的,更新速度快,bug修复快。支持N多种语言做本身和插件的二次开发
　　　　图形很高大上 很美观 老板特别喜欢看这种业务图(主要是值更grafana的结合)
　　　　一些不足的地方
　　　　　　因其数据采集的精度 如果集群数量太大,那么单点的监控有性能瓶颈 目前尚不支持集群 只能workaround
　　　　　　学习成本太大,尤其是其独有的数学命令行(非常强大的同时 又极其难学 <<=自学的情况下),中文资料极少,本身的各种数学模型的概念很复杂 (如果没有人教 自己一点点学英文官网 得1-3个月入门)
　　　　　　对磁盘资源也是耗费的较大,这个具体要看监控的集群量和监控项的多少 和保存时间的长短
　　　　　　本身的使用 需要使用者的数学不能太差 要有一定的数学头脑(这个说真的 我觉得才是最难克服的)

第一讲:企业级运维监控理论基础

0.概要

监控在企业中的重要性
监控在运维工作中的比重
数据采集的重要性
运维监控种类的大题分类
监控做不好的各种后果
监控做好了的各种好梦

1.监控在企业中的重要性

追溯到监控不发达的时代,那时候 基本属于一个 出行基本靠走,安全基本靠狗
记得在2006年 我刚刚开始做运维的时候,哪里有什么自动化监控的概念
至少都得是人工盯着(不至于靠狗)
服务器大概是2,3台的样子 记不清楚了
放在一个比较简陋的机房里(说机房 不如说就是个不用的仓库)
所以服务器 都接着单独的显示器运行着
每天上班第一件事 就是走进去巡视一下,看看各种软件打印出来的输出信息 是否有报错 如果有 就那个excel记录一下,再发邮件给老板...
想起来都觉得 臊得慌(比较原始)
------
不过其实在那个年代 也是没有办法 运维本身就很原始,各种运维技术都处于拓荒的阶段
如今的企业中 动不动运维就要负责 成百上千 甚至上万台机器 (之前在一家公司 维护过近30000+服务器 虚拟机+物理机 横跨美国7个州)
没有高大上的方法 是绝对支撑不起来这种规模的监控的
服务器随时随地 都有可能出故障,出问题,需要被监控住
不管是虚拟机还是物理机 还是各种软件,各种线上产品,操作系统,网络设备,办公环境,业务数据,用户体验
说句夸张点的话: 现在连员工上个班 打卡机都弄个监控,打卡机自己本身可能会坏,打卡记录 还得被HR监控
各种监控啊~~~都是运维的事~~~
------
监控在企业中 扮演者重要的监督者的角色,任何一个地方出现问题 我们都需要及时的知道
很多情况下 企业对某种类型的监控 需要非常的敏感,例如用户正常访问 这种业务级别的监控
一旦出现了问题 需要在秒级时间 立刻知道,不然就是毁灭性的灾难和损失 尤其是针对那些大规模的企业
所以说 监控对于企业的重要性 不言而喻了

2.监控在运维工作中的比重

基础运维 主要扮演者是一个处理日常任务,及时救火 这样的角色
而监控的搭建和数据采集的工作 很多时候 需要依赖 运维开发的协助
在大米运维课堂 第一阶段前三节课中,有详细介绍各种运维职位的职责(没有看的同学 感兴趣的话 可以去回顾一下课程)
不管是哪一种运维(哪怕你是运维架构师 运维专家) 在紧急的时候 人人都要扮演起 救火英雄的角色
而救火 指的是 及时的发现和解决线上出现的各种故障 问题
那么为了要做到 及时的发现问题, 一个好的完善的监控系统 就很自然的作为 运维工作中的第一优先级任务
一个最理想的 完整的 监控体系的搭建 有赖于如下这个几个方面的工作 以及流程
见图:监控部署上线流程
------
值得一说的是,在大部分的企业中,都无法做到 如上图的如此完善的监控创作体制
很多时候 有些其实很重要的部分 却被当成可有可无 一带而过
我本人觉得 非常不可取的同时 也感到无奈
因为很多时候 客观因素的力量太强大了...事事完美无缺 难
(但是我们作为一个运维架构师 依然要有追求完美的信念)
接下来我们分别解释一下 监控流程中的这些部分的内容

2.1.监控系统设计(架构师):

首当其冲 就是压在运维架构师的肩膀上的任务
设计如果都设计不好,那么后面的事儿也是白干
设计部分包括如下的内容:
评估系统的业务流程 业务种类 架构体系
各个企业的产品不同,业务方向不同,程序代码不同,系统架构更不同
对于各个地方的细节 都需要有一定程度的认知 才可以开起设计的源头
分类出所需的监控大分类
一般可分为: 业务级别监控/系统级别监控/网络监控/程序代码监控/日志监控/用户行为分析监控/其他种类监控
大的分类 还有更多的细小分类
这里给出几个例子
例如:
业务监控 可以包含用户访问QPS,DAU日活,访问状态(http code),业务接口(登录,注册,聊天,上传,留言,短信,搜索),产品转换率,充值额度,用户投诉 等等这些很宏观的概念(上层)
系统监控 主要是跟系统相关的 基本监控项 CPU/内存/硬盘/IO/TCP链接/流量 等等(nagios-plugins,prometheus)
网络监控 (IDC)对网络状态的监控(交换机,路由器,防火墙,VPN) 互联网公司必不可少 但是很多时候又被忽略 例如: 内网之间(物理内网,逻辑内网 可用区 创建虚拟机 内网IP) 外网 丢包率 延迟 等等
日志监控 监控中的重头戏(splunk,ELK),往往单独设计和搭建,全部种类的日志都有需要采集(syslog,soft,网络设备,用户行为)
程序监控 一般需要和开发人员配合,程序中嵌入各种接口 直接获取数据 或者特定的日志格式
监控技术的方案/软件选取
各种监控软件层出不穷,开源的 商业的 自行开发的 几百种的可选方案
架构师凭借一些因素 开始选材
针对企业的架构特点,大小,种类,人员多少 等等 选取合适的技术方案
监控的人员安排
运维团队的任务划分,责任到人,分块进行
开发团队的配合人员选取,很多监控涉及的工作 都需要跟开发人员配合 才可以进行
2.监控系统的搭建
单点服务端的搭建
单点客户端的部署
单点客户端服务器测试
采集程序单点部署
采集程序批量部署
监控服务端HA/cloud
监控数据图形化搭建(grafana)
报警系统测试(pagerduty)
报警规则测试
监控+报警联合测试
正式上线监控
3.数据采集的编写
可选用脚本作为数据采集途径
例如: /shell/python/awk/lua(nginx安全控制,功能分类)/php/perl/go等等
shell: 运维的入门脚本,任何和性能/后台/界面无关的逻辑 都可以实现最快速的开发
python: 各种扩展功能 扩展库 功能丰富,伴随各种程序的展示+开发框架(如django)等 可以实现快速的中高档次的平台逻辑开发 目前在运维届 除去shell这个所有人必须会的脚本外,火爆程度就属python了
awk: 本身是一个实用命令 也是一门庞大的编程语言,结合shell脚本 或者独立 都可以使用,在文本和标准输出处理上 有很大的优势
lua: 多用于nginx的模块结合 是比较新型的一个语言
php: 老牌子的开发语言,在大型互联网开发中,目前有退潮的趋势 不过在运维中 工具开发还是很依赖PHP
perl: 传说中 对文本处理最快的脚本语言 (但是代码可读性不强)
go: 新型的语言 目前在开发和运维中 炒的很热 工资也高 在各种后端服务逻辑的编写上 开发速度快 成型早
作为监控数据采集,我们首推shell/python,如果说 数据采集选取的模式 对性能/后台/界面不依赖,那么shell速度最快 成本最低(公司往往喜欢快的)
数据采集的形式分类
一次性采集:例如我们使用比较简单的shell+crontab(ps ef|grep,netstat -an|wc)+crontab的形式 按10秒/30秒/一分钟 这样的频率去 单词采集
这种形式的优点=> 一次性采集的模式 稳定性较好 不容易出现各种错误和性能瓶颈,且开发逻辑简单 实现快速
这种形式的缺点=> 一次性采集 对于有些采集项目 实现起来不够智能 也不够到位 例如 日志的实时采集 (使用一次性采集 日志文件 200/5xx diff grep 也可以实现 但是很low 不够准确 不够直观)
后台式采集:采集程序以守护进程运行在后台,持续不断的采集数据:prometheus exporter 例如python/go开发的daemon程序 后台持续不断的采集
优点:后台采集程序 数据准确性高 采集密度精细 管理方便
缺点:后台采集程序 如果开发过程不够仔细 可能会出现各种 内存泄漏 僵尸进程 性能瓶颈的问题,且开发周期较长
桥接式采集:本身以后台进程运行 但是采集不能独立 依然跟服务器关联 以桥接方式收集采集数据
例如:NRPE for nagios
4.监控数据分析和算法
例如: 采集CPU的七种等待状态参数,采集用户每秒访问请求量QPS,对于这些"基本单位"的数据采集 本身是必须的 也是没有疑问的
但是这里有一个问题
采集回来的单位数据 如果没有懂行的人 将它们形成 监控公式 和 报警阈值
那采集数据就没有任何的意义了
按上面两个例子来举例:
cpu来举例:
如图:top命令状态
cpu采集回来的 平均负载数值,以及cpu的时间分布百分比nagios top
如果作为一个运维架构师 不懂得linux中cpu各种参数的深入原理
例如 平均负载时如何计算的,cpu的时间片分布式是如何分类的,什么叫作 用户态/内核态 CPU等待/处理时间 什么是 interuptable/uniteruptable cpu等待等等这些概念。那么即便数据被采集回来的再精细准确 你也利用不好
所以 这一点我给大家强调的是: 监控的数据分析和算法 其实非常依赖 运维架构师对linux操作系统的各种底层知识的掌握,(这也是其中一个 我推荐prometheus的原因)
如果 我们使用那种老式的傻瓜式的监控 如nagios,里面的监控脚本很全面,生成报警规则和阈值也很简单,缺点却显而易见: 监控的太粗糙 实用性不强，另外也不利于我们希望提高的同学
(例如:naigios监控中 对CPU高不高的监控判断 就依据一个 当前的load值 >5 就警告 >10就报警,我请问这种方式的CPU报警 有什么意义么?有利于我们通过监控找到真正的问题么？)
注:本阶段课程 主题是prometheus 我们可能没有过多的时间 给大家细讲linux系统模型和内核参数等等这些底层的优化知识,这些高级内容的具体学习 请参考大米运维课堂(系列课程) 第三第四阶段的高级课程
另外还有一个问题
例如业务级别监控的算法 运维自身无法做到十分专业
因为本身跟操作系统无关,是跟数据算法相关
举个例子:如果我想通过prometheus实现对用户访问qps的精确监控
那么对于监控图形曲线QPS上涨 QPS下跌 QPS凸起 QPS和历史数据的比较方法 等等这些 都属于业务级别的监控阈值类型
需要有专业的数据分析人员的协助 才可以算出优良的算法
例如: 如果我现在想针对当前QPS下跌率进行报警计算,那么用什么养的公式 针对我们的业务类型更贴切?
我是选择计算当前5分钟内的平均值当<-一个固定数值的时候 报警合适?
我是选择计算当前10分钟的总量然后和前一个小时同一时段比较合适？
我是选择计算当前一小时的平均值和过去一周内每一天的同一时段的时间比较合适?
.....
以此类推,这些数据算法 本身和linux无关,只有非常专业的数据计算团队 才可以给出一个最合理的算法 协助我们的报警规则
5.监控稳定测试
不管是一次性采集,还是后台采集,只要是在linux上运行的东西 都会多多少少对系统产生一定的影响
稳定性测试 就是通过一段时间的单点部署观察 对线上有没有任何影响
6.监控自动化
监控客户端的批量部署,监控服务端的HA再安装,监控项目的修改,监控项目的监控集群变化
种种这些地方 都需要大量的人工
自动化的引进 会很大程度上 缩短我们对监控系统的维护成本
这里给出几个实例:puppet(配置文件部署),jenkins(CI持续集成部署),CMDB(运维自动化的最高资源管理平台和理念)...等等
利用好如上这几个聚的例子,就可以实现 对监控自动化的掌握
(自动化工具和编程 相关的学习 请参考 大米运维课堂 第二/三阶段的课程)
7.监控图形化工作
采集的数据和准备好的监控算法,最终需要一个好的图形展示 才能发挥最好的作用
监控的设计搭建需要大量的技术知识 但是对于一个观察者来说 往往不需要多少技术 只要能看懂图就好(例如 老板想看看 当前用户访问量状况 想看看 整体CPU高不高等等)
所以,监控的成图工作 也是很重要的一个内容
本阶段课程中,会详细介绍一个 很实用的高大上的图形集成工具=>> garafana的使用和搭建

第二讲:企业监控通用技术

介绍企业目前在监控上的发展阶段
介绍企业当前实用的通用技术和工具
企业监控目前面临的一些问题
介绍监控的最终理想化
1.介绍企业目前在监控上的发展阶段
早起企业监控(路远靠走 安全靠狗)
全部都是人工盯着 服务器 操作系统 软件 网络 等等
中前期企业 半自动脚本监控
利用shell脚本这种类型的形式,做最简单的监控脚本
循环登录机器 查看一些状态 之后人工记录
无报警 无自动化 无监控图形
中期企业 自动化程序/脚本/软件/监控
脚本更新换代 开始使用各种开源非开源软件 程序 进行监控的搭建和开发
监控形成图形化,加入报警系统,有一定的监控自动化实现
这个阶段监控开始逐步成型 但是仍然缺乏精确度和稳定程度 报警的精细度
中后期企业 集群式监控 各种外援监控方案
监控开始自成体系 加入各种自动化
除去自身开发和搭建监控系统外,还会大量使用各种外围监控(各种商品监控 例如云计算监控 友盟等等)
监控发展出 内监控 外监控 (内监控是企业自己搭建的自用监控,外监控是使用外援的商业监控产品 往往对产品的最外层接口和用户行为进行更宏观的监控)
当前和未来监控
根据目前的发展状况
未来的监控 主要会在几个方面 不断的提高
监控准确性 真实性
监控高度集成自动化 无人值守
监控成本的日益降低
监控和CMDB的集成化以及自愈系统的发展
2.介绍企业当前实用的通用技术和工具
脚本监控(当前依然使用最原始的 脚本运行的形式 采集和监控的公司 依然不在少数 很多时候是为了节约成本)
开源/非开源工具监控 如:nagios/cacti/icinga/zabbix/ntop/prometheus等等
报警系统: pagerduty/自建语音报警系统/自建邮件系统/自建短信童子/各种商业报警产品
3.企业监控目前面临的一些问题
监控自动化依然不够
很少能和CMDB完善的结合起来
监控依然需要大量的人工
监控的准确性和真实性 提高的缓慢
监控工具和方案的制定 较为潦草
对监控本身的重视程度 依然有待提高
4.介绍监控的未来最终理想化
未来理想中最完美的监控 我这里给出两个定义词汇
完整自愈式监控体系
监控和报警 总归还是只能发现问题。出现问题之后的处理 依然需要人工的大量干预
未来当自愈系统完善之后,各种层级的问题 都会被各种自动化 持续集成 人工智能 灾备 系统缓冲 等登技术自行修复
真实链路式监控
监控和报警的准确性 真实性 发展到最终极的一个理想化模型
举个例子:当系统发出报警信息后,往往是各个层级的报警 一大堆一起发出 把真实引起问题的地方掩盖住非常不利于我们即时的发现和处理问题
例如:真实发生的问题 是在于 数据库的一个新的联合查询 对系统资源消耗太大造成各个方面的资源被大量消耗 间接的就引起各种链路的问题
于是乎 各个层面的报警接踵而至,日志在报警,慢查询在报警,数据库cpu内存报警,程序层TCP链接堆积报警,HTTP返回码5xx 499报警
所有系统CPU 缓存报警,企业级监控用户流量下降报警
种种一堆一堆被连带出来的报警 全都暴露出来了,结果真正的背后原因 这一个祸根的DB查询反而没有被监控发现 或者说发现了 但是被彻底淹没了
最终理想的未来报警系统 可以把所有无关的报警全部忽略掉,以链路的方式 对问题一查到底 把最终引起问题的地方 报警出来 让运维和开发 即时做出响应和处理
这就是未来的终极化监控报警系统的构想。(这个理念说起来容易,实现起来非常难,需要大量的彻底的跟业务和代码结合起来,并且配合精密的前沿新算法以及所有运维
开发的功能努力,才有可能在未来的5-10年最终实现)

第三讲:prometheus监控入门简介

prometheus是什么?
prometheus能为我们带来什么
prometheus对于运维的要求
prometheus多图效果展示
1.prometheus是什么?
我们还是来先看看 官方对它的原始定义
prometheus是一个开源系统监控和报警的工具集合,由soundcloud创建(http://soundcloud.com),自从2012诞生之后,至今已经有许多公司和组织开始使用它了,
这个开源项目拥有大量的积极参与开发和建设的研发人员以及社区用户,目前已经是一个独立运行的开源的由各公司自行维护的监控项目。为了让项目更充实更清晰2016
年prometheus加入了cloud native computing fondation (CNCF),并且成为继kubernets(结合 容器/docker)之后 第二个加入该组织的成员
这个就是来自于官方的介绍
其中更多突出的 还是这个项目基于开源的和各种社区组织维护多重联合开发的这样一个特性
也就决定了这个项目必然是越来越好
当前最新的版本prometheus2.0也是近期刚推出不久,经过本人最近几个月的对最新版本的实践 各种之前遇到的问题 差不多都被修复了 而且性能更加稳定
(大米老师当前所在的企业 也是以prometheus作为核心监控,新版本运行 几个月来 没有出现过任何稳定和性能上的问题)
2.prometheus能给我们带来什么
之前在第二讲最后的部分 我们给大家推出了一个 最终的未来理想化监控
那么prometheus可以针对未来监控对于准确性和精确度的要求极大的贡献了自己的一份力量
为什么这么说呢?我们不能凭空判断,咱们用真实数据来说话
认识prometheus监控的优质特性
基于time series时间序列模型
时间序列(time series)是一系列有序的数据。通常是等时间间隔的采样数据
基于K/V的数据模型
Key/value这个键值得概念 咱们很熟悉
{ disk_size: 80G }
最大的好处就是数据格式简单速度快易维护开发
采样数据的查询 完全基于数学运算 而不是其他的表达式 并提供专有的查询输入console
这个特点很独特,所有的查询都基于数学运算公式 例如(增量(A)+增量(B)/总增量(C)>固定百分比
采用HTTP pull/push两种对应的数据采集传输方式
所有的数据采集 都基本采用http,而且分为pull push 推和拉两种方式去写采集程序 方便
开源,且大量的社区成品插件
这个非常厉害,很多prometheus社区开发的差距已经异常强大和完善
如果公司对监控要求不是特别高德话,默认的几个成品插件 装上就可以用到底了
监控成型速度太快了
push的方法 非常非常的灵活
pull push的方法 我们往后会具体介绍,这里提一句
push的这种采集方法 灵活程度超过你的想象 几乎任何形式的数据 都可以实现最快速的开发
本身自带图形调试
prometheus本身的就自带了现成的图形成型界面
虽然最终肯定不能更garafana的效果相比,但是这种自带图形成图 可以大大帮助运维做调试
最精细的数据采样
大多数市面上的开源监控 采样也就能精确到 半分钟 一分钟的程度
商品化监控产品就更别提了(为了缩小数据存储的成本)有的甚至5分钟就是采样最小间隔
prometheus理论上可以达到每1秒采集!!而且而已自行定制频率(不过强大的同时 其实大米不太建议细到这个程度因为数据量太大了如果1s采样一次)
最新的高大上监控 很霸气 面试很有料
呵呵 这个就比较个人主义了,运维面试的时候 监控方面 如果你懂得这么个高大上的工具,并且对各种监控算法 系统底层相关都很熟悉(prometheus逼着你必须熟悉底层)的话,优势很大
比较显著的特点就介绍到这里了
另外:咱们也不能盲目崇拜 也需要客观的对待prometheus
prometheus还是有一些不足 有待于改进
不支持集群化(这个是当前最迫切的需求)
被监控集群过大后 本身性能有一定瓶颈(如果有集群 就可以解决这个问题)
偶尔发生数据丢失(这个问题 在2.0之前 会偶尔发生几次,2.0之后貌似已经彻底解决 至少大米这几个月 没有看到丢失)
中文支持不好 中文资料也很少 (这个问题 也是老生常谈了 往往新的 很牛的国外工具 都不太支持中文)
3.prometheus对于运维的要求
要求对操作系统有很深入扎实的知识 不能只是浮在表面
对数学思维有一定的要求 因为它基本的内核就是数学公式
对监控的经验有很高的要求 很多时候 监控项需要很细的定制
4.prometheus各种图形展示
prometheus主界面
如图:普罗米修斯主界面
prometheus 数学查询命令行展示
rate(node_cpu[1m])
查询一分钟的cpu负载
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance)) //(sum(increase(node_cpu[1m])) by (instance)))) * 100(较复杂数学公式查询展示)
prometheus配置展示
fgaegag

第四讲:prometheus运行框架介绍

简单了解一下prometheus的框架结构
介绍一下prometheus的各种组件
1.框架结构的展示图
this diagram illustrates the architecture of prometheus and some of its ecosystem components:
prometheus server => retrieval storage promql => node hdd/ssd
这里是prometheus的服务器 也就是核心
prometheus本身是一个以进程方式启动,之后以多进程和多线程实现监控数据收集 计算 查询 更新 查询 的这样一个C/S模型运行模式
本身的启动很简单
./prometheus
如果不带参数的启动 不考虑后台运行的问题 那么prometheus默认启动痕更简单
解压缩之后
./prometheus即可 之后默认监听在9090端口 用来访问
接下来我们来看看prometheus的存储形式
这是一段来时官网的prometheus存储数据的介绍
prometheus includes a local on-disk time series database,but also optionally integrates with remote storage systems
- prometheus采用的是time-series(时间序列)的方式 以一种自定义的格式存储在本地硬盘上
- prometheus的本地T-S(time-series)数据库以每两小时为间隔来分block(块)存储,每一块中又分为多个chunk文件(我们以后会介绍chunk的概念),chunk文件是用来存放 采集过来的数据的T-S数据,metadata和索引文件(index)
- index文件是对metrics(prometheus中 一次K/V 采集数据 叫作一个metrics)和labels(标签)进行索引 之后存储在chunk中 chunk是作为存储的基本单位,index and metadata是作为子集
- prometheus平时是将采集过来的数据 先都存放在内存之后(prometheus对内存的消耗 还是不小的) 以类似缓存的方式 用于加快搜索和访问
- 当出现宕机时,prometheus有一种保护机制 叫作wal 可以将数据定期存入硬盘中 以chunk来表示,并在重新启动时 用以恢复进入内存
- 然后我们来看看大图的这个部分
service discovery => dns kubernetes consul ... custom integratic
这里讲的是prometheus可以集成的服务发现功能
例如consul
prometheus本身跟其他的开源软件类似 也是通过定义配置文件 来给prometheus本身规定需要被监控的项目和被监控节点
我们看下配置文件的模板
- jojb_name: \'test\'
static_configs:
- targets: [\'prometheus.server:9090\',\'web01:9090\']
配置文件中 规定了一个大的job的名字
之后 在这个jobs的名字下面 具体来定义 要被监控的节点 以及节点上具体的端口信息等等
那么如果prometheus配合了例如consul这种服务发现软件
prometheus的配置文件就不再需要人工去手工定义出来,而是能自动发现集群中 有哪些新机器 以及新机器上出现了哪些新服务 可以被监控
- 接下来我们来看看采集客户端的部分
short-lived jobs -> pushgateway -> pull metrics -> jobs/exporter
prometheus的客户端 之前给大家介绍过 主要有两种方式采集
pull主动拉取的形式 push被动推送的形式
pull:指的是客户端(被监控机器)先安装各类已有exporter(由社区组织或企业开发的监控客户端插件)在系统上之后,exporter以守护进程的模式运行并开始采集数据
exporter本身也是一个http_server可以对http请求作出响应 返回数据
prometheus用pull这种主动拉的方式(http_get)去访问每个节点上exporter并采样回需要的数据
push: pushgateway
指的是在客户端(或者服务端)安装这个 官方提供的pushgateway插件
然后,使用我们运维自行开发的各种脚本 把监控数据组织成k/v的形式 metrics形式 发送给pushgateway之后 pushgateway会再提送给prometheus
这种是一种被动的数据采集模式
- 最后 咱们来看下这个部分 报警的部分
push alerts -> alertmanager -> notify -> [pagerduty email ...]
prometheus本身并不具备报警的功能
只能通过第三方开源或者商业软件实现报警
<- [webUI grafana APIclients]
另外 这是指的是prometheus可以依赖很多方式二次绘制监控图形
本课程中 首推grafana

第五讲:prometheus数据格式介绍

prometheus metrics的概念
k/v的数据形式
prometheus exporter的使用(pull形式采集数据)
prometheus pushgateway的入门介绍(push形式采集数据)
- prometheus监控中,对于采集过来的数据 统一称为metrics数据
metrics,我们听到的太多了,熟悉大数据系统的不可能没听说过metrics,当我们需要为某个系统某个服务做监控、做统计,就需要用到metrics。
metrics是一种对采样数据的总称(metrics并不代表某一种具体的数据格式 是一种对于度量计算单位的抽象)
咱们来介绍一下metrics的几种主要的类型
gauges
最简单的度量指标,只有一个简单的返回值,或者叫瞬时状态,例如,我们想衡量一个待处理队列中任务的个数
用更简单的方式举个例子
如果我要监控硬盘容量或者内存的使用量,那么就应该使用gauges的metrics格式来度量
因为 硬盘的容量或者内存的使用量是随着时间的推移 不断的瞬时变化的
这种变化没有规律 当前是多少 采集回来的就是多少
既不能肯定是一直持续增长也不能肯定是一直降低
是多少就是多少,这种就是gauges使用类型的代表
CPU的上下浮动就是采集使用gauge形式的metrics数据没有规律 是多少就得到多少 然后显示出来
counters类型metrics
counters就是计数器,从数据量0开始累积计算 在理想状态下 只能是永远的增长 不会降低 (一些特殊情况另说)
举个例子来说
比如对用户访问量的采样数据
我们的产品被用户访问一次就是1 过了10分钟后 积累到100
过一天后 积累到20000
一周后 积累点 100000-150000
counter数据 是从0开始 一直不断的积累 累加下去的 所以理想状态下 不可能出现降低的状况
最多只可能是 一直保持不变 (例如 用户不再访问了,那么当前累积的总访问量 会以一条水平线的状态保持下去 直到 再被访问)
histogram
histogram统计数据的分布情况.比如最小值,最大值,中间值,还有中位数,75百分位,90百分位,95百分位,98百分位,99百分位,和99.9百分位的值(percentiles)。
这是一种特殊的metrics数据类型,代表的是一种近似的百分百估算数值
这个metrics种类 是最难理解的一种(但是很实用)估计大多数学员看了上面这几行定义头会很大
大米老师用一种更简单的方式来给大家做解释一下 什么是histogram数据
比如我们在企业工作中 经常接触这种数据
http_response_time HTTP响应时间
代表的是一次用户HTTP请求 在系统传输和执行过程中 总共花费的时间
nginx中的 也会记录这一项数值 在日志中 那么问题来了 我们做一个假设
如果我们想通过监控的方式 抓取当天的nginx access_log,并且想监控用户的访问时间我们应该怎么做呢?
同学们肯定很容易想到 简单啊 把日志的http_response_time 数值统统采集下来啊 然后计算一下总的平均值即可
那么大米要问大家一句了 假如我们采集到 今天一天的访问量 是100万次
然后把这100万次的http_response_time全都加一起然后除以100万最后得出来一个值
0.05秒 = 50毫秒
这个数据意义大么?
假如 今天中午1:00的时候 发生了一次线上故障 系统整体的访问变得非常缓慢 大部分的用户请求时间都达到了0.5~1秒作用 但是这一段时间 只持续了5分钟,总的一天的平均值并不能表现得出来 我们如何在1:00-1:05的时候 实现报警呢?
再举个例子:
就算我们一天下来 线上没有发生故障 大部分用户的响应时间 都在0.05秒 (通过 总时间/总次数取得出)
但是我们不要忘了 任何系统中 都一定存在 慢请求 就是有一少部分的用户 请求时间会比总的平均值大很多 甚至接近5秒 10秒的也有(这种情况很普遍 因为各种因素 可能是软件本身的bug 也可能是系统的原因 更有可能是少部分用户的使用途径中出现了问题)
那么我们的监控需要发现和报警这种少部分的特殊情况,用总平均能获得吗？
如果采用总平均的方式,那不管发生什么特殊情况,因为大部分的用户响应都是正常的你永远也发现不了少部分的问题
所以histogram的metrics类型 在这种时候就派上用场了
通过histogram类型(prometheus中 其实提供了一个 基于histogram算法的 函数 可以直接使用)
可以分别统计出 全部用户的响应时间中
<0.05秒的量有多少 1~0.05秒的有多少,>2秒的有多少>10秒的有多少
我们就可以很清晰的看到 当前我们的系统中 处于基本正常状态的有多少百分比的用户(或者是请求)多少处于速度极快的用户,多少处于慢请求或者有问题的请求
metrics的类型其实还有另外的类型
但是在我们大米运维的课程中 我们最主要使用的就是counter ganga 和histogram
- k/v的数据形式
我们之前了解了metrics的概念,和类型
prometheus的数据类型 就是依赖于 这种metrics的类型来计算的
而对于采集回来的数据类型再往细了说必须要以一种具体的数据格式 供我们查看和使用
那么我们来看一下 一个exporter给我们采集来的服务器上的k/v形式 metrics数据
当一个exporter被安装和运行在被监控的服务器上后
使用简单的curl命令 就可以看到exporter帮我们采集到metrics数据的样子,以k/v的形式展现和保存
curl localhost:9100/metrics
prometheus_server
带#的行是注释行 用来解释下面这一项k/v数值 是什么东东的采样数据
而我们真正关心的是这样的数据
process_max_fds 65535
process_open_fds 10
看到了没有 就是用空格分开的KEY/Value数据
第一个代表的是当前采集的最大文件句柄数是65535
第二个代表的是当前采集的被打开的文件句柄数是10
这样就非常好理解了
另外我们看下这里
process_max_fds 65535
# help process_open_fds number of open file descriptors.
# type process_open_fds gauge
第二行的#告诉我们了这一项数据的metrics类型属于gauge
因为很简单,文件句柄数的使用是没哟规律的瞬时采样数据 当前是多少就是多少
- exporter的使用
官网提供了丰富的成型exportrs插件可以使用
举几个例子
prometheus - alertmanager - blackbox_exporter - consul_exporter - graphite_exporter
haproxy_exporter - memcached_exporter - mysqld_exporter - node_exporter - pushgateway - statsd_exporter
下载首页其实就已经提供了很多很常用的exporter
这些exporters分别使用不同的开发语言开发,有go有java有python有ruby等等
我们不关心社区组织 用什么语言做的开发
我们只要关心 如何下载和正确安装使用即可
大多数exporter下载之后,就提供了启动的命令 一般直接运行 带上一定的参数就可以了
比如最常用的node_exporter=>这个exporter非常强大,几乎可以把linux系统中和系统自身相关的监控数据全抓出来了(很多参数 说真的 都没听说过 比你想象的 学过的 多的多)
这里只给大家一个截图 展示node_exporter一部分的支持的监控数据采集
- pushgateway的概念介绍
之前说的exporter是首先安装在被监控服务器上的运行在后台,然后自动采集系统数据,本身又是一个http_server可以被prometheus服务器定时去http get取得数据，属于pull的形式
如果把这个过程反过来
push的形式是把pushgateway安装在客户端或者服务端(其实装哪里都无所谓)
pushgateway本身也是一个http服务器
运维通过写自己的脚本程序抓自己想要的监控数据,然后推送pushgateway再由pushgateway推送到prometheus服务端
是一个反过来的被动模式
一个问题?为什么已经有了那么强大的pull形式的exporter采集还需要一个pushgateway的形式呢?
其实对这个问题的回答是:
exporter虽然采集类型已经很丰富了,但是我们依然需要很多自制的监控数据 非规则化的 自定制的
exporter由于数据类型采集量大 其实很多数据 或者说大部分数据 其实我们监控中 真的用不到 用pushgateway是定义一项数据 就采集这一种 节省资源
一个新的自定义的pushgateway脚本开发 远远比开发一个全新的exporter简单快速的多的多的多!(exporter的开发 需要使用真正的变成语言,shell这种快速脚本是不行的 而且需要了解很多prometheus自定的编程格式才能开始 制作工作量很大)
exporter虽然已经很丰富了,但是依然有很多的我们需要的采集形式,exporter无法提供,或者说现有的exporter还不支持,但是如果使用pushgateway的形式就可以任意灵活想做什么都可以做到 而且极快
最后用一张图来表达这两种不同的采集形式
prometheus server -> [被监控服务器[exporter]]
prometheus <- pushgateway <- [被监控服务器[我们开发的小脚本]]

第六讲:prometheus初探和配置(安装测试)

prometheus官网下载
prometheus开始安装
prometheus启动运行
安装第一个exporter=>node_exporter
prometheus连接exporter获取数据
prometheus命令行入门 第一个数学查询公式
之前我们说过,相对于较难的使用方法,prometheus其实安装的过程反而是异常的简单
安装prometheus之前 我们必须先安装 ntp时间同步(prometheus T_S 对系统时间的准确性要求很高,必须保证本机时间时间同步)
以centos7为例
timedatectl set-timezone Asia/Shanghai
* * * * * ntpdate -u cn.pool.org
1.prometheus下载
首先 我们去到prometheus.io官网,下载最新版本prometheus-2.1.0.linux-amd64.tar.gz
wget https://github.com/prometheus/releases/download/v2.1.0/prometheus-2.1.0.linux-amd64.tar.gz
2.prometheus的安装非常简单
tar xf prometheus-2.1.0.linux-amd64.tar.gz -C /usr/local
ln -s prometheus-2.1.0.linux-amd64 prometheus
3.prometheus启动和后台运行
cd /usr/local/prometheus/ && ./prometheus &
不指定配置文件默认在当前目录寻找配置文件运行
默认运行在9090端口
浏览器可以直接打开访问 无账号密码验证 (如果希望加上验证,可以使用apache httppass方式添加)
4.接下来 我们来简单看一下prometheus的主配置文件
其实prometheus解压安装之后,就默认自带了一个基本的配置文件如下
prometheus.yml
global:
scrape_interval: 15s #set the scrape interval to every 15 seconds.Default is every 1 minute. 15s采集间隔
evaluation_interval: 15s #evaluate rules every 15 seconds. the default is every 1 minute.
# scrape_timeouot is set to the global default(10s)
前两个全局变量
scrape_interval. 抓取采样数据的时间间隔,默认每15秒去被监控机上采样一次=>5
这个就是我们所说的prometheus的自定义数据采集频率了
evaluation_interval.监控数据规则的评估频率
这个参数是prometheus多长时间 会进行一次 监控规则的评估
举个例: 假如我们设置当内存使用量>70%时发出报警这么一条rule(规则)
那么prometheus会默认每15秒来执行一次这个规则 检查内存的情况
# alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093
alertmanager是prometheus的一个用于管理和发出报警的插件
我们这里对alertmanager暂时先不做介绍 暂时也不需要 (我们采用4.0最新版的grafana,本身就已经支持报警发出功能了 往后我们会学习到)
再往后 从这里开始 进入prometheus重要的 配置采集节点的配置
#here it\'s prometheus itself.
scrape_configs:
# the job name is added as a label`job=<job_name>`to any timeseries scraped from this config.
- job_name:\'prometheus\'
# metrics_path defaults to \'/metrics\'
# scheme defaults to \'http\'.
static_configs:
- targets:[\'localhost:9090\']
先定义一个job的名称
- job_name:\'prometheus\'
然后 定义监控节点 targets
# metrics_path defaults to \'/metrics\'
# scheme defaults to \'http\'.
static_configs:
- targets: [\'localhost:9090\']
- targets的设定
以这种形式设定 默认带了一个prometheus本机的
static_configs:
- targets:[\'localhost:9090\']
这里可以继续 扩展加入 其他需要被监控的节点
如下是一个 生产配置例子
- job_name:\'aliyun\'
static_configs:
- targets: [\'server04:9100\',\'web3:9100\',\'nginx06:9100\',\'web7:9100\',\'redis1:9100\',\'log:9100\',\'redis2:9100\']
可以看到targets可以并列写入多个节点,用逗号隔开,机器名+端口号
端口号:通常用的就是exporters的端口
在这里9100其实是node_exporter的默认端口
如此prometheus就可以通过配置文件识别监控的节点,持续开始采集数据
prometheus到此就算初步的搭建好了(后续课程 还有各种扩展的优化)
5.光搭建好prometheus_server是不够的,我们需要给监控节点 搭建第一个exporter用来采样数据
我们就选用企业中最常用的node_exporter这个插件
node_exporter之前介绍过,是一个以http_server方式运行在后台,并且持续不断采集linux系统中 各种操作系统本身相关的监控参数的程序
其采集量是很大很全的,往往默认的采集项目 就远超过你的实际需求
接下来我们来看下node_exporter是怎么回事
一样先下载node_exporter从官网
https://prometheus.io/download/#node_exporter
下载之后 解压缩 然后直接运行即可
./node_exporter
node_exporter的运行更加简单 如上图所示
运行起来以后 我们使用netstat -lutnp 可以来看下 node_exporter进程的状态
这里就可以看到node_exporter默认工作在9100端口可以响应prometheus_server发过来的http_get请求
也可以响应其他方式的http_get请求 我们自己就可以发送 测试
curl localhost:9100/metrics
执行curl之后,我们看到node_exporter给我们返回大量的这种metrics类型 K/V数据
关于metrics和k/v之前咱们介绍过了 就不再重复了
而这些返回的K/V数据,其中的key的名称 就可以直接复制粘贴 在prometheus的查询命令行 来查看结果了
我们来试一试 就用这一项node_memory_MemFree
直接就可以看到曲线了 对吗?
其实这个就是最简单的来查看一下服务器的空闲内存状态的方式
觉得很简单对吗?prometheus不也就如此而已吗？ 没什么难的 我暗中呵呵...
好吧 那么我们接下来再来看下一个难一些的例子 cpu使用率的获取方式
node_cpu这个key也是node_exporter返回的一个用来统计cpu使用率的
node_cpu输入查询框之后,咱们来看一下结果
疑?怎么回事 CPU不是应该是使用率吗?雷士百分之50% 80%这样的数据才对啊
说到这儿,我们就不得不给大家提一句了 这个其实就关系到prometheus对linux数据的采集的精细的特性
其实prometheus对linux CPU的采集 并不是 直接给我们返回一个 现成的CPU百分比 而是返回linux中很底层的cpu时间片 累计数值的这样一个数据(我们平时用惯了top/uptime这种简便的方式 看cpu使用率,往往浅尝辄止 根本没有好好深入理解 所谓的cpu使用率 在linux中到底是怎么回事)
当懒人当的时间长了 自己问问自己对linux到底了解多少呢?
大米给大家补补课吧:)
其实如果想真的弄明白cpu的使用率这个概念 在linux中要先从cpu时间这个概念开始建立
linux中cpu时间实际是指:从操作系统开启算起 cpu就开始工作了 并记录自己在工作中 总共使用的"时间"的累计量 把它保存在系统中
而累计的cpu使用时间 还会分成几个重要的状态类型
比如cpu time=>分成cpu user time/sys time/nice time/idletime/irq/等等...
翻译过来就是cpu用户态使用时间,系统/内核态使用时间,nice值分配使用时间,空闲时间,中断时间等等
那么所谓的cpu使用率是什么意思呢?
cpu使用率最准确的定义其实是cpu各种状态中除了idle(空闲)这个状态外,其他所有的cpu状态的加合/总CPU时间
得出来的就是我们所说的cpu使用率
那么回到我们刚才使用node_cpu这个key如果直接输入进去
他返回的其实是cpu各个核 各个状态下从开机开始 一直累积下来的cpu使用时间的累积值
所以我们才看到这个一个node_cpu:726546.19
如下截取一段网上对各个cpu状态的时间单位的解释
参数 解析(单位:jiffies) jiffies是内核中的一个全局变量,用来记录自系统启动以来产生的节拍数,在linux中,一个节拍大致可理解为操作系统进程调度的最小时间片,不同linux内核可能值不同,通常在1ms到10ms之间)
user(38082) 从系统启动开始累积到当前时刻,处于用户态的运行时间,不包含nice值为负进程。
nice(627) 从系统启动开始累积到当前时刻,nice值为负的进程所占用的cpu时间
system(27594) 从系统启动开始累积到当前时刻,处于核心态的运行时间 idle(893908)从系统启动开始累积到当前时刻,除IO等待时间以外的其他等待时间iowait(12256)从系统启动开始累计到当前时刻,IO等待时间(since 2.5.41)
irq(581) 从系统启动开始累计到当前时刻,硬中断时间(since 2.6.0-test4)
softirq(895) 从系统启动开始累计到当前时刻,软中断时间(since 2.6.0-test4)stealstolen(0) which is the time spent in other operating systems when running in a virtualized environment(since 2.6.11)
guest(0) which is the time spent running a virtual cpu for guest operating systems under the control of the linux kernel(since 2.6.24)
所以:如果在prometheus中 相对cpu的使用率准确的来查询
正确的方法如下:(难的开始要来了...)
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance)) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
这才是真正的cpu使用率V%
呵呵...现在还觉得prometheus和linux简单吗?
其实话说回来,prometheus的这种精细的底层的计算特性虽然学起来难,不过带来的好处也是显而易见
1. prometheus这种底层数据采集 所形成的的监控 其实是最准确 最可信的
2. prometheus本身也逼着使用它的运维同学 你不踏实下来 好好的真正把linux技术学过关的话 你就没有办法使用好 这个超强力的监控工具了
所以说呢 我们还是踏踏实实的一步一步脚印的来学习吧 加油~
最后再额外提两句
1. 最后使用的这个复杂的cpu计算 prometheus公式,我们从下一讲开始 会给大家详细讲解 (不用着急哈)
2. 对于linux操作系统 底层的各种深入知识学习 请关注 大米运维课堂的系列课程 第三/第四阶段 高级=>专业课程(面向5-10年经验工程师)
(今天随口提的这个cpu时间计算 只不过是linux开始深入的冰山一角而已)

第七讲:prometheus数学理论基础学习(prometheus数学consule使用)

回顾上篇最后留给大家的一个较难cpu使用率计算公司
拆分并解释这个运算公式
举一反三计算其他cpu状态
(一)回顾上篇最后留给大家的一个较难CPU使用率计算公式
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance)) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
上篇最后一节课给大家讲解了linux系统中底层计算cpu占用率的方法
简单的总结如下:
linux系统开启后,cpu开始进入工作状态,每一个不同状态的cpu使用时间 都从零开始累计
而我们在被监控客户端安装的node_exporter会抓取并返回给我们常用的八种cpu状态的累计时间数值
我们就先使用用户态cpu来给大家举个例子
用户态cpu通常是占用整个cpu状态最多的类型,当然也有个别的情况,内核态或IO等待占用的更多
TOP=>user%
12:00开机后一直到12:30截止
这30分钟的过程中(当前我们先暂时忽略 是几核CPU 就当中1核心来说)
cpu被使用在用户态的时间一共是8分钟
cpu被使用在内核态的时间一共是1.5分钟
cpu被使用在IO等待状态的时间一共是0.5分钟
cpu被使用在idle(空闲状态)的时间一共是20分钟
(idle空闲状态的cpu时间 其实就是cpu处于没事干的时间)
cpu被使用在其他几个状态的时间是0
上面的这些数据是为了我们计算cpu在30分钟时间的使用率提供了单位数据基础
cpu的使用率=(所有非空闲状态的CPU使用时间总和)/(所有状态CPU时间的总和)
有了这个公式后 咱们就可以很自然的 得出如下的计算公司
(user(8mins)+sys(1.5mins)+iowa(0.5mins)+0+0+0+0)/(30mins)=10分钟/30分钟
所以针对这30分钟我们cpu平均使用率就是33.33%
其实上面的这个计算公式还是有一点点累赘,我们可以换一个更简明的算法
idle(20mins)/(30mins)=>66.66%
空闲时间除以总时间等于空闲cpu的比例,然后我们100%-66.66%=33.34%,是不是更简单了
其实还有另外两个问题没有解决 咱们来说一下
1.上面这样的方法去计算 只能是算出CPU在30分钟内的总平均时间
如果我是需要中间的某一个分钟CPU的总平均时间是多少?
那么使用当前的这个算法我们就没办法精确地知道某一分钟的平均值了
(其实也是合情合理的提问,对于向CPU这种实时变化的监控数据,我们往往需要更精确的单位去判断当前时刻或者过去某一时刻更细节的即时状况,所以只知道30分钟的平均值是没有太大意义的)
如何解决这个问题?
还记得咱们学过的counter的数据类型吗？(虚拟的数据类型 针对返回的数值 他的使用途径)
node_exporter=>node_cpu给我们返回的是counter的数据类型(cpu底层是时间的累计)
counter是一个一直持续增长的数值
现在面临的问题是30分钟内cpu使用时间持续增长,我们需要截取其中一段增长的增量值
如果我们能获得1分钟的增量值然后拿这个值再去使用刚才同样的计算公司就可以得到1分钟的平均值
解决办法 接踵而至
prometheus的数学查询命令行 其实给我们提供了非常丰富的计算函数
关于种类繁多的函数我们从第八讲开始给大家逐一普及
在这里先给大家介绍一个很实用的函数
increase()
increase函数在prometheus中,是用来针对counter这种持续增长的数值,截取其中一段时间的增量
increase(node_cpu[1m])=>这样就获取了cpu总使用时间在一分钟内的增量
2.实际工作中cpu大多数都是多核的
如下图node_exporter给我们截图回来的
采集的数据自然也是精细到采集每一个核的cpu时间
不过我们在运维实际监控中,往往并不是太关注每一个cpu核表现如何
而是希望知道 整个cpu表现如何
(一般生成服务器 动不动cpu就是16 20 32 40核)
如果每一个核都单独来一个监控曲线图 意义不大 而且看着太混乱了
有什么办法可以解决这个问题?
prometheus提供了另一个sum()函数
sum()就如其字面意思一样 起到加合的作用
sum(increase(node_exporter[1m]))
外面套用一个sum即可把所有核的数值加合,问题就可以解决了
(二)拆分并解释这个运算公式
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance)) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
这个prometheus的计算公司其实就是我们最后那个使用100%-(空闲时间/总时间)的方法
不过这个公式直接拿来看还是有点痛苦,咱们来学一下拆分
首先第一步
node_cpu是我们需要使用的key_name
第二步
咱们把idle的cpu时间和全部cpu时间都给过滤出来使用{}过滤
node_cpu{mode="idle"}/node_cpu
第三步
我们使用increase([1m])把node_cpu{mode="idle"}包起来
increase(node_cpu{mode="idle"}[1m])/increase(node_cpu[1m])
这样就是把一分钟的增量的cpu时间给取出来了,不够因为cpu核数太多曲线太混杂我们需要进一步加强公式
第四步
我们使用sum()将increase(node_cpu{mode="idle"}[1m])括起来
sum(increase(node_cpu{mode="idle"}[1m]))/sum(increase(node_cpu[1m]))
到这里之后感觉应该可以了,不过我们细心的同学又发现了一个问题
那就是我们这个cpu的监控其实采集的是多台服务器的监控数据,怎么现在变成一条线了...
其实是由于这个sum()函数默认情况下是吧所有数据不管什么内容全部加合了
第五步
这里再给大家引出一个新的函数(或者说一个新功能)
by (instance)
这个函数可以把sum加合到一起的数值 按照指定的一个方式 进行一层的拆分 [instance代表的是机器名]
意思就是说把sum函数中服务器加合的这个数据再拆分出来指定的数据
sum(increase(node_cpu{mdoe="idle"}[1m])) by (instance)
第六步
这下3个问题全都解决了 让我们继续把公式写完整 看看输入如何
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
sum(increase(node_cpu{mode="idle"}[1m])) by (instance) => 是空闲cpu时间 1分钟的增量
sum(increase(node_cpu[1m])) by (instance) => 是全部cpu时间 1分钟的增量
sum(increase(node_cpu{mode="idle"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance) => 这样就得到了空闲cpu的百分比了
第七步
最后一步 用1去减掉整个上面的公式再*100 => 这样我们就得到了最终我们期望的结果
(1-((sum(increase(node_cpu{mode="idle"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance)))) * 100
基本上大部分服务器的cpu使用率都是在50%以下的,还是一个比较良好的状态的^_^
(三)举一反三,查看几个其他cpu状态时间的使用率
既然要看每一个单独cpu类型的使用率,那么1-idle的方式就不好用了
sum(increase(node_cpu{mode="user"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance)
sum(increase(node_cpu{mode="system"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance)
sum(increase(node_cpu{mode="iowait"}[1m])) by (instance) / (sum(increase(node_cpu[1m])) by (instance)
这样我们就可以举一反三轻松获得每一种cpu状态时间的使用百分比了
说到这里我们是不是发现这下top命令中这一行我们总算是彻底明白怎么回事了对吗?
所以 就如我们说所
prometheus计算公式的使用强制要求我们运维人员必须要对linux系统的深层次的知识 要有一定的掌握(依赖linux的命令行),不然公式都没得写
有点麻烦的同时,更多的是提供给我们更加广阔的平台让我们尽情发挥

第八讲:prometheus命令行使用扩展

prometheus命令行格式
rate函数的使用
increase函数的使用
sum函数使用
(一)prometheus命令行格式
这次我们选用一个新的key来做讲解
count_netstat_wait_connections(TCP wait_connect数)
这个key值得一说的是并不是由我们熟悉的node_exporter挖掘而来的,而是我们自定义并且使用bash脚本+pushgateway的方法推送prometheus server采集的
gauge类型
gauge类型的数据,属于随机变化的数值,并不像counter那样是持续增长的
把一个key直接输入命令行之后得到的是最原始的数据输出
count_netstat_wait_connections
counter类型的数据使用起来相对容易的多,不需要任何increase() rate()之类的函数去计算 单位时间段的增量
直接输入后就可以看到已经成型的有确实意义的曲线图
我就使用这个key来进行我们的命令行正式的学习
count_netstat_wait_connections
默认输入后 会把所有安装了这个采集项的服务器数据都显示出来
我们来学习命令行的过滤
count_netstat_wait_connections{exported_instance="log",exported_job="pushgateway1",instance="localhost:9092",job="pushgateway"}
看下上面这张图的显示,后面的{.}的部分属于标签
标签:也是来自于采集数据,可以自定义也可以直接使用默认的exporter提供的标签项
上面的这几个标签中最重要的是exported_instance指明是哪台被监控服务器"log"是一台日志服务器的机器名
命令行的查询在原始输入的基础上先使用{}进行第一步过滤
count_netstat_wait_connections{exporter_instance="log"}
之后就只显示这一台服务器的数据
过滤除了精确匹配还有模糊匹配
count_netstat_wait_connections{exporter_instance=~"web.*"}
把所有机器名中带有web的机器都显示出来
.*属于正则表达式 模糊匹配:=~ 模糊不匹配:!~
标签过滤之后 就是数值的过滤
比如我们只想找出 wait_connection数量大于200的
count_netstat_wait_connections{exporter_instance=~"web.*"} > 400
这时候发现图上看不见曲线了只看到很小的点,是因为我们>400的过滤在30分钟之内只有很少的时间点达到了这个数值
(二)rate函数的使用
rate函数可以说是prometheus提供的最重要的函数之一
tate()
rate()函数是专门搭配counter类型数据使用的函数,它的功能是按照设置的一个时间段,取counter在这个时间段中的平均!每秒!的增量
这么说可能还是有点抽象,咱们来举个例子吧
这个例子使用的node_exporter key node_network_receive_bytes
rate(node_network_receive_bytes[1m])
node_network_receive_bytes本身是一个counter类型字面意思也很好理解 - 网络接收字节数
咱们之前也学习过了对于这种持续增长的counter数据,直接输入key是没有任何意义的,我们必须要以获取单位时间内增量的方式来进行加工才能有意义
那么对于counter数据,进行第一步的初始化的增量获取加工通常的使用发放就是直接用rate()包上。(increase().也是可以的,之后会讲到)
node_network_receive_bytes 被rate(.[1m])包上以后,就可以获取在1分钟时间内,平均每秒钟的增量
这样一来数据就变得有意义了
所以说我们以后在使用任何counter数据类型的时候,永远记得别的先不做先给它加上一个rate()或者increase()
接下来我们把rate()做的事情更加细化的咱们来解释一下
比如上面这个图,网络接收字节数一直不停的累加,从23:44开始到23:45比如累积量从440011229804456到了440011229805456,一分钟内增加了1000bytes(假设)
从23:45开始到23:50比如累计量从440011229804456到了440011229810456,5分钟内增加了5000bytes(假设)
加入raet(.[1m])之后,会把1000bytes除以1m*60秒,=~16bytes 就是这样计算出在这1分钟内,平均每秒钟增加16bytes,这个还是比较好理解的
接下来咱们修改1m=>5m变成这样rate(.[5m])
这样就变成把5分钟内的增量除以5m*60,5分钟的增量假如是5000,那么除以300以后也还是约等于16bytes,感觉好像是一模一样的?那么我们来看下输出rate[5]
感觉图形发生了一定的变化,怎么回事? - 明明是一样的平均16/s啊 怎么图形变了呢?
事实是这样的,如果我们按照rate(1m)这样来取,那么是取1分钟内的增量除以秒数
如果我们按照rate(5m)这样来取,那么是取5分钟内的增量除以秒数,而这种取法是一种平均的取法,而且是假设的
刚才我们说,counter在1分钟、5分钟之内的增量1000和5000其实是一种假设的理想状态
事实上,生产环境网络数据接收量可不是这么平均的,有可能在第一分钟内增加了1000,到第二分钟就变成了增加了2500...
所以rate(1m)这样的取值方法比起rate(5m),因为它取得时间较短,所以任何某一瞬间的凸起或者降低在成图的时候会体现的更细致更敏感
而rate(5m)把整个5分钟内的都一起平均了,那么当发生瞬时凸起的时候,会显得图平缓了一些(因为取得时间段长把波峰波谷都给平均消下去了)
那么我们再放大一些看看rate(20m)会怎么样,是不是更平缓了
在我们的工作中,取1m还是取5m,这个取决于我们对于监控数据的敏感性程度来挑选
(三)increase函数的使用
increase函数其实和rate()的概念及使用方法非常相似
rate()是取一段时间增量的平均每秒数量,increase()则是取一段时间增量的总量
比如:
increase(node_network_receive_bytes[1m])取的是1分钟内的增量总量和rate(node_network_receive_bytes[1m])取的是1分钟内的增量除以60秒每秒数量
从这两个图我们可以看到其实曲线的走势基本是一样的,但是显示出来的数量级bytes可不一样
137303978*60=8238238680正好是60倍,，也就很好理解了,increase()是不会取一秒的平均值的
increase() rate() 监控获取采集数据源 5m=> rate() 形成图断链 increase(5m) rate()->cpu 内存 硬盘 IO 网络流量
(四)sum()函数的学习
sum()函数的使用,我们在上节课讲cpu拆分公式的时候,已经讲过了,sum就是取舍,sum会把结果集的输出进行总加合
比如,rate(node_network_receive_bytes[1m])显示的结果集 会包含如下内容
从标签我们就不难看出,有好多台服务器都返回了这个监控数据,当我们使用sum()包起来以后
sum(rate(node_network_receive_bytes[1m]))就变成了下面这样了,变成一条线了
等于是给出了所有机器的每秒请求量...
我们之前也说过,如果要进行下一层的拆分,需要在sum()的后面加上by (instance)才可以按照机器名拆分出一层来
sum()加合 其实还有更多巧妙使用,sum() by (cluster_name)
如果是by instance那么其实跟不加sum()的输出结果是一样的,本来rate(node_network_receive_bytes[1m])就已经是按照每台机器返回了
但是如果我们希望按集群总量输出呢?
比如我们返回了20台机器的数据,其中有6台属于web_server,10台属于DB_server,其他的属于一般server
那么我们这时候sum()by(cluster_name)就可以帮我们实现集群加合并分三条曲线输出了
顺带一提的是(cluster_name)这个标签,默认node_exporter是没有办法提供的,node_exporter只能按照不同的机器名去划分
如果希望支持cluster_name我们需要自行定义标签,往后的课程我们会涉及到这个内容
目前我们学到的函数,rate()increase()sum()by()感觉有点少
其实prometheus还提供了更多的函数让我们调用,只不过更加专业化了,对于我们学习阶段这几个函数使用好了基本上就能应付60-70%的需要了
往后的企业实践篇中还会有陆续新的函数引进给大家
(五)topk()函数的学习
定义:取前几位的最高值
gauge类型的使用
topk(3,count_netstat_wait_connections)
counter类型的使用
topk(3,tate(node_network_receive_bytes[20m]))
这个函数还是比较容易理解的,根据给定的数字取数值最高>=x的数值,唯一需要注意的是:这个函数一般在使用的时候,只适用于在console查看graph的意义不大
因为对于每一个时间点,都只取前三高的数值,那么必然会造成单个机器的采集数据不连贯
比如server01在这一分钟的wait_connection数量排在所有机器的前三,到了下一分钟可能就排到垫底了...自然其曲线就会中断
实际使用的时候一般用topk()函数进行瞬时报警,而不是为了观察曲线图
(六)count()函数的学习
定义:把数值符合条件的输出数目进行加合
举个例子:找出当前(或者历史的)当TCP等待数大于200的机器数量 - count(count_netstat_wait_connections > 200)
这个函数在实际工作中还是很有用的,一般用它进行一些模糊的监控判断
比如说企业中有100台服务器,那么当只有10台服务器CPU高于80%的时候这个时候不需要报警,但是当符合80%CPU的服务器数量超过30台的时候那么就会触发报警
第九讲:企业级监控数据采集方法
(一)prometheus服务端的安装和后台稳定运行
prometheus的下载地址 https://prometheus.io/download/#prometheus
下载和安装的过程相对非常的简单
prometheus-2.2.0-rc.0.linux-amd64.tar.gz 最新版prometheus_server下载
tar -xvzf prometheus-2.2.0-rc.0.linux-amd64.tar.gz
cp -r prometheus-2.2.0-rc.0.linux-amd64 /usr/local
之后解压缩后 即可直接运行在默认的9090端口 直接就可以使用了
不过我们作为合格的运维工程师,对生产环境上运行的软件需要多考虑一些更合理的运行模式,接下来咱们来一起看一下
1.我们需要让prometheus_server运行在后台而不是前端(客户端退出后 prometheus也退出了这个很好理解)
相对比较好的运行后台模式这里给大家推荐两种方法
第一种:安装screen工具 放入后台运行
这种screen放入后台运行的方式,最简单快速了,最适合懒人使用...比如我 哈哈
screen还有另外一个好处 就是可以随时切换进入程序前台窗口查看各种调试信息
screen也有不好的地方
不够正规化总觉得还是个临时办法
screen -l提供的后台列表不够人性化,很多时候你记不住到底哪个是哪个
很容易被误关闭 操作的时候ctrl+ad/ctrl+d不小心操作错了 直接就退出了...
第二种:使用daemonize放入后台方式
daemonize unix系统后台守护进程管理软件
优点: 更加正规 后台运行更稳定
git clone git://github.com/bmc/daemonize.git
sh configure && make && sudo make install
daemonize -c /data/prometheus/ /data/prometheus/up.sh -c 是指定运行路径
/date/prometheus/up.sh是运行路径下的一个启动脚本,下面是这个启动脚本的内容 内容:就是开启prometheus进程
cat /data/prometheus/up.sh
/data/prometheus/prometheus --web.listen-address="0.0.0.0:9090" --web.read-timeout=5m --web.max-connections=10 --storage.tsdb.retention=15d --storage.tsdb.path="data/" --query.max-concurrent=20 --query.timeout=2m
然后我们来看下./prometheus在实际企业运行时启动参数的合理配置
--web.read-timeout=5m maximum duration before timing out read of the request,and closing idle connections.
请求链接的最大等待时间,防止太多的空闲链接占用资源
--web.max-connections=512 maximum number of simultaneous connections.
最大链接数
--storage.tsdb.retention=15d how long to retain samples in the storage.
prometheus开始采集监控数据后会存在内存中和硬盘中,对于保留期限的设置很重要,太长的话硬盘和内存都吃不消,太短的话要查历史数据就没有了企业中设置15天为宜
--storage.tsdb.path="data/" base path for metrics storage.
存储数据路径 这个也很重要 不要随便放在一个地方就执行 会把/根目录塞满了
--query.timeout=2m maximum time a query may take before being aborted.
--query.max-concurrency=20 maximum number of queries executed concurrently.
上面这两项是对用户执行prometheus查询时候的优化设置,防止太多的用户同时查询,也防止单个用户执行过大的查询而一直不退出
如上这几项参数 配置上去后 prometheus运行就相对稳妥多了
web上直接输入ip:port就可以进入首页 这里遇到一个问题,就是prometheus对系统时间非常敏感,一定要时时刻刻保证系统时间同步,不然曲线是乱的
ntpdate循环同步时间后错误提示就没有了,prometheus运行时存放的历史数据在这儿
其中这些长串字母的是历史数据保留,而当前近期数据实际上保留在内存中,并且按照一定间隔存放在wal/目录中,防止突然断电或者重启以用来恢复内存中的数据(这个咱们之前也提到过)
(二)prometheus服务端配置文件写法
prometheus_server安装稳妥之后 咱们要来看下配置文件 /data/prometheus/prometheus.yml
配置文件是运行在哪个目录,就默认读取哪个目录下prometheus.yml文件,除非使用参数指定其他位置的配置文件
配置文件中,我们主要关注这几个地方
global:
scrape_interval: 15s #set the scrape interval to every 15 seconds.default is every 1 minute.
evaluation_interval: 15s #evaluate rules every 15 seconds.the default is every 1 minute.
scrape_configs:
#the job name is added as a label`job=<job_name>`to any timeseries scraped from this config.
- job_name: \'prometheus\'
#metrics_path defaults to \'/metrics\'
#scheme defaults to \'http\'.
static_configs:
- targets:[\'prometheus.server:9090\',\'prometheus.server:9100\']
- job_name:\'pushgateway\'
static_configs:
- targets:[\'localhost:9091\',\'localhost:9092\']
- job_name:\'aliyun\'
static_configs:
- targets:[\'server4:9100\',\'web3:9100\',\'server6:9100\',\'server7:9100\',\'web8:9100\',\'log1:9100\',\'mysql1:9100\']
一个就是全局变量scrape_interval 设置多少时间间隔 采集一次数据
另一个就是job和targets的写法,配置一个job的标签,然后在这个标签下定义我们需要监控的机器
targets:[\'server4:9100\'] hostname+端口 而这里的端口 实际上 就是node_exporter的默认运行端口
(三)node_exporter安装和后台运行
node_exporter的下载和安装 跟prometheus也是一样的,这里就不再掩饰了,下载地址为https://prometheus.io/download/#node_exporter
同样适用daemonize放入后台运行,ps -ef|grep node_exporter 默认运行在9100端口
(四)node_exporter观察和采集数据
运行在后台以后,我们需要针对这个node_exporter进行初步的手动查询,以确保正常获取监控数据,用如下方法进行本地查询
curl localhost:9100/metrics
-node_cpu{cpu="cpu7",mode="steal"} 0
node_cpu{cpu="cpu7",mode="system"} 131503.32
-node_cpu{cpu="cpu7",mode="user"} 397798.53
prometheus 15s get请求,只有挑几个重要的key看到有数据采集上来就ok了
prometheus命令行,node_exporter经过实际测试在centos/redhat任意版本系统中均可以顺利运行(ubuntu debian)
还没有遇到过什么问题,给node_exporter的开发者点个赞
然后我们去到node_exporter在github上的地址
来看看我们伟大的社区开发者们都给咱们提供了哪些有用的采集项目
https://github.com/prometheus/node_exporter
node_exporter启动时默认启动一些参数,而一些额外非默认启动的参数可以通过手动指定的方式添加进启动项里
例: ./node_exporter --collector.arp
(五)prometheus查询采集回来的各种数据
接下来我们回到prometheus的主界面,验证一下我们新部署的监控机器上的node_exporter是否给我们正确返回了数据
随便挑几个key就可以查看,另外prometheus的命令行本身也支持suggest功能(输入提示)
本身node_exporter提供的keys实在太多了(因为都是从linux系统中的底层各种挖掘数据回来)
我们没有时间也没有必要把每一个key都掌握只要知道一部分重要的必须的key就足够了
(六)使用我们之前的学过的prometheus命令行的形式练习组合各种监控图
接下来咱们找一个比较重要的key,然后用我们学过的命令行方式给他组成一个临时监控图
比如 node_cpu node_memory node_disk等等,这里我们不再做演示了,可以自行找几个类似的keys组成监控图
不过这里有一个问题
命令行组成监控图之后,这些图都是临时的,如果我关闭了浏览器,那么下次再想看的时候就没有了,又要重新输入查询语句(比较麻烦)
而且prometheus自带的这个监控图实际上并不是很美观
那么我们如何既能永久保存这些监控图,又可以让它更美观呢?
请关注后面的篇章(grafana+prometheus)
第十讲:企业级监控数据采集脚本开发实践
(一)pushgateway的介绍
pushgateway是另一种采用被动推送的方式(而不是exporter主动获取)获取监控数据的prometheus插件
在上篇中,我们对pushgateway已经做过介绍,它是可以单独运行在任何节点上的插件(并不一定要在被监控客户端)
然后通过用户自定义开发脚本,把需要监控的数据发送给pushgateway,再由pushgateway把数据推送给prometheus server
接下来咱们来实践一下
(二)pushgateway的安装和运行和配置
pushgateway跟prometheus和exporter一样,下载地址 https://prometheus.io/download/#pushgateway
解压后直接运行,github的官网地址https://github.com/prometheus/pushgateway 又是以go语言开发的,用go开发的程序,在安装运行时就是这么得天独厚的简单任性同样我们使用daemonice的方式将pushgateway放入后台运行
root 13980 13976 16 1月19 ? 4-19:53:51 /data/pushgateway/pushgateway
root 13981 13978 0 1月19 ? 04:15:08 /data/pushgateway/pushgateway1 -web.listen-address 0.0.0.0:9092
关于pushgateway的配置 主要指的是在prometheus server端的配置,我们来看下
- job_name:\'pushgateway\'
static_configs:
- targets: [\'localhost:9091\',\'localhost:9092\']
在prometheus.yml配置文件中,单独定义一个job
然后target指向到pushgateway运行所在的机器名和pushgateway运行的端口即可
这里我们发现了没有,localhost:9091/9092 大米老师企业中使用的pushgateway开启了两个在prometheus_server本机上
为什么开启两个 我最后一个段落给大家解释
(三)自定义编写脚本的方法 发送pushgateway采集
接下来进入重头戏了,pushgateway本身是没有任何抓取监控数据的功能的,它只是被动的等待推送过来
所以让我们来学习pushgateway编程脚本的写法,如下是一段生产环境中,使用shell编写的pushgateway脚本
用于抓取tcp waiting_connection瞬时数量
cat /usr/local/node_exporter/node_exporter_shell.sh
#!/bin/bash
instance_name=`hostname -f|cut -d\'.\' -f1` #本机机器名 变量 用于之后的标签
if [$instance_name == "localhost"];then #要求机器名不能是localhost不然标签就没有区分了
echo "must fqdn hostname"
exit 1
fi
# for waiting connections
label="count_netstat_wait_connections" #定一个新的key
count_netstat_wait_connections=`netstat -an|grep -i wait|wc -l` #定义一个新的数值 netstat中 wait的数量
echo "$label:$count_netstat_wait_connections"
echo "$label $count_netstat_wait_connections"|curl --data-binary @-http://prometheus.server.com:9091/metrics/job/pushgateway1/instace/$instance_name
#最后把key&value推送给pushgateway
curl -data-binary
将http post请求中的数据发送给http服务器,与用户提交html表单时浏览器的行为完全一样
http post请求中的数据为纯二进制数据
从上面的短短的十几行的脚本来看,其实最重要的是两个标红的地方
count_netstat_wait_connections=`netstat -an|grep -i wait|wc -l`
后面红色部分是我们通过linux命令行 就简单的获取到了 我们需要监控的数据 tcp_wait数
http://prometheus.server.com:9091/metrics/job/pushgateway1/instance/$instance_name
最后这里用post方式把key&calue推送给pushgateway的url地址,这个url地址中,分成如下三个部分
http://prometheus.server.com:9091/metrics/job/pushgateway1 这里是url的主location
job/pushgateway1 这里是第二部分 第一个标签:推送到哪一个prometheus.yml定义的job里
instance/$instance_name 这里是第二个标签 推送后 显示的机器名是什么
其实pushgateway的脚本,并不是很难写,但是通过这样的脚本编程方式,我们可以很快速的自定义我们需要的任何监控数据
最后这个我们编写的监控bash脚本是一次性执行的,我们需要按时间段反复执行
所以呢?自然就得结合contab了,这里顺带提一句
crontab默认只能最短一分钟的间隔,如果希望小于一分钟的间隔,我们使用如下的方法
sleep10 or sleep20 之后我们回到prometheus主界面尝试输入由我们自己定义的new_key看看结果
key的名字就是这个label="count_netstat_wait_connections" #定一个新的key
嘿嘿 很愉快 对不?
其他种类的监控数据我们都可以通过类似的形式直接写脚本发送,使用python也是很好的方式
不过我个人还是推荐bash shell因为速度超级的快~ (用python的话 还得include 很多库 大米老师有点懒 哈哈)
(四)使用pushgateway的优缺点
大米之前就跟大家说过 pushgateway这种自定义的采集方式非常的快速而且极其灵活几乎不收到任何约束
其实我个人还是非常希望使用pushgateway来获取监控数据的
各类的exporter虽然琳琅满目而且默认提供的数据很多了已经,一般情况下我在企业中只安装node_exporter和db_exporter两个
其他种类的监控数据我倾向于全部使用pushgateway的方式采集(要的就是快速~灵活~)
不过言归正传,习惯并不代表正确性
pushgateway虽然灵活,但是并不代表正确性 pushgateway虽然灵活 但是也是存在一些短板的,接下来我们来看看prometheus官网是怎么说的
1.pushgateway会形成一个单点瓶颈,假如好多个脚本同时发送给一个pushgateway的进程,如果这个进程没了,那么监控数据也就没了
2.pushgateway并不能对发送过来的脚本采集数据进行更智能的判断,假如脚本中间采集出问题了,那么有问题的数据pushgateway一样照单全收,发送给prometheus
虽然有这么两个所谓的缺点
但是实际上通过我2年多的使用
对于第一条缺点其实只要服务器不宕机那么基本上pushgateway运行还是很稳定的
就算有太多的脚本同时都发送给一个pushgateway其实也只是接收的速度会变慢 丢数据没哟遇到过(有的时候我甚至觉得比exporters还稳定exporters倒是有时候会真的就宕机或者丢失数据 因为exporters开发比较复杂 越简单的东西 往往越稳定)
对于第二条缺点
其实只要我们在写脚本的时候细心一些别出错(这也是为什么我推荐就用bash写因为简单不容易出错,python我可不敢打包票)
那么监控数据也不会有错误
所以说,相信大米,我们就放心的使用pushgateway来尽情采集我们的数据吧
课堂的结尾,给大家留一个作业吧(学习需要勤快)
我们自己搭建pushgateway并自行编写一个采集脚本(bash shell即可),采集一个ping延迟和丢包率吧^_^
第十一讲:prometheus之exporter模块采集学习
第十二讲:prometheus之pushgateway模块学习
(一)编写一个exporter的流程
官网有介绍 编写exporter的详细内容
我们这里给大家做一个简单的归纳
首先,不同于pushgateway,exporter是一个独立运行的采集程序,其中的功能需要有这三个部分
1.自身是http服务器,可以响应从外发过来的http_get请求
2.自身需要运行在后台,并可以定期触发 抓取本地的监控数据
3.返回给prometheus_server的内容是需要符合prometheus规定的metrics类型(key-value)
接下来给大家一份我之前用go编写一份exporter源代码
(二)用go开发一个exporter的源代码及讲解
package main
import(
"fmt"
_"net/http/pprof"
"sync"
// "github.com/hpcloud/tail"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/common/log"
"github.com/prometheus/common/version"
// //"net"
"net/http"
// "net/url"
// "errors"
"flag"
"os"
"os/exec"
"io/ioutil"
// "regexp"
// "strconv"
// "strings"
"time"
)
const(
namespace = "my_exporter"
)
type exporter struct {
cmd string
mutex sync.rwmutex
up,freeram,totalram prometheus.gauge
debug bool
upstreamresponsetimes *prometheus.histogramvec
}
func (e *exporter)scrape() {
log.infoln("------")
e.up.set(1)
}
func (e *Exporter) Describe(ch chan<- "prometheus.desc){
e.upstreamResponseTimes.Describe(ch)
}
func (e *Exporter) Collect(ch chan<- prometheus.metric){
e.mutex.lock() // to protect metrics from concurrent collects
defer e.mutex.unlock()
e.scrape()
e.upstreamResponseTimes.collect(ch)
e.up.collect(ch)
}
func newexporter(cmd string,timeout time.duration)(*exporter,error){
return &Exporter{
cmd:cmd,
up:prometheus.newgauge(prometheus.gaugeopts{
namespace: namespace,
name: "up",
help: "was the last scrape of nginx exporter successful.",}),
upstreamResponsetimes:prometheus.newhistogramvec(
prometheus.histogramopts{
namespace:namespace,
name: "http_upstream_request_times",
help: "response times from backends/upstreams",
},
[]string{"method","endpoint","response_code","client_type"},
),
},nil
}
func run(){
cmd:= exec.command("/bin/sh","-c",`free -m`)
stdout,err:=cmd.stdoutpipe()
if err !=nil{
fmt.printin("stdoutpipe error",err.error())
}
stderr,err:=cmd.stderrpipe()
if err !=nil{
frnt.println("stderrpipe error",err.error)
}
if err := cmd.star();err != inl {
fmt.println("error start",err)
}
byteserr,err := ioutil.readall(stderr)
if err != nil {
fmt.println("readall stderr:",err.error())
return
}
if len(byteserr)!=0{
fmt.printf("stderr is not nul: %s",byteserr)
return
}
bytes,err := ioutil.readall(stdout)
if err != nil {
fmt.println("readall stdout:",err.error())
return
}
if err := cmd.wait();err!=nul{
fmt.println("wait:",err.error())
return
}
fmt.printf("stdout:%s",string(bytes))
}
func main(){
var(
listenaddress = flag.string("web.listen-address",":9100","address to listen on for web interface and telemetry.")
metricspath = flag.string("web.telemetry-path","/metrics","path under which to expose metrics.")
cmd = flag.string("free","","command to run")
nginxtimeout = flag.duration("nginx.timeout",5*time.second,"timeout for trying to get stats from HA.")
showversion = flag.bool("version",false,"print version information.")
// debug = flag.bool("debug","false","print debug information.")
)
flag.parse()
if * showversion {
fmt.println(os.stdout,verson.print("shannon_exporter"))
os.exit(0)
}
log.infoln("starting shannon_exporter",version.lnfo())
lgo.lnfoln("build context",version.buildcontext())
run()
exporter,_:=newexporter(*cmd,*nginxtimeout)
prometheus.mustregister(exporter)
prometheus.mustregister(version.newcollector("nginx_exporter"))
http.handle(*metricspath,prometheus.handler())
http.handlefunc("/",func(w http.responsewriter,r *http.request)){
w.write([]byte(`<html>
<head><title>haproxy exporter</title></head>
<boby>
<h1>haproxy exporter</h1>
<p><a href=\'`+*metricspath+`\'>metrics</a></p>
</body>
</html>`))
})
log.fatal(http.listenandserve(*listenaddress,nil))
}
// 前面的describe collect是struct类型的成员函数,这几个函数并没有直接在这个go里被调用,而是mustregister注册进去了它们。
//http.handle里的prometheus.handler将上一部2个mustregister的注册关联进入http.handle.也就进一步注册进入了httpserver-listerner
//http.lister是组赛程序,只有启动后被curl的时候才会执行。并且由于之前经过2步的注册,跟exporter的成员函数建立了关联(其实是指针关联)所以,每次被curl的时候,所有上面的成员函数都会被调用
//例如上面的up.set(1)就是只有被curl的时候才会被调用,成员函数是作为生成metrics的入口
注:本go源代码是半年前写的了 其中一些地方可能需要进一步修改才可以正常使用(本人go开发能力也比较菜-_-)
(三)对于编写exporter的个人建议
通过上面的对一个exporter源代码的讲解,我们也看的出来
编写一个exporter远远比写一个pushgateway脚本要复杂的多的多
个人建议:除非是工作中真的有需要(例如:社区的exporter都不能满足需求,且对于监控客户端的规范化比较严格)且对自己的编程能力有自信
那么可以自行开发new exporter
exporter开发的过程中 要特别注意 各种文件句柄等等资源的完整回收
因为一个非常被频繁调用的后台程序中 一旦循环中出现了资源泄漏 那么后果是很严重的
(之前其实就遇到过一次 资源没有正确回收 导致每一次prometheus_server访问过来都造成僵尸进程最终服务器被拖垮的窘境 ...囧 当然了 如果是开发高手的话 相信我的担心也就多余啦~~~)
所以如果企业中运维开发的实力不够过硬,我还是尽量建议大家 使用现成的社区exporter,配合自行开发pushgateway脚本
第十二讲:grafana超实用企业级监控绘图工具的结合
grafana这款软件的介绍
定义: frafana是一款近几年新兴的开源数据绘图工具平台,默认支持如下这么多种数据源作为输入
cloudwatch elasticsearch graphite influxdb mysql opentsdb postgresql prometheus
现如今在各大企业被广泛使用中,其强大而美观的绘图能力灵活的数据链接以及4.0之后的报警功能让人爱不释手
接下来咱们就一起来实践一下吧
grafana下载/安装/配置/运行
官方网站:grafana.com
wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-4.6.3-1.x86_64.rpm
yum localinstall grafana-4.6.3-1.x86_64.rpm
安装更简单了 直接rpm就装完了
运行:也更简单 更规范化 直接service就可以启动
service grafana-server status
访问:默认运行在3000端口 直接ip:3000即可
grafana设置数据源连接prometheus_server
进入grafana主界面后
第一件事就是要:设置新的数据源
让grafana链接上我们的prometheus_server
设置方法
找到左上角的开始按钮并选择datasources
设置连接的类型=>prometheus
设置prometheus的url地址 ip:9090即可
grafana建立dashboard
grafana创建graph成图
接下来我们来创建第一个graph图
点击graph
这个是空graph,我们开始给它添加内容
点击edit
之后我们来到了graph的edit编辑模式
首先我们给这个graph起一个名字
点击general选项卡之后,我们进入右边下一个选项卡metrics,data source选择prometheus,之后在里面输入key名称
grafana graph进阶内容
接下来咱们来详细讲一个graph的编辑
第一个选项卡general的部分,可以设置整个graph的分辨率
如果希望图形更清晰可以设置height的部分,到200-400px,接下来我们看metrics选项卡的部分
默认图像下方的输出信息是输出全部的标签,看着很乱,我们可以定制自己的标签别名
使用{{ 标签名称 }}
接下来我们来到legend选项卡,在这里我们可以进一步对输出值进行规划
可以将显示数值额外设置最小最大平均当前数值进行显示,最终可以做成这种样子的显示
然后我们可以对曲线图的颜色进行设置(保存后永久生效),最后我们来看下最终效果
grafana dashboard全局部署优化
grafana json备份和还原
save as
当我们的dashboard设置的越来越多时,我们除了即使保存,还要掌握导出的方法以便永久保存
在最上面设置的部分选择view json,将全部的json拷贝出来保存到一个地方,以备不时之需,grafana支持将json导入还原成dashboard
grafana实现报警功能 连接(4.0新功能 重要!)
grafana4.0之后 支持报警功能
所有的graph图形都可以设置连接上多个报警平台并设置阈值并报警
这个是一个非常重要的新功能,有了这个新功能后,prometheus_server仅仅作为数据源即可(没有必要再使用prometheus做报警设置了)
整个的流程如下:
[被监控服务器[exporter/pushgateway]]<-获取数据<-[prometheus_server[收集监控数据/临时查询]]<-从prometheus直接获取监控数据<-[grafana_server[成图/设置报警阈值/连接平台]]->[报警平台[如pagerduty]]->[用户手机/短信/邮箱]
接下来我们来看下如何设置grafana的报警功能
1.新建一个报警平台 连接渠道(alerting channel)
我们先去pagerduty获取一个integration key,这个integration key实际是一串数字,作为让其他软件连接到自己的认证码
xxxxxxxxx
然后我们进入grafana的alerting选项卡,点击notification channels,之后我们新建一个channel,然后我们在新建channel中设置如下
如此设置让这个channel连接pagerduty报警平台,并黏贴上那一串pagerduty申请的注册码(这个码如何申请,我们会在pagerduty的章节进行讲解),保存
2.回到我们的dashboard=>graph
我们来设置报警阈值
进入编辑模式后,如下我们选择alert选项卡,点击create alert之后我们就可以开始设置我们对于这一个graph监控的阈值设置了
conditions是作为报警阈值的设置项,when之后选择阈值的选取形式,可以是avg()也可以是max()min()等等
对一段数据的数值进行估算,可以走平均也可以取最大值最小值
然后OF之后选择我们的之前的查询公式
query(A,1m,now)
其中的A就是我们在创建graph metrics选项卡的设置的第一个查询公式
1m代表的是取1分钟内的数据
is above后就是报警的触发阈值了,当大于2000的时候就会发出报警到pagerduty,保存之后我们的graph图如下:
可以看到图上方多了一条红色报警阈值线,当我们曲线达到了这个阈值时,就是触发报警的时刻,可以看到在过去的12个小时中,只有一个时刻真的到达了触发点
3.继续设置我们的notification
第十三讲:prometheus企业级实际使用(一)
(一)prometheus+grafana 企业cpu监控 真实案例
我们在企业中基础监控的第一项一般就是针对服务器集群的cpu进行监控,为什么呢?
因为: 1:CPU是处理所有任务的核心(这是废话) 2: 另外由于cpu存在各种状态类型cpu时间,所以很多情况下,大部分的出现问题的情况都可以反映在cpu的表现上
下面举一个在企业中对cpu使用率监控的实例
数据采集:node_exporter
使用prometheus公式
(1-((sum(increase(node_cpu{mod"idle"}[1m])) by (instance) /(sum(increase(node_cpu[1m])) by (instance)))) * 100
第一幅图就是咱们之前讲过的,计算cpu综合使用率这里就不再重复它的计算方法了(可以回顾下篇的67讲)
在生产环境中一般70-80%以上的cpu高是因为用户态user cpu高所导致
我们使用top命令随便查看一台服务器的时候一般也会看到user%会最高
用户态的cpu使用率是跟应用程序(或者说软件)的运行密切相关的
当软件启动大量进程并行处理任务时,当进程之间频繁上下业切换时,对用户态的cpu消耗最大
不过我们在做监控的时候一般倒是不用单独列出一个user%态的cpu使用率因为除去IO等待造成的cpu高之外,大部分情况就是user%造成的
另外,system%内核态的cpu使用率偶尔也会出现高的情况,我们这个课程中就不再讲解了
使用prometheus公式
(sum(increase(node_cpu{mod"iowait"}[1m])) by (instance) /(sum(increase(node_cpu[1m])) by (instance)))) * 100
第二个图是针对iowait类型的cpu等待时间,其中不同的地方是mode=iowait
很多情况下,当服务器硬盘IO占用过大时,cpu会等待IO的返回进入interuptable类型的cpu等待时间
所以对于IOWAITCPU的监控是很有必要的
另外对于cpu高的报警阈值,是这样的设置的,设置成99或者100都可以
如果设置成80 90就报警,根据实际测试并不合适,因为80% 90%状态下的服务器还是可以处理请求的,只不过速度会慢了
但是一旦综合cpu上了98 99 100 那么整个服务器就几乎失去可用性了 连ssh登录有时候都很困难
所以针对linux系统的优化非常重要要通过各个内核参数软件参数来控制服务器尽量不让cpu堆到99 100 (更多linux内核优化知识请关注大米运维第三四阶段)
(二)prometheus+grafana 企业内存监控 真实案例
接下来就到了内存监控了
首先大米需要给大家说一下内存的计算公式,我们先从linux命令来看起
centos6.x 5.x free -m
centos5/6的版本中如上显示内存
内存管理是linux内核的非常重要的一个强势功能
可以说linux对于内存的使用率非常的高效比起windows来说真的智能了很多
主要依赖于linux内存管理的缓存功能(简单来说就是刚用过的内存中的内容会被暂时缓存一段时间,以备下次再使用快速调用)
然而5.x 6.x的内存命令 却有一点 不太善解人意
对于大多数的零基础和初级学员来说,命令行显示的这个很容易让人误解(甚至我遇到很多工作5年以上的人依然搞不清这里的)
关于linux的内存种类和内存管理细节我们这里就不过多阐述了
直接给出大家5.x 6.x的真实内存使用率公式即可
从应用程序的角度说,linux实际可用内存=系统free memory+buffers+cached
使用率=实际可用内存/总内存,centos7.x
对于最新的7.x中,free命令行的输出解决了这个问题,变得简单易懂,实际可用内存直接放在了最后一列直接使用
接下来我们来看下企业实际内存监控案例
给出大家prometheus公式
(1-((node_memory_buffers+node_memory_cached+node_memory_memfree)/node_memory_memtotal)) * 100
这里就很清楚了 跟上面讲的是对应的算法
从图上可以看出大部分机器的内存使用率比较低,基本都在20%以下
是因为之前的生成环境使用中并不是内存密集型的(是cpu密集型)
所以说我们内存的计算公式来说,prometheus也让我们很精细很放心,很多老式的监控直接返回一个内存使用率很多时候无法确认准确性
(三)prometheus+grafana 企业硬盘/IO监控 真实案例
数据来源:node_exporter
硬盘剩余容量的监控,相比上面的2个就简单很多
(node_filesystem_free/node_filesystem_size)<0.2
公示上看 也很好理解 当空闲硬盘小于0.2的时候就显示在图上
另外提到了硬盘使用率
我在这里给大家推荐另一个难度较高的prometheus函数
predict_linear()
predict_linear(v range-vector,t scalar) predicts the value of time series t seconds from now,based on the range vector v,using simple linear regression.
predict_linear should only be used with gauges.
关于这个函数我们后面会讲解
在这里我们先提出一个对于硬盘监控的比较新的理念
对于硬盘使用率来说
通常不管使用什么样子的监控工具基本上都是简单算法 空闲/总量 或 已使用/总量 当大于或小于一个阈值时 报警
这么定义的方法比较简单和普遍,那么我给大家提一个问题,假如有这么一种情况
有一个晚上8:00的时候 一台很重要的服务器上 硬盘使用率超过了90%，超过了报警阈值,于是乎报警电话就响了
结果运维人员上线一看,哦,还有百分之10的空间呢,根据以往的经验10%的空间基本上还能撑个3,4天呢
况且我们的服务器每天24:00还会做日志压缩呢 会释放很多空间,所以不着急处理就回去睡觉了
又有一天晚上10点的时候还是这台服务器又报警了>90%
这次运维人员还是老样子觉得没啥大事就去睡觉了报警也给屏蔽了,结果到了10点10分的时候整个生产线上报警了,老板也给吵起来了
运维慌慌张张打开电脑一看...我靠!
硬盘100% 导致nginx服务器无法响应了...
怎么搞的呀,平时不会这样子啊
后来经过分析,是由于晚上9:00的时候服务器系统上的app软件出现了一个死循环的错误
超大量的info/warning日志把整个根目录都给盛满了 而且用的时间很短,运维哭了
运维这个时候想,既然会有这种特殊情况那么干脆把报警阈值设置的更高一些吧
70%就报警好了,结果可想而知,往后的日子里运维都是黑眼圈了...
给大家讲这个真实发生过的运维故事,就是想告诉大家prometheus针对这种特殊的问题提供了一个非常好用的函数
predict_linear()
这个函数如果想讲清楚它的底层实现原理比较复杂
这里就给大家简单介绍一下它能做什么吧
对于刚才那种硬盘百分比报警的案例
predict_linear() 函数可以起到对曲线变化速率的计算以及在一段时间加速度的预测,说的简单一些
它可以实时监测硬盘使用率曲线的变化情况,假如在一个很小的时间段中发现硬盘使用率急速的下降(跟之前平缓时期相比较)
那么对这种下降的速度进行一个未来一段时间的预测,如果发现未来比如5分钟内按照这个速度硬盘肯定就100%了
那么在当前硬盘还剩余20%的时候就会报警!
说起来都觉得绕口 不过使用起来并不是很难
官网有predict_linear的使用方法介绍
https://prometheus.io/docs/prometheus/latest/querying/functions/#predict_linear()
另外也有针对这个函数的基础理论linear数学计算模型的介绍
https://en.wikipedia.org/wiki/simple_linear_regression
总之prometheus就是这样一个有各种数学家(也可能是物理学家)通过他们的辛勤努力给我们提供了非常繁多的这种复杂计算的实用函数,为的都是把监控做的越来越好
然后我们来看下硬盘IO使用的监控,使用公式
((rate(node_disk_bytes_read[1m])+rate(node_disk_bytes_written[1m]))/1024/1024)>0
硬盘使用率是read+written 读和写都会占用IO
/1024两次后就由bytes=>Mbs
如果这个指标标高了,那么必然cpu_iowait也会飙高
(所以说从这里我们也可以看得出报警中很多项目虽然重要但是无法避免重复都有一定的连带关系这也是大米为什么在上篇中给大家提出来一个真实链路报警的未来展望)
(四)prometheus+grafana 企业网络传输 真实案例
使用公式 rate(node_network_transimit_bytes[1m])/1024/1024
最后这个咱们之前78讲的时候用过它举过例子
这里就不再重复了,公式大家可以直接使用
第十四讲:prometheus企业级实际使用(二)
prometheus+grafana TCP等待链接监控 企业实际使用
tcp等待链接其实之前应该给大家用这个举例子过好几次了
使用公式: count_netstat_wait_connections 一个key足够了
数据来源: pushgateway+脚本
其实node_exporter也有对应的tcpwait
不过里面提供的各种tcp状态的数据种类实在太多太细了(我有点懒得去一个一个tcp状态加起来出监控,不过感兴趣的同学可以自己尝试)
索性我这里就用脚本自己及写一个了
处于各种wait状态的tcp链接是作为运维平日排查(网络负载,服务器的负载,DB)的一个重要指标
netstat
close_wait,time_wait 等等.. (tcp:链接的)
一般当wait类型的tcp过大时,一定说明系统网络负载(流量负载)出现问题了
比如这种状况
导致这种状况的原因很多,并非只会因为网络不给力,还跟访问请求量攻击流量数据库CPU等等都有可能引起
prometheus+grafana 文件描述符监控 企业实际使用
linux系统我们之前在系列课程上篇时提到过本身就是一个基于文件表达的操作系统
任何资源的使用都可以映射一个文件
文件和文件句柄(linux中 叫作文件描述符更准确 不够习惯叫句柄 不好改口了) 虽然并无直接联系 但是有间接的连带关系
如下是一段网上对文件描述符的解释 我们来看下
文件描述符是linux/unix操作系统中特有的概念.其相当于windows系统中的句柄.习惯性的,我们也把linux文件描述符称之为句柄.
linux系统中,每当进程打开一个文件时,系统就为其分配一个唯一的整型文件描述符,用来标识这个文件.标准C中每个进程默认打开的有三个文件,标准输入,标准输出,标准错误,分别用一个file结构的指针来表示,即stdin,stout,sterr,这三个结构分别对应着三个文件描述符0,1,2.
文件描述符是一个简单的整数,用以标明每一个被进程所打开的文件和socket.第一个打开的文件是0,第二个是1,以此类推.linux操作系统通常对每个进程能打开的文件数量有一个限制.
linux系统默认的最大文件描述符限制是1024.
prometheus+grafana 网络丢包率监控 企业实际使用
网络监控
我们来看一下,一个企业中实际使用的对服务器内网流量ping延迟和丢包率
#ping prometheus server
lostpk=`timeout 5 ping -q -A -s 500 -W 1000 -c 100 prometheus|grep transmitted|awk \'{print $6}\'`
rrt=`timeout 5 ping -q -A -s 500 -W 1000 -c 100 prometheus|grep transmitted|awk \'{print $10}\'`
-s 一个ping包的大小
-W 延迟timeout
-c 发送多少个数据包
test----
value_lostpk=`echo $lostpk|sed "s/%//g"`
value_rrt=`echo $rrt|sed "s/ms//g"`
echo "lostpk_"$instance_name"_to_prometheus:$value_lostpk"
echo "lostpk_"$instance_name"_to_prometheus $value_lostpk"|curl --data-binary @-
http://prometheus.monitor.com:9092/metrics/job/pushgateway1/instance/localhost:9092
test----
echo "rrt_"$instance_name"_to_prometheus:$value_lostpk"
echo "lostpk_"$instance_name"_to_prometheus $value_rrt"|curl --data-binary @-http://prometheus.monitor.com:9092/metrics/job/pushgateway1/instance/localhost:9092
如上就是 使用scripts获取网络延迟和丢包率的实例
另外针对企业中对网络的监控,我们还可以通过安装smokping等更专业的网络监控工具来采集数据
smokping本身就提供很专业的图形展示命令行输出
当然我们为了统一化的考虑 也可以和prometheus连用
第十五讲:alertmanager连用(可选)
pagerduty注册新账号
pagerduty注册新账号(免费试用14天)
https://signup.pagerduty.com/accounts/new
我们新注册的pagerduty账号默认14天的免费试用时间
期间对于接收报警的数量是有一定限制的,不过对于我们学习阶段已经足够
pagerduty创建新的service,点击配置中的services选项
点击配置中的services选项,之后我们来新建一个service
之后我们把生成的这个newservice\'s interation key复制到我们grafana平台的notification_channel中(12讲中有讲过如何加载这个key)
就完成了grafana+pagerduty的连接
pagerduty报警信息的设置
做好了grafana+pagerduty的连接,最后我们自然就需要设置一下pagerduty给咱们用户发送报警信息
回到pagerduty的主页面后找到设置里的users选项卡
设置接收项目-电话/短信/邮箱
之后我们就可以正式开始使用了
另外在企业中使用的时候,我们需要在这里把所有需要接受报警信息的员工手机号邮箱地址同时都设置上
这样一来每一次发送报警,所有被加入的员工就都会收到了
第十六讲:prometheus专题讲座 总结和展望篇
我们通过这一个阶段的prometheus专题讲座的学习
我们对于prometheus这一款新兴的强大的开源监控平台应该有了一个不错的开始
其实对于我本人这10多年的运维生涯,我自己并不是一个新产品控(意思是说 并不是一贯只推崇使用最新的技术)
就拿监控工具来说,这些年用过的大概有10几种
客观的来说 每一款监控工具都有自己的优点缺点 并不是越新的就一定越好
就拿nagios和prometheus来说,虽然nagios它的年头很老了 而且很多功能已经比较落后了
但是 nagios即便在今天,运维工作中依然有它独立存在的意义
比如说:我之前所在的一家公司,我们核心监控使用的是prometheus,但是发现prometheus这个高大上的监控工具在某些很基本的监控项目中反而不如nagios好用
比如我们对一个整机的监控ping和telnet port
prometheus对这两项最简单的监控反而做的不够好
(prometheus有一个up功能函数,用来实现这种ping port的持续监控,但是由于这种ping类的监控,是一次性的发生并且只有两个状态up and down,这样一来就只有0 1两个数值会显示在prometheus上,很多时候汇总出来的图形会有误差)
所以我们后来针对这种最简单的ping and port
直接就迁移进入nagios,发现nagios对这种状态比较少的简单监控室最优秀的,而且还非常省时省力
prometheus呢,就专门用来应付比较难的监控业务逻辑需求,最简单的监控交给nagios.这样集联的来使用反而更能让监控体系完善
所以说,也证实了我刚才提到的并不是越新的工具就越好,而且最合适的工具使用在最合适的地点才是最好的
这也是我们作为一个运维架构师在给企业做综合框架设计时的一种专业态度
一句话 不好一味地只知道追新
另外,prometheus当前在国外尤其是欧美国家是非常流行了带起了一股用数学家的头脑做监控的风潮
prometheus经过充分学习的练习之后,它的搭建速度神一般的快速
下载和安装就不用说了很简单快速
而对于它的监控采集脚本开发其重复利用的成本非常的低尤其是系统基础层的监控几乎不用做什么修改直接放上去就可以再利用
grafana也是一样还记得咱们学过的json导出吗 也是一样的优点
另外随着对prometheus各种函数以及linux系统底层的深入理解,我们能自行实现的监控项目会越来越丰富越来越精细
而这种精细让我们未来的实现真实链路监控的目标变得越来越近了
监控在我们运维工作当中可以说是第一优先级
记得有一个老运维说过这么一句话,监控如果真的做的完美了,我们运维也就可以高枕无忧了,每天可以就看看监控,然后各种的\'挑刺儿\'就行了
可以看出了 监控在运维中的这种核心地位不可动摇