7 ms·

The OOM/restart loop problem is one of those things that eats engineers alive at 2am because the actual root cause is almost never in the container logs themsel

The OOM/restart loop problem is one of those things that eats engineers alive at 2am because the actual root cause is almost never in the container logs themselves — it's usually misconfigured resource limits, noisy neighbors on the node, or a memory leak that only surfaces under specific request patterns. The autonomous RCA angle is interesting but I'm curious whether you're correlating against node-level metrics or just container events, because without that layer you'll chase a lot of false leads. One thing I've seen bite teams hard at this stage: the investigation agent needs read-only access to work, but most setups end up giving it broader Docker socket permissions "temporarily" and that never gets cleaned up. That's a real blast radius problem if the agent itself gets exploited or misbehaves. What does your permission model for the agent look like right now?

ismailperim 7mo ago
Great questions - you're right on both fronts. *Node metrics:* Currently we're container-only (docker stats/logs), so yes - we'd miss noisy neighbors or node-level memory pressure. Prometheus integration is on the roadmap to correlate container events with node/cluster metrics. Right now we catch the obvious cases: "this container OOMKilled at its 512MB limit." *Permissions:* Funny story - I built this while working with OpenClaw (an AI assistant framework). OpenClaw has broad system access by design, but I wanted to explore: what if we made a micro-agent with the minimum permissions needed? So OnCallMate offers two modes: 1. *Direct socket* (if you trust it / testing): bind /var/run/docker.sock 2. *docker-socket-proxy* (production): read-only layer, no exec/restart/POST The proxy approach: - Agent connects via TCP, never touches the socket directly - Whitelist: containers, logs, stats, inspect (GET only) - Blacklist: exec, restart, swarm, secrets - Even if AI hallucinates "docker restart nginx", it physically can't All tool calls are logged for audit trails. You're right that we should emphasize this more in the README. Principle: treat AI agents like untrusted input. Have you seen other patterns for safely exposing Docker APIs to automation?

ismailperim 7mo ago

Great questions - you're right on both fronts. *Node metrics:* Currently we're container-only (docker stats/logs), so yes - we'd miss noisy neighbors or node-level memory pressure. Prometheus integration is on the roadmap to correlate container events with node/cluster metrics. Right now we catch the obvious cases: "this container OOMKilled at its 512MB limit." *Permissions:* Funny story - I built this while working with OpenClaw (an AI assistant framework). OpenClaw has broad system access by design, but I wanted to explore: what if we made a micro-agent with the minimum permissions needed? So OnCallMate offers two modes: 1. *Direct socket* (if you trust it / testing): bind /var/run/docker.sock 2. *docker-socket-proxy* (production): read-only layer, no exec/restart/POST The proxy approach: - Agent connects via TCP, never touches the socket directly - Whitelist: containers, logs, stats, inspect (GET only) - Blacklist: exec, restart, swarm, secrets - Even if AI hallucinates "docker restart nginx", it physically can't All tool calls are logged for audit trails. You're right that we should emphasize this more in the README. Principle: treat AI agents like untrusted input. Have you seen other patterns for safely exposing Docker APIs to automation?