refactor(perf-platform): drop version diff and ratio exporter

Remove the canary-regression detection path entirely. The diff lane,
ratio gauge, and version-aware webhook handling fought the timing
constraints of a workshop session — JIT warm-up on a freshly started
canary produces ±10pp deltas that drown anything else, and there is
no way to wait it out in 90 minutes. Replace with a four-lane
single-version analysis that runs equally well at zero load, light
load, and saturating load.

Analyzer

- Drop ProfileRatioExporter and PyroscopeVersionService entirely.
  No more in-process Prometheus gauge, no more version-pair selection.
- PyroscopeTool keeps a single @tool method, topFunctions(service,
  profileType, from, to, limit). The diff() tool method, totalsForVersion
  helper, and total-time delta formatter are gone.
- AnalysisService runs four parallel lanes (CPU top, wall top, JFR,
  thread dump). AnalysisContext drops the diff and version fields.
  Window stays 5 minutes, single static value at the top of the file.
- AiService prompt reframed around two-lens correlation rather than
  diffs. System prompt: CPU is what is computing, wall is what is
  waiting; cross-check both. The application-frame-vs-low-level-frame
  guidance carries over.
- AnalyzeController.toRequest still recovers workload + platform from
  the {service_name}-{eks|ecs} convention so any Grafana alert label
  pattern carrying that name works without code changes.

Collector

- AsyncProfilerAttach javadoc rewritten to match the implementation:
  CPU + wall via -e cpu --wall 10ms, JFR rotation via --loop 15s,
  Pyroscope splits the JFR file into process_cpu and wall profile
  types automatically. No code change to the attach itself; the
  previous wall-only experiment has been reverted.

Verified end-to-end on the live cluster: stripped analyzer rebuilt,
redeployed, and a single on-demand /api/v1/analyze against the
unicorn-store-spring pod produced a 60-second report that correctly
identified the latent blocking .get() in UnicornService.publishUnicorn-
Event with a source-code citation.

Author: Yuriy Bezsonov

apps/perf-analyzer/src/main/java/com/example/perf/analyzer/AiService.java

@@ -30,49 +30,39 @@ public class AiService {
 
     private static final String SYSTEM_PROMPT = """
         You are a Java performance engineer. You receive:
-          - per-frame Pyroscope diffs between the current service version
-            and the prior one (when two versions are present), shown in two
-            views: CPU profile and wall-clock profile. The diffs rank frames
-            by total-time share (frame plus its descendants), so an
-            application caller that walks into a new hotspot or a new
-            contended primitive will appear directly in the diff even when
-            the actual time is burned in a JVM intrinsic, glibc lock primitive
-            or other low-level frame underneath it. CPU diff surfaces new
-            on-CPU work; wall diff surfaces new contention or I/O waits.
-          - pre-aggregated Pyroscope top-functions tables for the current
-            version, again in CPU and wall views.
+          - pre-aggregated Pyroscope top-functions tables for the target
+            service in two views: CPU profile (process_cpu) and wall-clock
+            profile (wall). CPU shows what is actually computing on a core;
+            wall shows where every sampled thread spends time, regardless of
+            state. CPU is the right lens for finding new computation; wall
+            is the right lens for finding contention, blocked I/O, and
+            downstream waits.
           - a JFR summary covering GC pauses, JIT compilation, deoptimization,
             monitor contention, safepoints and JVM configuration.
           - a thread dump.
         All were captured around the time an alert fired or a developer
         triggered an on-demand analysis.
 
-        When diffs are present, treat the frames with the largest positive
-        deltas as the primary suspects — they are what changed. Pay particular
-        attention to *application* (project package) frames in the diff: they
-        identify the caller in the user's code and are usually the right
-        anchor for a finding even when an underlying low-level frame
-        (HashMap.merge, futex, arraycopy, JIT helper) shows a similar delta —
-        those are typically the *mechanism*, not the cause. Cross-check the
-        CPU and wall diffs: a real regression usually shows clearly in at
-        least one and weakly in the other (CPU-heavy regression: big in CPU,
-        small in wall; contention regression: big in wall, small in CPU).
-        Frames that are large in absolute terms but small in any diff are
-        long-standing workload characteristics and are usually not the cause
-        of a regression, though they may still be worth flagging separately.
-        Analyze the data and report what you find.
+        Cross-check across signals: a method that appears hot in the wall
+        profile and shows blocked or waiting threads in the dump is the
+        same observation in two lenses. A method that appears hot in CPU
+        but quiet in wall is real on-CPU work, not waiting. Pay particular
+        attention to *application* (project package) frames — they identify
+        the caller in the user's code and are usually the right anchor for
+        a finding even when the actual time is burned in a low-level frame
+        underneath (HashMap, futex, JIT helper, glibc lock primitive); the
+        low-level frame is the mechanism, the application frame is the
+        cause. Analyze the data and report what you find.
         """;
 
     private final ChatClient chatClient;
-    private final PyroscopeTool pyroscopeTool;
     private final String githubToken;
 
     public AiService(
         ChatClient.Builder chatClientBuilder,
         PyroscopeTool pyroscopeTool,
         @Value("${GITHUB_TOKEN:}") String githubToken
     ) {
-        this.pyroscopeTool = pyroscopeTool;
         this.githubToken = githubToken;
         this.chatClient = chatClientBuilder
             .defaultSystem(SYSTEM_PROMPT)
@@ -113,63 +103,16 @@ String buildPrompt(AnalysisService.AnalysisContext ctx, boolean sourceCodeAvaila
         sb.append("- platform: **").append(r.platform().name().toLowerCase().replace('_', '-')).append("**\n");
         sb.append("- target: **").append(r.target()).append("**\n");
         sb.append("- trigger: ").append(r.source()).append("\n");
-        if (ctx.currentVersion() != null) {
-            sb.append("- current version: ").append(ctx.currentVersion()).append("\n");
-        }
-        if (ctx.baselineVersion() != null) {
-            sb.append("- prior version (baseline for diff): ").append(ctx.baselineVersion()).append("\n");
-        }
         if (r.reason() != null && !r.reason().isBlank()) {
             sb.append("- reason: ").append(r.reason()).append("\n");
         }
         sb.append("- analysisId: ").append(ctx.analysisId()).append("\n\n");
 
-        // Diffs are the most decision-useful pieces when they exist — they
-        // tell the model what is *new* in the current version. Wall and CPU
-        // diffs answer different questions: wall surfaces new contention or
-        // I/O waits; CPU surfaces new actual computation. Present both first
-        // (when available) so regression findings lead the report.
-        boolean diffWallPresent = ctx.pyroscopeDiffWallMarkdown() != null
-            && !ctx.pyroscopeDiffWallMarkdown().isBlank();
-        boolean diffCpuPresent = ctx.pyroscopeDiffCpuMarkdown() != null
-            && !ctx.pyroscopeDiffCpuMarkdown().isBlank();
-
-        if (diffWallPresent || diffCpuPresent) {
-            sb.append("## Pyroscope version diffs (pre-fetched)\n\n")
-                .append("Two views of what changed between baseline and current. Both diffs rank by ")
-                .append("**total-time share** (frame plus descendants), so application callers that walk ")
-                .append("into a new hotspot or contended primitive show up directly. ")
-                .append("**CPU diff** is what to read first for new computation — frames with positive ")
-                .append("Δ pp on the CPU diff are new on-CPU work. **Wall diff** is what to read first ")
-                .append("for new contention or I/O waits — frames with positive Δ pp on the wall diff are ")
-                .append("new waiting time. A regression often shows up sharply in one and weakly in the ")
-                .append("other; cross-check both. When an application frame and a low-level frame both ")
-                .append("rise together, the application frame is the cause and the low-level frame is the ")
-                .append("mechanism.\n\n");
-
-            sb.append("### CPU diff (process_cpu)\n\n");
-            sb.append(diffCpuPresent
-                ? ctx.pyroscopeDiffCpuMarkdown()
-                : "_CPU diff unavailable._");
-            sb.append("\n\n");
-
-            sb.append("### Wall diff (wall)\n\n");
-            sb.append(diffWallPresent
-                ? ctx.pyroscopeDiffWallMarkdown()
-                : "_Wall diff unavailable._");
-            sb.append("\n\n");
-        } else if (ctx.currentVersion() != null) {
-            sb.append("## Pyroscope version diffs (pre-fetched)\n\n")
-                .append("_No prior version is visible in Pyroscope for this service; diffs are not available. ")
-                .append("Rely on the top-functions snapshots and JFR/thread-dump signals below._\n\n");
-        }
-
         // Top-functions snapshots in both lenses. Same window, two lenses on
-        // the same workload state. Useful both as supporting context for the
-        // diff above and as the primary signal when no diff is available.
+        // the same workload state.
         sb.append("## Pyroscope top functions (pre-fetched)\n\n")
-            .append("Two lenses on the same window for the current version. Use **CPU** to find what is ")
-            .append("computing right now; use **wall** to find what is waiting right now.\n\n");
+            .append("Two lenses on the same window. Use **CPU** to find what is computing right now; ")
+            .append("use **wall** to find what is waiting on locks, I/O, or downstream calls right now.\n\n");
 
         sb.append("### CPU (process_cpu)\n\n")
             .append(ctx.pyroscopeCpuTopFunctionsMarkdown() == null
@@ -203,12 +146,10 @@ String buildPrompt(AnalysisService.AnalysisContext ctx, boolean sourceCodeAvaila
 
             ## Findings
             Correlate the Pyroscope ranked functions (CPU and wall) with JFR
-            events and thread states. When diffs are available, lead with what
-            changed; cross-check CPU vs wall diffs to distinguish a new
-            CPU-heavy code path from a new contention or I/O bottleneck. Flag
-            resource pressure, configuration issues, or patterns that suggest
-            a problem. Cite specific methods,
-            thread names, and numbers.
+            events and thread states. Distinguish on-CPU work (CPU view) from
+            blocking waits and contention (wall view). Flag resource pressure,
+            configuration issues, or patterns that suggest a problem. Cite
+            specific methods, thread names, and numbers.
 
             ## Recommendations
             Prioritized — most impactful first. Only include actionable items

apps/perf-analyzer/src/main/java/com/example/perf/analyzer/AnalysisService.java

@@ -28,9 +28,13 @@
 
 /**
  * Virtual-thread orchestrator. Each submitted analysis runs on its own
- * virtual thread, launching three parallel sub-lanes for JFR, thread dump,
- * and Pyroscope top functions. Results are stitched together, handed to
- * AiService, and the Markdown report lands in S3 alongside the raw artifacts.
+ * virtual thread, launching four parallel sub-lanes:
+ *   - Pyroscope CPU top functions (current 5-minute window)
+ *   - Pyroscope wall top functions (current 5-minute window)
+ *   - JFR snapshot via the collector
+ *   - Thread dump via the collector
+ * Results are stitched together, handed to AiService, and the Markdown
+ * report lands in S3 alongside the raw artifacts.
  *
  * Collector locating (pod -> node -> DaemonSet pod IP on EKS; task ARN ->
  * ENI IP on ECS) lives here too. It's a single-responsibility concern —
@@ -47,14 +51,14 @@ public class AnalysisService {
         DateTimeFormatter.ofPattern("yyyyMMdd-HHmmss").withZone(ZoneOffset.UTC);
     private static final ObjectMapper MAPPER = new ObjectMapper();
     private static final int COLLECTOR_PORT = 8090;
+    private static final Duration WINDOW = Duration.ofMinutes(5);
 
     private final CoreV1Api k8s;
     private final EcsClient ecs;
     private final S3Repository s3;
     private final JfrParser jfrParser;
     private final AiService ai;
     private final PyroscopeTool pyroscope;
-    private final PyroscopeVersionService versions;
     private final String collectorNamespace;
     private final String collectorPodLabel;
 
@@ -68,7 +72,6 @@ public AnalysisService(
         JfrParser jfrParser,
         AiService ai,
         PyroscopeTool pyroscope,
-        PyroscopeVersionService versions,
         @Value("${perf.analyzer.collector.namespace:monitoring}") String collectorNamespace,
         @Value("${perf.analyzer.collector.pod-label:app=perf-collector}") String collectorPodLabel
     ) {
@@ -78,7 +81,6 @@ public AnalysisService(
         this.jfrParser = jfrParser;
         this.ai = ai;
         this.pyroscope = pyroscope;
-        this.versions = versions;
         this.collectorNamespace = collectorNamespace;
         this.collectorPodLabel = collectorPodLabel;
     }
@@ -130,25 +132,17 @@ private void run(AnalysisRequest request, String analysisId, String prefix) {
         var jfrDumpUri = s3.profilingDumpUri(request, analysisId, "jfr");
         var threadDumpUri = s3.profilingDumpUri(request, analysisId, "json");
 
-        // Pre-resolve the version pair so the diff lane and the prompt both
-        // know the exact labels we're comparing. Same 5-minute window as the
-        // exporter — if the exporter is firing an alert for this service,
-        // we want the analyzer looking at the same window it alerted on.
         var pyroService = pyroscopeServiceName(request);
-        var versionPair = versions.selectCurrentAndBaseline(pyroService, 300L);
-
-        var windowStart = Instant.now().minus(Duration.ofMinutes(5));
         var windowEnd = Instant.now();
+        var windowStart = windowEnd.minus(WINDOW);
 
+        // Four parallel lanes. Pyroscope lanes pre-fetch ranked top-N tables
+        // for both profile types so the prompt has them ready; collector
+        // lanes capture JFR + thread dump for the same workload.
         var jfrLane = CompletableFuture.supplyAsync(
             () -> captureJfr(request, analysisId, collectorUrl, jfrDumpUri), laneExecutor);
         var threadLane = CompletableFuture.supplyAsync(
             () -> captureThreadDump(request, analysisId, collectorUrl, threadDumpUri), laneExecutor);
-
-        // Top-functions lanes — one per profile type. Wall surfaces "where is
-        // time being spent including waits"; CPU surfaces "where is the CPU
-        // actually doing work". Both views go to the model so it can decide
-        // which lens applies to the question at hand.
         var pyroWallLane = CompletableFuture.supplyAsync(
             () -> pyroscope.topFunctions(pyroService, "wall",
                 windowStart.toString(), windowEnd.toString(), 20),
@@ -158,32 +152,10 @@ private void run(AnalysisRequest request, String analysisId, String prefix) {
                 windowStart.toString(), windowEnd.toString(), 20),
             laneExecutor);
 
-        // Diff lanes — conditional on a baseline existing. We run BOTH
-        // profile-type diffs because a regression can show up differently
-        // in each lens: a new contention point shows in wall, a new hot
-        // computation shows in CPU. CompletableFuture.completedFuture(null)
-        // for the skipped case keeps the prompt-builder branch simple.
-        CompletableFuture<String> diffWallLane = versionPair.hasBaseline()
-            ? CompletableFuture.supplyAsync(
-                () -> pyroscope.diff(pyroService, "wall",
-                    versionPair.baseline(), versionPair.current(),
-                    windowStart.toString(), windowEnd.toString(), 20),
-                laneExecutor)
-            : CompletableFuture.completedFuture(null);
-        CompletableFuture<String> diffCpuLane = versionPair.hasBaseline()
-            ? CompletableFuture.supplyAsync(
-                () -> pyroscope.diff(pyroService, "cpu",
-                    versionPair.baseline(), versionPair.current(),
-                    windowStart.toString(), windowEnd.toString(), 20),
-                laneExecutor)
-            : CompletableFuture.completedFuture(null);
-
         String jfrMarkdown = null;
         String threadDumpText = null;
         String pyroscopeWallMarkdown = null;
         String pyroscopeCpuMarkdown = null;
-        String pyroscopeDiffWallMarkdown = null;
-        String pyroscopeDiffCpuMarkdown = null;
 
         try { jfrMarkdown = jfrLane.get(3, TimeUnit.MINUTES); }
         catch (Exception e) { logger.warn("JFR lane failed: {}", e.getMessage()); }
@@ -193,16 +165,10 @@ private void run(AnalysisRequest request, String analysisId, String prefix) {
         catch (Exception e) { logger.warn("Pyroscope wall lane failed: {}", e.getMessage()); }
         try { pyroscopeCpuMarkdown = pyroCpuLane.get(30, TimeUnit.SECONDS); }
         catch (Exception e) { logger.warn("Pyroscope cpu lane failed: {}", e.getMessage()); }
-        try { pyroscopeDiffWallMarkdown = diffWallLane.get(30, TimeUnit.SECONDS); }
-        catch (Exception e) { logger.warn("Pyroscope wall-diff lane failed: {}", e.getMessage()); }
-        try { pyroscopeDiffCpuMarkdown = diffCpuLane.get(30, TimeUnit.SECONDS); }
-        catch (Exception e) { logger.warn("Pyroscope cpu-diff lane failed: {}", e.getMessage()); }
 
         var ctx = new AnalysisContext(
             request, analysisId, jfrMarkdown, threadDumpText,
             pyroscopeWallMarkdown, pyroscopeCpuMarkdown,
-            pyroscopeDiffWallMarkdown, pyroscopeDiffCpuMarkdown,
-            versionPair.current(), versionPair.baseline(),
             metadata.githubRepo(), metadata.githubPath());
 
         String analysisMd;
@@ -449,13 +415,9 @@ public record AnalysisContext(
         String analysisId,
         String jfrSummaryMarkdown,
         String threadDumpText,
-        String pyroscopeWallTopFunctionsMarkdown,   // wall-clock top-N
-        String pyroscopeCpuTopFunctionsMarkdown,    // on-CPU top-N
-        String pyroscopeDiffWallMarkdown,           // null if only one version visible
-        String pyroscopeDiffCpuMarkdown,            // null if only one version visible
-        String currentVersion,           // null if no version labels present
-        String baselineVersion,          // null if only one version visible
-        String githubRepo,     // e.g. "aws-samples/java-on-aws", null if not configured
-        String githubPath      // e.g. "apps/unicorn-store-spring"
+        String pyroscopeWallTopFunctionsMarkdown,
+        String pyroscopeCpuTopFunctionsMarkdown,
+        String githubRepo,
+        String githubPath
     ) {}
 }

apps/perf-analyzer/src/main/java/com/example/perf/analyzer/AnalyzeController.java

@@ -82,11 +82,14 @@ private static void validateTarget(AnalyzeRequest r) {
     }
 
     /**
-     * Derive the analysis request from Grafana alert labels. The exporter emits
-     * {@code perf_profile_cpu_ratio{service_name="unicorn-store-spring-eks",version="v2"}} —
-     * we strip the {@code -eks}/{@code -ecs} suffix to recover the workload name and
-     * derive the platform from the suffix, then resolve a current pod/task by the
-     * {@code perf-profile/service} label or tag.
+     * Derive the analysis request from Grafana alert labels. Whatever the
+     * alert source, we expect either:
+     *   - a {@code service_name} label that matches what the collector
+     *     publishes (e.g. {@code unicorn-store-spring-eks}), with the
+     *     {@code -eks}/{@code -ecs} suffix telling us the platform; or
+     *   - a {@code service} label plus an explicit {@code platform} label.
+     * For EKS we resolve a current pod by the {@code perf-profile/service}
+     * label; for ECS the alert must carry an explicit {@code task} label.
      */
     private AnalysisService.AnalysisRequest toRequest(Map<String, String> labels) {
         if (labels == null) return null;
@@ -123,16 +126,14 @@ private AnalysisService.AnalysisRequest toRequest(Map<String, String> labels) {
                 return null;
             }
         } else {
-            // ECS target resolution via tags isn't wired here yet — fall back to
-            // whatever the alert labels supply (set manually in curl-based tests).
             task = labels.get("task");
             if (task == null || task.isBlank()) {
                 logger.warn("No task in labels for workload={} on ECS", workload);
                 return null;
             }
         }
 
-        var reason = "Grafana alert: " + labels.getOrDefault("alertname", "PerfProfileRegression");
+        var reason = "Grafana alert: " + labels.getOrDefault("alertname", "unknown");
         return new AnalysisService.AnalysisRequest(
             workload, platform, pod, task, reason,
             AnalysisService.TriggerSource.GRAFANA_WEBHOOK);