> 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 records 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 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.

## Workstation navigation

The sidebar is grouped the way you work:

* **Home** — [Workspace](/7/user-guide/observing-and-diagnosing/workspace.md), [Instances](/7/user-guide/setting-up-monitoring/agents.md), [Live](/7/user-guide/observing-and-diagnosing/live-view.md), [Dashboards](/7/user-guide/observing-and-diagnosing/dashboards.md)
* **Analytics** — [AI Assistant](/7/user-guide/observing-and-diagnosing/ai-assistant.md), [Data Analysis](/7/user-guide/observing-and-diagnosing/data-analysis.md), [Data Browser](/7/user-guide/observing-and-diagnosing/data-browser.md), [Data Correlation](/7/user-guide/observing-and-diagnosing/data-correlation.md), [Key-Value](/7/user-guide/observing-and-diagnosing/metrics.md)
* **Configuration** — profiles, plugins, data masking, license
* **Administration** and **Access Management** — server, tokens, users, roles, LDAP (see the Administrator Guide)

Items appear only when your role grants the matching permission.

## 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]
        DASH[Dashboards] --> H
    end
    subgraph narrow [Narrow]
        direction LR
        B[Data Browser] --> A[Data Analysis]
        A --> CO[Data Correlation]
        A --> AI[AI Assistant]
    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

[Workspace](/7/user-guide/observing-and-diagnosing/workspace.md) is the landing page: connected agents, applications, and whether anything needs attention.

[Live View](/7/user-guide/observing-and-diagnosing/live-view.md) 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.

[Dashboards](/7/user-guide/observing-and-diagnosing/dashboards.md) are named collections of live charts, each chart defined by matching rules. Use them for a rolling view of specific services or entry points, then jump into Data Analysis for the same slice.

[Data Browser](/7/user-guide/observing-and-diagnosing/data-browser.md) 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](/7/user-guide/observing-and-diagnosing/method-execution-tree.md) opens a single invocation and shows the nested call hierarchy that produced it. Complementary tabs cover the flame chart, method spectrum, top duration and self-time, critical path, CPU efficiency, fan-in/out, and exceptions.

[Data Correlation](/7/user-guide/observing-and-diagnosing/data-correlation.md) stitches related invocations together across threads and applications when they share a parameter value, so you can follow one logical operation rather than viewing each hop in isolation.

[Data Analysis](/7/user-guide/observing-and-diagnosing/data-analysis.md) (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.

[Key-Value](/7/user-guide/observing-and-diagnosing/metrics.md) plots time series of key-value metrics the agent recorded.

[AI Assistant](/7/user-guide/observing-and-diagnosing/ai-assistant.md) asks an LLM to read the same data through tools, either from a free-form workspace or from the current analysis or call stack.

OpenTelemetry traces can be ingested by the server when the license includes that capability. See [OpenTelemetry](/7/user-guide/opentelemetry.md).

## 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 and instrumentation (see [Setting Up Monitoring](/7/user-guide/setting-up-monitoring.md)). If an operation you expect is missing, it is usually because it is not yet instrumented, rather than because nothing happened. Dashboards only select and display already recorded invocations.