Cacti (英文含义为仙人掌)是一套基于PHP,MysQL,SNMP和RRDtoo1开发的网络流量监测图形分析工具。
它通过snmpget来获取数据,使用RRDtool绘图,但使用者无须了解RRDtool复杂的参数。它提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与IDAP结合进行用户认证,同时也能自定义模板,在历史数据的展示监控方面,其功能相当不错。Cacti通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力(数据的叠加功能)
Nagios是一款开源的免费网络监视工具,能有效监控windows, Linux和Unix的主机状态,交换机路由器等网络设置,打印机等在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员,在状态恢复后发出正常的邮件或短信通知。
nagios主要的特征是监控告警,最强大的就是告警功能,可支持多种告警方式,但缺点是没有强大的数据收集机制,并且数据出图也很简陋,当监控的主机越来越多时,添加主机也非常麻烦,配置文件都是基于文本配置的,不支持web方式管理和配置,这样很容易出错,不宜维护。
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。
zabbix由2部分构成, zabbix server与可选组件zabbix agento zabbix server可以通过SNMP, zabbixagent, ping,端口监视等方法提供对远程服务器/网络状态的监视,数据收集等功能,它可以运行在linux, Solaris, HP-UX,AIX, Free BSD, Open BSD, Os x等平台上。
zabbix解决了cacti没有告警的不足,也解决了nagios不能通过web配置的缺点,同时还支持分布式部署,这使得它迅速流行起来zabbix也成为目前中小企业监控最流行的运维监控平台。
当然, zabbix也有不足之处,它消耗的资源比较多,如果监控的主机非常多时(服务器数量超过500台) ,可能会出现监控超时、告警超时、告警系统单点故障等现象,不过也有很多解决办法,比如提高硬件性能、改变zabbix监控模式等。
作为一个数据监控解决方案,它由一个大型社区支持,有来自700多家公司的6300个贡献者, 13500个代码提交和7200个拉取请求
Prometheus具有以下特性:
多维的数据模型(基于时间序列的Key, Value键值对)
灵活的查询和聚合语言PromQL
提供本地存储和分布式存储通过基于HTTP的Pu11模型采集时间序列数据
可利用Pushgateway (Prometheus的可选中间件)实现Push模式可通过动态服务发现或静态配置发现目标机器
支持多种图表和数据大盘
open-Falcon是小米开源的企业级监控工具,用Go语言开发而成,包括小米、滴滴、美团等在内的互联网公司都在使用它,是一款灵活、可扩展并且高性能的监控方案
1、数据收集模块
2、数据提取模块
3、监控告警模块可细化为"6层模型
第六层:用户展示管理层 同一用户管理、集中监控、集中维护
第五层:告警事件生成层 实时记录告警事件、形成分析图表(趋势分析、可视化)
第四层:告警规则配置层 告警规则设置、告警伐值设置
第三层:数据提取层定时采集数据到监控模块
第二层:数据展示层 数据生成曲线图展示
第一层:数据收集层 多渠道监控数据
1.CPU、 Load、Memory、 swap、 Disk 1/O、 Process
2.网络监控:网络设备、工作负载、网络延迟、丢包率等(协议)
Kafka, RocketMQ、 Rabbitmg等消息代理
WEB服务容器: Tomcat
数据库/缓存数据库: MysQL, PostgresQL,MogoDB, es, redis
存储系统: Ceph、GFS等
用于衡量应用程序代码状态和性能
用于衡量应用程序的价值,如电商业务平台的销售量
OPS, DAU日活、转化率等
业务接口:登陆数量、注册数、订单量、搜索量和支付量
谷歌的内部大型集群系统borg
borg: kubernetes的前身borgmon (监控系统)对应克隆的版本: prometheus (go语言)
所以prometheus特别适合k8s的架构上
Prometheus是一套开源的监控&报警&时间序列数据库的组合
采集到的样本以时间序列的方式保存在内存(TSDB时序数据库)中,并定时保存到硬盘中
官网: https://prometheus.io/docs/concepts/data model/
prometheus特点
1.自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)
2.非常高效的存储平均一个采样数据占~3.5 bytes左右, 320万的时间序列,每30秒采样,保持60天,消耗磁盘大概228G.。
3.在多维度上灵活且强大的查询语言(PromQL)
4.不依赖分布式存储,支持单主节点工作
5.通过基于HTTP的pul1方式采集时序数据
6.可以通过push gateway进行时序列数据推送(pushing)。
7.可以通过服务发现或者静态配置去获取要采集的目标服务
8.多种可视化图表及仪表盘支持
什么时候合适?
Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视,也适用于高度动态的面向服务的体系结构的监视。在微服务世界中,它对多维数据收集和查询的支持是一种特别的优势。
Prometheus是为可靠性而设计的,它是您在中断期间要使用的系统,可让您快速诊断问题。每个Prometheus服务器都是独立的,而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时,您可以依靠它,并且无需设置广泛的基础结构即可使用它。
什么时候不适合?
普罗米修斯重视可靠性。即使在故障情况下,您始终可以查看有关系统的可用统计信息。如果您需要100%的准确性(例如按请求计费) ,则Prometheus并不是一个不错的选择,因为所收集的数据可能不会足够详细和完整。在这种情况下,最好使用其他系统来收集和分析数据以进行计费,并使用prometheus进行其余的监视。
时序数据,是在一段时间内通过重复测量(measurement)而获得的观测值的集合
将这些观测值绘制于图形之上,它会有一个数据轴和一个时间轴
服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据;
数据来源
prometheus基于HTTP call (http/https请求配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据
监控概念:白盒监控、黑盒监控
白盒监控:自省方式,被监控端内部,可以自己生成指标,只要等待监控系统来采集时提供出去即可
黑盒监控:对于被监控系统没有侵入性,对其没有直接"影响",这种类似于基于探针机制进行监控
Prometheus支持通过三种类型的途径从目标上“抓取(Scrape) "指标数据(基于白盒监控) :
Exporters 周期性的抓取数据
Instrumentation 监控对象内部
Pushgateway--专门对接数据保存
Prometheus同其它TSDB相比有一个非常典型的特性:它主动从各Target上"拉取(pull)"数据,而非等待被监控端的"推送(push) "
两个方式各有优劣,其中, Pull模型的优势在于:
集中控制:有利于将配置集在Prometheus Server上完成,包括指标及采取速率等;
Prometheus的根本目标在于收集在Target上预先完成聚合的聚合型数据,而非一款由事件驱动的存储系统;
prometheus生态圈中包含了多个组件,其中部分组件可选:
Prometheus Server:收集和存储时间序列数据;
Clienl Library:客户端库, 目的在于为那些期望原生提供InstrumenLalion功能的应用程序提供便捷的开发途径;
Push Gateway:接收那些通常由短期作业生成的指标数据的网关,并支持由PrometheusServer进行指标拉取操作;
Exporters:用于暴露现有应用程序或服务(不支持Instrumentation)的指标给Prometheus Server;
Alertmanager: 从prometheus Server接收到“告警通知"后,通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送:Data visualization: Prometheus web uI (Prometheus Server内建) ,及Grafana等;
Service discovery:动态发现待监控的Targct,从而完成监控配置的重要组件,在容器化环境中尤为有用;该组件目前由Promctheus Server内建支持
任何能够支持Scrape指标数据的应用程序都首先要具有一个测量系统
在Prometheus的语境中, Instrumentation是指附加到应用程序中的那些用于暴露程序指标数据的客户端库;程序员借助于这些客户端库编写代码生成可暴露的指标数据;
Prometheus Server是Prometheus组件中的核心部分,负责实现对监控数据的获取,存储以及查询。 Prometheus Server可以通过静态配置管理监控目标,也可以配合使用Service Discovery的方式动态管理监控目标,并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储,Prometheus Server本身就是一个时序数据库,将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言,实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI,通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据,因此在大规模监控的情况下,可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server,Prometheus Server通过访问该Exporter提供的Endpoint端点,即可获取到需要采集的监控数据。
一般来说可以将Exporter分为2类:
直接采集:这一类Exporter直接内置了对Prometheus监控的支持,比如cAdvisor,Kubernetes,Etcd,Gokit等,都直接内置了用于向Prometheus暴露监控数据的端点。
间接采集:间接采集,原有监控目标并不直接支持Prometheus,因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如: Mysql Exporter,JMX Exporter,Consul Exporter等。
由于Prometheus数据采集基于Pull模型进行设计,因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时,就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。
补充说明:Prometheus抓取数据的两种模式 (1) push 模式(2)pull模式
push 模式 :这种模式我们可以灵活的zai被监控端使用各种语言编写数据采集脚本,通过PushGateway传输给Prometheus,传输方式为http
pull 模式 :我们直接使用采集数据客户端xxx_exporters将数据传输给Prometheus,已经有很多xxx_exporters详见官档,同样也是http
抓取异常值, pro通过告警机制发现和发送警示
在Prometheus Server中支持基于PromQL创建告警规则,如果满足PromQL定义的规则,则会产生一条告警,而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件,Slack等等内置的通知方式进行集成,也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。
1.prome theus-server: retrieval (获取数据pull/discover) , TSDB存储, HTTPserver控制台接口内建了数据样本采集器,可以通过配置文件定义,告诉prometheus到那个监控对象中采集指标数据, prometheus采集过后,会存储在自己内建的TSDB数据库中(默认为2个月时间) ),提供了promgL支持查询和过滤操作,同时支持自定义规则来作为告警规则,持续分析一场指标,一旦发生,通知给alcrter来发送告警信息,还支持对接外置的UI工具(gralana)来展示数据
2.pushgateway (短周期任务)允许短暂和批量作业将其指标暴露给普罗米修斯。由于这些类型的作业可能存在时间不足以被删除,因此他们可以将其指标推送到Pushgateway,然后, Pushgateway将这些指标暴露给普罗米修斯(prometheus-server端),主要用于业务数据汇报等。各种汇报数据的exporters :例如汇报机器数据的node exporter,汇报MongoDB信息的MongoDB exporter等等。
3.exporters (常规任务-守护进程) :采集一些web服务、nginx, mysq1服务例如nysq1服务,因不适合直接通过http的方式采集数据,所以需要通过exporter采集"数据(下载mysql exporter,采集mysq1数据指标,)cadvisor: docker数据收集工具(docker也有自己内置的监控收集方式)
4.exporter和instrumtations,采集服务数据,然后暴露出来inst.rument.ation :服务内建的数据
5.service discovery:原生支持k8s的服务器发现,支持consul, DNS等
6.prometheus内置TSDB (时序数据的存储, prometheus的TsDB数据库默认保存15天,可自行调整)数据库作为存储PS:时间序列数据库(时序数据库)主要用于指处理带时间标签(按照时间的顺序变化,即时间序列化)的数据,带时间标签的:据也称为时间序列数据,这是一种特殊类型的数据库,一般不会保存长时间的数据(与mysq1相比)数据保存时间在–storage.t.sdb. retent.ions90d参数中修改即可(或启动时指定)
7.alertmanager : pro可以生成告信息,但是不能直接提供告警,需要一个外置的组件altermanager来i行古, emai.etcd优势在于,收敛、支持静默、去重、可以防止告警信息的轰炸
8.Data Visualization: Prometheus web UI (Prometheus Server内建) ,及Grafana等
9.PrmoQL (告警规则编写) ,通过告警规则的文件指定输出到展示界面(grafana)
10.UI表达式浏览器,只是为了调试
1.prometheus server可以定期从活跃的目标监控主机上拉取监控数据,目标监控主机可以通过配置静态job或者服务发现的方式被prometheus
server采集到的,这种方式是默认的pull方式拉取指标,也可以通过pushgateway去收集目标监控主机的数据最后上报给prometheus server,也可以通过自带的exporter采集相应的数据
2.prometheus把采集到的监控指标数据保存到本地磁盘或者数据库中
3.prometheus采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到alertmanager
4.altermanager通过配置报警接收方,发送报警到邮箱、微信、钉钉等
5.prometheus自带的web ui界面提高promeql查询语言,可以查询监控数据
6.grafana可接入prometheus数据源,展示监控数据
Prometheus将所有采集到的样本数据以时间序列(time-series)的方式保存在内存数据库中,并定时保存在硬盘上。时间序列中的每一个样本由以下三部分组成。
指标(metric)
: metric name和描述当前样本特征的labelsets组成,参考格式如 {=, …};,其中metric name的命名规则为:应用名称开头_监测对像_数值类型_单位
时间截(timestamp)
:一个精确到毫秒的时间截;
样本值(value)
:一个float64的浮点类型数据表示当前的样本值。
• Counter:递增的计数器
适合:API 接口请求次数,重试次数。
• Gauge:可以任意变化的数值
适合:cpu变化,类似波浪线不均匀。
• Histogram:对一段时间范围内数据进行采样,并对所有数值求和与统计数量、柱状图
适合:将web 一段时间进行分组,根据标签度量名称,统计这段时间这个度量名称有多少条。
适合:某个时间对某个度量值,分组,一段时间http相应大小,请求耗时的时间。
• Summary:与Histogram类似,Summary和Histogram十分相似
常用于跟踪事件发生的规模,例如:请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。它提供一个quantiles的功能,可以按%比划分跟踪的结果。