E2. Core Concepts and the Data Flow
Diátaxis: Explanation · Audience: operators / administrators ← Back to contents · ← E1 Overview
This document explains the three skeleton concepts met throughout using OPENMARU APM -- what you are looking at (groups, instances, agents), what is being traced (transactions), and how that data reaches the screen. These are concepts rather than operations, so reading them once before opening a screen makes every menu afterwards easy to follow.
If you only need short definitions of the terms, see R8. Glossary; for what the metrics (TPS, APDEX, and so on) mean, see E3. What the Metrics Mean.
E2.1 Application Groups, Instances, and Agents
Every screen in OPENMARU APM comes down to "whose data are we going to show". That target has three layers.
| Concept | What it is | Analogy |
|---|---|---|
| Agent | The collector attached to an instance that gathers performance data and sends it to the APM server | The tachograph (sensor) fitted to a bus -- it sends speed and position to the control centre |
| Instance | One process actually running (one WAS, one database broker, and so on) | One bus |
| Application group | The unit bundling the instances that are meaningful to look at together (usually one service) | The buses running the same route |
In that analogy the APM server is the control centre -- it gathers the data every bus's (instance's) tachograph (agent) sends and shows the state of the whole route (the application group) on one screen.
Why They Are Bundled into "Groups"
One service usually runs on several instances (several WAS instances for load balancing -- like putting several buses on a busy route). Looking at instances one at a time makes it hard to judge "is this service all right as a whole". So the related instances are bundled into an application group, the totals and averages are seen at a glance, and you narrow down to one instance when you need to.
This "whole → narrow to one" is how the context selector at the top of the screen (group → host → instance) works. How to narrow the target is covered in H1. Narrowing the Monitored Target, and how to create a group yourself in H19. Application Groups.
Note Custom groups: there are also separate groups that bundle instances by any criteria you like, such as department or inspection purpose. Where an application group is "a service unit", a custom group is "a unit bundled however you want to see it".
Caution When a screen is empty, it is usually because no target is selected or because no agent is connected on that target. Check the agent connection state in H20. Checking Agent Status.
E2.2 What a Transaction Is — How One Request Is Handled
A transaction is the whole flow of one user request being handled. Think of it as the unit that bundles what happens inside the server for one click of a button.
One transaction consists of several spans -- one SQL statement, one external call, one method. OPENMARU APM draws these spans in time order and by length, showing at a glance where one request spent its time. That picture is the waterfall.
Why Transactions Matter
"The average response time is slow" alone does not reveal the cause. Opening one slow transaction and looking at the longest span in the waterfall immediately shows whether it is a database query, an external call, or internal processing. Transaction tracing is therefore the key to moving from "it is slow" to "it is slow because of this".
- To follow it through in practice → T2. Tracing One Slow Request All the Way
- The 19 common problem patterns → H6. Finding the Cause of a Slow Transaction
- The T-Map, for seeing the response distribution of the whole service as a pattern → H5. Diagnosing with T-Map Patterns
E2.3 How the Data Reaches the Screen
Every number and graph on the screen goes through the path below. Knowing this flow makes it natural to understand "why a value appears slightly late" and "why past data can be queried".
The Difference between Real Time and Querying the Past
- The real-time (current) screen receives and refreshes the latest data about every 5 seconds. That is why something that has just happened appears on the screen within seconds.
- Querying a past interval loads the stored data. That is why the period picker can show yesterday, last week, and other past points → H2. Changing the Period.
Note The dates and times on the screen are shown against the user profile's time zone and the server time. That is why the date does not go out even when the PC clock differs from the server.
When a Threshold Is Passed -- Events
At the storage step, when a value passes a configured threshold or a state changes, the APM server records that occurrence as an event. Events accumulate in the event list on the screen and, according to the policy, are also delivered by email or messenger. The kinds of event and their meaning are covered in R3. Event Reference, and how to fit alerts to your operation in H15. Alert Policies.
Summary
| Question | Concept |
|---|---|
| What are we looking at? | Application group → instance (the data is collected by the agent) |
| What is being traced? | A transaction = the flow of one request, a waterfall of spans |
| How does it reach the screen? | Collect → send → store → display (real time about 5s / querying the past) |
What to Read Next
- E3. What the Metrics Mean -- what TPS, response time, APDEX, heap, and GC mean
- R2. Chart Metric Reference -- the meaning and problem signals per chart
- Trying it straight away -- T1. Quick Start in 5 Minutes