> 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/user-guide/observing-and-diagnosing.md).

# Observing & Diagnosing

Once agents are attached and a monitoring profile is active, Flopsar begins recording how your application actually behaves in production — every instrumented method invocation, its timing, its parameters, and any exception it raised. This chapter covers the tools you use to turn that stream of recorded data into answers: *Is the system healthy right now? Which operation is slow? Why did this specific request fail, and where exactly did it break?*

The tools are designed to be used together, following the natural arc of an investigation — from a broad, real-time sense of system health, down to a single method call on a single request.

## The diagnostic workflow

A typical investigation moves through three stages:

1. **Notice** — you become aware that something is off, either from the live view, from your own alerting, or from a user report.
2. **Narrow** — you search the recorded data, slice it by application, time range, operation name, or parameter, and use distribution analysis to separate the normal cases from the outliers.
3. **Pinpoint** — you open an individual invocation and walk its execution tree to find the exact method, downstream call, or exception responsible.

{% code expandable="true" %}

```mermaid
flowchart TD
    subgraph notice [Notice]
        direction LR
        L[Live View] --> H[Health signals]
    end
    subgraph narrow [Narrow]
        direction LR
        B[Data Browser] --> A[Data Analysis]
        A --> CO[Data Correlation]
    end
    subgraph pinpoint [Pinpoint]
        direction LR
        T[Method Execution Tree] --> R[Root cause]
    end
    notice --> narrow --> pinpoint
```

{% endcode %}

You will not always start at the top. When you already have a request ID or a timestamp, you can jump straight into the Data Browser or Correlation view; when you are doing capacity work, you may live in Data Analysis. The stages are a guide, not a fixed path.

## What Each Tool is for

Live View gives you a real-time picture of one or more applications: throughput and latency distribution as it happens. Use it for at-a-glance health checks and to confirm whether a problem is occurring right now.

Data Browser is where you query the recorded invocations. You search by application, time range, method name, and parameters, then scan the resulting calls with their timing, status, and selected parameter values. It is the starting point whenever you need to find specific calls after the fact.

Method Execution Tree opens a single invocation and shows the full nested call hierarchy that produced it, with the time spent in each method. Three complementary views help you read it: a Flame Chart for the shape of the call stack over time, Self-Time to rank methods by the time spent in their own body (excluding children), and Hot Path to follow the single most expensive branch down to its leaf. This is where you pinpoint the exact cause of a slow or failing call.

Data Correlation stitches related invocations together across threads, components, and separate services, so you can follow one logical operation as it travels through a distributed system rather than viewing each hop in isolation.

Data Analysis (Multidimensional Analysis) aggregates many invocations into performance distributions and exception breakdowns — total call counts, percentiles, and where errors concentrate. Use it to tell the difference between a one-off spike and a systemic regression, and to decide which operations are worth a deeper look.

Metrics lets you work with OpenTelemetry metric streams ingested by the server, so numeric time-series signals from your application sit alongside the invocation-level data Flopsar records.

OpenTelemetry provides a dedicated browser and analysis surface for OTLP trace data sent to the server. Spans are presented with the same drill-down experience as Flopsar's native invocations, so distributed traces and agent- recorded calls can be investigated side by side.

## Before you Start

Everything in this chapter reads from data the agent has already recorded, so the depth and usefulness of what you see depends directly on your monitoring profile, instrumentation, and filters (see *Setting Up Monitoring*). If an operation you expect is missing, it is usually because it is not yet instrumented or is excluded by a filter, rather than because nothing happened.