India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Observability Modernization with OpenTelemetry, Tracing and SLOs
Observability modernization replaces siloed monitoring, meaning server checks, scattered logs and per-team APM agents, with consistent telemetry that explains why a system is slow or failing. NTSPL instruments applications with OpenTelemetry, builds trace, metric and log pipelines on cloud-native or open-source backends, and sets journey SLOs and alerts for teams running distributed applications they cannot debug quickly today.
Delivered on
In scope
Why modernised applications outgrow host-based monitoring
Modernised applications break old monitoring. A request that once ran inside one JVM now crosses an API gateway, six services, two queues and a managed database. Nagios still checks CPU, logs land in three different tools, and each team's APM agent covers only its own services. Incidents turn into bridge calls where everyone proves their component is green. Meanwhile log bills climb because every debug line is ingested and retained at the same price, and CERT-In's 180-day retention is met by keeping everything in expensive hot storage.
NTSPL instruments once with OpenTelemetry SDKs and auto-instrumentation, so traces, metrics and logs share trace IDs and resource attributes whatever the backend. OpenTelemetry Collectors sample, redact and route: error and slow traces are kept in full, healthy traffic is tail-sampled, and personal data is stripped at source. Logs split into hot search for 7-30 days and a cheap 180-day archive for compliance. SLOs per user journey drive burn-rate alerts, so pages fire on customer impact rather than one host's CPU.
Signals that your telemetry no longer explains incidents
Signals you need Observability Modernization
- Mean time to identify the failing component in an incident exceeds 30-45 minutes.
- Three or more monitoring and logging tools run side by side with no shared trace or request ID.
- Log ingestion cost grows faster than traffic, or exceeds 10-15% of total cloud spend.
- On-call receives hundreds of mostly host-level alerts a day and ignores most of them.
- Microservices, serverless functions or queues arrived in the last two years without distributed tracing.
When to choose something else
- If you need a team watching dashboards and responding around the clock, that is managed monitoring under Managed Cloud Services.
- Security detection and SIEM design belong to Logging & Threat Detection, though it can share our collectors.
- A single monolith on a few VMs with stable traffic may need only a cloud-native APM agent and basic alerts.
Observability rebuild components
Telemetry audit
Inventory of agents, log sources, dashboards, alert rules and costs, plus incidents where telemetry failed to help.
Instrumentation
OpenTelemetry SDKs and auto-instrumentation for Java, .NET, Node, Python and Go, with context propagation across HTTP, gRPC and queues.
Collector pipeline
Agent and gateway collectors with tail sampling, attribute redaction, batching and routing.
Log tiering
Structured logging standards, hot, warm and archive tiers, and a 180-day compliance archive.
SLOs and alerting
Journey SLOs, multi-window burn-rate alerts, routing rules and alert noise reduction.
Dashboards and runbooks
Service and journey dashboards linked to traces and to the runbook for each alert.
How Observability Modernization Works, Step by Step
OpenTelemetry Collection, Sampling and Routing Pipeline
Services emit traces, metrics and logs through OpenTelemetry SDKs to node-level collectors, which forward to a gateway tier that samples, redacts and routes. Hot telemetry feeds trace, metric and log backends with SLO alerting, while a low-cost archive holds logs for compliance retention.
Select any component
OpenTelemetry Collection, Sampling and Routing Pipeline: click any of its 10 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Cloud-native observability backends
Application Signals builds SLOs and service maps from OpenTelemetry data, and S3 holds the 180-day archive. Amazon Managed Grafana is not offered in Indian regions, so dashboards stay in CloudWatch or self-hosted Grafana.
The Azure Monitor OpenTelemetry Distro sends traces to Application Insights, managed Prometheus collects AKS metrics, and Basic or Auxiliary log plans cut the cost of verbose logs.
Cloud Monitoring defines SLOs and burn-rate alerts natively, and log buckets in asia-south1 with custom retention meet CERT-In, while exclusion filters drop debug noise before ingestion charges apply.
Telemetry choices that control cost and signal
Sampling strategy
Use tail sampling at the gateway: keep 100% of error traces and traces slower than the SLO threshold, and 5-10% of healthy ones. Head sampling at 1-5% is simpler but loses rare failures entirely. For payments or regulated flows, keep complete trace metadata for every request with sampled detail spans, so audit lookups always find the transaction.
Neutral or provider-native backend
Instrument with OpenTelemetry regardless of backend, then choose the backend on cost and skills. Cloud-native backends suit single-cloud estates and remove storage operations. Open-source stacks such as Prometheus, Tempo, Loki or OpenSearch, or a commercial SaaS, suit multi-cloud estates, at the price of either operating effort or per-host licence fees.
Log levels and tiers
Run production at INFO with structured JSON, and enable DEBUG only through per-service toggles that expire within hours. Send audit and security logs to the compliance archive, application logs to 14-30 day hot search, and drop health-check and load-balancer noise at the collector; that noise is often 30-50% of total volume.
SLO design
Define two to four SLOs per user journey, covering availability and latency at p95 or p99, measured on requests at the edge. Set initial targets from the last 90 days of real performance, not aspirations, and alert on multi-window burn rates, for example 2% of the monthly budget in one hour or 5% in six hours.
Instrumenting services and journeys in phases
Telemetry audit and journey selection
Inventory tools and costs, review recent incidents and choose 5-8 critical journeys.
Collector pipeline and backends
Deploy agent and gateway collectors with sampling, redaction and routing as code.
Instrument critical journeys
Add SDKs and auto-instrumentation, propagate context through queues and add business attributes.
SLOs, alerts and noise reduction
Define journey SLOs, build burn-rate alerts and retire host-level noise.
Log tiering and tool retirement
Move logs to tiers, prove 180-day retention and retire overlapping tools at renewal.
What you receive
Observability outcome targets
| KPI | Typical target |
|---|---|
| Mean time to identify the failing component | Under 10 minutes |
| Alerts per on-call shift | Under 10, with more than 80% actionable |
| Log ingestion cost at the same traffic | 30-50% lower |
| Critical journeys with SLOs and end-to-end traces | 100% |
| Instrumentation overhead | Under 3-5% CPU and latency |
Observability programme pitfalls
| Risk | How NTSPL prevents it |
|---|---|
| Instrumentation overhead | Load tests run with and without instrumentation, and sampling is tuned until overhead stays under 3-5%. |
| Personal data leaking into telemetry | Collector redaction for PAN, Aadhaar, phone and email patterns, plus code-review rules against logging request bodies. |
| Cost moving rather than shrinking | Ingestion budgets per team and a weekly report of the top log producers. |
| Dashboards nobody opens | Dashboards are tied to SLOs and runbooks, and unused ones are pruned every quarter. |
OpenTelemetry or proprietary APM agents?
Use OpenTelemetry for instrumentation in any new or modernised application. It is the CNCF standard supported by every major cloud and APM vendor, so you can change backends later without re-instrumenting code. Proprietary agents still offer deeper automatic coverage for some runtimes and faster setup, and remain reasonable for a stable monolith that is already well covered. A practical path: keep existing agents where they work, introduce OpenTelemetry for new services and the collector pipeline, route both to the same backend, and retire the old agents at licence renewal.
Key facts: Observability Modernization
Observability Modernization in Practice
2 Observability Modernization scenarios, from Cab aggregation (tier-2 cities) and Diagnostics (home sample collection), plus related platform case studies.
Cab aggregator cuts incident diagnosis from 70 to 9 minutes with OpenTelemetry tracing
Diagnostics network traces every sample from collection to report across AWS and Azure
Telecom VAS provider cuts daily pages from 2,300 alerts to 9 actionable incidents
IT services firm brings 43 Azure subscriptions under one policy hierarchy
Observability Modernization: Frequently Asked Questions
What does observability modernization cost?
A collector foundation plus instrumentation of 5-8 critical journeys typically takes 10-12 weeks and INR 30-55 lakh. Most clients recover part of that through lower log and APM spend, because trimming noise and tiering logs commonly cuts ingestion cost by a third or more.
How do we meet CERT-In's 180-day log retention without a huge bill?
Keep a small hot tier for search and alerting, and send everything needed for compliance to low-cost archive storage in an Indian region, such as S3, Azure Storage or Cloud Storage with lifecycle rules. Archived logs stay retrievable for investigations and support CERT-In's 6-hour incident reporting.
Do we have to change application code?
Very little at first. Auto-instrumentation for Java, .NET, Node and Python captures HTTP, database and messaging spans without code changes. On critical journeys we then add manual spans and business attributes, such as order ID or scheme code, where they speed up diagnosis.
Can we keep using Grafana?
Yes. Grafana works with Prometheus, cloud monitoring APIs and common log backends. On AWS in Indian regions we run self-hosted Grafana on EKS or ECS, because Amazon Managed Grafana is not offered there; on Azure and Google Cloud we use managed or self-hosted Grafana depending on regional availability.
What is an error budget?
It is the amount of unreliability an SLO allows. A 99.9% monthly availability target leaves 0.1%, about 43 minutes in a 30-day month. When a team burns budget fast, alerts fire; when it is spent, the team prioritises reliability work over new features until it recovers.
How does this relate to our SIEM?
They share collection but serve different purposes. Our collectors can forward security-relevant logs to the SIEM while application telemetry goes to observability backends, avoiding duplicate agents on every host. Detection rules and SOC workflows are designed by our security practice.