> 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/monitoring-profiles.md). # Monitoring Profiles A monitoring profile is the central object you use to tell Flopsar **what to measure in an application and how**. It bundles instrumentation rules, plugin selections, JMX monitoring, and tuning options into one named configuration that is assigned to an application and then **deployed** to the agents running it. Until a profile is deployed, it changes nothing in your running system; once deployed, agents begin collecting exactly what the profile defines. ## What a Profile Is Each profile is tied to a single target **application** and contains: * **Instrumentation rules** — which classes and methods the agent records, and which it explicitly excludes. * **Plugin rules** — which installed plugins are active for this application (see *Plugins*). * **JMX MBeans** — which JMX object names are collected. * **Options** — JMX sampling period, CPU-time recording, and automatic tuning. A profile moves through a lifecycle and is then pushed to agents on demand. The same application can have more than one profile (for example, a lightweight profile and a deep-diagnostics profile), but only the deployed one is active.
## The Profiles List The Profiles page lists every profile with its current state and lets you create new ones. Use **New Profile** to start a profile, then open any profile to edit, deploy, or manage it. Creating and editing profiles requires the **Edit Profiles** permission.
## Profile Lifecycle and States A profile is always in one of three states, shown next to its name: * **Draft** — the profile is being built and has not been made deployable yet. * **Ready** — the profile is complete and can be deployed, but is not currently collecting data. * **Active** — the profile is deployed and agents are collecting data for its application according to its definition. Editing a deployed (Active) profile and deploying again (**Redeploy**) pushes the updated definition to agents; **Undeploy** returns it to a non-collecting state. ## Defining Instrumentation The **Definition** tab is where you describe what the agent records. It has three parts: the target application, plugin rules, and custom instrumentation rules.
### Target Application Assign the application this profile applies to. A profile must be assigned to an application before it can be deployed. ### Plugin Rules Installed plugins available to this application appear as toggleable tiles; enabling a tile activates that plugin for the application when the profile is deployed. The header shows how many plugins are active out of those available. Plugins are uploaded and managed separately — see *Plugins*. ### Custom Rules Custom rules are the instrumentation rules that decide which methods the agent records. Each rule is one of two kinds: * **ALLOW** (inclusive) — record the matching classes/methods. Allow rules can be assigned to a **group**, which organizes related instrumentation together. * **BLOCK** (exclusive) — explicitly exclude matching classes/methods from instrumentation, even if an allow rule would otherwise include them. Each rule combines a **class pattern** with a **method pattern**; an Allow rule additionally specifies a **match action**. Rules can be enabled/disabled, inspected, cloned, edited, and deleted, and Allow rules can be assigned to a **group** to organize related instrumentation. Block rules always take precedence — a method matched by a Block rule is excluded even if an Allow rule would include it. Changes are staged until you **Save**, and take effect on agents only after you deploy. #### Defining an Allow Rule An Allow rule is created in a three-step wizard.
**Step 1 — Class pattern.** Choose how the pattern matches classes, then enter the pattern value: * **Package** — instrument all classes in the matching package (e.g. `com.example.service.*`). * **Classname** — instrument a specific class by its fully qualified name. * **Superclass** — instrument classes that extend the given class (fully qualified name). * **Interface** — instrument classes that implement the given interface (fully qualified name). If you have saved classes on the clipboard, you can pick the value from there instead of typing it.
**Step 2 — Method pattern.** Choose how the pattern matches methods within those classes: * **Access Modifiers** — match by visibility/modifiers; select any of `public`, `protected`, `default` (package), `private`, `static`, `synchronized`. * **Name** — match methods whose name matches a name pattern. * **Name & Signature** — match one specific method by its full signature, e.g. `java.lang.String foo(int, java.lang.String)` (selectable from the clipboard of saved methods).
**Step 3 — Match action.** Choose what the agent does when the rule matches: * **Basic** — report the invocation only (timing). * **Standard** — report the invocation together with its arguments. * **Extended** — report the invocation with its arguments at the finest level of detail. * **Custom** — run a user-defined extension method on the invocation and report its result; select the extension as `class/method` (this links the rule to an installed plugin — see [*Plugins*](/7/user-guide/plugins.md)). Two options refine the action: * **Always report** — ignore automatic tuning and always report this data. * **Instrument on exit** — execute the custom code at method exit; this is required if you want to report methods' return values. {% hint style="info" %} Argument capture and custom code (Standard, Extended, Custom) require the **Name & Signature** method pattern. With the Access Modifiers or Name pattern, only the **Basic** action is available. {% endhint %} ## JMX Monitoring The **JMX** tab configures which JMX MBeans the agent samples for the application. Add the object names you want to monitor, search the configured set, and save your changes. How often these are sampled is controlled by the **JMX Period** option (see below).
## Profile Options The **Overview** tab holds the profile's metadata and tuning options. Details include the editable **Name**, the assigned **Application**, free-form **Notes**, and an audit trail of who **created**, **edited**, and **deployed** the profile and when. Preferences control runtime behavior: * **JMX Period** — how often JMX MBeans are sampled (minimum 5 seconds). * **CPU Time** — whether per-invocation CPU time is recorded in addition to wall-clock duration. * **Auto Tuning** — an automatic tuning mode that adjusts instrumentation to balance diagnostic detail against overhead. ## Deploying a Profile Deployment is what makes a profile take effect. Use **Deploy** to push a Ready profile to the agents running its application; for an already-active profile the action becomes **Redeploy**, which rolls out the latest definition. Deployment shows progress per agent so you can confirm each one received the profile.
**Undeploy** stops the profile: agents stop collecting data for that application. Deploying and undeploying require the **Deploy Profiles** permission. ## Maintaining Profiles Beyond editing, profiles support several housekeeping actions: * **Clone** — duplicate a profile as a starting point for a new one. * **Export / Import** — save a profile (or selected rules) to a file and load it on another server, which is useful for moving configuration between environments. * **Delete** — remove a profile you no longer need. ## Permissions * **Edit Profiles** — create, edit, clone, and delete profiles and their rules. * **Deploy Profiles** — deploy, redeploy, and undeploy profiles. Profile changes and deployments are recorded in the security audit trail.