admin管理员组文章数量:1570425
目录
一、概述
1.Zabbix和Prometheus区别
2.prometheus特点
二、Prometheus基础架构
1.报警和监控
2.优秀的报警系统pagerduty
3.Prometheus相比其他的监控,优势
4.不足的地方
5.监控的分类
6.Prometheus监控的优质特性
三、Prometheus安装-图形界面展示
四、Prometheus组件
五、Prometheus metrics概念
六、metrics的几种类型
1.Gauges
2.counters
3.Histograms
七、exporter的使用
八、Prometheus配置文件
九、部署node_exporter组件
十、部署mysqld_exporter 组件
1.在mysql中创建监控用户,并赋权
2.为mysqld_exporter 创建个配置文件
3.启动组件
十一、配置Prometheus获取监控数据
十二、部署grafana
1.为grafana配置Prometheus数据源
2.Grafana 展示 Linux 的监控数据
3.Grafana 展示 MySQL 的监控数据
4.告警配置
一、概述
Prometheus 是一个开源监控系统,它前身是 SoundCloud的告警工具包。从 2012 年开始,许多公司和组织开始使用 Prometheus。该项目的开发人员和用户社区非常活跃,越来越多的开发人员和用户参与到该项目中。目前它是一个独立的开源项目,且不依赖于任何公司。为了强调这点和明确该项目治理结构,Prometheus 在 2016 年继Kurberntes 之后,加入了 Cloud Native Computing Foundation。
1.Zabbix和Prometheus区别
和Zabbix类似,Prometheus也是一个近年比较火的开源监控框架,和Zabbix不同之处在于Prometheus相对更灵活点,模块间比较解耦,比如告警模块、代理模块等等都可以选择性配置。服务端和客户端都是开箱即用,不需要进行安装。zabbix则是一套安装把所有东西都弄好,很庞大也很繁杂。 zabbix的客户端agent可以比较方便的通过脚本来读取机器内数据库、日志等文件来做上报。而Prometheus的上报客户端则分为不同语言的SDK和不同用途的exporter两种,比如如果你要监控机器状态、mysql性能等,有大量已经成熟的exporter来直接开箱使用,通过http通信来对服务端提供信息上报(server去pull信息);而如果你想要监控自己的业务状态,那么针对各种语言都有官方或其他人写好的sdk供你使用,都比较方便,不需要先把数据存入数据库或日志再供zabbix-agent采集。 zabbix的客户端更多是只做上报的事情,push模式。而Prometheus则是客户端本地也会存储监控数据,服务端定时来拉取想要的数据。 界面来说zabbix比较陈旧,而prometheus比较新且非常简洁,简洁到只能算一个测试和配置平台。要想获得良好的监控体验,搭配Grafana还是二者的必走之路。
2.prometheus特点
多维度数据模型,一个时间序列由一个度量指标和多个标签键值对确定 灵活的查询语言,对收集的时许数据进行重组 强大的数据可视化功能,除了内置的浏览器,也支持grafana集成 高效存储,内存加本地磁盘,可通过功能分片和联盟来拓展性能 运维简单,只依赖于本地磁盘,go二进制安装包没有任何其他依赖 精简告警 非常多的客户端库 提供了许多导出器来收集常用系统指标。
promQL一种灵活的查询语言,可以利用多维数据完成复杂查询。
二、Prometheus基础架构
service discovery:服务发现
左边部分就是数据采集模块的两种方式如pushgatway和exporters
右边部分就是监控报警模块Prometheus成图绘图增强功能的方式
如上图,Prometheus 主要由以下部分组成:
Prometheus Server:主要是负责存储、抓取、聚合、查询方面。(服务器端) Alertemanager:主要是负责实现报警功能。 Pushgateway:主要是实现接收有 Client-push 过来的指标数据,在指定的时间间隔,有主程序来抓取。 *_exporter:主要是负责采集物理机、中间件的信息。(客户端)
1.报警和监控
报警和监控是需要严格区分开来的,监控是监控数据,报警有自己专门的报警系统,包括:短信报警,邮件报警,电话报警等,不想监控系统比较成型的报警系统,没有钱大多数是要收费的,商业化的。
报警系统中,最重要的一个概念就是对报警阈值的理解。
阈值(trigger value):是监控系统中,对数据到达某一个临界值的定义:例如一台机器cpu突然升高,超过了80%的使用率,80就是作为一次报警的出发阈值。
2.优秀的报警系统pagerduty
pagerduty在企业中,尤其是外企出境率非常高,它的费用也相对非常便宜
pagerduty拥有短信,电话,邮件所有的报警机制。
pagerduty还有非常实用的必要的运维值班管理制度和报警升级等等扩展功能
不足的问题:对中文支持不好,几乎不支持,站点在外网网络不太行。
3.Prometheus相比其他的监控,优势
监控数据的惊喜程序,绝对的第一可以精确到1-5s的采集精度
集群部署的速度,监控脚本的制作,非常快速大大缩短监控的搭建时间成本
周边插件很丰富,大多数都不需要自己开发
本身基于数学计算模型,大量的实用函数,可以实现很复杂的业务逻辑监控
可以嵌入很多开源工具的内部进行监控,数据更准时更可信
本身是开源的,更新速度快,bug修复快,支持n多种语言做本身和插件的二次开发
图形很难高大上很美观,老板特别喜欢这周业务图(和grafana的结合)
4.不足的地方
因数据采集的精度,如果集群数量太大,那么单点的监控有性能瓶颈,目前尚不支持集群,只能workaround
学习成本太大,尤其是其独有的数学命令行(非常强大的同时有机器难学),中文资料少
对磁盘资源消耗也非常大,这个具体要看监控的集群量和监控项的多少,还有保存时间的长短
本身的实用需要使用者的数学不难太差
5.监控的分类
业务监控:可以包含用户访问QPS,DAU日活,访问状态,业务接口(登陆,注册,聊天,上传等)
系统监控:主要是跟操作系统相关基本监控项,CPU/内存/硬盘/IO/TCP链接/流量
网络监控:对网络状态的监控,互联网公司必不可少,但很多时候会被忽略,如:丢包率,延迟等
日志监控:监控种的重头戏,往往单独设计和搭建,全部种类的日志都需要采集
程序监控:一般需要和开发人员配置,程序中嵌入各种接口,直接获取数据或者特质的日志格式
6.Prometheus监控的优质特性
基于时间序列模型(time series)
时间序列(time series)是一系列有序的数据,通常是等时间间隔的采样数据
基于K/V的数据模型
Key/value键值的概念:数据格式简单,速度快,易维护开发
采样数据的查询完全基于数学的运算,而不是其他的表达式,并提供转悠的查询输入console
采用HTTP pull/push两种对应的数据采集传输方式
开源,且大量的社区成品插件
pus
本文标签: prometheus
版权声明:本文标题:prometheus 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dianzi/1727663310a1124432.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论