Anyone actually using LogRhythm in production after 2024?

Yeah, I'm with you on the data quality angle. We tried to use LogRhythm's built-in taxonomy for a unified data layer about a year ago, and it became a maintenance nightmare. The MPE rules for custom JSON felt brittle.

We ended up doing a weird dual pipeline where we landed raw logs in a cheap blob store first, used a lightweight parser to tag them, and then shipped only the tagged subset to LogRhythm for alerting. The governance overhead of managing field extractions inside the platform was just too high for our volume.

Are you considering keeping the raw log parsing entirely outside the SIEM? I'm nervous about building that myself, but the vendor lock-in on schema management is a real worry.

Your dual pipeline approach is interesting. I've been thinking about something similar, but using a no-code platform like n8n or Make to handle the initial parsing and tagging before it ever hits the SIEM. It feels less daunting than building a full parser from scratch, and you keep the transformation logic outside vendor walls.

How do you handle schema drift in your raw logs with that setup? Do you find the lightweight parser needs constant updates anyway, or was moving that work out of LogRhythm itself the main gain?

Your questions assume the platform's core is still under active development. It isn't.

They've been in a holding pattern for years, just rebranding the same legacy parsing engine under new buzzwords. The "modern schema-less data" you're asking about? Their MPE can't handle it natively without a fight. You'll spend more time writing and debugging custom parsers than actually using the data.

Realistic throughput is fine if you're just piping syslog. For anything like CrowdStrike or complex JSON, you'll hit performance cliffs that force you into that exact dual-pipeline workaround everyone else is already building. That should tell you something about its "production viability." Why pay their premium to then bypass their core feature?

Your focus on data-centric operations is the right lens. From that angle, the cost of governing the taxonomy itself becomes a major factor.

> How manageable is the taxonomy and field extraction process at scale?

It's not, without significant overhead. We tracked the engineering hours spent maintaining custom MPE rules and normalizing fields for just our core app logs. That operational cost rivaled the annual license fee. When we modeled moving that parsing layer to a dedicated pipeline (like a serverless function writing to S3), the TCO dropped enough to fund the new pipeline build.

So the question flips: can you afford to use LogRhythm's built-in data management as anything more than a consumer of pre-processed data? For us, the answer was no.

>weird dual pipeline

That's the new default, not a weird workaround. You're just doing their R&D for them.

If the governance overhead is already this bad, why keep paying for the SIEM's broken parser at all? A couple lambda functions writing to OpenSearch is cheaper and you actually own the schema. The "vendor lock-in" you're worried about is already happening; you're just managing two systems instead of one.

Building it yourself is less daunting than spending another year fighting MPE.

>cheaper and you actually own the schema

Cheaper on paper, maybe. Run the TCO for a 50 TB/month cluster with the necessary availability zones, cross-AZ replication, and the team to babysit it. My last OpenSearch bill was 40% higher than the LogRhythm SKU it was meant to replace.

You own the schema, sure. You also own the 2am P1 because your custom parser choked on a nested JSON array change. That's the real lock-in.

Your idea of using a no-code platform for pre-parsing is clever and addresses the real problem, which is vendor rigidity. I've seen teams use similar approaches with Cribl or even a simple Python Lambda.

> How do you handle schema drift in your raw logs with that setup?

The main gain isn't eliminating schema updates, it's decoupling them from the SIEM's release cycle and opaque error handling. You can implement your own drift detection logic. For instance, you can route any logs that fail a JSON schema validation check to a separate S3 prefix for review, while known-good events flow to LogRhythm. This is impossible to do cleanly within their MPE.

The parser still needs updates, but now you control the logic, the tests, and the deployment. You're trading one maintenance task for another, but the latter is far more debuggable and automatable. The operational cost shifts from fighting the platform to engineering a solution.

Oh, the "couple lambda functions" solution. I've been down that exact garden path, my friend. It starts as a weekend project and ends up as a full time job nobody wanted.

> cheaper and you actually own the schema

Sure, you own the schema. You also own the alerting logic, the retention policy engine, the dashboarding quirks, the certificate rotations, the version upgrade path when AWS deprecates a runtime, and the pager duty for when the ingest queue backs up because somebody pushed a malformed CloudTrail log. You're trading vendor lock-in for ops lock-in.

I'm not defending LogRhythm here - the MPE is a relic. But there's a hidden tax to building your own "cheaper" SIEM that only shows up at 3 AM. Sometimes the devil you know, even if he's slow and grumpy, is better than becoming the devil yourself. 😅