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

简介: 自动抓取占用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
目录
相关文章
|
3月前
|
JSON 网络协议 安全
【Java】(10)进程与线程的关系、Tread类;讲解基本线程安全、网络编程内容;JSON序列化与反序列化
几乎所有的操作系统都支持进程的概念,进程是处于运行过程中的程序,并且具有一定的独立功能,进程是系统进行资源分配和调度的一个独立单位一般而言,进程包含如下三个特征。独立性动态性并发性。
230 1
|
3月前
|
JSON 网络协议 安全
【Java基础】(1)进程与线程的关系、Tread类;讲解基本线程安全、网络编程内容;JSON序列化与反序列化
几乎所有的操作系统都支持进程的概念,进程是处于运行过程中的程序,并且具有一定的独立功能,进程是系统进行资源分配和调度的一个独立单位一般而言,进程包含如下三个特征。独立性动态性并发性。
246 1
|
4月前
|
数据采集 存储 弹性计算
高并发Java爬虫的瓶颈分析与动态线程优化方案
高并发Java爬虫的瓶颈分析与动态线程优化方案
Java 数据库 Spring
199 0
|
4月前
|
算法 Java
Java多线程编程:实现线程间数据共享机制
以上就是Java中几种主要处理多线程序列化资源以及协调各自独立运行但需相互配合以完成任务threads 的技术手段与策略。正确应用上述技术将大大增强你程序稳定性与效率同时也降低bug出现率因此深刻理解每项技术背后理论至关重要.
356 16
|
5月前
|
缓存 并行计算 安全
关于Java多线程详解
本文深入讲解Java多线程编程,涵盖基础概念、线程创建与管理、同步机制、并发工具类、线程池、线程安全集合、实战案例及常见问题解决方案,助你掌握高性能并发编程技巧,应对多线程开发中的挑战。
|
5月前
|
数据采集 存储 前端开发
Java爬虫性能优化:多线程抓取JSP动态数据实践
Java爬虫性能优化:多线程抓取JSP动态数据实践
|
10月前
|
Linux 数据库 Perl
【YashanDB 知识库】如何避免 yasdb 进程被 Linux OOM Killer 杀掉
本文来自YashanDB官网,探讨Linux系统中OOM Killer对数据库服务器的影响及解决方法。当内存接近耗尽时,OOM Killer会杀死占用最多内存的进程,这可能导致数据库主进程被误杀。为避免此问题,可采取两种方法:一是在OS层面关闭OOM Killer,通过修改`/etc/sysctl.conf`文件并重启生效;二是豁免数据库进程,由数据库实例用户借助`sudo`权限调整`oom_score_adj`值。这些措施有助于保护数据库进程免受系统内存管理机制的影响。
|
10月前
|
Linux Shell
Linux 进程前台后台切换与作业控制
进程前台/后台切换及作业控制简介: 在 Shell 中,启动的程序默认为前台进程,会占用终端直到执行完毕。例如,执行 `./shella.sh` 时,终端会被占用。为避免不便,可将命令放到后台运行,如 `./shella.sh &`,此时终端命令行立即返回,可继续输入其他命令。 常用作业控制命令: - `fg %1`:将后台作业切换到前台。 - `Ctrl + Z`:暂停前台作业并放到后台。 - `bg %1`:让暂停的后台作业继续执行。 - `kill %1`:终止后台作业。 优先级调整:
852 5
|
算法 Linux 调度
探索进程调度:Linux内核中的完全公平调度器
【8月更文挑战第2天】在操作系统的心脏——内核中,进程调度算法扮演着至关重要的角色。本文将深入探讨Linux内核中的完全公平调度器(Completely Fair Scheduler, CFS),一个旨在提供公平时间分配给所有进程的调度器。我们将通过代码示例,理解CFS如何管理运行队列、选择下一个运行进程以及如何对实时负载进行响应。文章将揭示CFS的设计哲学,并展示其如何在现代多任务计算环境中实现高效的资源分配。

推荐镜像

更多