Flopsar 7 — the new generation is here

See why it failed.
Not just that it failed.

Flopsar records how methods actually execute in production — the tree of calls, their timings, captured arguments, and exceptions. When something is slow or breaks, you open the execution stack and read the answer.

Request a demo Read the docs
  • No code changes
  • No vendor cloud
  • Any JVM framework
0years in business
0enterprise clients
0transactions daily
0system availability

Trusted by leaders in finance, telecom, insurance & the public sector

Why Flopsar

Most tools tell you that.
Flopsar shows you why.

Traditional APM asks you to instrument your application — SDKs, annotations, vendor builds — and gives back averages and sampled spans. Flopsar takes the opposite approach on every count.

Non-invasive

A native JVMTI agent loaded with a single JVM option. No SDK in your project, no source changes, no redeploy of a special build. Independent of framework and application server.

-agentpath:/opt/flopsar/agent.so

Declarative

What to observe is a profile — named rules for classes and methods, pushed from the server to running agents. Start broad, then narrow or deepen as you learn. Live, without restarts.

profile: entry-points → deepen: CardGateway.*

Diagnostic

Method-level execution data is kept, not sampled away. Open one request, read its stack, parameters, and the exception that aborted it. Charts find the case — the stack explains it.

stack → args → exception → root cause
Flopsar 7

Everything you need for
method-level diagnosis

The unit of observation is the execution stack — a single recorded invocation and the nested methods it called. Deeper than dashboards of averages. Deeper than span-based traces.

Complete execution stacks

Every recorded invocation keeps its full call tree: timings, captured method arguments, CPU time, and the exception that ended it. Search, aggregate, and walk the stack after the fact — without having guessed in advance which metric you would need.

▾ OrderService.submit(cart=…, user=#4471)  312 ms
  ▾ InventoryClient.reserve(sku="A-9920", qty=2)  288 ms
    · JsonCodec.encode(payload)  1 ms
    ✕ RestTemplate.exchange(POST /reserve)  HttpServerErrorException: 503

Latency distributions

Percentiles, histograms, and how they drift over time. Find the tail, then open the exact invocations behind it.

p50 · 24 msp99 · 1.8 s

Exception intelligence

Exceptions are detected, grouped, and traced back to their root cause — with the stack and arguments that produced them.

SocketTimeoutException×117
OptimisticLockException×23
NullPointerExceptionnew

JVM & resource telemetry

Garbage collection behavior, memory, CPU, connection pools, and JMX metrics — correlated with the code that was running.

heap after GCold gen · stable

AI Assistant

Ask questions about the same execution data — summaries, anomalies, likely causes — always within your permissions.

Why did checkout p99 spike at 14:02?
✦ 117 invocations waited on an exhausted HTTP pool in CardGateway.authorize — pool size 50, all busy since 14:01:47.

OpenTelemetry ingest

The server is also an OTLP backend. Collect distributed traces alongside Flopsar's native method-level data — one place to look.

OTLP
traces → Flopsar
Server ← JVM
agents

Your infrastructure. Your data.

Flopsar runs entirely on-premises or in your private cloud. The agent maintains a single encrypted connection to your server; the server stores the data and serves the Workstation web app and REST API. Nothing about the diagnosis requires sending application telemetry to a vendor cloud.

Your perimeter
JVM + Agent Flopsar Server Workstation
encrypted · self-hosted · zero egress
How it works

Two components.
Minutes to first insight.

01

Agent

Native JVMTI library attached to your Java process. Instruments selected methods dynamically, builds per-thread execution stacks, collects parameters, exceptions, CPU time and JVM metrics.

02

Server

Receives and stores execution data, enforces licensing, serves the REST API — and acts as an OpenTelemetry backend over OTLP.

03

Workstation

The bundled web app: live monitoring, dashboards, multidimensional analysis, execution stacks, instrumentation profiles, and administration.

  1. 1

    Attach the agent

    One JVM option. No code changes, no rebuild, no framework coupling.

  2. 2

    Declare a profile

    Name the classes and methods to observe in the Workstation and push it. Running JVMs are instrumented live.

  3. 3

    Watch production

    Every matching invocation is recorded — stacks, arguments, exceptions, resource metrics. 24/7, no gaps.

  4. 4

    Diagnose in seconds

    Find the interesting case with charts and percentiles. Open its stack and read the root cause.

Traditional APM

  • SDKs, annotations, wrapped clients
  • Telemetry model decided up front
  • Sampled spans of selected operations
  • Averages that hide the failing case
  • Your data in a vendor's cloud

Flopsar

  • Native agent — zero application changes
  • Declarative profiles, adjusted live
  • Full execution stacks with arguments
  • The exact invocation that failed, kept
  • Self-hosted — data never leaves you
Contact

Let's talk about
your production.

Questions, pricing, or a live demo on your own stack — get in touch and we'll show you what method-level evidence looks like.

contact@flopsar.com Explore documentation