Prometheus监控网络设备结合Grafana展示

发表于 更新于 阅读次数： Waline： 本文字数： 3.2k 阅读时长 ≈ 3 分钟

折腾Prometheus、Grafana笔记

介绍

Prometheus是一套开源的监控&报警&时间序列数据库的组合,起始是由SoundCloud公司开发的。成立于2012年，之后许多公司和组织接受和采用prometheus,他们便将它独立成开源项目，并且有公司来运作.该项目有非常活跃的社区和开发人员，目前是独立的开源项目，任何公司都可以使用它，2016年，Prometheus加入了云计算基金会，成为kubernetes之后的第二个托管项目.google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。

特性

  • 自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)

  • 非常高效的存储 平均一个采样数据占 ~3.5 bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G。

  • 在多维度上灵活且强大的查询语言(PromQl)

  • 不依赖分布式存储，支持单主节点工作

  • 通过基于HTTP的pull方式采集时序数据

  • 可以通过push gateway进行时序列数据推送(pushing)

  • 可以通过服务发现或者静态配置去获取要采集的目标服务器

  • 多种可视化图表及仪表盘支持

Pull方式

  • Prometheus采集数据是用的pull也就是拉模型，通过HTTP协议去采集指标，只要应用系统能够提供HTTP接口就可以接入监控系统，相对于私有协议或二进制协议来说开发、简单。

Push方式

  • 对于定时任务这种短周期的指标采集，如果采用pull模式，可能造成任务结束了，prometheus还没有来得及采集，这个时候可以使用加一个中转层，客户端推数据到push gateway缓存一下，由Prometheus从push gateway pull指标过来。
  • 需要额外搭建push gateway，同时需要新增job从gateway采集数据。

基础架构

  • Prometheus server：主要负责数据采集和存储，提供PromQL查询语言支持。
  • 客户端SDK官方提供的客户端类库：go、java、Scala、python、ruby、等等其他第三方开发的类库，支持nodejs、php、erlang等。
  • push gateway：支持临时性job主动推送指标的中间网关。
  • promDash：使用rails开发的dashboard，用于可视化指标数据。
  • exportters：支持其他数据源的指标导入到Prometheus，支持数据库、硬件、消息中间件、存储系统、HTTP服务器、jmx等。
  • alertmanager：实验性组件，用来进行报警。
  • Prometheus_cli：命令行工具。
  • 其他辅助工具。

数据模型

Prometheus从根本上所有的存储都是按时间序列去实现的，相同的metrics（指标名称）和label（一个或多个标签）组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。

  • 每条时间序列是由唯一的指标名称和一组标签的形式组成。
  • 指标名称：一般给监测对象起一个名字，例如http_requests_total这样，它有一些命名规则，可以包含字母数字之类的。通常是以应用名称开头监测对象数值类型单位。例如：
1
2
3
- push_total
- userlogin_mysql_duration_seconds
- app_memory_usage_bytes
  • 标签：就是对一条时间序列不同维度的识别，例如一个http请求用的是post还是get，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了。
1
http_requests_total(method="POST",endponit="/api/tracks")

记住，针对http_requests_total这个metrics name 无论是增加标签还是删除标签都会形成一条新的时间序列。
查询语句就可以跟据上面标签的组合来查询聚合结果了。
如果以传统数据库的理解来看这条语句，则可以考虑 http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储)

数据类型

Counter

  • counter用于累计值，例如记录请求次数、任务完成数、错误发生次数。
  • 一直增加，不会减少。
  • 重启进程后，会被重置。
  • 样例：
1
2
http_reponse_total{method="GET",endpoint="/api/tracks"} 10
# 10秒后抓取

Gauge

  • Gauge常规数值，例如：温度变化、CPU、内存、网络流量等。
  • 可变大、可变小
  • 重启进程后，会被重置。
  • 样例：
1
memory_usage_bytes{host="master-01"} 100 < 抓取值

Histogram

Histogram 可以理解为柱状图的意思，常用于跟踪事件发生(通常是请求持续时间或响应大小)的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供 count 和 sum 全部值的功能。

1
例如：{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值

Summary

Summary和Histogram十分相似，常用于跟踪事件(通常是要求持续时间和响应大小)发生的规模，例如：请求耗时、响应大小。同样提供 count 和 sum 全部值的功能。
例如：count=7次，sum=7次的值求值
它提供一个quantiles的功能，可以按%比划分跟踪的结果。例如：quantile取值0.95，表示取采样值里面的95%数据。

Jobs and Instance

在prometheus中，任何被采集的目标被称为instance,通常对应于单个进程，而相同类型(可扩展性和可靠性的复制)的instance集合被称为Job。例如:Api server job由4个复制instance组成:

1
2
3
4
5
- job: api-server
    - instance1: 1.2.3.4:5670
    - instance2: 1.2.3.4:5671
    - instance3: 5.6.7.8:5670
    - instance3: 5.6.7.8:5671

自动生成标签和时间序列

当prometheus采集目标时，它会自动附加某些标签，用于识别被采集的目标。

  • job: 配置目标所属的job名称
  • instance: 目标 HTTP URL:部分

如果任何一个标签已经存在于采集的数据中，则此行为依赖honor_labels 配置选项。

对于每个被采集的instance,prometheus存储如下的时间序列样本：

  • up{job=”“,instance=”“}:1 如果实例处于health，为1，否则为0
  • scrape_duration_seconds{job=”“,instance=”“} 持续采集时间

“up”时间序列metric对于instance可用性监控是有效的。

原文链接

作者：YichenWong
链接：https://www.jianshu.com/p/0a4acb61ce35
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

后续