I'm a senior DevOps engineer at a mid-sized e-commerce company in India, and we're planning to replace our current Coralogix and CloudWatch setup. We run about 200 mostly static AWS ECS Fargate tasks across production and pre-production. Around 120 core backend services need APM and distributed tracing, while the other 80 mainly need application logs.
Our team has 30 developers and only two DevOps engineers, so we need a managed service with a reasonably intuitive visual interface. We don't have the bandwidth to maintain complicated dashboards or serve as a query helpdesk for every developer. The team is comfortable with Coralogix's general workflow, but we would prefer clean OpenTelemetry support so we can use AWS ADOT sidecars instead of maintaining proprietary agents.
Traffic is fairly consistent throughout the year, with one annual festive-season flash sale that can increase volume by roughly five times. We can tolerate a temporary increase during that month, but our normal observability budget is a firm $3,000–$4,000 per month.
Datadog and Dynatrace appear too expensive because of task, host, memory, and APM pricing. New Relic's per-user pricing is also unattractive for 30 developers. Grafana Cloud looks more promising, but we're concerned about asking developers to learn PromQL and LogQL.
We're considering services such as SigNoz, Logz.io, Last9, Honeycomb, Uptrace, and other managed OpenTelemetry-compatible platforms. What would you shortlist for this setup? Are there cost-effective architectural approaches, such as using separate backends for logs and traces, that we should consider?
4 Answers
SigNoz, Uptrace, and ClickHouse-based products are reasonable candidates if you want an OpenTelemetry-first workflow and relatively simple cost modeling. They can be easier to estimate on a data-volume basis than per-task or per-host products. Ask each vendor to price your actual trace volume, retention, indexing, support tier, and annual spike rather than relying on a headline per-gigabyte rate.
Self-hosted SigNoz or a similar stack may work well for development and low environments, while production remains managed. That hybrid approach can reduce spend, but only if the team is comfortable owning upgrades and troubleshooting in the less critical environments.
Honeycomb is worth evaluating if high-quality tracing and fast incident investigation matter more than putting every log into one system. Its OpenTelemetry support and event-based interface can make exploratory debugging easier for developers, especially when services emit structured, wide events. You could keep ordinary logs from the 80 low-priority tasks in a cheaper destination and send traces, errors, and selected logs from the 120 core services to the primary platform.
Also look at simpler Elastic- or ClickHouse-based SaaS offerings. Some provide a familiar log-search interface and flexible dashboards without charging separately for every chart or user. Just verify that the quoted price includes APM, trace retention, ingestion overages, and the annual traffic spike.
Grafana Cloud is worth testing rather than dismissing because of the query languages. Developers can use the Explore UI, saved searches, dashboards, and service-level views without writing PromQL or LogQL for routine investigations. Your DevOps team can provide a small set of standard dashboards and recording rules, then let developers use the visual interface for everything else.
A typical OpenTelemetry architecture would send traces to Tempo, logs to Loki, and metrics to the managed metrics service. Make sure you model the flash-sale month separately and check ingestion, retention, and cardinality limits in the quote. Self-hosting the same components can reduce licensing costs, but it transfers availability, upgrades, storage, and capacity planning to your two-person team.
A few hours of training and some saved queries may be cheaper than paying several thousand dollars more every month. I would run a small Grafana proof of concept with representative logs and traces before making the decision.
Start by getting exact telemetry volumes before comparing vendors: daily log ingestion, metric cardinality, trace spans, sampling rate, retention, and the number of active users. APM and tracing for 120 services can be much more expensive than the task count suggests. You may need to decide whether every service really needs full-fidelity tracing or whether head-based or tail-based sampling is sufficient.
Managed services are probably a better fit than self-hosting for a two-person operations team, but the budget may require separating use cases. Keep inexpensive or low-value logs in AWS, object storage, or a lower-cost log backend, and reserve the premium observability platform for traces, errors, and important application logs.
That makes sense. The $4,000 limit is specifically for observability, and we’re trying to avoid adding a platform that requires substantial engineering time to operate.
We’re mainly looking for a ready-to-integrate SaaS option at first. We don’t have much spare time for operating another production platform, but we may consider self-hosting for non-production environments.