prometheus 配置服务器监控、服务监控、容器中服务监控与告警

       最近公司有几个服务遇到了瓶颈,也就是数据量增加了,没有人发现,这不是缺少一个监控服务和告警的系统吗?  

      主要需求是监控每个服务,顺带监控一下服务器和一些中间件,这里采集的2种,zabbix和prometheus,由于我们要监控的是Docker容器中的服务,最终选择prometheus。

如下:

一 实现功能

  1. 服务宕机,不能提供服务,飞书收到告警信息。
  2. 容器中服务占用分配内存达到50, 飞书收到预警信息。
  3. 容器中服务中JVM堆内存占用达到80, 飞书收到预警信息。
  4. 服务发生OOM后,服务可以立刻重启。

 二:流程图

 三 步骤

确定要监控的docker服务, 这里以公司的A服务为例子

  1. 查看服务的Dockerfile 和run.sh   

Dockerfile是构建docker镜像,run.sh是启动服务用的

 1.1 Dockerfile中java执行命令添加:

"-XX:+HeapDumpOnOutOfMemoryError","-XX:HeapDumpPath=/temp/dump","-XX:+ExitOnOutOfMemoryError","-XX:MaxRAMPercentage=75.0"

-XX:+HeapDumpOnOutOfMemoryError:参数表示当JVM发生OOM时,自动生成DUMP文件

-XX:HeapDumpPath=/temp/dump:生成dump目录文件的位置

-XX:+ExitOnOutOfMemoryError:JVM在第一次出现内存不足错误时退出,启动JVM实例

-XX:MaxRAMPercentage=75.0: 这为JVM定义了75%的总内存限制

查看服务目前容器大小,和占用内存大小,保证占用内存稳定在30%一下。

docker stats dcda4228b794

 这边找了一个47%的,只给了1G的容器大小。需求中超过50%就会告警。

如果超过50%,需要在启动容器的run.sh命令中提升初始容器大小

修改--memory 1024m \   --memory-swap 1024m \的值,是容器的内存大小

以上是容器要做的一些调整,也是自己定义的规则。

2. Idea中找到A应用,修改POM和 application.properties文件

application.properties中添加

management.endpoint.health.show-details=always
management.endpoints.web.exposure.include=*

这边要注意,如果你是yml文件 management.endpoints.web.exposure.include=*,

这个 * 一定要加 ''单引号,*在yml文件中是通配符。

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>

 注意,如果你的服务属于对外接口访问服务,有Shiro拦截的话要配置

filterChainDefinitionMap.put("/actuator/prometheus", "anon");

至此完成代码的整改,可以提交代码,部署服务。

确定服务正常启动:输入docker ps -a  (不加-a就看正常运行的服务,-a是看所有的服务,包括停止的)

 去服务器厂商放开当前服务对外的端口号,主要是对指定监控的服务器放开,不是所有

环境地址访问  http://ip:port/actuator/prometheus

看到如下,就是提供的指标数据

 3 docker容器监控服务

部署prometheus,alertmanager,garfana, 还有一个推消息给飞书的服务, 这个大家如果想找到怎么部署,可以留言,我整理一下,写出来。不过后面有时间我也会更新这边部署监控文章的。

1. cadvisor 是容器内个服务的监控指标提取

2. prometheus-webhook-feishu 是网上找的一个开源的飞书通知服务

3.alertmanager是告警管理 --通知2下发告警的

4.grafana是可视化大屏,对prometheus采集的数据可视化展示

5.node-exporter 是服务器监控,提取服务器的指标数据

6.prometheus 是核心的监控服务

4. 配置prometheus

进入prometheus

 看到这几个文件夹/文件,其中主要配置实例在prometheus.yml中,rules文件下是配置告警规则的。

进入prometheus.yml仿照- job_name: 自己创建一个

- job_name: "A"    # 监控的job名称

    metrics_path: '/actuator/prometheus'   # 监控的指标路径

    static_configs:

      - targets: ['ip:port']    #监控的服务器和端口端口已经开放

        labels:

          serviceId: A-snapshot   #服务id告警展示

          serviceName: A-web  #服务名称   告警展示

重启prometheus

docker restart prometheus

访问http://ip:9090/查看配置的任务,如下up状态代表服务正常启动,配置任务成功。

 rules下有配置服务器/服务的告警规则

1. 服务器内存使用超过98%告警规则

  (node_memory_MemTotal_bytes - (node_memory_MemFree_bytes+node_memory_Buffers_bytes+node_memory_Cached_bytes )) / node_memory_MemTotal_bytes * 100 > 98

 (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 > 95

会对配置在prometheus中没有job都做监控,up==0标识改服务宕机,提示。

可以做验证

 docker stop A服务容器id

 

飞书收到这个通知,如何配置 prometheus-alertmanager-feishu的流程后续会同步上

4.配置其他告警规则 这里配置容器内存超过50提示,和服务jvm中堆占用80提示

配置路径/minitor/prometheus/rules

可以自己重新定义一个yml ,下面yml下面所有规则都会被prometheus识别,一般按照项目建一个文件

容器内存超过50


groups:
# 组名。报警规则组名称
- name:  A服务内存预警
  rules:
  - alert:  a服务内存使用率预警
  # expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
    expr: container_memory_usage_bytes{image="a:latest"}/container_spec_memory_limit_bytes{image="a:latest"} * 100 > 50
  # for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
    for: 20s # for语句会使 Prometheus 服务等待指定的时间, 然后执行查询表达式。(for 表示告警持续的时长,若持续时长小于该时间就不发给alertmanager了,大于
该时间再发。for的值不要小于prometheus中的scrape_interval,例如scrape_interval为30s,for为15s,如果触发告警规则,则再经过for时长后也一定会告警,这是因为>最新的度量指标还没有拉取,在15s时仍会用原来值进行计算。另外,要注意的是只有在第一次触发告警时才会等待(for)时长。)
  # labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。
    labels:
    # severity: 指定告警级别。有三种等级,分别为 warning, critical 和 emergency 。严重等级依次递增。
      severity: critical
  # annotations: 附加信息,比如用于描述告警详细信息的文字等,annotations的内容在告警产生时会一同作为参数发送到Alertmanager。
    annotations:
      title: "a服务内存使用率预警"
      serviceName: "{{ $labels.serviceName }}"
      instance: "{{ $labels.instance }}"
      value: "{{ $value }}"
      btn: "点击查看详情 :玫瑰:"
      link: "http://xxxxxxxxx:9090/targets"
      template: "**${serviceName}**(${instance})正式服务内存使用率已经超过阈值 **50%**, 请及时处理!\n当前值: ${value}%"

expr:container_memory_usage_bytes{image="a:latest"}/container_spec_memory_limit_bytes{image="a:latest"} * 100 > 50
这个可以在之前prometheus查看

服务jvm中堆占用80提示


- name: A服务堆内存超高预警
  rules:
  - alert: A服务堆内存使用率超高预警
    expr: sum(jvm_memory_used_bytes{serviceId="a", area="heap"})*100/sum(jvm_memory_max_bytes{serviceId="a", area="heap"}) > 80
    for: 20s
    labels:
       severity: red
    annotations:
      title: "a服务堆内存使用率超高预警"
      serviceName: "{{ $labels.serviceName }}"
      instance: "{{ $labels.instance }}"
      value: "{{ $value }}"
      btn: "点击查看详情 :玫瑰:"
      link: "http://xxxxxxxx:9090/targets"
      template: "**${serviceName}**(${instance})正式环境服务内存使用率已经超过阈值 **80%**, 请及时处理!\n当前值: ${value}%"

 expr: sum(jvm_memory_used_bytes{serviceId="job中配置的", area="heap"})*100/sum(jvm_memory_max_bytes{serviceId="job中配置的", area="heap"}) > 80

 

 重启prometheus

5 验证容器内存超过50  堆内存超80  和出现OOM后容器自动重启服务

 在服务中加一个测试oom的接口, 正式发布后,这个接口要去掉

如下: 会不断的生成不回收的对象 /dev/d

package xxx;

import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.http.HttpServletRequest;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

/**
 */
@Slf4j
@RestController
@RequestMapping("dev")
public class Controller {


    @RequestMapping("/a")
    public Integer message() {
        log.info(">>>>info");
        log.debug(">>>>>Debug");
        return Runtime.getRuntime().availableProcessors();
    }

    @RequestMapping("/d")
    public String messaged(HttpServletRequest request) throws InterruptedException {
        log.info(">>>>info");
        log.debug(">>>>>Debug");
        List<Object> list = new ArrayList<>();
        new Thread(new Runnable() {
            @Override
            public void run() {
                List<Object> list2 = new ArrayList<>();
                int initSize =  1024 * 1024 * 300;
                Map<String, Object> map = new HashMap<>();
                int i= 0;
                while(true) {
                    try{
                        Thread.sleep(5000);
                    } catch(Exception e) {
                        e.printStackTrace();
                    }
                    //每次添加50M
                    int userMemory = 1024*1024*10;
                    i++;
                    map.put("userMemory" + i, new byte[userMemory]);
                    list.add(map);
                    list2.add(map);
                }
            }
        }).start();
        return "OK";
    }
}

这里对A服务运行dev/d接口

先看dev/a 是看运行的cpu个数,验证服务是否启动

这时候别着急让服务OOM

先看cAdvisor,容器监控都靠他,监控别的服务器容器也要在对应服务器上安装。

环境运行: http://ip:19190/

点击Docker Containers可以看具体容器的信息,找到你要配置的容器A

里面包括很多参数指标信息,这里先看容器内存

 

 和docker stats运行的值基本一致

Jvm堆内存使用占比,我们可以根据cAdvisor提供的

jvm_memory_used_bytes

jvm_memory_max_bytes

执行接口,查看对应数据,验证告警信息。

 等会我们执行增加jvm堆内存的接口,要看容器的内存使用,和jvm中堆占比都上升,知道堆内存占比100%发生OOM后,容器重启服务,过程中,会提示容器内存使用超过50%,堆内存使用超过80%

1. 系统OOM 产生dump文件 之前第一步有配置

2. 系统OOM 会立刻重启服务,保证不宕机,服务可用

3. 容器内存超50% 告警

4. 堆内存超80% 告警

第一个:

在docker下dump/temp发现 java_pid6.hprof 文件--后面讲

第二个 服务立刻重启,并且输入dev/a  还是可以访问的

第三个 收到告警

这个过程,百分比是慢慢上升的可以通过docker stats/cadvisor看数据

  • 继续监控

 此时堆内存已经达到91 > 80

 容器内存也快达到,瓶颈

 

  • 继续监控,突然会服务重新,出现OOM

也可以docker logs -f xxx查看日志,此时对象都释放掉了

又回到服务初始容器内存占比和jvm堆使用占比

至此,完成了服务宕机告警,容器内存超50%告警,堆内存超80%告警,服务出现OOM后服务重启。

6 可视化监控的页面grafana

可以通过看大屏数据,感觉还挺牛的,可以自定义。

http://xxxxx:3000/    grafana可视化监控,是对prometheus采集的数据做大屏展示

如:展示刚刚容器中jvm的一些指标信息  配置模板id:4701 用过grafana你就知道了。相当于一个模版id

 展示当前服务器中所有容器的cpu,内存,硬盘等使用情况

模板id: 116000 是查看当前容器中各服务,cpu,内存使用情况。

 也可以对整个服务器做监控展示    模板id:8919

grafana的更多常用模板地址:Dashboards | Grafana Labs 

目前监控的实现方案如上,有好的优化方案和新的监控点,告警点互相讨论。

上面代码出现OOM,简单排查过程

主要是分析dump文件

通过写的代码,看到开启一个线程,不停的给ArrayList插入一个value是10M的Map

在配置java启动中,我们把oom自动生成的dump文件拿出来

进到容器中把文件cp到宿主机

 分析工具:MemoryAnalyzer  导入文件

1 进入Leak Suspects  2进入Dominator Tree

进入Leak Suspects 点击detail  发现出现一堆HashMap没有回收,这和我们的代码问题一致

 

 进入 Dominator Tree查看

发现有很多的HashMap key 是递增的,value是一个10M的Byte[]

代码都是自己写的。哈哈。

 定位代码:

服务地址:

Promethues:   http://xxxx:9090

Grafana: http://xxxx:3000

Alertmanager: http://xxxx:19093

cAdvisor的所有容器监控 http://xxxxx:19190/containers/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值