Has anyone successfully used LogRhythm for non-security IT ops monitoring?

Great question on cost. We ran into that exact issue. For purely ops logging, we found you need to be ruthless with filters at the source. Sending everything will bankrupt you.

We built separate "fat" and "lean" log streams. The lean stream goes to LogRhythm, filtered down to just ERROR/CRITICAL events, health checks, and key deployment events. That cut our volume by about 70%. The fat stream with all the verbose debug logs goes to a cheap S3 bucket for occasional deep dives.

Our lean stream for about 200 nodes and 50 microservices sits around 15-20 GB/day. The dashboards for service health and automated alerts on failed deployments work great. Just don't expect to do detailed APM tracing there.

That's a smart approach with the fat/lean streams. We've done something similar, but we pipe our lean stream into a separate "alerting engine" (a simple Lambda that parses and routes) before it even hits LogRhythm. That way, we get PagerDuty blasts for critical stuff instantly, and LogRhythm becomes our source of truth for historical trends and dashboards.

It does mean you're maintaining two systems, but the cost savings are real. Have you run into any issues with log format changes breaking your source filters? That's bitten us a few times after major app updates.

The log format change issue is a real one. We standardized on a structured JSON schema for all application logs early on, with a mandatory version field. That version field is the first thing our ingestion layer checks, and it routes to different parsers. It adds a bit of overhead, but it's prevented those silent breaks after updates.

Have you considered adding a validation step in your CI/CD pipeline that checks log output against a schema for critical services? It catches most format drift before it hits production.

Your primary concern about cost efficiency is the key constraint that determines feasibility. I've seen this exact evaluation twice, and both times the operational log volume made the vendor's standard ingestion pricing model a non-starter.

The architectural pattern that made it work involved pre-processing. We used Fluent Bit as a universal agent, deployed as a DaemonSet in K8s and on VMs, to perform aggressive filtering and transformation before egress. This wasn't just severity-based filtering. We parsed logs at the edge to extract and forward only specific high-cardinality fields needed for ops dashboards (like pod name, error code, latency bucket) while discarding the full message body. This reduced ingest volume by nearly 85% compared to a raw feed.

For your question on real-world volumes: a deployment monitoring about 300 EKS pods and 100 EC2 instances settled at ~10 GB/day after this processing. That volume supported dashboards for deployment success rates and system health, but true APM correlation was impossible. You'll need a dedicated APM tool for traces; trying to force that use case into LogRhythm will bloat cost and complexity. The platform is competent for centralized error aggregation and historical trend analysis, but only if you treat it as a destination for curated, high-signal events.

That split makes sense for cost. The maintenance overhead you're seeing is the hidden tax.

We run the validation check in CI/CD like user1013 mentioned. It's a simple unit test that verifies our log schema against a spec for key services. Catches 90% of breaks.

But the bigger issue is alert fatigue from the Lambda. If your parsing logic is too simple, you get false positives from edge case log formats. We added a short quarantine buffer to S3 for unparseable logs before triggering a human review.

You're right to question the cost model for verbose ops data. I ran the numbers for a 500-node hybrid fleet last year, and the raw syslog/app log volume was over 120 GB/day. At LogRhythm's standard ingestion rates, that was financially untenable for a non-security budget.

The only way we made the math work was by implementing a three-stage filter pipeline before ingestion. First, we used Fluentd with custom plugins to drop all debug/info logs at the source. Second, we aggregated repetitive health check pings into a single "status heartbeat" every 30 seconds instead of logging each request. Third, we parsed error logs to extract only the error code, service name, and timestamp, discarding the full stack trace. This got us down to about 8 GB/day of high-value data.

Even with that, the dashboards for proactive health monitoring were useful but limited. You won't get true APM correlation because you've stripped out the trace IDs and latency details to save cost. It's good for answering "is it down?" but not "why is it slow?" For that, you'll still need a dedicated APM tool.

You're asking the right question about cost. Everyone's describing elaborate filtering schemes to make a security tool affordable for ops. That should tell you something.

We tried this exact path. The problem isn't the data volume you can achieve with enough engineering. It's the total cost of ownership when you add all that custom pipeline work to the vendor's bill. You end up paying for the SIEM and building half a logging platform in front of it.

You'll spend more time managing filters and parsers than looking at dashboards. If your goal is a unified operational view, start with a tool built for that volume from the ground up. Using LogRhythm here is like using a fire truck to water your lawn. It can be done, but why?

Cost efficiency is exactly why this idea usually falls apart. You're looking at a tool priced for the high-margin, low-volume world of security events and trying to jam terrabytes of operational chattiness through it.

Everyone's sharing their elaborate filtration schemes like it's a badge of honor. But step back. If you need to build a whole pre-processing pipeline with Fluent Bit, quarantine buffers, and schema validation just to make the vendor's pricing palatable, you've already lost. You're now running two logging platforms.

For your specific points:
* APM correlation? It's not built for that. You'll be building those correlations yourself, if the granular data even survives your cost-cutting filters.
* Proactive health dashboards? Sure, you can make some. After you've spent months tuning and pruning what data you're allowed to send.

The real-world volume numbers others posted - 15 GB/day after heroic filtering from 200+ nodes - tell the story. The architecture pattern is "spend more on engineering than licensing."

The version field is a smart move. We enforce that on all structured logs, but it only works if teams actually increment the version when the schema changes. We've had issues where devs add new fields but leave the version number alone, assuming it's backward compatible, which still breaks some of our parsing logic for dashboards.

Your CI/CD validation idea is solid. We implemented it as a pre-merge check for any service that writes to our central log stream. It catches the obvious breaks, but you still need monitoring on the ingest pipeline itself for logs coming from legacy systems or third-party software you can't control.

You're hitting on the exact tension I've seen teams struggle with. The desire for a unified view is completely valid, but using LogRhythm for ops feels like forcing a square peg into a round hole, purely because of the cost structure.

I helped a team implement something similar a while back for Kubernetes and cloud logs. We got proactive dashboards for service health and automated alerts for things like pod crash loops or elevated API error rates, but only after building a massive Fluentd filtering pipeline. The real-world volume we landed at was about 12 GB/day for a 200-node hybrid environment after aggressive filtering, but the engineering effort to maintain those parsers and filters became a full-time job for a junior engineer. The dashboards were useful, but the TCO was enormous when you added the labor.

For your question on architectural patterns, the most successful approach I've seen is to use a lightweight, purpose-built log shipper for aggregation and basic alerting, and only send summarized health metrics or specific error signatures to LogRhythm. That keeps the SIEM volume low for correlation with security events, but your primary operational visibility lives elsewhere. Have you looked at using something like Grafana Loki or even a cloud-native service for the high-volume streaming, and reserving LogRhythm for the curated, actionable events?

Totally feeling that TCO pain in my own project right now. That "full-time job for a junior engineer" line hit home - I'm basically the junior engineer trying to maintain our own fragile filter pipeline for something similar.

Your split approach makes a ton of sense. We're trying to do it all in one place and the alert noise is drowning out actual problems. If you only send summarized metrics to LogRhythm, how do you handle the correlation later? Like if you get a security alert, do you have to go query your other "primary" logging system manually to see what the ops state was, or is there a way to link them that doesn't break the bank?

> reduced ingest volume by nearly 85%

That's the key number. But you're still left paying LogRhythm's price per GB for the remaining 15%. On 300 pods and 100 instances, that's still ~$3-4k/month just for ingestion at their standard rates, before you add in compute and storage. The cost avoidance is in the millions you didn't ingest, but you're still funding a premium tool for filtered ops data.

The ~10 GB/day you landed on is exactly the volume where dedicated observability platforms become competitive, and they're built for the ops use case you're trying to force. You're doing all the hard filtering work yourself but still paying SIEM prices.