3 ms·

Show HN: OnCallMate – AI agent for autonomous Docker incident RCA

1 points by ismailperim 7mo ago

Hey HN! I built this because I got tired of waking up to read Docker logs. OnCallMate is an autonomous AI agent that: - Monitors your Docker containers (proactive scheduler) - Detects anomalies (crashes, OOM, restarts) - Autonomously investigates using OpenAI function calling - Performs RCA and suggests fixes Example workflow: User: "any issues?" → AI calls docker_list, docker_inspect (4x), docker_stats (3x), docker_logs → Returns: " CRITICAL nginx - OOMKilled. Memory hit 512MB limit. Recommend: docker update --memory=1g nginx" Security-first design: - not SaaS/self-hosted - Docker socket proxy (read-only by default, no direct socket exposure) - Admin-only access (Telegram ID allowlist) AI provider options: - OpenAI/Claude API (you choose what to send) - OpenRouter free tier (cost-effective) - Bring your own model (extensible architecture) Built in 3 days using: - OpenAI function calling (multi-turn tool loops) - Universal tool architecture (Docker now, K8s and cloud providers later) - TypeScript + Dockerode + Telegram (Slack etc. later) Open source (MIT), runs entirely in your network. GitHub: https://github.com/ismailperim/oncallmate https://github.com/ismailperim/oncallmate What features would make this more useful for you?

matrixgard 7mo ago
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?

1 points by ismailperim 7mo ago

matrixgard 7mo ago

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?