Завел #3

perforator на C++ написан, если я правильно понимаю

Вообще хостовый агент написан на Go (на C написана eBPF программа, раскручивающая стэки из контекста ядра, предполагаю что в затрагиваемой интеграции она участвовать не будет).

Но на мой взгляд, в данный момент нужен не код, а дизайн. Например у меня сходу имеются такие вопросы:

• Какие данные собирать? (Не уверен, что все события JFR осмысленны в виде флеймграфов)
• Как их собирать? (Должны ли мы реимплементировать кусок JFR на го, линковаться с ним, запускать как отдельный процесс, что-то еще?)
• Как подмешивать их в профили?

В команде мы это тоже обсудим (но по срокам обещать ничего не могу).

JFR встроен в JVM. Есть несколько способ записи снепшотов: через XX-флаги, JMX и jcmd. Через XX-флаги это выглядит примерно так: java -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=myrecording.jfr MemoryIssue.java
JFR по-умному буферизирует записи событий, они могу храниться на диске или стримиться и обрабатываться программно, в коде. Можно например написать свой java agent, который будет собирать нужные события и отправлять их куда нужно в формате, в котором вы придумаете.

По опыту разбора различных инцидентов с java-сервисами анализ флэйм графа далеко не всегда нужен, возможно если вы свой "фреймворк/очень большую библиотеку" написали и там очень много вашего, кода, который никогда не профилировался локально бенчмарками.

Обычно в продакшне мы имеем дело с использованием heap'а в jvm и OutOfMemory. Нужно смотреть как работал GC, какие объекты в памяти занимают больше всего места и т.п. JFR собирает достаточно событий чтобы с этим разбираться. Например в случае OutOfMemory можно смотреть memory allocation события:

и по ним так же можно построить флэйм граф использования памяти:

Кроме того можно покрыть приложение своими метриками и выводить их через JFR. Условное приложение на Spring Boot принимает запросы, ходит в БД, кэши и смежные сервисы. Можно собирать метрики задержек, чтобы "раскручивать" чего именно мы ждали на запросе в ендпойнт. Но это уже по сути трассировка и есть устоявшиеся решения на grafana stack (loki, tempo, OpenTelemetry).
Смотреть через флейм граф, какой сетевой запрос, сделанный сервисом, внес большую задержку кажется не подходящим решением, потому что это в java-проектах очень давно делают иначе. Или какие методы, делающие запросы в БД, заняли больше времени опять таки странно смотреть через флэйм граф.

Флейм графы с длительностью выполнения методов могут быть полезны, когда есть много логики, которая сильно CPU нагружает. Типовые java-приложения чаще страдают проблемами с использованием памяти, а не CPU.

Поэтому я бы посмотрел в сторону профилирования java-приложений еще и по памяти. А JFR дает столько событий, что там только под них можно сделать отдельный дашборд.