# Key Concepts & Glossary This page explains the ideas you need before using Flopsar and defines the vocabulary used throughout the User Guide. If a term elsewhere in the documentation is unfamiliar, look it up in the Glossary at the bottom of this page. ## The big picture Flopsar observes your Java applications from the inside and records **how their methods actually execute**, so that when something is slow or fails you can see exactly what happened and why — without guessing in advance which averages or metrics to collect.\ Three components work together: ```mermaid flowchart LR subgraph App["Monitored host"] JVM["Your Java application (JVM)"] --- Agent["Flopsar Agent\n(in-process)"] end Agent -- "encrypted session" --> Server["Flopsar Server\n(processes & stores data)"] Server --> WS["Flopsar Workstation\n(analyze & diagnose)"] User(("Analyst")) --- WS ``` * The Agent runs inside each monitored JVM, instruments selected methods, and streams what it observes to the server. * The Server receives, processes, and stores that data. * The Workstation is the web interface where you watch live activity and analyze recorded data. What you choose to observe is controlled by a profile, which defines the instrumentation (which classes and methods to watch). As instrumented methods run, the agent captures execution stacks — the tree of method calls, their timing, their parameters, and any exceptions — which you then explore in the Workstation. ## The execution model This is the heart of Flopsar, and the terms here are used everywhere. ### Execution stack When an instrumented method runs, Flopsar records the whole tree of calls it makes. That tree is the execution stack. * The first method in the tree is the root call. * Every method invocation below it is a call (also referred to as an invocation — the two are interchangeable). * If an exception is thrown and propagates up the tree, the originating exception is the root exception ### Assembled stacks (why what you see can differ from reality) The execution stack you view is an assembled view, not necessarily the complete real call tree: * Only instrumented methods are recorded; methods you did not select are not in the stack. * Occasionally an instrumented call may not be reported. The Workstation assembles the stack from what was reported and omits the gaps, so the displayed tree can be shallower than the application's true call flow. Understanding this is key to reading execution stacks correctly. See [Method Execution Tree](vscode-file://vscode-app/user-guide/method-execution-tree). ### Self-time Self-time is the part of a method's duration spent running its own code, excluding the time spent waiting for the methods it calls. If method `A` calls method `B`, then `A`'s self-time is `A`'s total duration minus the time spent in `B`. Self-time is what tells you which method is actually responsible for time spent, as opposed to merely passing it down to a callee. ### Parameters and exceptions For instrumented calls, the agent can capture method parameters (argument values) and exception details. These are powerful for diagnosis but may contain sensitive data, which is why Flopsar provides [data masking](vscode-file://vscode-app/user-guide/data-masking) and filtering. ## Configuring what to monitor * A profile is a named set of monitoring rules for an application: what to instrument and how. You create, activate, and deploy profiles to agents. * Instrumentation is the selection of classes and methods to observe, plus options such as parameter capture. It can be applied dynamically at runtime. * Filters & services let you group and classify executions — for example, defining a service as a meaningful entry point and filtering the executions you care about. * Data masks redact values matching configured patterns before they are stored. ## Observing and diagnosing * Live view shows real-time activity as it happens. * The data browser lets you search and open recorded execution stacks. * The method execution tree is the detailed, drill-down view of a single execution stack. * Data correlation links related executions across components or transactions. * Data analysis provides tools to compare, aggregate, and find the root cause of a problem. * Metrics are numeric measurements over time, including custom key-value metrics your application or extensions can publish. ## Extending and ingesting * Plugins / extensions run custom logic inside monitored JVMs to perform additional processing at runtime without changing your application's source code. See [Using Plugins & Extensions](vscode-file://vscode-app/user-guide/extensions) and, for authoring them, [Agent Extensions](vscode-file://vscode-app/developer-guide/agent-extensions). * OpenTelemetry (OTLP) data can be ingested by the server, letting you work with telemetry from instrumented applications alongside Flopsar's own data. ## Glossary * Agent — the Flopsar component that runs inside a monitored JVM, performs instrumentation, and sends observations to the server. * Application — a monitored system as Flopsar identifies it; an agent reports under an application identity. * Call (Invocation) — a single method invocation within an execution stack. The two terms are used interchangeably. * Data analysis — the Workstation tools for comparing and aggregating recorded data to find root causes. * Data browser — the Workstation view for searching and opening recorded execution stacks. * Data correlation — linking related executions across components or transactions. * Data mask — a pattern-based rule that redacts matching values before storage. * Execution stack — the recorded tree of method calls produced when an instrumented method runs. * Filter — a rule that selects or classifies executions. * Instrumentation — the selection of classes and methods to observe, and how (for example, with parameter capture). * Live view — real-time display of activity as it happens. * Metric — a numeric measurement over time; custom key-value metrics are application- or extension-defined. * Method execution tree — the detailed drill-down view of a single execution stack. * OpenTelemetry / OTLP — an open telemetry standard whose data Flopsar can ingest. * Parameter (Argument) — a captured method argument value. * Plugin / Extension — custom logic loaded into monitored JVMs to perform additional runtime processing. * Profile — a named set of monitoring rules (instrumentation and options) for an application. * Root call — the first (top) method in an execution stack. * Root exception — the originating exception that propagates up an execution stack. * Self-time — the part of a method's duration spent in its own code, excluding time spent in methods it calls. * Server — the Flopsar component that receives, processes, and stores agent data and serves the Workstation. * Service — a meaningful, named entry point used to group and classify executions. * Workstation — the Flopsar web interface for live monitoring and analysis. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.flopsar.com/7/user-guide/key-concepts-and-glossary.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.