grafana / jpprof Goto Github PK

Hello,
We have a service in SpringBoot.
We have added controller by documentation (https://grafana.com/docs/phlare/latest/operators-guide/configure-agent/language-support/jvm/) as follows:

dependencies {
    implementation 'com.grafana:jpprof:0.1.6'
}

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;

import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.time.Duration;

import jpprof.CPUProfiler;

@RestController
public class PprofController {

  @GetMapping("/debug/pprof/profile")
  @ResponseBody
  public void profile(@RequestParam(required = false) String seconds, HttpServletResponse response) {
    try {
      Duration d = Duration.ofSeconds(Integer.parseInt(seconds));
      CPUProfiler.start(d, response.getOutputStream());
      response.flushBuffer();
    } catch (Exception e) {
      System.out.println("exception: " + e.getMessage());
    }
  }
}

After container started we tried to fetch cpu profiles by using command:
go tool pprof -http :6060 http://localhost:8080/debug/pprof/profile\?seconds\=100

We get error:
http://localhost:8080/debug/pprof/profile?seconds=100: parsing profile: empty input file failed to fetch any source profiles

See async-profiler/async-profiler#713 (cc @NeQuissimus)

Afaict https://github.com/grafana/JPProf/blob/main/lib/src/main/java/jpprof/jfr2pprof.java was copied from async-profiler, so the above patch should apply fairly cleanly with some manual intervention, since the code has been refactored some.

It also looks like there could be some fixes here that could be backported to async-profiler if indeed they share a common origin.

Currently the library is not being built or package with native dependencies. We should also think about pushing the library to maven central.

We should provide a changelog and github release.

We should replace our custom integration of AsyncProfiler with https://github.com/parttimenerd/ap-loader so that we don't have to worry about the platform and architecture.

Hello,

It seems, that you pushed the library to maven repo with JDK 11 target.

jpprof-0.1.0/jpprof$ javap -verbose PprofHttpHandler | grep "major"
Warning: File ./PprofHttpHandler.class does not contain class PprofHttpHandler
  major version: 55

When I try to run an example with JDK 8, I got the following error:

$ java -version
openjdk version "1.8.0_333"
OpenJDK Runtime Environment (build 1.8.0_333-b02)
OpenJDK 64-Bit Server VM (build 25.333-b02, mixed mode)

JPProf/examples/springboot/src/main/java/com/example/springboot/PprofController.java:11: error: cannot access jpprof.CPUProfiler
import jpprof.CPUProfiler;
             ^
  bad class file: /home/user/.gradle/caches/modules-2/files-2.1/com.grafana/jpprof/0.1.0/701850efd445118005e300aaa9efd4b1424910d0/jpprof-0.1.0.jar(jpprof/CPUProfiler.class)
    class file has wrong version 55.0, should be 52.0
    Please remove or make sure it appears in the correct subdirectory of the classpath.

I think, you pushed the library to maven before this change 290f9a5#diff-655a69127303f6948c0b150902436756156ec7f82640e994c1f552cbdec5bbceL11-L12

It would be great to package JPProf as a Java agent, so I can specify it on the command line of an existing application and don't need to change my applications.

java -javaagent:jpprof-javaagent.jar -jar myapp.jar

Other frameworks like open telemetry do this already. See https://github.com/open-telemetry/opentelemetry-java-instrumentation, and looking at the standalone example this should hopefully be possible.

There would be the need to pass the port as a parameter, for example as a system property (-Dgrafana.jpprof.port=xxx).

Thanks!

We should be able to configure count/total but also the interval (default to 10ms).

See https://github.com/jvm-profiling-tools/async-profiler/blob/master/src/arguments.cpp#L52-L111

Security department within my company does not allow open containers sys_admin permissions, because it is easy to produce risk.
After my guess and actual test, to the open container perf_event_open permission also can achieve the same effect, whether can give other users clue in the document?