上帝之火
本系列讲述的是开源实时监控告警解决方案Prometheus
,这个单词很牛逼。每次我都能联想到带来上帝之火的希腊之神,普罗米修斯。而这个开源的 logo 也是火,集体挺喜爱这个 logo 的设计。
本系列着重介绍 Prometheus
以及如何用它和其周边的生态来搭建一套属于本人的实时监控告警平台。
本系列受众对象为首次接触 Prometheus
的用户,大神勿喷,偏重于操作和实战,然而重要的概念也会精炼出提及下。系列次要分为以下几块
Prometheus
各个概念介绍和搭建,如何抓取数据(本次分享内容)- 如何推送数据至
Prometheus
,推送和拉取别离用于什么样的场景 Prometheus
数据的构造以及查询语言PromQL
的应用- Java 利用如何和
Prometheus
集成,如何启用服务发现,如果自定义业务指标 Prometheus
如何和Grafana
可视化套件进行集成和设置告警- 教你如何手写一个集成了监控 Dubbo 各个指标的 java 套件
- 理论案例分享,如何做各个业务端和零碎端的监控大盘
Prometheus 以及时序数据库的基本概念
Prometheus
当初在 Github
有 3w 多的 star,基本上过万星的开源工具,能够认为是社区里相对的支流,社区也相当沉闷,能够有大量的教训能够借鉴。在企业级零碎中,能够释怀的应用。
Prometheus
是由 SoundCloud
开发的开源监控报警零碎和时序列数据库。从字面上了解,Prometheus
由两个局部组成,一个是监控报警零碎,另一个是自带的时序数据库(TSDB)。
对于 时序数据库 (TSDB) 这里要说下,咱们能够简略的了解为一个优化后用来解决工夫序列数据的数据库,并且数据中的数组是由 工夫 进行索引的。相比于传统的结构化数据库次要有几个益处:
- 工夫序列数据专一于海量数据的疾速摄取。时序数据库视数据的每一次变动为一条新的数据,从而能够去掂量变动:剖析过来的变动,监测当初的变动,以及预测将来将如何变动,传统结构化数据在数据量小的时候能做到,在数据量大的时候就须要破费大量的老本。
- 高精度数据保留工夫较短,中等或更低精度的摘要数据保留工夫较长。对于实时监控来说,不肯定须要每一个精准的数据,而是固定工夫段时间数据的摘要。这对于结构化数据库来说就意味着要进行筛选,在保障大量的写入同时还要进行帅选,这是一个超出结构化数据库设计来解决的工作量。
- 数据库自身必须间断计算来自高精度数据的摘要以进行长期存储。这些计算既包含一些简略的聚合,同时也有一些简单计算。传统数据库无奈接受那么大量的计算。因为必须去实时统计这些聚合和简单运算。
开始搭建 Prometheus
https://prometheus.io/
在 Prometheue
官网 Download 标签页进行下载,这里以 linux
版本为例:
下载好之后,解压,运行
nohup /data/prometheus/prometheus --web.listen-address=0.0.0.0:9090 --config.file=/data/prometheus/prometheus.yml --web.enable-lifecycle --storage.tsdb.path=/data/prometheus/data --storage.tsdb.retention.time=15d &
这样,就简略的搭建起来 Prometheus
服务端了。这时候,咱们能够在 web 上拜访
http://127.0.0.1:9090
就能够拜访到治理页面
界面上几个标签阐明下:
Alert
:用来配置告警规定。之后咱们会用 Grafana
本身的告警界面配置来代替这个。
Graph
:用来运行 PromQL 语句的一个控制台,并且能够把运行进去的语句用用图形化进行展现,此块咱们前面章节会介绍到。
Status
:蕴含零碎信息,零碎状态,配置信息,指标节点的状态,服务发现状态等元信息的查看。
Prometheus 整体架构以及生态
这张图是官网的整体架构图。米黄色局部是 Prometheus
本人的组件,绿色的为第三方的中间件和利用。
简略介绍下整个 Prometheus
的生态架构:
Prometheus
获取数据的形式只有一种,就是scrape
,也称作pull
,意为拉取。Prometheus
每隔一段时间会从指标 (target
) 这里以Http
协定拉取指标(metrics
),这些指标能够是利用,也能够是代理,缓存中间件,数据库等等一些中间件。- 拉取出来的数据
Prometheus
会存到本人的 TSDB 数据库。本人的 WebUI 控制台以及Grafana
能够对其数据进行工夫范畴内的一直查问,绘制成实时图表工展示。 Prometheus
反对例如zookeeper
,consul
之类的服务发现中间件,用以对指标 (target
) 的主动发现。而不必一个个去配置target
了。alertManager
组件反对自定义告警规定,告警渠道也反对很多种
拉取数据
Prometheus
次要是通过拉取的形式获取数据,说简略点,就是每隔固定工夫去拜访配置的 target
,target
就是一个获取数据的 url。
当初咱们就来模仿一个数据源,并让 prometheus
去拉取。
新建一个 springboot
的 web 我的项目,pom 依赖加上
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
application.properties
里加上
server.port=8080
anagement.endpoints.web.exposure.include=*
启动结束后,咱们就能够在页面上拜访如下地址:
http://127.0.0.1:8080/actuator/prometheus
失去如下数据:
对于 actuator
如何监控利用指标以及自定义指标我会在之后的系列里独自剖析,这里只有了解成咱们启动了一个服务,提供了一个 url 能列出一些 kv 模式的指标就行了。
例如 jvm_memory_max_bytes{area="heap",id="PS Old Gen",} 2.863661056E9
这个指标,后面是 key,前面为 value。
其中 key 上又分 key name
和key labels,
key name就是
`jvm_memory_max_bytes,
key labels` 有 2 个。
这个指标提供了 jvm 的最大内存,其中 area
为heap
,表明这是堆内存区域,id
为PS Old Gen
,表明这是老年代。综合起来看,这个指标就是 jvm 中老年代的最大值。数值类型是 byte,换算下来大略是 286M 左右。
咱们有指标的数据源后,再在 prometheus
的根目录下编辑prometheus.yml
文件,增加如下配置:
- job_name: 'test'
scrape_interval: 5s
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['localhost:8080']
labels:
instance: demo
这个配置示意:prometheue
每隔 5 秒钟从 http://localhost:8080/actuator/prometheus
这个 url 拉取指标,并且为每个指标增加 instance
这个标签。
增加结束后,重启 prometheus
。进入 web 页面中的targets
页面。如果后面步骤没问题的话,会看到:
状态为 UP
表明 prometheue
曾经胜利获取到了这个target
的数据。
在查问页面上输出方才那个指标的 key:
这里每个 value 都是 prometheus
最近一次抓取的数据。你每执行一次,数据都会变。
这里为什么会有多条数据呢,是因为每个指标他们的标签不一样。齐全一样的标签会被归为一种指标。
点 Graph
这标签能够看到在工夫序列下,某个指标的变化趋势
上图展现了零碎 cpu 指标的变动图。
最初
现在微服务流行,小规模的企业的微服务节点也快上百了,Prometheus
生态可能用最小的代价使所有的数据实时可视化。这对于开发和运维来说,意义在于,所有的数据不再是黑盒了,至多我集体感觉所有的数据可能被观测和剖析,是具备安全感的。
这个系列旨在利用实战操作教你一步步搭建本人零碎和业务监控大盘。前面会持续更新。下一个章节将剖析:搭建 pushgateway
去 push 数据到prometheus
,以及 2 种不同的数据获取形式别离用于什么样的场景。
分割作者
欢送微信公众号关注「元人部落」
关注后回复“材料”收费获取 50G 的技术材料,包含整套企业级微服务课程和秒杀课程