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

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.

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.

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.