prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。)

一、常用监控简介

Cacti(英文含义为仙人掌〉是一套基于 PHP、MysQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。 它通过snmpget来获取数据,使用RRD"ocl绘图,但使用者无须了解RDPocl复杂的参数。它提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与LDAP 结合进行用户认证,同时也能自定义模板,在历史数据的展示监控方面,其功能相当不错。Cacti 通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力(数据的叠加功能) 2、Nagios Nagios是一款开源的免费网络监视工具,能有效监控windows、Linux和Unix的主机状态,交换机路由器等网络设置打印机等。在系统或服务状态异灞时发出邮件或短信报警第一时间通知网站运维人员,在状态恢复后发出正常的邮件或短信通知。 nagios主要的特征是监控告警,最强大的就是告警功能,缺点是没有强大的数据收集机制,并且数据出图也很简陋,当监控的主机越来越多时,添加主机也非常麻烦,配置文件都是基于文本配置的,不支持web方式管理和配置,这样很容易出错,不宜维护。 3、Zabbix zabbix是一个基于wBB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。 zabbix由2部分构成,zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP,zabbix agent,ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在Linux, Solaris,H-UX,AIX,Free BSD,OpenBSD,os x等平台上。 zabbix解决了cacti没有告警的不足,也解决了nagios不能通过web配置的缺点,同时还支持分布式部署,这使得它迅速流行起来,zabyix也成为目前中小企业监控最流行的运维监控平台。 当然,zabbix也有不足之处,它消耗的资源比较多,如果监控的主机非常多时(服务器数量超过500台),可能会出现监控超时、告警超时、告警系统单点故障等现象,不过也有很多解决办法,比如提高硬件性能、改变zabbix监控模式、多套zabbix等 agent代理。专门的代理服务方式进行监控,专属的协议,装有zabix-agent的主机就可以被zabbix-server监控,主动或被动的方式,把数据给到srver进行处理。 ssh/telent: linux主机支持ssh/telent协议 snmp;网络设备路由器、交换机不能安装第三方程序(agent),使用简单网络协议。大多数的路由器设备支持snmp协议 ipmi通过ipmi接口进行监控,我们可以通过标准的ipmi硬件接口,监控被监控对象的物理特征,比如电/压,温度,风扇状态电源情况,被广泛使用服务监控中,包括采集cpu温度,风扇转递,主板温度,及远程开关机等等,而且ipmi独立于硬件和操作系统,无论是cpu, bios还是ost出t现故障,都不会影响ipmi的工作,因为ipmi的硬件设备BNCc (bashboard management controller)是独立的板卡,独立供电 zabbix核心组件介绍 zabbix Server: zabbix软件实现监控的核心和序,主要功能是与zabbixproxies和Agents进行交互、触发器计算、发送告警通知;并将数据集中保存。与prontheus的类似可以保存收集到的数据,但是prometheus告警需要使用alter manager组件 Database storage:存储配置信恩以及收集到的数据 web Interface: Zabbix的GUI接口,通常与server运行在同一台机器上 Proxy:可选组件,常用于分布式监控环境中,一个帮助zabbix Server收集数据,分担zabbix Server的负载的程序Agent:部署在被监控主机上,负责收集数据发送给server 4、PrometheusIborg. kubernetes borgmon(监控系统)对应克隆的版本:prometheus(go语言)所以prometheus特别适合K8S 的架构上 而作为一个数据监控解决方案,它由一个大型社区支持,有来自700多家公司的6300个贡献者,13500个代码提交和7200个拉取请求 Prometheus具有以下特性: 1.多维的数据模型(基于时间序列的Key、 value键值对) 2.灵活的查询和聚合语言PromQL 3.提供本地存储和分布式存储 4.通过基于HTTP和HTTPs的Pull模型采集时间序列数据(pull数据的推送,时间序列:每段时间点的数据值指标,持续性的产生。横轴标识时间,纵轴为数据值,一段时间内数值的动态变化,所有的点连线形成大盘式的折线图) 5.可利用Pushgateway (Prometheus的可选中间件)实现Push模式 6.可通过动态服务发现或静态配置发现目标机器(通过consul自动发现和收缩)支持多种图表和数据大盘 *补充: open-Falcaon是小米开源的企业级监控工具,用co语言开发,包括小米、滴滴、美团等在内的互联网公司都在使用它,是一款灵活、可拓展并且高性能的监控方案。

二、运维监控平台设计思路

1.数据收集模块 2.数据提取模块(prometheus-TSDB 查询语言是PromQL) 3.监控告警模块―(布尔值表达式判断是否需要告警Promg (cPu使用率)>80%) 町以细化为6层 第六层:用户展示管理层同一用户管理、集中监控、集中维护 第五层:告警事件生成层―实时记录告警事件、形成分析图表(趋势分析、可视化) 第四层:告警规则配置层告警规则设置、告警伐值设置 第三层:数据提取层定时采集数据到监控模块 第二层:数据展示层―数据生成曲线图展示(对时序数据的动态展示)第一层:数据收集层多渠道监控数据

三、prometheus监控体系(一)监控体系:

系统层监控(需要监控的数据) 1.cPU、Load、Memory、swap、disk i/o、process等 2.网络监控:网络设备、工作负载、网络延迟、丢包率等 中间件及基础设施类监控 1.消息中间件:kafka、RocketMQ、等消息代理 2.wEB服务器容器: tomcat 3.数据库/缓存数据库:MySQI、PostgresQL、MogoDB、es、 redisredis监控内容: redis所在服务器的系统层监控redis 服务状态 RDB AOF日志监控 日志—>如果是哨兵模式—>哨兵共享集群信息,产生的日志—>直接包含的其他节点哨兵信息及redis信息 key的数量 key被命中的数据/次数 最大连接数——》redis 和系统:系统: ulimit -a redis:redis-cli登陆—》config get maxclients查看最大连接 应用层监控 用于衡量应用程序代码状态和性能#监控的分类#:黑盒监控,白盒监控PS: 白盒监控,自省指标,等待被下载 黑盒指标:基于探针的监控方式,不会主动干预、影响数据 业务层监控 用于衡量应用程序的价值,如电商业务的销售量,ops、dau日活、转化率等,业务接口:登入数量,注册数、订单量、搜索量和支付量

四、prometheus使用场景

1.Prometheus特点: 自定义多维数据模型(时序列数据由metric名和一组key/value标签组成) 非常高效的储存平均一个采样数据占大约3.5bytes左右,320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G 在多维上灵活且强大的查询语句( PromQL) 不依赖分布式储存,支持单主节点工作通过基于HTTP的pull方式采集时序数据 可以通过push gateway进行时序列数据库推送(pushing>可以通过服务发现或静态配置去获取要采集的目标服务器多种可视化图表及仪表盘支持 2.使用场景 Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视,也适用于高度动态的面向服务的体系结构的监视。在微服务世界中,它对多维数据收集和查询的支持是一种特别的优势。(k8s) Prometheus是为可靠性而设计的,它是您在中断期间要使用的系统,可让您快速诊断问题。每个Prometheus服务器都是独立的,而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时,您可以依靠它,并且无需设置广泛的基础结构即可使用它 3.不适合的场景 普罗米修斯重视可靠性。即使在故障情况下,您始终可以查看有关系统的可用统计信息。如果您需要100 %的准确性(例如按请求计费),则Pprometheus并不是一个不错的选择,因为所收集的数据可能不会足够详细和完整。在这种情况下,最好使用其他系统来收集和分析数据以进行计费,并使用erometheus进行其余的监视。

五、prometheus时序数据

时序数据,是在一段时间内通过重复测量(measurement》而获得的观测值的集合将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴,服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据; 1.数据来源: prometheus基于HrTP call (http/https请求),从配置文件中指定的网络端点(endpoint/TP;:端口)上周期性获取指标数据。 很多环境、被监控对象,本身是没有直接响应/处理http请求的功能,prometheus-exporter则可以在被监控端收集所需的数据,收集过来之后,还会做标准化,把这些数据转化为prometheus可识别,可使用的数据(兼容格式) 2.收集数据: 监控概念:白盒监控、黑盒监控 白盒监控:自省方式,被监控端内部,可以自己生成指标,只要等待监控系统来采集时提供出去即可 黑盒监控:对于被监控系统没有侵入性,对其没有直接"影响",这种类似于基于探针机制进行监控(snmp协议) Prometheus支持通过三种类型的途径从目标上"抓取(Scrape)"指标数据(基于白盒监控); Exporters—>工作在被监控端,周期性的抓取数据并转换为pro兼容格式等待prometheus来收集,自己并不推送 Instrumentation—>指被监控对象内部自身有数据收集、监控的功能,只需要prometheus直接去获取 Pushgateway ——>短周期5s—10s的数据收集 3.prometheus(获取方式) Prometheus同其它rsDB相比有一个非常典型的特性:它主动从各Target.上拉取(pull)数据,而非等待被监控端的推送(push) 两个获取方式各有优劣,其中,Pull模型的优势在于: 集中控制:有利于将配置集在Prometheus server上完成,包括指标及采取速率等; Prometheus的根本目标在于收集在rarget上预先完成聚合的聚合型数据,而非一款由事件驱动的存储系统通过targets (标识的是具体的被监控端) 比如配置文件中的targets: [ 'localhost : 9090'] exporter收集了200行数括cpu使用率{ code='cpu0'}cpu使用率{ code='cpul'}cpu使用率{ code='cpu2' }##### schme { "http" } HOST { "192.168.226.128"}Port { "9100"} PATH{ " / usr / local/ nginx/"} 需求是输出完整的URL _sdhme_host_port_path { "http://192.168.226.128:9100/usr/local/nginx" }

六、prometheus生态组件

prometheus生态圈中包含了多个组件,其中部分组件可选 1.prometheus-server: retrieval(获取数据pull/discover) ,TSDB存储,HTPserver 控制台接口,内建了数据样本采集器,可以通过配置文件定义,告诉prometheus到那个监控对象中采集指标数据,prome theus采集过后,会存储在自己内建的rSDB数据库中(默认为2个月时间1),提供了promgL支持查询和过滤操作,同时支持自定义规则来作为告警规则,持续分析一场指标,一旦发生,通知给alerter来发送告警信息,还支持对接外置的UI工具 (grafana)来展示数据 2.pushgateway (短期周期任务) 允许短暂和批量作业将其指标暴露给普罗米修斯,由于这些类型的作业可能存在时间不足而被删除,因此他们可以将其指标推送到pushgateway,然后pushgateway将这些指标暴露给Prometheus-server端,主要用于业务数据汇报 3.exporters (常规任务-守护进程) 专门采集一些web服务,nginx, mysql服务。因为不适合直接通过attp的方式采集数据,所以需要通过exporter采集数据(下载mysql_exporter,采集mysql数据指标) cadvisor: docker数据收集工具(docker也有自己内置的监控收集方式 exporter和instrumtations,负责专门服务数据的收集然后暴露出来等待promtheus收集 4.service discovery:原生支持k8s的服务发现,支持consul、DNS等 5.prometheus内置TSDB数据库作为存储(时序数据的储存,promtheus的TSDB数据库默认保存15天,可以自行调整) ps:时间序列数据库(时序数据库)主要用于指处理代表签(按照时间的顺序变化,既时间序列化)的数据,带时间标签的数据也成为时间序列数据,这是一种特殊类型的数据库,一般不会保存长时间的数据(与mysql相比)。 数据保存时间storge.tsdb.retention=90d参数中修改即可(或启动时间指定) 6.alertmanagr: prometheus可以生成告警信息,但是不能直接提供告警,需要使用一个外置的组件altermanager来进行告警,emailteor代t势在于,收敛、支持静默、去重、可以防止告警信息的轰炸 7.data visualization: prometheus web ui (prometheus-server内建),也可以便用grafana 8.PrmoQL (告警规则编写),通常告警规则的文件指定输出到展示界面(grafana) 9.ui表达式浏览器(调试)  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。)

七、安装prometheus

第一步准备  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第二步解压  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第三步进入目录,执行脚本  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第四步查看端口  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第五步浏览器登入  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第六步查看状态  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。) 第七步查看内置数据  prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。)

 prometheus监控介绍1.0(故事的结局总是这样,花开两朵,天各一方。)

八、prometheus数据模型(什么是标签、什么是指标、什么是样本)-概述

prometheus仅用键值方式存储时序式的聚合数据,他不支持文本信息 其中的""键"成为指标(metric),通常意味着cpu速率、内存使用率或分区空闲比例等 向一指标可能适配到多个目标或设备、因而它使用"标签"作为元数据,从而为metric添加更多的信息描述维度例如三台设备,在同一时刻,都会产生例如1分组cPu负载的数据,他们都公使用相同的指标(metric),而此时一个指标,如何表示时间序列? 比如:三个node节点都公有相同的指标(例如cpu0的负载那么就公使用相同的指标名称) 使用指标:标签=标签值的格式来表乐,例如: local1 (host=node1, host=node2 ) metric icpu指标): 示例: cpu_usage{ core-" 1 ',ip-"192.168.226.128" 14.04 key cpu0 labels (元数据) 样本 1 2 prometheus每一份样本数据都包含了: 时序列标识:key+lables 当前时间序列的样本值value这些标签可以作为过滤器进行指标过滤及聚合运算,如何从上万的数据过滤出关键有限的时间序列,同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们需求的样本数据
上一篇:【SpringCloud】<微服务>Ribbon负载均衡


下一篇:java获取ip,spring boot获取访问者ip地址绕过代理