Alright, let’s cut through the usual “Claw is a game-changer” marketing fluff. I’ve been running their Docker agent for container monitoring in a mid-sized AWS EKS cluster (team of ~25, mix of Java/Go services) for about six months. The promised “lightweight” agent is anything but.
For the past two weeks, we’ve seen sporadic CPU spikes on nodes where the Claw agent is deployed—pegging a core to 95%+ for minutes at a time. This isn’t during high traffic; it happens during off-hours, like 3 AM on a Sunday. Our “golden image” hasn’t changed, and the only common variable is their agent pod.
We considered self-hosted/open-source monitoring (Prometheus/Grafana stack is still running in parallel, because you should always have an exit strategy), but went with Claw for the promised ease. Joke’s on us, I guess.
Before I deep-dive into a vendor support ticket that’ll inevitably blame our “unique environment,” I want to know:
* Is anyone else seeing this, or are we just the lucky ones?
* Specifically, which version of their agent? We’re on `3.7.1`.
* Any correlation with certain log volumes or specific container image types?
Their SLA mentions resource usage, but the fine print defines “excessive” as “more than 0.5 cores sustained”… which, hilariously, we’re now hitting. So much for that credit.
Your free trial ends today.
Yeah, we saw similar spikes on version `3.6.8` a few months back. It was during scheduled metric aggregation windows, not log volume. Moving the agent to dedicated infra nodes (tainted so nothing else schedules there) was our band-aid. Not ideal, but it stopped the app pods from getting hit.
Have you checked if the spikes align with their "data flush" schedule? Our config had a weird default for that. Good luck with support
3.7.1 introduced a new metrics compression routine. The 3 AM spike is likely that batch job, but it's poorly optimized for multi-core.
Check the agent's stdout for "Compacting metric batches". It logs the start but not the resource cost. We saw it take 45 seconds per 100k series.
EXPLAIN ANALYZE
Ah, the "unique environment" deflection. Classic. Their support's default playbook is to ask for three months of logs, blame your kernel version, then quietly close the ticket as "non-reproducible."
You mentioned their SLA fine print. If it's anything like their last version, they define "excessive" usage as anything over 90th percentile for your plan tier, which they calculate based on *their* aggregate customer data. Good luck proving your 3 AM spike violates that.
Stick with your Prometheus exit strategy. It's looking better by the minute.
Trust but verify – especially the audit log.
We hit the exact same thing on 3.7.1 in our Azure AKS clusters. The 3 AM Sunday spike was the giveaway. It's absolutely their metrics compaction routine, which doesn't respect resource limits well. We found a correlation with services using dynamic tags, like per-request IDs in logs that get turned into high-cardinality series.
Our temporary fix was to pin the agent pod to a specific node and double its CPU limit, which felt wrong. Support eventually gave us a config flag to stagger the compaction schedule, but we still saw spikes. Rolling back to 3.6.9 stopped the spikes, but we lost some newer integrations. We're also leaning harder on our Prometheus fallback now.
Data is sacred.
Oh wow, that's almost exactly our timeline too - six months in, and the 3.7.1 agent started acting up a few weeks back. We're also on EKS.
We found a strong correlation with Go services that use the standard `runtime/metrics` package. The agent seems to go haywire when collecting certain Go-specific runtime metrics, especially around memory allocs and goroutines. Our pure Java services on the same node? Barely a blip.
You're right about the support ticket. Ours is still open, with them asking for "a full tcpdump" from a spiking node. Like that's production-friendly.
Curious - are you using their default log sampling? We turned ours down from 100% to 50% and saw a small improvement, but the 3 AM Sunday core-pegging still happens.
Benchmarking my way to better decisions