Application Monitoring and Observability: Logs, Metrics, Traces and Useful Alerts
Application monitoring and observability: logs, metrics, traces, error tracking, SLIs and SLOs, alerting, incident workflows and privacy-conscious telemetry.
What does good application monitoring look like?
Good application monitoring tells you quickly when users are affected and gives you enough information to find out why. That means structured logs, metrics and traces, error tracking, a few service level indicators for the journeys that matter, alerts tied to those indicators, and an incident workflow, all designed so telemetry does not leak personal information. Uptime checks alone are not enough, and no tool guarantees uptime.
This guide is for engineering leads, product owners and founders running web applications, SaaS products and APIs. It covers logs, metrics, traces, alerts, error monitoring, SLIs and SLOs, incident workflows and privacy-conscious telemetry. For online stores, see ecommerce observability; for apps, mobile crash reporting; for AI features, LLM observability.
Key takeaways
- Monitoring detects known problems; observability helps explain unknown ones. You need both.
- Instrument once with open standards such as OpenTelemetry.
- Use request and tenant IDs to connect logs, metrics and traces.
- Define a few SLIs and SLOs for key journeys; alert on them.
- Every alert must be actionable and owned.
- Keep personal information out of telemetry; mask, restrict and set retention.
- Review incidents and improve instrumentation afterwards.
Monitoring vs observability
| Uptime monitoring | Application monitoring | Observability | |
|---|---|---|---|
| Answers | Is it reachable? | Is it healthy against known measures? | Why is it behaving this way? |
| Data | External checks | Metrics, error rates, thresholds | Logs, metrics and traces with context |
| Catches | Full outages | Known failure modes | Unexpected and partial failures |
| Misses | Slow or broken journeys | Problems nobody anticipated | Little, if instrumented well |
The three signals
Logs record events. Use structured logs (key-value or JSON) with timestamps, severity, request ID, tenant ID where relevant, and a clear message; avoid logging secrets and personal data. Metrics are numbers over time: request rates, error rates, latency percentiles, queue depth, resource use. Traces follow a request across services, showing where time is spent and where it failed. OpenTelemetry provides a vendor-neutral way to produce all three (OpenTelemetry).
Add error tracking to capture exceptions with stack traces and context, grouped and assigned to owners, for both server and browser code.
SLIs, SLOs and alerting
Pick a few journeys that matter, such as sign-in, checkout, booking or report generation, and define indicators like 'share of checkout requests completing successfully within two seconds'. Set objectives for them over a period, as described in Google's SRE guidance (Google SRE book). Alert when you are at risk of missing an objective, not on every internal blip.
- Every alert has an owner and a runbook link.
- Pages (urgent alerts) only for user-affecting problems that need action now.
- Lower-priority issues go to tickets, not phones.
- Review alert noise monthly and delete alerts nobody acts on.
- Monitor background jobs, queues and scheduled tasks, which often fail silently.
Incident workflows
When an alert fires: acknowledge, assess user impact, communicate status, mitigate (roll back, switch off a feature flag, scale), investigate with traces and logs, resolve, then review. Keep an incident log and a status page or customer communication process. If an incident may involve personal information or a security compromise, follow your security incident plan; see cyber incident response planning.
Privacy-conscious telemetry
Telemetry is data, and it often contains personal information by accident.
- Do not log request bodies, form fields, tokens or passwords.
- Strip or hash identifiers in URLs and query strings.
- Use internal IDs rather than emails or names in logs and traces.
- Configure session replay and front-end monitoring to mask inputs and text.
- Restrict access to logs and set retention to what operations and investigations need.
- Know where your observability vendor stores data; if you are covered by the Privacy Act and telemetry includes personal information, APP 8 and APP 11 apply (OAIC).
Choosing tools
Hosted observability platforms, open-source stacks and cloud-native tools all work. Consider instrumentation standards (prefer OpenTelemetry), cost at your data volume (ingestion and retention drive most cost), data location, access controls, and how well the tool links logs, metrics, traces and errors. Start small: error tracking, key metrics and tracing on your most important service usually deliver the most value first.
Hypothetical example: a booking platform
This example is hypothetical. A booking platform's uptime checks were green while some customers could not complete bookings. The team adds error tracking to the front end and API, OpenTelemetry traces across the booking service and payment integration, and an SLO for successful bookings. Traces show a payment provider timeout on one card type; a retry and timeout fix resolves it. Logs are changed to remove customer emails from URLs, and front-end session replay is configured to mask all inputs.
Common mistakes
- Relying on uptime checks alone.
- Logging everything, including personal data, then paying to store it.
- Alerts on every metric, so none are trusted.
- No request IDs, so logs from different services cannot be connected.
- Ignoring background jobs and scheduled tasks.
- Promising customers uptime the system cannot measure.
Related guides
For delivery practices, see DevOps for growing businesses. For growth, see scaling SaaS applications. For cost control of telemetry, see cloud cost optimisation.
Sources
OpenTelemetry documentation; Google SRE book, service level objectives; OAIC, APP 11.
Tables, checklists and example are ours. No uptime or performance outcome is promised. Nothing here is ZSpace client data.
Conclusion
Monitoring tells you something is wrong; observability helps you understand why. Instrument with open standards, connect logs, metrics and traces, define SLOs for the journeys users care about, alert only on what needs action, and keep personal information out of telemetry. Then learn from every incident. To turn monitoring into reliability targets, see SLOs and error budgets.
Can you see what your users experience?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on well-instrumented web applications and mobile apps. If it would help to review what your application should measure, we are happy to talk it through.
Common questions.
Monitoring checks known conditions, such as whether a site is up or CPU is high, and alerts when they cross thresholds. Observability is the ability to understand why something is happening from the data the system emits, usually logs, metrics and traces, including problems you did not anticipate. You need both: monitoring tells you something is wrong; observability helps you find out why.