> 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/setting-up-monitoring.md).

# Setting Up Monitoring

Before you can analyze anything in Flopsar, you decide **what to observe**. This section walks through that setup, from getting an agent connected to shaping exactly which method executions are captured and ensuring sensitive values are protected.

Instrumentation is **declarative** and **non-invasive**. You describe what to observe in a monitoring profile and deploy it to agents; you do not change application source, add an SDK, or rebuild the service. You can widen or narrow the profile at runtime as you learn.

## The setup workflow

A typical path from "nothing configured" to "useful data" looks like this:

```mermaid
flowchart LR
    A["1. Connect an agent"] --> B["2. Create a profile"]
    B --> C["3. Choose instrumentation"]
    C --> D["4. Protect data with masking"]
    D --> E["Analyze in the Workstation"]
```

1. Connect an agent. An agent runs inside your JVM and reports under an application identity. Confirm it is connected and healthy under **Home → Instances** ([Agents](/7/user-guide/setting-up-monitoring/agents.md)). Provisioning the agent's token and attaching the library are administrator tasks; see [Installation](/7/administrator-guide/installation/agent.md) and [Agent Tokens](/7/administrator-guide/agent/agent-tokens.md).
2. Create a profile. A [profile](/7/user-guide/setting-up-monitoring/monitoring-profiles.md) is the named set of monitoring rules for an application — the container for everything you decide to observe.
3. Choose instrumentation. Within the profile, select the classes and methods to watch and whether to capture parameters. See [Instrumentation](/7/user-guide/setting-up-monitoring/instrumentation.md). You can refine this as you narrow down a problem.
4. Protect sensitive data. Configure [Data Masking](/7/user-guide/setting-up-monitoring/data-masking.md) so that values matching your patterns are redacted before they are stored.

Once data is flowing, move on to [Observing & Diagnosing](/7/user-guide/observing-and-diagnosing.md). Group the entry points you care about on [Dashboards](/7/user-guide/observing-and-diagnosing/dashboards.md).

## Choosing what to instrument

Instrumentation is a balance:

* Too little, and the execution stack is shallow and gaps hide the cause (remember that what you see is an [assembled stack](/7/user-guide/key-concepts-and-glossary.md#assembled-stacks-why-what-you-see-can-differ-from-reality)).
* Too much, and you add overhead and capture noise.

A practical approach is to start broad at the entry points you care about, look at the resulting execution stacks, and then drill in — adding instrumentation to the methods that turn out to be interesting. Because changes can be applied dynamically, this iterative loop is fast.

## Roles and permissions

Setting up monitoring requires the appropriate permissions (for example, to view agents, and to view, edit, and deploy profiles). If an action is unavailable to you, your role may not grant it; see [Authentication, Authorization & Identity](/7/security/authentication-authorization-and-identity.md). All profile, instrumentation, masking, and filter changes are recorded in the [audit trail](/7/security/logging-monitoring-and-audit-trail.md).

## A note on overhead and safety

Because the agent runs inside your application, instrumentation has a cost and, in the extreme, can affect application behavior. Prefer to validate significant instrumentation changes in a non-production environment first, scope changes to what you need, and watch application overhead after applying them. See [Known Risks & Limitations](/7/security/known-risks-and-limitations.md).