热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

轻松入门普罗米修斯

轻松入门普罗米修斯Prometheus(由go语言(golang)开发)是一开源的监控&报警&时间序列数据库的组合。适合监控docker容器。因为kubernetes(俗称k8s)

轻松入门普罗米修斯

Prometheus(由go语言(golang)开发)是一开源的监控&报警&时间序列数据库的组合。 适合监控docker容器。因为kubernetes(俗称k8s)的流行带动了 prometheus的发展。

普罗原理架构图:

 

 

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层

第六层:用户展示管理层同一用户管理、集中监控、集中维护

第五层:告警事件生成层―实时记录告警事件、形成分析图表(趋势分析、可视化)

第四层:告警规则配置层告警规则设置、告警伐值设置

第三层:数据提取层定时采集数据到监控模块

第二层:数据展示层―数据生成曲线图展示(对时序数据的动态展示)第一层:数据收集层多渠道监控数据

 

 

 


普罗监控体系:

系统层监控(需要监控的数据)

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数据模型(什么是标签、什么是指标、什么是样本)-概述

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这些标签可以作为过滤器进行指标过滤及聚合运算,如何从上万的数据过滤出关键有限的时间序列,同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们需求的样本数据

(一)指标类型

默认都是以双精度浮点型数据(服务端无数据量类型数据)

counter :计数器单调递增

gauge :仪表盘:有起伏特征的histogram:直方图:

在一段时间范围内对数据采样的相关结果,并记入配置的bucket中,他可以存储更多的数据,包括样本值分布在每个bucket的数量,从而prometheus就可以使用内置函数进行计算:

计算样本平均值:以值得综合除以值的数量

计算样本分位值:分位数有助于了解符合特定标准的数据个数,例如评估响应时间超过1秒的请求比例,若超过20%则进行告警等 summary,摘要,histogram的扩展类型,它是直接由监控端自行聚合计算出分位数,同时

将计算结果响应给prometheus server的样本采集请求,因而,其分位数计算是由监控端完成

(二)作业job和实例targets/instance

job:能够接收prometheus server数据scrape

targets每一个可以被监控的系统,成为targets多个相同的targets的集合(类)称为jobinstance:实例与targets (类似)

与target相比,instance更趋近于一个具体可以提供监控数据的实例,而targets则更像一个对象、目标性质



(三) prometheusQL(数据查询语言也是时序数据库使用语言)支持两种向量,同时内置提供了一组用于数据处理的函数

o即时向量:最近以此时间戳上跟踪的数据指标(一个时间点上的数据)

即时向量选择器:返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本该样本成为即时样本

时间范围向量:指定时间范围内所有时间戳上的数据指标

范围向量选择器:返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)

 

 

 

 

 

 

 

 

自古英雄多磨难


原文链接:https://www.cnblogs.com/lvrui/p/15674535.html



推荐阅读
  • docker镜像重启_docker怎么启动镜像dock ... [详细]
  • 本文探讨了如何在日常工作中通过优化效率和深入研究核心技术,将技术和知识转化为实际收益。文章结合个人经验,分享了提高工作效率、掌握高价值技能以及选择合适工作环境的方法,帮助读者更好地实现技术变现。 ... [详细]
  • 本文详细介绍了 Kubernetes 集群管理工具 kubectl 的基本使用方法,涵盖了一系列常用的命令及其应用场景,旨在帮助初学者快速掌握 kubectl 的基本操作。 ... [详细]
  • 深入解析 Apache Shiro 安全框架架构
    本文详细介绍了 Apache Shiro,一个强大且灵活的开源安全框架。Shiro 专注于简化身份验证、授权、会话管理和加密等复杂的安全操作,使开发者能够更轻松地保护应用程序。其核心目标是提供易于使用和理解的API,同时确保高度的安全性和灵活性。 ... [详细]
  • 科研单位信息系统中的DevOps实践与优化
    本文探讨了某科研单位通过引入云原生平台实现DevOps开发和运维一体化,显著提升了项目交付效率和产品质量。详细介绍了如何在实际项目中应用DevOps理念,解决了传统开发模式下的诸多痛点。 ... [详细]
  • 深入解析Serverless架构模式
    本文将详细介绍Serverless架构模式的核心概念、工作原理及其优势。通过对比传统架构,探讨Serverless如何简化应用开发与运维流程,并介绍当前主流的Serverless平台。 ... [详细]
  • 使用GDI的一些AIP函数我们可以轻易的绘制出简 ... [详细]
  • 本题探讨如何通过最大流算法解决农场排水系统的设计问题。题目要求计算从水源点到汇合点的最大水流速率,使用经典的EK(Edmonds-Karp)和Dinic算法进行求解。 ... [详细]
  • 实体映射最强工具类:MapStruct真香 ... [详细]
  • 探讨如何真正掌握Java EE,包括所需技能、工具和实践经验。资深软件教学总监李刚分享了对毕业生简历中常见问题的看法,并提供了详尽的标准。 ... [详细]
  • FinOps 与 Serverless 的结合:破解云成本难题
    本文探讨了如何通过 FinOps 实践优化 Serverless 应用的成本管理,提出了首个 Serverless 函数总成本估计模型,并分享了多种有效的成本优化策略。 ... [详细]
  • 探讨如何从数据库中按分组获取最大N条记录的方法,并分享新年祝福。本文提供多种解决方案,适用于不同数据库系统,如MySQL、Oracle等。 ... [详细]
  • 本文探讨了2012年4月期间,淘宝在技术架构上的关键数据和发展历程。涵盖了从早期PHP到Java的转型,以及在分布式计算、存储和网络流量管理方面的创新。 ... [详细]
  • 本文探讨如何配置 Nginx 以将传入请求反向代理到运行在本地绑定端口上的 Docker 容器,并解决常见的路径重定向问题。 ... [详细]
  • 深入解析Docker镜像的工作机制
    本文旨在深入探讨Docker镜像的内部结构及其工作机制,包括镜像的分层体系、联合文件系统(UnionFS)的应用,以及各层如bootfs和rootfs的具体作用。 ... [详细]
author-avatar
财气冲天6_757
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有