Go微服务: Prometheus性能监控与Grafana平台的搭建

Wang's Blog

墨衍会员 · AI 创作全网分发码龄12年

关注

原创最新推荐文章于 2026-07-29 22:30:00 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

Prometheus+Grafana监控一网打尽 Prometheus监控 Grafana平台数据展示服务器监控组件服务中间件监控组件阅读详情

Prometheus 概述

promethues 是一套开源的监控&报警&时间序列数据库的组合
基本原理是通过http协议周期性抓取被监控组件的状态
适合Docker、Kubernetes环境的监控系统

Promethues 整体架构

一、抓取数据的两种方式

1 ）Short-lived jobs 短暂的任务
- 不会提供长时间的http去为promethues抓取数据
- 这个服务很短暂, 运行后就会关闭
- 短暂的服务怎么去监控
- 它是通过主动推送数据到网关，进而由 promethues server 端去抓取 PushGateway 上推上来的数据
2 ）另一种方式是 ClientLib/Exporters
- 可以通过不同的 exporters 提供http的方式
- 来给 promethues server 来抓取数据

二、Promethues Server 端

主要分为三个环节：抓取，存储，查询
在抓取网关的时候，promethues server 端如何知道抓取哪些链接
- 获取目标的时候，是通过配置文件，文本文件，consul等方式
- 来存储我们的抓取目标
- 比较常用的是通过配置文件来记录下抓取的目标
- Promethues 根据抓取目标，定期采集数据
当 Promethues 抓取完成后，进行存储阶段
Promethues 会根据报警规则计算是否满足报警规则
在报警规则中，会提供报警消息，主动推送给报警模块
报警模块在收到消息后进行一系列的处理来进行报警
另外数据存储进来，提供给客户访问的时候
Promethues 还有一个简单的web ui, 通过界面的方式查询存储的数据
以上就是 Promethues 整体架构图

三、Promethues 重要组件

基于架构图，可知里面有很多重要组件
Prometheus Server
- 用于收集和存储时间序列数据
- 客户端存储用的是时序数据库
Client Library
- 客户端库生成相应的 metrics 并暴露给 Prometheus Server 去采集
- 课程里就是客户端提供http的端口暴露给 Prometheus Server 让它定期采用数据，达到监控能力
Push Gateway
- 主要用于短期的jobs
- 短期任务，可能5s采集一次，短期任务可能5s内会完成
- 这样server端可能采集不到
- 所以，短期任务，可以主动上报到 Push Gateway 上
- Server 定期采集 Push Gateway 上的数据
Exporters
- 用于暴露已有的第三方服务的metrics 给 Prometheus
- 第三方服务，比如 mysql, redis, mongodb, 等等已经写好的一些 exporters 拿来用
- 主动把需要采集的功能暴露出来，server主动来采集
Alertmanager
- 报警模块，从 Prometheus server 端接收到 alerts 后
- 会进行一些列去除重复，分组，并路由到接受方式，发出报警
- 通过微信，email, QQ等等，都是可以进行发送的

Promethues 工作流程

promethues server 定期从配置好的 jobs/exporters/PushGateway中拉数据
promethues server 记录数据并根据报警规则推送 alert 数据
alertmanager 根据配置文件，对接收到的警报进行处理，发出告警
在图形界面中，可视化采集数据，提供一个简单的 web ui，也有一个漂亮的ui工具，在后面介绍

Promethues 数据模型

规定方式存储数据就是数据模型
promethues 中存储的数据为时间序列
格式上由 metric 的名字和一系列的标签(键值对)唯一标识组成
不同的标签则代表不同的时间序列

promethues 相关概念 - metric(指标)类型

Counter 类型
- 一种累加的指标，如：请求的个数，出现的错误数等
Gauge 类型
- 可以任意加减，如：温度，运行的 goroutines 的个数
Histogram 类型
- 可以对观察结果采样，分组以及统计，如：柱状图
Summary 类型
- 提供观测值的 count 和 sum 功能，如：请求持续时间

Promethues 相关概念 - instance 和 jobs

instance: 一个单独监控的目标，一般对应于一个应用进程
jobs: 一组同类型的 instances 的组合 (主要用于保证可扩展性和可靠性)
理解：
- 假设应用程序处理能力不够，横向扩展了3个应用程序
- 分别调用这3个应用程序进行监控，但是代码上写的包括暴露端口都一样
- 我们要监控这一块，要通过 instance 和 jobs 来进行组合
- 它提供 handler，不同的服务，它认为是不同的 instance
- 它这个服务及时不一样，但类型是一样的，会基于相同类型组成一个 jobs
- 这样，不管应用程序扩展了多少个，都可以很细粒度来监控我们的程序

微服务监控系统 grafana 看板

拥有丰富的 dashboard 和图表编辑的指标分析平台
拥有自己的权限管理和用户管理系统
- 如果要扩展它，可以在基础上进行定制
Grafana 更适合用于数据可视化展示
- 在日常工作中发现，它的数据可视化展示能力非常的强

微服务监控系统 Promethues + Grafana 安装

1 ）拉取镜像

$ docker pull prom/prometheus
$ docker pull grafana/grafana

2 ）基于 docker-compose 部署

version: "2"

services:
  prometheus:
    image: prom/prometheus
    # network_mode: "host"
    container_name: prometheus-compose
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml   #prometheus主配置文件
      - ./prometheus/prometheus-data:/prometheus  #数据存储映射
      - ./prometheus/conf:/etc/prometheus/conf   #prometheus子配置文件路径
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'    #加载主配置文件
      - '--storage.tsdb.path=/prometheus'    #启动数据持久存储
    restart: always

  grafana:
    image: grafana/grafana
    # network_mode: "host"
    container_name: grafana-compose
    ports:
      - "3000:3000"
    volumes:
      # - ./grafana/grafana.ini:/etc/grafana/grafana.ini #grafana配置文件
      - ./grafana/grafana_data:/var/lib/grafana   #数据存储映射
    restart: always

下面开始写这个 prometheus.yml

global:
    scrape_interval: 15s # 默认15s采集一次
    external_labels: # 额外的标签 全局的配置
        monitor: 'go-micro-xxx-monitor'
scrape_configs:
    # 监控的服务：按照一个个的job来监控的
    - job_name: 'services-order'
      scrape_interval: 5s # 覆盖默认值
      static_configs:
        - targets: ['192.168.1.7:9092'] # 这个地址是容器能够访问到的地址，写本机地址, 这个地址在容器或k8s中是会变的, 这个端口是 services-order 的端口

运行：$ docker-compose up
运行起来后，进入prometheus UI界面，访问 ip:9090
注意：
- prometheus 如果运行在K8s中，这个地址就要特别注意
- 这里只是用本机来进行prometheus的搭建测试
- 上面9092端口是services-order中暴露出来的
- 服务自定义的prometheus端口，以此来采集自身服务的信息
在界面上看下它的 targets ，位置 (上导航，Status 下拉 targets)