ERP Application Monitoring and Observability: Reading Performance Metrics Correctly
Seeing a metric is not the same as knowing why there is a problem. Reading ERP performance well means relating user experience, application, database, and infrastructure signals as different faces of the same event.
'Login duration increased' is a finding. It is not a root cause. Good observability shows the metric and opens a path for investigating the cause.
Table of contents
The Topic in Five Minutes
Monitoring collects metrics, logs, alerts, and health signals. Observability is the capacity to investigate an unexpected behaviour with enough context, without first writing new code. Both matter: an invisible system cannot be managed, but a dashboard alone does not provide a root cause.
The central thesis
Start with user impact, then relate signals across layers. Saying that CPU is high does not prove a CPU problem any more than slow login proves an authentication problem.
Mental Model: From User to Infrastructure
Layers for investigating ERP performance
- 1
User Experience
The duration and failure a user experiences.
- 2
Application
Requests, sessions, memory, queues, and connection pools.
- 3
Database
Queries, locks, waits, and connection pressure.
- 4
Infrastructure
CPU, memory, disk, network, and runtime health.
Branches to investigate when login duration increases
- 1
Login Duration ↑
The user-visible finding.
- 2
Authentication
Identity provider or authorization call.
- 3
Network / Application
Latency, capacity, cache, or concurrent load.
- 4
Database
Query, lock, wait, or connection pressure.
Which Metric Speaks for Which Layer?
| Layer | Example signals | First interpretation |
|---|---|---|
| User Experience | Login duration, page/transaction opening duration, response time, perceived latency | Makes business impact visible. |
| Application | Concurrent sessions, request volume, memory, cache, threads/workers, queues, connection pools | Shows how the application carries demand. |
| Database | Query duration, locks, waits, connection pressure, expensive operations | Signals waiting or resource contention in the data layer. |
| Infrastructure | CPU, memory, disk, network, container/VM health | Shows capacity and failure boundaries of the runtime environment. |
Layer
User Experience
Example signals
Login duration, page/transaction opening duration, response time, perceived latency
First interpretation
Makes business impact visible.
Layer
Application
Example signals
Concurrent sessions, request volume, memory, cache, threads/workers, queues, connection pools
First interpretation
Shows how the application carries demand.
Layer
Database
Example signals
Query duration, locks, waits, connection pressure, expensive operations
First interpretation
Signals waiting or resource contention in the data layer.
Layer
Infrastructure
Example signals
CPU, memory, disk, network, container/VM health
First interpretation
Shows capacity and failure boundaries of the runtime environment.
Movement in three layers at once does not automatically establish cause and effect. Time alignment, affected user group, release/change information, and the business context of the request still need examination.
Metric, Symptom, Signal, and Root Cause
| Concept | Short meaning |
|---|---|
| Metric | A measured value, such as p95 response time. |
| Symptom | An effect observed by a user or system, such as slow login. |
| Signal | A change or pattern worth investigating. |
| Correlation | An observation that two events move together; not causality by itself. |
| Root cause | The underlying reason that starts or sustains the problem. |
| Baseline | The reference line for normal behaviour. |
| Threshold | A boundary requiring attention or action. |
| Trend / saturation / anomaly | Direction over time, approach to capacity limit, or unexpected deviation. |
Concept
Metric
Short meaning
A measured value, such as p95 response time.
Concept
Symptom
Short meaning
An effect observed by a user or system, such as slow login.
Concept
Signal
Short meaning
A change or pattern worth investigating.
Concept
Correlation
Short meaning
An observation that two events move together; not causality by itself.
Concept
Root cause
Short meaning
The underlying reason that starts or sustains the problem.
Concept
Baseline
Short meaning
The reference line for normal behaviour.
Concept
Threshold
Short meaning
A boundary requiring attention or action.
Concept
Trend / saturation / anomaly
Short meaning
Direction over time, approach to capacity limit, or unexpected deviation.
A good alert does not fire only because a number crosses a line. It also considers business impact, persistence, and meaningful departure from normal behaviour.
Why an Average Can Mislead on Its Own
An average can hide the delay experienced by a meaningful group of users. p50 describes the median, or typical middle experience; p95 marks the boundary for the slowest five percent; p99 describes the far end of the tail. A stable average with a deteriorating p95 can point to severe user impact under a particular load or data condition.
| View | Question it asks |
|---|---|
| p50 | What is the typical user experience? |
| p95 | What does a meaningful group with poor experience see? |
| p99 | Do edge cases point to a capacity or failure boundary? |
| Trend | Is the issue isolated, recurring, or growing? |
View
p50
Question it asks
What is the typical user experience?
View
p95
Question it asks
What does a meaningful group with poor experience see?
View
p99
Question it asks
Do edge cases point to a capacity or failure boundary?
View
Trend
Question it asks
Is the issue isolated, recurring, or growing?
Percentiles do not replace a performance objective. Interpret them with the critical user journey, business hour, and load condition in mind.
What Should I Examine?
- Are critical user journeys and their normal durations defined?
- Can metrics be related across user, application, database, and infrastructure layers?
- Can logs, metrics, and traces be tied to the same business request?
- Do baselines and thresholds account for business hours, period-end, or planned batch load?
- Are alert ownership, first investigation, and escalation boundary clear?
- Where does capacity saturation appear: queues, pools, workers, disk, or another bottleneck?
- Are sensitive values masked while enough diagnostic context is retained?
Where Is It Commonly Misunderstood?
| Anti-pattern | Why it is risky |
|---|---|
| Watching infrastructure metrics only | User impact and application behaviour remain invisible. |
| Making every threshold a critical alert | Alert fatigue hides the meaningful signal. |
| Looking at average duration | The poor experience in the tail can disappear. |
| Treating correlation as root cause | Events moving together may have another common cause. |
| No owner for observability data | Dashboards exist, but learning and improvement do not. |
Anti-pattern
Watching infrastructure metrics only
Why it is risky
User impact and application behaviour remain invisible.
Anti-pattern
Making every threshold a critical alert
Why it is risky
Alert fatigue hides the meaningful signal.
Anti-pattern
Looking at average duration
Why it is risky
The poor experience in the tail can disappear.
Anti-pattern
Treating correlation as root cause
Why it is risky
Events moving together may have another common cause.
Anti-pattern
No owner for observability data
Why it is risky
Dashboards exist, but learning and improvement do not.
Choosing a monitoring solution is broader than choosing a dashboard. The metric vocabulary, user journeys, retention, access, cost, and incident-response practice need to be considered together.
One Page Cheat Sheet
| Remember | Short version |
|---|---|
| Metric | A starting point for investigation, not a decision on its own. |
| Symptom | Describes user impact; it does not name the cause. |
| Baseline | You cannot interpret an anomaly without knowing normal. |
| p95/p99 | Makes the poor experience hidden by an average visible. |
| Correlation | Gives an investigation direction; it does not prove causality. |
| Observability | The ability to explain unexpected behaviour with context. |
Remember
Metric
Short version
A starting point for investigation, not a decision on its own.
Remember
Symptom
Short version
Describes user impact; it does not name the cause.
Remember
Baseline
Short version
You cannot interpret an anomaly without knowing normal.
Remember
p95/p99
Short version
Makes the poor experience hidden by an average visible.
Remember
Correlation
Short version
Gives an investigation direction; it does not prove causality.
Remember
Observability
Short version
The ability to explain unexpected behaviour with context.
Mini glossary: latency = time for a request to complete; saturation = a resource nearing capacity; trace = a request's path across layers; anomaly = meaningful deviation from the expected pattern.
A Note for Those Researching TROIA
TROIA's public developer documentation includes a JMX monitoring topic, showing that monitoring concepts have a current counterpart in that ecosystem. This guide does not teach product metrics, management screens, or implementation steps; it explains how to read performance signals architecturally. Refer to the original documentation for current TROIA-specific detail.
Frequently asked questions
- What is the difference between monitoring and observability?
- Monitoring tracks known metrics and thresholds. Observability is the ability to investigate an unexpected behaviour using sufficient context.
- If CPU rises, does that mean CPU is the problem?
- No. Increased CPU may be an outcome of demand or waiting in another layer. Investigate it with user impact and time alignment.
- Should every transaction have the same p95 target?
- No. Login, reporting, batch work, and critical decision screens have different user expectations and business impact.
Related pages:
Related content
Relevant resource
Resources and checklists
Use the resources surface when you want a checklist, decision note, or downloadable asset to make this topic more concrete.
Continue →Conversation
If this is active, let us talk
If this topic matches a live project, sponsor decision, or delivery pressure, you can get in touch directly.
Continue →Framework
Return to the ERP framework
Use the ERP framework when you need the wider sponsor, delivery, and transformation picture beyond a single topic.
Continue →