使用 Grafana Alloy 为 Java 进程配置持续剖析Pyroscope Java Profiling【免费下载链接】pyroscopeContinuous Profiling Platform. Debug performance issues down to a single line of code项目地址: https://gitcode.com/GitHub_Trending/py/pyroscope本文以 Pyroscope 仓库中的官方配置指南为主体讲解如何通过 Grafana Alloy 的pyroscope.java组件基于 async-profiler 对本地进程、Docker 容器与 Kubernetes Pod 进行零侵入的持续剖析Continuous Profiling。读完本文你将掌握 Alloy 各组件的职责与完整参数、profiling_config的每一项配置含义以及三种典型部署场景下可直接复用的config.alloy配置。组件总览一条从发现到上报的剖析流水线Grafana Alloy 支持 Java 剖析其配置文件由一组用于采集、转换和发送数据的组件component组成语法遵循 Alloy 的配置语法。针对 Java 持续剖析一条典型的流水线包含四类组件discovery.process发现主机上运行的所有进程可选地通过join关联 Kubernetes、Docker 等额外发现结果discovery.relabel过滤出 Java 进程并设置service_name等自定义标签pyroscope.java对指定进程执行剖析并产出 Profile 数据pyroscope.write将采集到的 Profile 数据写入 Pyroscope Server 或 Grafana Cloud Profiles。这一点在仓库示例 docker/README.md 与 kubernetes/README.md 中被明确归纳为同样的组件组合。与语言 SDK 埋点不同这种方式无需修改应用代码、无需重启应用pyroscope.java在底层通过 async-profiler 以进程级 attach 的方式附加到目标 JVM 并下发剖析命令因而可以对已经运行中的 Java 应用直接开始剖析。配置pyroscope.java组件pyroscope.java组件用于对运行在本地 Linux 操作系统上的 Java 进程进行持续剖析底层依赖 async-profiler。一个最小可用的配置如下pyroscope.java java { profiling_config { interval 15s alloc 512k cpu true event wall per_thread true lock 10ms sample_rate 100 } forward_to [pyroscope.write.endpoint.receiver] targets discovery.relabel.java.output }其中targets参数指定了要剖析机器上的哪些进程和容器forward_to参数指向一个pyroscope.write组件用于把采集到的 Profile 发送到 Pyroscope Server 或 Grafana Cloud。组件参数说明名称类型描述默认值是否必填targetslist(map(string))要剖析的 Java 进程目标列表。是forward_tolist(ProfilesReceiver)接收采集到的 Profile 的接收器列表。是tmp_dirstring存放 async-profiler 的临时目录。/tmp否两个必须存在的特殊标签targets中每个目标都必须携带特殊标签__process_pid__其值对应该进程的PIDpyroscope.java正是根据它定位并 attach 到目标 JVM。另一个特殊标签service_name同样必须存在。如果未显式指定pyroscope.java会尝试从发现组件的 meta 标签中推断若指定了却无法推断则该值会被设置为unspecified。因此在discovery.relabel中主动设置一个有意义的service_name是让剖析数据在 UI 中清晰可读的关键一步。深入profiling_configasync-profiler 的每个参数profiling_config块描述的是 async-profiler 的调用方式支持以下参数名称类型描述默认值是否必填intervalduration从目标进程采集 Profile 的频率。60s否cpubool是否启用 CPU 剖析使用itimerasync-profiler 事件。true否eventstring设置 CPU 剖析事件可取itimer、cpu或wall。itimer否sample_rateintCPU 剖析采样率会从 Hz 转换为间隔并作为-i参数传给 async-profiler。100否allocstring分配Allocation剖析采样配置作为--alloc参数传给 async-profiler。512k否lockstring锁Lock剖析采样配置作为--lock参数传给 async-profiler。10ms否per_threadbool启用 async-profiler 的 per-thread 模式-t。使用 wall 事件剖析时推荐开启。false否几点实操建议event wall与per_thread true搭配wall-clock 剖析按真实墙钟时间采样能捕捉线程在等待锁、I/O 等非 CPU 状态下的热点per-thread 模式让每个线程独立采样避免线程切换导致的采样偏移官方推荐在 wall 事件剖析时开启sample_rate的单位换算该值以 Hz 给出Alloy 内部会将其转换为采样间隔并映射为 async-profiler 的-i参数100 Hz 意味着每个 CPU 核心每秒约采集 100 个样本alloc/lock采样阈值512k表示对超过 512KB 的分配事件采样10ms表示对持锁超过 10ms 的锁事件采样阈值越小采样越密集、开销越大。关于 async-profiler 更完整的选项说明可参考其官方文档 profiler-options。为采集器设置权限pyroscope.java与discovery.process组件要正常工作必须以root 身份运行采集器如 Alloy并且必须运行在宿主的pid命名空间内——因为 Alloy 需要能枚举并 attach 到宿主机上或同一节点其他容器中的所有 Java 进程。这一点在仓库的两个示例中都有对应体现Docker 场景docker-compose.yml中Alloy 服务设置了privileged: true与pid: hostKubernetes 场景grafana-alloy.yaml中Alloy 以 DaemonSet 部署Pod 上设置了hostPID: true容器以runAsUser: 0运行并额外授予了PERFMON、SYS_PTRACE、SYS_RESOURCE、SYS_ADMIN等 Linux capabilities以满足 async-profiler attach 与性能事件采样的内核权限要求。启动采集器Grafana Alloyv1.2 及更高版本将configuration.alloy替换为你的配置文件名后直接运行alloy run configuration.alloyGrafana Alloyv1.0 或 v1.1启动命令为alloy run --stability.levelpublic-preview configuration.alloystability.level选项在 Alloy v1.0/v1.1 下对pyroscope.scrape是必需的其允许的取值说明可参考 run 命令文档。发送数据到 Grafana Cloud Profiles当需要把剖析数据发送到 Grafana Cloud Profiles 时可以使用如下基于环境变量的pyroscope.write组件配置。使用前请确保已正确配置GC_URL、GC_USER和GC_PASSWORD三个环境变量pyroscope.write endpoint { endpoint { basic_auth { password env(GC_PASSWORD) username env(GC_USER) } url env(GC_URL) } }若目标改为自建 Pyroscope Server则只需像下文示例那样直接指定url例如http://pyroscope:4040。三种实战场景完整可运行的配置示例以下三个示例均可在仓库 examples/grafana-alloy-auto-instrumentation/java 目录下找到对应的完整工程含 Docker Compose、Kubernetes 清单与示例 Java 程序。场景一剖析本地 Java 进程discovery.process all { } discovery.relabel java { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } // Filter processes. For example: only processes with command line containing FastSlow rule { source_labels [__meta_process_commandline] regex java FastSlow action keep } // Provide a service name for the process, otherwise it will be unspecified. rule { action replace target_label service_name replacement java-fast-slow } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解discovery.process all不写任何参数时会枚举本机全部进程第一条 relabel 规则按可执行文件路径.*/java$过滤出 JVM 进程第二条规则按命令行关键字进一步收窄目标示例中为java FastSlow对应仓库示例程序 FastSlow.java最后一条规则把service_name固定为java-fast-slow避免落入unspecified。仓库中 docker/config.alloy 即此类配置的完整版并额外开启了logging { level debug }便于排查同时在pyroscope.write上通过external_labels附加了env example标签。场景二剖析 Docker 容器discovery.docker local_containers { host unix:///var/run/docker.sock } discovery.process all { join discovery.docker.local_containers.targets } discovery.relabel java { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } // Filter only needed containers rule { source_labels [__meta_docker_container_name] regex .*suspicious_pascal action keep } // Provide a service name for the process, otherwise it will default to the value of __meta_docker_container_name label. rule { action replace target_label service_name replacement java-fast-slow } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解通过discovery.docker连接宿主机的 Docker socketunix:///var/run/docker.sock发现容器discovery.process的join参数把进程目标与容器目标按container_id关联起来从而让进程附带__meta_docker_*标签如果不在 relabel 中显式设置service_name默认会取__meta_docker_container_name的值。仓库中对应的可运行工程位于 java/docker其docker-compose.yml会同时拉起 Java 示例应用、Pyroscope端口 4040、Alloy 与 Grafana。Alloy 容器以privileged: true和pid: host启动示例 Java 应用由 java.Dockerfile 构建基于sapmachine:17-jdk-headless编译并运行FastSlow.java一个持续递归计算斐波那契数列的 CPU 密集程序非常适合验证 CPU 剖析效果。启动方式docker-compose up --build随后可通过 Grafana 的 Profiles Drilldown 应用http://localhost:3000/a/grafana-pyroscope-app/explore查看剖析数据。场景三剖析 Kubernetes Poddiscovery.kubernetes local_pods { selectors { field spec.nodeName env(HOSTNAME) role pod } role pod } discovery.process all { join discovery.kubernetes.local_pods.targets } discovery.relabel java_pods { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } rule { action drop regex Succeeded|Failed|Completed source_labels [__meta_kubernetes_pod_phase] } rule { action replace source_labels [__meta_kubernetes_namespace] target_label namespace } rule { action replace source_labels [__meta_kubernetes_pod_name] target_label pod } rule { action replace source_labels [__meta_kubernetes_pod_node_name] target_label node } rule { action replace source_labels [__meta_kubernetes_pod_container_name] target_label container } // Provide arbitrary service_name label, otherwise it will be inferred from discovery labels automatically rule { action replace regex (.*)(.*) replacement java/${1}/${2} separator source_labels [__meta_kubernetes_namespace, __meta_kubernetes_pod_container_name] target_label service_name } // Filter only needed services rule { action keep regex (java/ns1/.*)|(java/ns2/container-.*0) source_labels [service_name] } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java_pods.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解discovery.kubernetes通过selectors限定只发现当前节点spec.nodeNameHOSTNAME上的 Pod这正是 DaemonSet 模式的典型用法discovery.process的join把 Pod 目标与进程目标合并使进程获得__meta_kubernetes_*标签先drop掉已结束的 PodSucceeded|Failed|Completed再把namespace、pod、node、container等 meta 标签映射为普通标签带__前缀的标签最终会被丢弃不进入上报数据service_name通过regex (.*)(.*)separator 将「命名空间 容器名」拼接为java/namespace/container形式最后一条规则再按service_name的匹配结果只保留关心的服务。仓库中对应的完整部署位于 java/kubernetes其 grafana-alloy.yaml 展示了 Alloy 以 DaemonSet 形态部署所需的全部 Kubernetes 资源ClusterRolepods的list/watch权限供discovery.kubernetes使用、ServiceAccount、ClusterRoleBinding以及带hostPID: true、root 运行与特权 capabilities 的 DaemonSet。该清单中的 ConfigMap 内嵌配置与上文略有差异但思路一致例如直接用separator /拼接service_name并通过 Pod 注解__meta_kubernetes_pod_annotation_cluster_name设置cluster标签。部署步骤kubectl create namespace pyroscope-java kubectl apply -n pyroscope-java -f .查看数据可先转发 Grafana 服务端口kubectl port-forward -n pyroscope-java deployment/grafana 3000 3000小结与进一步阅读在 Pyroscope 体系中Grafana Alloy pyroscope.java是 Java 持续剖析的推荐采集方案它无需改造应用即可对运行中的 JVM 采样配合discovery.process与discovery.relabel可以实现进程/容器/Pod 的自动化发现与标签管理最终由pyroscope.write将 Profile 写入自建 Pyroscope Server 或 Grafana Cloud Profiles。本文覆盖的三类场景配置均可直接复制改造后投入实际环境。如需深入可继续查阅仓库内的以下资源官方组件参考pyroscope.scrape、pyroscope.write、discovery.kubernetes、discovery.docker、discovery.relabel可运行的完整示例工程examples/grafana-alloy-auto-instrumentation/javaDocker 与 Kubernetes 两套含 Java 示例程序、Compose/K8s 清单与 Grafana 预置面板语言 SDK 方式的对照参考docs/sources/configure-client/language-sdks/java.md了解 push 模式与 pullAlloy 采集模式的区别。【免费下载链接】pyroscopeContinuous Profiling Platform. Debug performance issues down to a single line of code项目地址: https://gitcode.com/GitHub_Trending/py/pyroscope创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
使用 Grafana Alloy 为 Java 进程配置持续剖析Pyroscope Java Profiling【免费下载链接】pyroscopeContinuous Profiling Platform. Debug performance issues down to a single line of code项目地址: https://gitcode.com/GitHub_Trending/py/pyroscope本文以 Pyroscope 仓库中的官方配置指南为主体讲解如何通过 Grafana Alloy 的pyroscope.java组件基于 async-profiler 对本地进程、Docker 容器与 Kubernetes Pod 进行零侵入的持续剖析Continuous Profiling。读完本文你将掌握 Alloy 各组件的职责与完整参数、profiling_config的每一项配置含义以及三种典型部署场景下可直接复用的config.alloy配置。组件总览一条从发现到上报的剖析流水线Grafana Alloy 支持 Java 剖析其配置文件由一组用于采集、转换和发送数据的组件component组成语法遵循 Alloy 的配置语法。针对 Java 持续剖析一条典型的流水线包含四类组件discovery.process发现主机上运行的所有进程可选地通过join关联 Kubernetes、Docker 等额外发现结果discovery.relabel过滤出 Java 进程并设置service_name等自定义标签pyroscope.java对指定进程执行剖析并产出 Profile 数据pyroscope.write将采集到的 Profile 数据写入 Pyroscope Server 或 Grafana Cloud Profiles。这一点在仓库示例 docker/README.md 与 kubernetes/README.md 中被明确归纳为同样的组件组合。与语言 SDK 埋点不同这种方式无需修改应用代码、无需重启应用pyroscope.java在底层通过 async-profiler 以进程级 attach 的方式附加到目标 JVM 并下发剖析命令因而可以对已经运行中的 Java 应用直接开始剖析。配置pyroscope.java组件pyroscope.java组件用于对运行在本地 Linux 操作系统上的 Java 进程进行持续剖析底层依赖 async-profiler。一个最小可用的配置如下pyroscope.java java { profiling_config { interval 15s alloc 512k cpu true event wall per_thread true lock 10ms sample_rate 100 } forward_to [pyroscope.write.endpoint.receiver] targets discovery.relabel.java.output }其中targets参数指定了要剖析机器上的哪些进程和容器forward_to参数指向一个pyroscope.write组件用于把采集到的 Profile 发送到 Pyroscope Server 或 Grafana Cloud。组件参数说明名称类型描述默认值是否必填targetslist(map(string))要剖析的 Java 进程目标列表。是forward_tolist(ProfilesReceiver)接收采集到的 Profile 的接收器列表。是tmp_dirstring存放 async-profiler 的临时目录。/tmp否两个必须存在的特殊标签targets中每个目标都必须携带特殊标签__process_pid__其值对应该进程的PIDpyroscope.java正是根据它定位并 attach 到目标 JVM。另一个特殊标签service_name同样必须存在。如果未显式指定pyroscope.java会尝试从发现组件的 meta 标签中推断若指定了却无法推断则该值会被设置为unspecified。因此在discovery.relabel中主动设置一个有意义的service_name是让剖析数据在 UI 中清晰可读的关键一步。深入profiling_configasync-profiler 的每个参数profiling_config块描述的是 async-profiler 的调用方式支持以下参数名称类型描述默认值是否必填intervalduration从目标进程采集 Profile 的频率。60s否cpubool是否启用 CPU 剖析使用itimerasync-profiler 事件。true否eventstring设置 CPU 剖析事件可取itimer、cpu或wall。itimer否sample_rateintCPU 剖析采样率会从 Hz 转换为间隔并作为-i参数传给 async-profiler。100否allocstring分配Allocation剖析采样配置作为--alloc参数传给 async-profiler。512k否lockstring锁Lock剖析采样配置作为--lock参数传给 async-profiler。10ms否per_threadbool启用 async-profiler 的 per-thread 模式-t。使用 wall 事件剖析时推荐开启。false否几点实操建议event wall与per_thread true搭配wall-clock 剖析按真实墙钟时间采样能捕捉线程在等待锁、I/O 等非 CPU 状态下的热点per-thread 模式让每个线程独立采样避免线程切换导致的采样偏移官方推荐在 wall 事件剖析时开启sample_rate的单位换算该值以 Hz 给出Alloy 内部会将其转换为采样间隔并映射为 async-profiler 的-i参数100 Hz 意味着每个 CPU 核心每秒约采集 100 个样本alloc/lock采样阈值512k表示对超过 512KB 的分配事件采样10ms表示对持锁超过 10ms 的锁事件采样阈值越小采样越密集、开销越大。关于 async-profiler 更完整的选项说明可参考其官方文档 profiler-options。为采集器设置权限pyroscope.java与discovery.process组件要正常工作必须以root 身份运行采集器如 Alloy并且必须运行在宿主的pid命名空间内——因为 Alloy 需要能枚举并 attach 到宿主机上或同一节点其他容器中的所有 Java 进程。这一点在仓库的两个示例中都有对应体现Docker 场景docker-compose.yml中Alloy 服务设置了privileged: true与pid: hostKubernetes 场景grafana-alloy.yaml中Alloy 以 DaemonSet 部署Pod 上设置了hostPID: true容器以runAsUser: 0运行并额外授予了PERFMON、SYS_PTRACE、SYS_RESOURCE、SYS_ADMIN等 Linux capabilities以满足 async-profiler attach 与性能事件采样的内核权限要求。启动采集器Grafana Alloyv1.2 及更高版本将configuration.alloy替换为你的配置文件名后直接运行alloy run configuration.alloyGrafana Alloyv1.0 或 v1.1启动命令为alloy run --stability.levelpublic-preview configuration.alloystability.level选项在 Alloy v1.0/v1.1 下对pyroscope.scrape是必需的其允许的取值说明可参考 run 命令文档。发送数据到 Grafana Cloud Profiles当需要把剖析数据发送到 Grafana Cloud Profiles 时可以使用如下基于环境变量的pyroscope.write组件配置。使用前请确保已正确配置GC_URL、GC_USER和GC_PASSWORD三个环境变量pyroscope.write endpoint { endpoint { basic_auth { password env(GC_PASSWORD) username env(GC_USER) } url env(GC_URL) } }若目标改为自建 Pyroscope Server则只需像下文示例那样直接指定url例如http://pyroscope:4040。三种实战场景完整可运行的配置示例以下三个示例均可在仓库 examples/grafana-alloy-auto-instrumentation/java 目录下找到对应的完整工程含 Docker Compose、Kubernetes 清单与示例 Java 程序。场景一剖析本地 Java 进程discovery.process all { } discovery.relabel java { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } // Filter processes. For example: only processes with command line containing FastSlow rule { source_labels [__meta_process_commandline] regex java FastSlow action keep } // Provide a service name for the process, otherwise it will be unspecified. rule { action replace target_label service_name replacement java-fast-slow } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解discovery.process all不写任何参数时会枚举本机全部进程第一条 relabel 规则按可执行文件路径.*/java$过滤出 JVM 进程第二条规则按命令行关键字进一步收窄目标示例中为java FastSlow对应仓库示例程序 FastSlow.java最后一条规则把service_name固定为java-fast-slow避免落入unspecified。仓库中 docker/config.alloy 即此类配置的完整版并额外开启了logging { level debug }便于排查同时在pyroscope.write上通过external_labels附加了env example标签。场景二剖析 Docker 容器discovery.docker local_containers { host unix:///var/run/docker.sock } discovery.process all { join discovery.docker.local_containers.targets } discovery.relabel java { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } // Filter only needed containers rule { source_labels [__meta_docker_container_name] regex .*suspicious_pascal action keep } // Provide a service name for the process, otherwise it will default to the value of __meta_docker_container_name label. rule { action replace target_label service_name replacement java-fast-slow } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解通过discovery.docker连接宿主机的 Docker socketunix:///var/run/docker.sock发现容器discovery.process的join参数把进程目标与容器目标按container_id关联起来从而让进程附带__meta_docker_*标签如果不在 relabel 中显式设置service_name默认会取__meta_docker_container_name的值。仓库中对应的可运行工程位于 java/docker其docker-compose.yml会同时拉起 Java 示例应用、Pyroscope端口 4040、Alloy 与 Grafana。Alloy 容器以privileged: true和pid: host启动示例 Java 应用由 java.Dockerfile 构建基于sapmachine:17-jdk-headless编译并运行FastSlow.java一个持续递归计算斐波那契数列的 CPU 密集程序非常适合验证 CPU 剖析效果。启动方式docker-compose up --build随后可通过 Grafana 的 Profiles Drilldown 应用http://localhost:3000/a/grafana-pyroscope-app/explore查看剖析数据。场景三剖析 Kubernetes Poddiscovery.kubernetes local_pods { selectors { field spec.nodeName env(HOSTNAME) role pod } role pod } discovery.process all { join discovery.kubernetes.local_pods.targets } discovery.relabel java_pods { targets discovery.process.all.targets // Filter only java processes rule { source_labels [__meta_process_exe] action keep regex .*/java$ } rule { action drop regex Succeeded|Failed|Completed source_labels [__meta_kubernetes_pod_phase] } rule { action replace source_labels [__meta_kubernetes_namespace] target_label namespace } rule { action replace source_labels [__meta_kubernetes_pod_name] target_label pod } rule { action replace source_labels [__meta_kubernetes_pod_node_name] target_label node } rule { action replace source_labels [__meta_kubernetes_pod_container_name] target_label container } // Provide arbitrary service_name label, otherwise it will be inferred from discovery labels automatically rule { action replace regex (.*)(.*) replacement java/${1}/${2} separator source_labels [__meta_kubernetes_namespace, __meta_kubernetes_pod_container_name] target_label service_name } // Filter only needed services rule { action keep regex (java/ns1/.*)|(java/ns2/container-.*0) source_labels [service_name] } } pyroscope.java java { forward_to [pyroscope.write.example.receiver] targets discovery.relabel.java_pods.output } pyroscope.write example { endpoint { url http://pyroscope:4040 } }要点拆解discovery.kubernetes通过selectors限定只发现当前节点spec.nodeNameHOSTNAME上的 Pod这正是 DaemonSet 模式的典型用法discovery.process的join把 Pod 目标与进程目标合并使进程获得__meta_kubernetes_*标签先drop掉已结束的 PodSucceeded|Failed|Completed再把namespace、pod、node、container等 meta 标签映射为普通标签带__前缀的标签最终会被丢弃不进入上报数据service_name通过regex (.*)(.*)separator 将「命名空间 容器名」拼接为java/namespace/container形式最后一条规则再按service_name的匹配结果只保留关心的服务。仓库中对应的完整部署位于 java/kubernetes其 grafana-alloy.yaml 展示了 Alloy 以 DaemonSet 形态部署所需的全部 Kubernetes 资源ClusterRolepods的list/watch权限供discovery.kubernetes使用、ServiceAccount、ClusterRoleBinding以及带hostPID: true、root 运行与特权 capabilities 的 DaemonSet。该清单中的 ConfigMap 内嵌配置与上文略有差异但思路一致例如直接用separator /拼接service_name并通过 Pod 注解__meta_kubernetes_pod_annotation_cluster_name设置cluster标签。部署步骤kubectl create namespace pyroscope-java kubectl apply -n pyroscope-java -f .查看数据可先转发 Grafana 服务端口kubectl port-forward -n pyroscope-java deployment/grafana 3000 3000小结与进一步阅读在 Pyroscope 体系中Grafana Alloy pyroscope.java是 Java 持续剖析的推荐采集方案它无需改造应用即可对运行中的 JVM 采样配合discovery.process与discovery.relabel可以实现进程/容器/Pod 的自动化发现与标签管理最终由pyroscope.write将 Profile 写入自建 Pyroscope Server 或 Grafana Cloud Profiles。本文覆盖的三类场景配置均可直接复制改造后投入实际环境。如需深入可继续查阅仓库内的以下资源官方组件参考pyroscope.scrape、pyroscope.write、discovery.kubernetes、discovery.docker、discovery.relabel可运行的完整示例工程examples/grafana-alloy-auto-instrumentation/javaDocker 与 Kubernetes 两套含 Java 示例程序、Compose/K8s 清单与 Grafana 预置面板语言 SDK 方式的对照参考docs/sources/configure-client/language-sdks/java.md了解 push 模式与 pullAlloy 采集模式的区别。【免费下载链接】pyroscopeContinuous Profiling Platform. Debug performance issues down to a single line of code项目地址: https://gitcode.com/GitHub_Trending/py/pyroscope创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
