Our organization recently completed a bifurcation of our observability stack, moving our log management from New Relic to Sumo Logic while retaining New Relic for APM and distributed tracing. The primary driver was cost optimization for a specific, high-volume data type. This was not a decision made lightly, as the operational overhead of managing two platforms is non-trivial.
The core financial rationale was the structure of our log data. We have several legacy applications that generate verbose, unstructured debug logs at a sustained rate of several terabytes per day. New Relic's pricing, based on ingested GB/month, became untenable for this firehose. Sumo Logic's pricing model, while also consumption-based, allowed for more aggressive cost controls through:
* **Flexible data tiers:** The ability to route less critical logs to a lower-cost, queryable tier.
* **Efficient parsing and retention:** Their log reduction and archiving rules are more granular out-of-the-box for our use case.
* **Commit-based discounts:** We negotiated a committed annual volume, which provided a predictable cost floor and ceiling.
Technically, the transition required a re-architecture of our log forwarding. We replaced the New Relic logging agents with Sumo Logic's collectors. The most significant configuration effort was in defining partitioning and field extraction rules in Sumo to replicate the key functionality we had in NRQL. A sample of our collector JSON configuration for a high-volume source:
```json
{
"api.version": "v1",
"sources": [
{
"name": "Legacy-App-Prod",
"category": "prod/legacyapp",
"automaticDateParsing": true,
"multilineProcessingEnabled": false,
"useAutolineMatching": true,
"forceTimeZone": false,
"filters": [
{
"filterType": "Exclude",
"name": "Drop_Healthchecks",
"regexp": ".*GET /health.*"
}
],
"encoding": "UTF-8",
"sourceType": "LocalFile",
"pathExpression": "/var/log/legacy/*.log"
}
]
}
```
The outcome has been a 40% reduction in our log management spend, meeting our primary objective. However, the trade-offs are real:
* **Correlation overhead:** Troubleshooting an issue now sometimes requires jumping between Sumo (for full log context) and New Relic (for trace details). We've mitigated this somewhat by passing trace IDs into logs and using them as a cross-platform key.
* **Unified alerting is gone:** We lost the ability to create single alerts that trigger based on a threshold breach in a NRQL query *and* a log event pattern. We now maintain separate alert policies in each system.
For teams considering a similar split, I would advise a clear delineation of responsibilities: Sumo for logs and security analytics, New Relic for APM and metrics. The cost benefit only materializes if your log volume is substantial and you are diligent in configuring data lifecycle rules in Sumo to avoid paying for "cold" data at "hot" storage prices.
Less spend, more headroom.