Prometheus 监控

常用监控介绍

常用监控简介

1、 cacti
Cacti(英文含义为仙人掌〉是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测图形分析工具。它通过snmpget来获取数据，使用RRDTool绘图，但使用者无须了解RRDPool复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能)
2、Nagios
Nagios是一款开源的免费网络监视工具，能有效监控windows、Linux和nix的主机状态，交换机路由器等网络设置打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。
nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文木配置的，不支持web方式管理和配置，这样很容易出错,不直维护。
3、zabbix
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabix能监视各种网络参数，保证服务器系统的安全运营;并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。
①agent代理:专门的代理服务方式进行监控，专属的协议，装有zabbix-agent的主机就可以被zabbix-server监控，主动或被动的方式，把数据给到server进行处理。
②ssh/telent: linux主机支持ssh/telent协议
③snmp:网络设备路由器、交换机不能安装第三方程序(agent)，使用简单网络协议。大多数的路由器设备支持SuwMP协议
④ipmi:通过ipmi接口进行监控，我们可以通过标准的iomi硬件接口，监控被监控对象的物理特征，比如电压，温度，风扇状态电源情况，被广泛使用服务监控中，包括采集cpu温度，风扇转速，主板温度，及远程开关机等等，而且ipmi独立于硬件和操作系统，无论是cpu，bios还是os出现故障，都不会影响ipmi的工作，因为ipmi的硬件设备BNC (bashboardmanagement controller)是独立的板卡，独立供电
⑤zabbix核心组件介绍

zabbix

Server:?Zabbix软件实现监控的核心程序，主要功能是与Zabbixproxies和Agents进行交互、触发器计算、发送告警通知;并将数据集中保存。与prometheus的类似可以保存收集到的数据，但是prometheus告警需要使用alter manager组件

Database storage :

存储配置信息以及收集到的数据

web Interface :

Zabbix的GUI接口，通常与server运行在同一台机器上

Proxy:

可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据，分担zabbix Server的负载的程序

Agent:

部署在被监控主机上，负责收集数据发送给server

Prometheus

borg .kubernetes ：borgmon (监控系统)对应克隆的版本:prometheus(go语言)

Prometheus具有以下特性:

①维的数据模型(基于时间序列的Key、 value键值对)
②灵活的查询和聚合语言PromQL(难)
③提供本地存储和分布式存储
④通过基于HTTP和HTTPs的Pull模型采集时间序列数据（pull数据的推送，时间序列:每段时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图)
⑤可利用Pushgateway (Prometheus的可选中间件）实现Push模式
⑥可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩)
⑦支持多种图表和数据大盘
补充: open-Falcaon是小米开源的企业级监控工具，用co语言开发，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可拓展并且高性能的监控方案。

二、监控系统背景

1、监控系统”三代”

第一代:以监控网络设备、网络流量为主的时代，代表协议（SNMP，监控交换机、路由、网关、操作系统等)
第二代(当今):zabbix prometheus cacti nagios open-falcaon等等72通常具备:数据采集、存储、告警+展示/可视化等基本功能
第三代（大厂):基于data驱动、ai驱动datavops aivops，(立体监控)需要了解在立体监控系统支撑下对系统运行状态的分析、监控、反馈到系统展示

2、基础/逻辑概念前提（一) :

监控系统的四个基础功能以监控系统的主体而言：
使用/管理者所关注的被监控"系统"(端）的相关组件，例如路由器、交换机、网关、应用、基础设施服务、业务特征等

3、基础/逻辑概念(二) :

但以上组件必须允许在基础设施层，例如物理主机、vm、 container

①指标数据采集到之后，作为"点状数据"，而此类点状数据称之为【样本数据】
②而此类【样本数据】做为事后的分析(趋势分析)，那么如果我们所需要监控的目标特别多，那么我们就需要存储大量数据
③那么在持续存储性能表现上必须要强【TSDB数据库】，那么接下来对此类样本数据进行分析，明确系统运行状态、特性，来预)、判断未来的某一时间、时刻是否会出现问题时我们的目的
④同时为了结果的可观测及清晰性，我们会做一些【可视化】处理分析功能，所以需要控制台（例如grafana)06(自前的形式,可视化与底代码趋势)
⑤我们也需要有一个守护进程，实时监测特定的样本序列、指标时间序列是否有异常状态08而通常此类异常状态的判断会以一种【布尔值表达式】的方式来做为判断依据
⑥满足布尔值表达式的要求的指标我们认为时异常指标，而此时我们就可以通过触发一种"媒介"(mnadia),把异常信息通知给用户

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

1.数据收集模块
2.数据提取模块
3.监控告警模块
###可以细化为6层
第六层:用户展示管理层―同一用户管理、集中监控、集中维护
第五层:告警事件生成层―实时记录告警事件、形成分析图表（趋势分析、可视化)
第四层:告警规则配置层―告警规则设置、告警伐值设置
第三层:数据提取层定时采集数据到监控模块
第二层:数据展示层――数据生成曲线图展示（对时序数据的动态展示)
第一层:数据收集层:多渠道监控数据

三、 prometheus监控体系

(一)监控体系:

1、系统层监控(需要监控的数据)
①CPU、Load、Memory、swap、disk i/o、process等
②网络监控:网络设备、工作负载、网络延迟、丢包率等
2、中间件及基础设施类监控端监控（移动APP、特定程序等)
①消息中间他:kafka、RocketMQ、等消息代理
②WEB服务器容器: tomcat
③数据库/缓存数据库:MySQL、PostgresQL、MogoDB、es、redis
3、 应用层监控
用于衡量成用程序代码状态和性能

监控的分类

白盒监控，白省指标（可自己产生指标，白治功能），等待被获取
黑盒指标:基于探针的监控方式，不会主动干预、影响数据
4、业务层监控
用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，业务接口:登入数量，注册数、订单量、搜索量和支付量

可观测性系统（立体监控）以下为三个维度：

①指标监控﹔随时间推移产生的一些与监控相关的可聚合的数据点（离散数据)，pro做为代表
②日志监控:离散式的日志或事件（日志结构化、非结构化概念)
③链路跟踪:分布式应用调用链跟踪（时长、状态数据)

Prometheus简介

谷歌的内部大型集群系统borg，是kubernetes的前身。其监控系统是Prometheus，而iprometheus是其克隆版，所以非常契合k8s的监控对容器非常适用。

监控的关键组件
TSDB: pro通过采集的样本以时间序列的方式保存在内存（TSDB时序数据库）中并定时保存到硬盘中（持久化)
target:主要指可输出、产生指标数据的组件/对象，包括但不限于主机、应用、服务、K8S ingress (逻辑主键)等
时序数据:一段时间内通过重复测量而获得的观测值的集合，并且可将这些观测值绘制与图形之上，以数据轴（纵轴）和时间轴（横轴）来表示随着时间流逝而产生的“渐变"变化（类似与股票)

.Prometheus特点:

自定义多维数据模型（时序列数据由metric名和一组key/value标签组成)
非常高效的储存平均一个采样数据占大约3.5bytes左右，320万的时间序列，每30秒采样，默认保持60天，消耗磁盘大概2286218在多维上灵活且强大的查询语句《 PromQL)
不依赖分布式储存，支持单主节点工作
通过基于HTTP的pull方式采集时序数据
可以通过push gateway进行时序列数据库推送(pushing)
可以通过服务发现或静态配置去获取要采集的目标服务器
多种可视化图表及仪表盘支持
##prometheus最难的两个部
 promQL查询语句
 重打标签

prometheus生态组件

prometheus生态圈中包含了多个组件，其中部分组件可选

1.Prometheus server:收集和储存时间序列数据通过scraping以刮擦的方式去获取数据放入storge(TSDE时序数据库），制定Rule/Alerts:告警规则，servicediscovery是自动发现需要监控的节点
2.client Library:客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径
3.Push Gateway:接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作;
4.Exporters:用于暴露现有应用程序或服务（不支持Instrumentation)的指标给Prometheus serve
5.Alertmanager:由告警规则对接，从Prometheus Server接收到"告警通知"后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送
6.Data Visualization (Dashboards):与TSbB对接并且展示数据库中的数据，Prometheus web UI(Prometheus server内建)，及Grafana等;
7.service
Discovery:动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由FropetheusSserver内建支持