Managed Services

Monitoring vs Observability: A Practical Guide for Enterprises in Thailand

TMES Managed Services Practice10 Nov 20265 min read

Operations team monitoring systems in a network operations centre

The short answer

Monitoring tells you whether something is wrong: a server is down, a disk is full, response time has crossed a threshold. Observability tells you why: it lets your team follow a slow or failed customer transaction from the screen, through every service and database it touched, to the exact cause, including problems nobody wrote an alert for.

Monitoring is still necessary. Observability builds on it by collecting richer data from your systems and connecting it, so investigations take minutes instead of a war room. For most enterprises in Thailand the question is not whether to replace monitoring, but how to grow from separate monitoring tools into one connected view without a big-bang project.

Why monitoring alone stops being enough

Classic monitoring works well when systems are few and predictable: you know in advance what can fail, so you write a check for it. Modern estates do not behave that way. A single customer action in a mobile app may cross an API gateway, several microservices, a cloud database, a payment provider and an on-premise ERP. When it slows down, every team's dashboard can be green while the customer waits.

The symptoms are familiar:

Customers report problems before IT notices them.
Infrastructure alarms, application logs and business numbers live in different tools owned by different teams.
Incidents turn into meetings where each team proves its part is fine.
Alerts are so noisy that people mute them, or so sparse that real problems pass unnoticed.
Monitoring licences priced per host or per agent grow faster than the business.

The four signals of observability

Observability comes from four kinds of telemetry, collected consistently and linked together:

Metrics. Numbers over time: requests per second, error rates, latency, CPU, queue depth, orders per minute. Cheap to store and ideal for dashboards and alerts.
Logs. Time-stamped records of events. They carry the detail of what happened, but they are the most expensive signal to keep if every word is indexed.
Traces. The path of one request across services, with the time spent in each step. Traces are what turn "the app is slow" into "the inventory database call takes 1.9 seconds".
Profiles. Continuous measurements of which functions use CPU and memory in production, linking an incident to the code behind it.

The value is in the connections. From a spike on a dashboard you should be able to open the traces from that minute, and from a slow trace jump to the logs of the service that caused it, without copying IDs between tools.

Open standards keep your options open

Two open-source projects of the Cloud Native Computing Foundation have become the common language of telemetry:

OpenTelemetry is a vendor-neutral way to instrument applications and collect metrics, logs and traces. Instrument once, then send the data wherever you choose.
Prometheus is the open format and query language for metrics that most modern tools can read and write.

Building on these standards means your telemetry is not locked into one vendor's agent. If you change platforms later, the instrumentation in your applications stays.

Cost and data residency: the two questions to settle early

Cost. Observability bills tend to grow with three things: the number of hosts or containers, the number of distinct metric series, and the volume of logs kept. Three habits keep them in check: drop telemetry nobody uses, index logs by labels rather than by full text, and set retention by value (for example, detailed data for weeks, summaries for a year). Open-source foundations also avoid per-host and per-agent licence models.

Data residency. Logs and traces often contain personal data such as names, phone numbers, account IDs and IP addresses, so the PDPA applies to them as much as to your customer database. Decide early which telemetry may leave Thailand, mask personal data at collection, and choose a deployment model to match: a managed cloud service for speed, a self-managed platform where telemetry must stay in your own environment, or a hybrid where sensitive logs stay local and metrics go to the cloud.

A 90-day plan to get started

Weeks 1–2: inventory. List what you monitor today, which alerts people actually act on, and which customer journeys matter most to the business. Retire checks nobody has looked at in a year.
Weeks 3–4: pick two critical journeys. For example online checkout and store POS sync, or account opening and fund transfer. Define what "good" means for each in numbers: availability and response time.
Weeks 5–8: instrument and connect. Add OpenTelemetry to the services behind those journeys, bring metrics, logs and traces into one platform, and build one dashboard per journey that business and IT can both read.
Weeks 9–10: fix alerting. Alert on customer impact (error rate and latency of the journey), not on every server metric. Route alerts to an on-call rota with a clear escalation path.
Weeks 11–12: run old and new in parallel. Keep the existing tool until the operations team signs off, then move the next set of journeys.

How to measure success

Mean time to detect: how quickly you know about a problem, ideally before a customer tells you.
Mean time to resolve: from alert to service restored.
Alert quality: the share of alerts that led to action. Fewer, better alerts beat more alerts.
Customer-found incidents: how many problems customers reported before IT saw them. This number should fall.
Tooling cost per service monitored, tracked as coverage grows.

How TMES helps

TMES is a Grafana technology partner. Grafana brings metrics, logs, traces and profiles into one workspace on open standards, and Grafana Labs was named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. TMES supplies the Grafana Cloud or Grafana Enterprise subscription, designs and implements the platform, migrates you off legacy monitoring tools in phases, and can run it 24/7 under an agreed service level, all on one local contract under ISO/IEC 27001, 27701 and 20000-1 certified governance. See how the platform is built and deployed, or talk to our observability team about your first two journeys.