> For the complete documentation index, see [llms.txt](https://docs.flopsar.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flopsar.com/7/what-is-flopsar.md).

# What is Flopsar?

{% hint style="danger" %}
This version is still under development.
{% endhint %}

Flopsar is a **fault detection and diagnosis** product for JVM applications. It records **how methods actually execute in production** — the tree of calls, their timings, captured arguments, and exceptions — so that when something is slow or fails you can see *why*, not only *that* it happened.

The unit of observation is the **execution stack**: a single recorded invocation and the nested methods it called. That is deeper than a dashboard of averages and deeper than a span-based trace of service hops. You search, aggregate, and walk that stack after the fact, without having guessed in advance which metric or span you would need.

Flopsar runs **on your infrastructure**. The agent attaches to the JVM; the server stores the data and serves the Workstation. Nothing about the diagnosis requires sending application telemetry to a vendor cloud.

## How Flopsar differs

Most APM and observability tools ask you to instrument the application: add an SDK, annotate methods, wrap clients, or ship a framework-specific agent that emits pre-defined spans. The result is usually metrics plus a sampled trace of selected operations. That is invasive (the application is changed or tightly coupled to the vendor) and prescriptive (you decide the telemetry model up front).

Flopsar is the opposite on both counts:

* **Non-invasive.** You do not modify application source code, add a library to the project, or redeploy a special build. The agent is a native JVMTI library loaded with a JVM option. It works at the JVM level, so it is independent of the framework and application server.
* **Declarative.** What to observe is a **profile**: named rules for classes and methods, deployed from the server to the agents. You declare the scope in the Workstation and push it; the running JVM is instrumented dynamically. You can start broad at entry points, then narrow or deepen the profile as you learn — still without touching the application.
* **Diagnostic, not only observational.** Flopsar keeps method-level execution data so you can open one request, read its stack, parameters, and the exception that aborted it. Percentiles and live charts are there to find the interesting cases; the stack is how you explain them.

Plugins extend what the agent records or computes at those same methods — still without changing application code. They are optional enrichments of the declarative profile, not a second instrumentation SDK.

{% hint style="info" %}
Flopsar is not a log platform, RUM, or infrastructure monitor. Native Flopsar data is JVM method execution, not distributed traces. The server can **ingest** OpenTelemetry (OTLP) alongside that data; that does not replace Flopsar's own execution stacks.
{% endhint %}

## How It Works

Flopsar is built from two components:

* **Agent** — a native JVMTI library attached to your Java process. Driven by a profile delivered from the server, it instruments selected methods, builds per-thread execution stacks, and collects parameters, exceptions, CPU time, and JVM metrics. Each agent maintains a single, encrypted connection to the server.
* **Server** — the backend that receives data from agents, stores it, enforces licensing, and serves the REST API. It also acts as an OpenTelemetry backend, accepting trace data over OTLP.

You interact with Flopsar through the **Workstation**, the web application bundled with the server. It is where you explore the collected data: live monitoring, dashboards, multidimensional analysis, execution stacks, instrumentation profiles, and administration. The server serves it from the same HTTPS endpoint as the REST API.

{% hint style="info" %}
For a deeper look at how these components fit together, see Architecture Fundamentals.
{% endhint %}

## What You Can Do with Flopsar

* Identify performance bottlenecks down to a single method invocation.
* Analyze latency distributions, percentiles, and how they change over time.
* Detect, group, and diagnose exceptions, all the way back to their root cause.
* Inspect complete execution stacks, including method parameters and stack traces.
* Ask the AI Assistant to summarize the same data within your permissions.
* Observe resource utilization, garbage collection behavior, and JMX metrics.
* Correlate related invocations across a system using a custom parameter.
* Collect OpenTelemetry traces alongside Flopsar's native JVM data.

In short, Flopsar gives developers and system administrators empirical, method-level evidence from production — declared in a profile, attached as an agent, with no change to application source.