猿创征文|Promethues入门,看懂不会写

1、Promethues架构

官方网站:Grafana | Prometheus

1)Prometheus server可定期从活跃的(up)目标主机上(target)拉取监控指标数据,目标主机的监控数据可通过配置静态job或者服务发现的方式被prometheus server采集到,这种方式默认的pull方式拉取指标;也可通过pushgateway把采集的数据上报到prometheus server中;还可通过一些组件自带的exporter采集相应组件的数据;

2)Prometheus server把采集到的监控指标数据保存到本地磁盘或者数据库;

3)Prometheus采集的监控指标数据按时间序列存储,通过配置报警规则,把触发的报警发送到alertmanager

4)Alertmanager通过配置报警接收方,发送报警到邮件,微信或者钉钉等

5)Prometheus 自带的web ui界面提供PromQL查询语言,可查询监控数据

6)Grafana可接入prometheus数据源,把监控数据以图形化形式展示出

简单描述下:

通过在所需要的应用上进行采集数据,然后promethues server定期去拉去数据,存储到时序数据库,

Grafana 作为一个展现的UI,通过拉取数据,展示

2、promethues指标

Micrometer在将Prometheus监控指标对接到Java应用的指标时,支持应用开发者用三个类型的语义来映射:

Prometheus监控指标类型

典型用途

Counter

计数器,单调递增场景。例如,统计PV和UV,接口调用次数等。

Gauge

持续波动的变量。例如,资源使用率、系统负载、请求队列长度等。

Histogram

统计数据分布。例如,统计某接口调用延时的P50、P90、P99等。

Summary

统计数据分布,与Histogram用途类似。

  • Counter指标类型,用来描述一个单调递增的变量。如某个接口的访问次数、缓存命中或者访问总次数等。Timer在逻辑上蕴含了Counter,即如果使用Timer采集每个接口的响应时间,必然也会采集访问次数。因此无需为某个接口同时指定Timer与Counter两个指标。
  • Gauge指标类型,用来描述在一个范围内持续波动的变量。如CPU使用率、线程池任务队列数等。
  • Histogram,用来描述与时间相关的数据。如某个接口RT时间分布等。
  • Prometheus监控中的Summary指标类型 ,与Histogram类似,Summary也是用于统计数据分布的,但由于数据的分布情况是在客户端计算完成后再传入Prometheus监控进行存储,因此Summary的结果无法在多个机器之间进行数据聚合,无法统计全局视图的数据分布,使用起来有一定局限性。

3、PromQL语法

指标{过滤器} [区间]

prometheus_http_requests_total{handler=~"/api/v1/.*"}

4、springboot整合

1、建立一个springboot项目,在pom.xml中增加依赖

<!-- spring-boot-actuator依赖 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- prometheus依赖 -->
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

2、在application.yml中添加相关配置暴露监测数据端口。例如,端口为8091。

management:
  endpoints:
    web:
      exposure:
        include: '*'
  metrics:
    tags:
      application: ${spring.application.name}

3、若要获取某个API接口的指标,您需要在对应的接口方法上打@Timed注解。这里以index页面接口为例打@Timed注解,如下代码段所示。

@RestController
public class TestController {

    @Autowired
    private MeterRegistry meterRegistry;

    /**
     * 订单请求测试
     */
    @GetMapping("/order/{appId}")
    public String orderTest(@PathVariable("appId") String appId) {
        Counter.builder("metrics.request.count").tags("apiCode", "order").register(meterRegistry).increment();
        return "order请求成功:" +appId ;
    }
}

使用Counter 计数器定义了自定义指标参数:metrics_request_count,来统计相关接口的请求次数。这里只是测试,所以直接在Controller类中进行统计。实际项目项目中,应该是使用AOP,或是拦截器的方式统计所有接口的请求信息,减少这种非关键代码的侵入性。

启动springboot ,暴露了/actuator/Prometheus的监控端点。

4、promethues配置

主要配置路径,让promethues server 知道要拉取的路径

修改 Prometheus 的配置文件 prometheus.yml ,添加上边启动的服务地址来执行监控。

vim /usr/local/etc/prometheus.yml 。具体配置如下:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "prometheus"
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
    static_configs:
      - targets: ["localhost:9090"]

  - job_name: 'prometheusapp'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['172.16.2.81:8080']

上面的prometheusapp 就是前面创建的Spring Boot 应用程序,也就是 Prometheus 需要监控的服务地址

5、看板配置

应用的监测数据已成功收集并存储到Prometheus监控,因此您可以配置相应的大盘及告警来查看监控到的数据。

设置grafana的数据源地址为promethues 的数据地址,然后就是grafana的设置了

总结

只是入门了解下这一套的监控体系,总体来说就是app 采集数据,promethues 拉取数据,放入自己的时序数据库,Grafana使用数据进行展示

这里面比较不习惯的就是PromQL ,需要具体学习研究下。

Everythis is hard before it is easy!

猜你喜欢

转载自blog.csdn.net/perfect2011/article/details/126624374