利用Grafana和Arthas自动抓取异常Java进程的线程堆栈

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 自动抓取占用CPU资源的Java程序线程栈。

前言

近期发现业务高峰期时刻会出现CPU繁忙导致的timeout异常,通过监控来看是因为Node上面的一些Pod突发抢占了大量CPU导致的。

问: 没有限制CPU吗?是不是限制的CPU使用值就可以解决了呢?
解: 其实不能根本解决这个问题,因为使用的容器引擎是Docker,而Docker是使用了cgroups技术,这就引入了一个老大难的问题,cgroup的隔离性。当问题发生时并没有办法把异常CPU进程直接摁住,而会有短暂的高峰,现象为:限制了CPU为2核,突发时CPU可能是4、5、6等,然后容器会被kill掉,K8S会尝试重建容器。

那么该如何解决?

  1. 使用隔离性更好的容器引擎,如 kata(VM级别)。
  2. 优化程序

方案1

我们可以知道方案1解决的比较彻底,而且只需要全局处理一次即可,但技术比较新颖,不知道会不会带来其它问题,我们之后准备拿出部分Node尝试kata container。

方案2

对应用开发者要求比较高,需要对应的开发者针对性介入,短期收益很高,我们先部署了这种。

如何实施?

我们知道程序在运行中,除非特别严重的BUG,CPU高峰一般非常短暂,这时候靠人肉抓包基本上是来不及的,也很耗费精力,我们就希望有一个程序能在CPU达到一定阈值的时候自动抓取线程堆栈来事后针对性优化,并且一定时间内只允许运行一次防止循环抓包导致程序不可用。

根据要实现的最终效果我们发现与Grafana、Prometheus的告警机制十分接近,我们要做的就是接收告警的webhook,去对应的容器中获取线程堆栈就行。

于是我们利用了 Grafana ,写了一个程序来完成这个功能。

项目信息

开发语言: Go、Shell
项目地址: https://github.com/majian159/k8s-java-debug-daemon

k8s-java-debug-daemon

利用了 Grafana 的告警机制,配合阿里的 arthas,来完成高CPU使用率线程的堆栈抓取。
整体流程如下:

  1. 为 Grafana 添加 webhook 类型的告警通知渠道,地址为该程序的 url(默认的hooks路径为 /hooks)。
  2. 配置Grafana图表,并设置告警阈值
  3. 当 webhook 触发时,程序会自动将 craw.sh 脚本拷贝到对应 Pod 的容器中并执行。
  4. 程序将 stdout 保存到本地文件。

效果预览


默认行为

  • 每 node 同时运行执行数为10
    可以在 ./internal/defaultvalue.go 中更改

    var defaultNodeLockManager = nodelock.NewLockManager(10)
  • 默认使用集群内的Master配置
    可以在 ./internal/defaultvalue.go 中更改

    func DefaultKubernetesClient(){}
    
    // default
    func getConfigByInCluster(){}
    
    func getConfigByOutOfCluster(){}
  • 默认使用并实现了一个基于本地文件的堆栈存储器, 路径位于工作路径下的 stacks
    可以在 ./internal/defaultvalue.go 中更改

    func GetDefaultNodeLockManager(){}
  • 默认取最繁忙的前50个线程的堆栈信息 (可在 craw.sh 中修改)
  • 采集样本时间为2秒 (可在 craw.sh 中修改)

如何使用

Docker Image

majian159/java-debug-daemon

为 Grafana 新建一个通知频道

注意点

  1. 需要打开 Send reminders, 不然 Grafana 默认在触发告警后一直没有解决不会重复发送告警
  2. Send reminder every 可以控制最快多久告警一次

为 Grafana 新建一个告警图表

如果嫌麻烦可以直接导入以下配置, 在自行更改

{
  "datasource": "prometheus",
  "alert": {
    "alertRuleTags": {},
    "conditions": [
      {
        "evaluator": {
          "params": [
            1
          ],
          "type": "gt"
        },
        "operator": {
          "type": "and"
        },
        "query": {
          "params": [
            "A",
            "5m",
            "now"
          ]
        },
        "reducer": {
          "params": [],
          "type": "last"
        },
        "type": "query"
      }
    ],
    "executionErrorState": "keep_state",
    "for": "10s",
    "frequency": "30s",
    "handler": 1,
    "name": "Pod 高CPU堆栈抓取",
    "noDataState": "no_data",
    "notifications": [
      {
        "uid": "AGOJRCqWz"
      }
    ]
  },
  "aliasColors": {},
  "bars": false,
  "dashLength": 10,
  "dashes": false,
  "fill": 1,
  "fillGradient": 0,
  "gridPos": {
    "h": 9,
    "w": 24,
    "x": 0,
    "y": 2
  },
  "hiddenSeries": false,
  "id": 14,
  "legend": {
    "alignAsTable": true,
    "avg": true,
    "current": true,
    "max": true,
    "min": false,
    "rightSide": true,
    "show": true,
    "total": false,
    "values": true
  },
  "lines": true,
  "linewidth": 1,
  "nullPointMode": "null",
  "options": {
    "dataLinks": []
  },
  "percentage": false,
  "pointradius": 2,
  "points": false,
  "renderer": "flot",
  "seriesOverrides": [],
  "spaceLength": 10,
  "stack": false,
  "steppedLine": false,
  "targets": [
    {
      "expr": "container_memory_working_set_bytes{job=\"kubelet\", metrics_path=\"/metrics/cadvisor\", image!=\"\", container!=\"POD\"}* on (namespace, pod) group_left(node) max by(namespace, pod, node, container) (kube_pod_info)",
      "legendFormat": "{{node}} - {{namespace}} - {{pod}} - {{container}}",
      "refId": "A"
    }
  ],
  "thresholds": [
    {
      "colorMode": "critical",
      "fill": true,
      "line": true,
      "op": "gt",
      "value": 1
    }
  ],
  "timeFrom": null,
  "timeRegions": [],
  "timeShift": null,
  "title": "Pod CPU",
  "tooltip": {
    "shared": true,
    "sort": 0,
    "value_type": "individual"
  },
  "type": "graph",
  "xaxis": {
    "buckets": null,
    "mode": "time",
    "name": null,
    "show": true,
    "values": []
  },
  "yaxes": [
    {
      "format": "short",
      "label": null,
      "logBase": 1,
      "max": null,
      "min": null,
      "show": true
    },
    {
      "format": "short",
      "label": null,
      "logBase": 1,
      "max": null,
      "min": null,
      "show": true
    }
  ],
  "yaxis": {
    "align": false,
    "alignLevel": null
  }
}

Queries配置

Metrics 中填写

container_memory_working_set_bytes{job="kubelet", metrics_path="/metrics/cadvisor", image!="", container!="POD"} * on (namespace, pod) group_left(node) max by(namespace, pod, node, container) (kube_pod_info)

Legend 中填写

{{node}} - {{namespace}} - {{pod}} - {{container}}

配置完如下:

Alert配置

IS ABOVE
CPU使用值,这边配置的是超过1核CPU就报警, 可以根据需要自己调节
Evaluate every
每多久计算一次
For
Pedding时间

配置完应该如下:

构建

二进制

# 为当前系统平台构建
make

# 指定目标系统, GOOS: linux darwin window freebsd
make GOOS=linux

Docker镜像

make docker

# 自定义镜像tag
make docker IMAGE=test
相关实践学习
通过可观测可视化Grafana版进行数据可视化展示与分析
使用可观测可视化Grafana版进行数据可视化展示与分析。
目录
相关文章
|
1月前
|
Java
在 Java 中捕获和处理自定义异常的代码示例
本文提供了一个 Java 代码示例,展示了如何捕获和处理自定义异常。通过创建自定义异常类并使用 try-catch 语句,可以更灵活地处理程序中的错误情况。
65 1
|
1月前
|
Java API 调度
如何避免 Java 中的 TimeoutException 异常
在Java中,`TimeoutException`通常发生在执行操作超过预设时间时。要避免此异常,可以优化代码逻辑,减少不必要的等待;合理设置超时时间,确保其足够完成正常操作;使用异步处理或线程池管理任务,提高程序响应性。
73 12
|
1月前
|
Java
在 Java 中,如何自定义`NumberFormatException`异常
在Java中,自定义`NumberFormatException`异常可以通过继承`IllegalArgumentException`类并重写其构造方法来实现。自定义异常类可以添加额外的错误信息或行为,以便更精确地处理特定的数字格式转换错误。
39 1
|
1月前
|
IDE 前端开发 Java
怎样避免 Java 中的 NoSuchFieldError 异常
在Java中避免NoSuchFieldError异常的关键在于确保类路径下没有不同版本的类文件冲突,避免反射时使用不存在的字段,以及确保所有依赖库版本兼容。编译和运行时使用的类版本应保持一致。
73 7
|
1月前
|
Java 编译器
如何避免在 Java 中出现 NoSuchElementException 异常
在Java中,`NoSuchElementException`通常发生在使用迭代器、枚举或流等遍历集合时,尝试访问不存在的元素。为了避免该异常,可以在访问前检查是否有下一个元素(如使用`hasNext()`方法),或者使用`Optional`类处理可能为空的情况。正确管理集合边界和条件判断是关键。
80 6
|
1月前
|
Java
Java异常捕捉处理和错误处理
Java异常捕捉处理和错误处理
68 1
|
1月前
|
Java 编译器 开发者
Java异常处理的最佳实践,涵盖理解异常类体系、选择合适的异常类型、提供详细异常信息、合理使用try-catch和finally语句、使用try-with-resources、记录异常信息等方面
本文探讨了Java异常处理的最佳实践,涵盖理解异常类体系、选择合适的异常类型、提供详细异常信息、合理使用try-catch和finally语句、使用try-with-resources、记录异常信息等方面,帮助开发者提高代码质量和程序的健壮性。
76 2
|
1月前
|
Java
如何在 Java 中处理“Broken Pipe”异常
在Java中处理“Broken Pipe”异常,通常发生在网络通信中,如Socket编程时。该异常表示写入操作的另一端已关闭连接。解决方法包括:检查网络连接、设置超时、使用try-catch捕获异常并进行重试或关闭资源。
117 5
|
27天前
|
SQL 数据库
gbase 8a 数据库 shm满导致gclusterd进程异常
gbase 8a 数据库 shm满导致gclusterd进程异常
|
1月前
|
存储 安全 Java
如何避免 Java 中的“ArrayStoreException”异常
在Java中,ArrayStoreException异常通常发生在尝试将不兼容的对象存储到泛型数组中时。为了避免这种异常,确保在操作数组时遵循以下几点:1. 使用泛型确保类型安全;2. 避免生类型(raw types)的使用;3. 在添加元素前进行类型检查。通过这些方法,可以有效防止 ArrayStoreException 的发生。
45 3