关于prometheus:Prometheus-监控系统的学习总结

67次阅读

共计 4267 个字符，预计需要花费 11 分钟才能阅读完成。

APM

APM (Application Performance Management) 是利用性能治理的缩写，代表了服务的行为、可靠性、性能等的监控和治理。当利用产生故障，利用 APM 设施能够迅速检测并定位到产生故障的起因。

现在的后端服务大都是分布式、微服务化的，做好 APM 尤为重要。APM 包含许多方面工作，包含 链路追踪 (Tracing)、 日志 (Logging) 和 指标 (Metrics) 监控与报警 等，对应的开源基础设施也有很多，如 Jaeger/Zipkin (链路跟踪)、ELK (日志)、Prometheus/Zabbix/InfluxDB (指标监控零碎)、Grafana (监控展现前端) 等。

明天来说说什么是指标监控，以及总结一下最近学习 Prometheus 的心得，梳理一下常识网络。

Metrics 指标和 Prometheus

咱们通常在应用程序中产生日志，日志往往代表的是一个利用或申请生命周期中的一个事件，它是离散的数据。而指标往往代表着应用程序中可量化可聚合剖析的数据，例如服务接管的申请量，申请量是一个一直减少的数据，咱们能够依据它和工夫的对应关系，计算出申请的增长率；再比方，服务的申请提早，咱们能够收集所有的提早时长，统计出不同的分位数，以掂量服务的整体提早体现；再比方音讯队列零碎的工作沉积状况、服务的内存占用、主机的 CPU 占用率等，这些是一个个高低浮动的数值，能够反馈一些实时情况，并且通过历史工夫的数据，反馈过来一段时间的数据稳定状况，以预测将来变动。

通过 Prometheus 咱们就能够进行这些指标数据的统计、收集、查问 / 聚合剖析、可视化展现、非正常指标的报警等工作。能够把 Prometheus 了解为一个指标收集器与时序数据库 (TSDB) 的汇合。

Prometheus 架构

Prometheus 采纳 PULL 的模式定期从应用程序中拉取指标数据。应用程序指标地址能够以动态配置的形式提供，也能够配置服务注册核心，动静的形式获取指标地址，见 文档。

组件

  • Exporter 采集指标数据，为 Prometheus server 提供采集接口。Exporter 能够集成在业务代码中，也能够是一个独自的过程服务，来采集其余的服务指标。
  • Pushgateway 是一个两头服务，短生命周期的 job 上传指标到 Pushgateway，server 从 Pushgateway 采集指标。
  • TSDB 是 Prometheus server 内置的时序数据库，用来存储采集的指标数据，并且内置了一套用以查问数据的语法 PromQL。
  • Alertmanager 是独立于 Prometheus server 的一个服务，用来解决报警。Prometheus server 只负责评估报警规定是否被触发，后续的报警告诉等工作交由 Alertmanager 解决。

部署

本地应用 Docker Compose 进行部署。

version: "3"  
  
volumes:  
    prometheus_config:  
    prometheus_data:  
    alertmanager_config:  
    grafana_config:  
    grafana_data:  
  
services:  
    prometheus:  
        image: prom/prometheus:v2.20.1  
        container_name: prometheus  
        hostname: prometheus-host  
        ports:  
            - 9090:9090  
        command:  
            - --config.file=/etc/prometheus/prometheus.yml # 指定配置文件  
            - --web.enable-lifecycle # 运行通过 HTTP 接口从新加载配置 (POST localhost:9090/-/reload)  
        volumes:  
            - prometheus_config:/etc/prometheus # 配置  
            - prometheus_data:/prometheus # TSDB、WAL 等数据  
        depends_on:  
            - alertmanager  
  
    alertmanager:  
        image: prom/alertmanager:v0.21.0  
        container_name: alertmanager  
        hostname: alertmanager-host  
        ports:  
            - 9093:9093  
        volumes:  
            - alertmanager_config:/etc/alertmanager # 配置  
  
    # user: admin, psw: admin 
    grafana:  
        image: grafana/grafana:7.1.5  
        container_name: grafana  
        hostname: grafana-host  
        ports:  
            - 3000:3000  
        depends_on:  
            - prometheus  
        volumes:  
            - grafana_config:/etc/grafana # 配置  
            - grafana_data:/var/lib/grafana # DB、Plugins 等数据

样本、工夫序列和指标类型

      ^
      │   . . . . . . . . . . . . . . . . . . .   
      │   . . . . . . . . . . . . . . . . . . .   
      │   . . . . . . . . . . . . . . . . . . .
      │   . . . . . . . . . . . . . . . . . . .  
      v
        <------------------ 工夫 ---------------->

样本

Prometheus TSDB 存储的根本单位是 样本，能够了解为下面坐标中的一个点，横轴代表样本工夫，数轴代表样本值。而样本自身又由一系列标签惟一标识，故样本由以下三局部组成：

  • 指标：蕴含指标名 (指标名称其实也是一个标签) 和形容以后样本特色的标签集 (labelsets)。
  • 工夫戳：一个准确到毫秒的工夫戳。
  • 样本值：一个 float64 的浮点型数据表示以后样本的值。

工夫序列

同一指标（指标名和标签集都雷同的所有样本）在下面坐标中所形成的一条间断的线，成为一条工夫序列。它代表了一个指标在工夫范畴内的数值稳定。

指标类型

为了辨别不同类型的指标，Prometheus 形象出四种类型的指标。

  • Counter 代表一个只增不减的计数器指标，例如，服务接管的申请总量。
  • Gauge 代表一个可增可减的计量器指标，例如，服务内存占用。

上述两种指标都是间断的指标，基于原来的数值进行增减，而上面两种指标属于统计类指标。

  • Histogram 意为直方图，它定义了不同的数值范畴（桶），而后将收集到的数据纳入桶内进行计数统计，可能失去不同数值范畴之间的比例。
  • Summary 定义了不同的分位点，而后将收集到的数据进行大小排序，最终失去不同分位点对应的数值 (分位数)。

Prometheus server 同时也蕴含一个 metrics 接口，供本身进行指标采集。在部署之后能够通过 http://your-prometheus-host:9090/metrics 查看到不同指标类型的样本。

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 2.86e-05
go_gc_duration_seconds{quantile="0.25"} 0.0001114
go_gc_duration_seconds{quantile="0.5"} 0.0001812
go_gc_duration_seconds{quantile="0.75"} 0.0003278
go_gc_duration_seconds{quantile="1"} 0.0038698
go_gc_duration_seconds_sum 0.0531145
go_gc_duration_seconds_count 210

下面这部分是 Go 垃圾回收进展工夫的 summary 类型样本，从数据中能够失去如下信息：

  • 总共进行了 210 次垃圾回收。
  • 垃圾回收总耗时 0.0531145。
  • 有一半次数的回收耗时是低于 0.0001812 的。
  • …

各种指标类型和样本含意不一一阐明了，能够细读 文档。

PromQL

PromQL 是 Prometheus 的查询语言，能够通过 PromQL 查问单条或多条工夫序列，也能够通过 PromQL 内置函数和操作符查问聚合后的数据。

可在 http://your-prometheus-host:9090/new/graph 中输出 PromQL 进行查问。

用法这里不再赘述，请参考 文档。

业务中集成 Exporter

咱们模仿一个工作队列零碎，应用 Go 来编写，用 Channel 来保留工作，利用生产者 - 消费者模型来进行工作的生产和生产。在生产者每次向队列 Push 工作时，收集队列的沉积的工作数，这是一个 Gauge 类型指标；在消费者解决工作时，统计实现的工作数，这是一个 Counter 指标，同时收集工作的实现工夫以统计工作耗时的 Histogram 和 Summary。而后再裸露一个 HTTP 接口提供最新的指标样本数据。

代码在：https://github.com/xvrzhao/examples/tree/master/prometheus

假若该程序是跑在宿主机的，然而咱们 Prometheus server 是跑在容器里的，server 要申请宿主机的端口，能够通过主机名 host.docker.internal 与宿主机通信。

能够批改容器里的配置文件 /etc/prometheus/prometheus.yml，减少如下配置：

scrape_configs: 
    - job_name: 'task_queue' 
      static_configs: 
        - targets: ['host.docker.internal:9000']

报警

报警须要 Prometheus server 和 Alertmanager 配合实现，Prometheus server 只负责评估报警规定条件，如果符合条件则将报警发送给 Alertmanager。

Prometheus server 每次评估时，处于 firing 状态的警报都会发送给 Alertmanager，只管同一条警报曾经发送过一次。所以在 Alertmanager 要做好警报的分组、提早合并、克制和静默。对于这些内容，这篇文章解说 得十分好，这里不再赘述。

参考链接

  • Prometheus 官网文档
  • Prometheus 中文手册
  • 从零搭建 Prometheus 监控报警零碎
  • Prometheus 的 Summary 和 Histogram 指标的简略了解
  • Prometheus 一条告警是怎么触发的

正文完
prometheus
发表至： prometheus
2020-09-14
 0
关于prometheus:Prometheus部署及nodeexporter部署方案
关于prometheus:KubeVela-KEDA为应用带来与生俱来的弹性伸缩能力
关于rocketmq:基于-RocketMQ-Prometheus-Exporter-打造定制化-DevOps-平台
关于prometheus:Prometheus监控神器Alertmanager篇4