Construa um Servidor Auto-Reparável com OpenClaw

E se o seu servidor pudesse se reparar sozinho? Não apenas alertar você quando algo dá errado, mas de fato diagnosticar o problema, aplicar a correção certa e contar a você sobre isso depois. Com o OpenClaw, você pode construir exatamente isso.

Este tutorial orienta você na criação de uma configuração de servidor auto-reparável, em que seu agente de IA monitora a saúde do sistema, detecta problemas comuns, aplica correções automaticamente e envia um relatório por e-mail.

O Que Vamos Construir

Um sistema em que o OpenClaw:

1. Monitora as métricas do servidor a cada 5 minutos (disco, memória, CPU, serviços)
2. Detecta problemas comuns (disco cheio, serviço travado, alta carga, expiração de SSL)
3. Diagnostica a causa raiz usando raciocínio de IA
4. Corrige o problema automaticamente quando for seguro
5. Notifica você por e-mail com um relatório completo do que aconteceu

O princípio fundamental: corrija o que é seguro corrigir, alerte sobre todo o resto.

Pré-requisitos

• OpenClaw instalado e rodando no servidor que você quer monitorar
• Skill de execução de shell habilitada
• Chave de API do Inbounter para notificações por e-mail
• Familiaridade básica com administração de sistemas Linux

Passo 1: Configurar o SOUL.md

Adicione uma seção de operações de servidor ao seu SOUL.md:

## Server Operations Role

You are responsible for monitoring and maintaining this server. Your priorities:

1. Keep services running
2. Prevent disk and memory exhaustion
3. Maintain security (SSL certificates, updates)
4. Log everything you do

### Auto-Fix Rules (SAFE to do without asking)
- Clear apt/package manager cache when disk > 85%
- Delete old log files (> 30 days) when disk > 85%
- Restart a crashed service (max 3 times, then escalate)
- Renew SSL certificates via certbot
- Clear /tmp files older than 7 days

### Escalate Rules (DO NOT auto-fix, notify admin)
- Disk usage above 95% after cleanup
- Service crashes more than 3 times in 1 hour
- Unusual processes or network connections
- Failed security updates
- Any issue you are not confident about

### Notification Rules
- Auto-fixes: Send summary email via Inbounter
- Escalations: Send urgent email via Inbounter with "URGENT" in subject
- Weekly: Send a health summary every Sunday at 8 AM

### Safety Rules
- NEVER delete user data to free disk space
- NEVER modify firewall rules automatically
- NEVER update the kernel without admin approval
- NEVER restart the server (only restart individual services)
- Always log commands to /var/log/openclaw-ops.log before executing

Passo 2: Criar Scripts de Verificação de Saúde

Crie um conjunto de scripts que o agente pode executar para coletar informações do sistema.

Script de Saúde do Sistema

#!/bin/bash
# /home/openclaw/scripts/health-check.sh

echo "=== System Health Report ==="
echo "Date: $(date)"
echo ""

echo "=== Disk Usage ==="
df -h / /home /var /tmp 2>/dev/null | grep -v tmpfs
echo ""

echo "=== Memory ==="
free -h
echo ""

echo "=== CPU Load ==="
uptime
echo ""

echo "=== Top Processes (by memory) ==="
ps aux --sort=-%mem | head -6
echo ""

echo "=== Top Processes (by CPU) ==="
ps aux --sort=-%cpu | head -6
echo ""

echo "=== Services Status ==="
for svc in nginx postgresql redis openclaw; do
    if systemctl is-active --quiet "$svc" 2>/dev/null; then
        echo "  $svc: RUNNING"
    else
        echo "  $svc: STOPPED"
    fi
done
echo ""

echo "=== SSL Certificates ==="
for domain in $(ls /etc/letsencrypt/live/ 2>/dev/null); do
    expiry=$(openssl x509 -enddate -noout -in "/etc/letsencrypt/live/$domain/cert.pem" 2>/dev/null | cut -d= -f2)
    if [ -n "$expiry" ]; then
        echo "  $domain: expires $expiry"
    fi
done
echo ""

echo "=== Recent Errors (last 30 min) ==="
journalctl --since "30 minutes ago" --priority=err --no-pager | tail -10
echo ""

echo "=== Open Connections ==="
ss -tuln | grep LISTEN | wc -l
echo "  listening ports"
echo ""

echo "=== Uptime ==="
uptime -p

Torne-o executável:

chmod +x /home/openclaw/scripts/health-check.sh

Passo 3: Configurar o Cron Job de Monitoramento

Agende o OpenClaw para rodar as verificações de saúde automaticamente:

# Every 5 minutes: quick check
openclaw cron add --name "quick-check" "*/5 * * * *" \
  "Run /home/openclaw/scripts/health-check.sh and analyze the output.
   
   CHECK FOR:
   1. Disk usage above 85% on any partition
   2. Memory usage above 90%
   3. CPU load average above 4.0 (for a 4-core server)
   4. Any service in STOPPED state
   5. SSL certificates expiring within 14 days
   
   IF everything is normal: Do nothing. No notification needed.
   
   IF an issue is detected:
   - Apply auto-fix if it matches the Auto-Fix Rules in SOUL.md
   - Log the fix to /var/log/openclaw-ops.log
   - Send a summary email via Inbounter to admin@company.com
   
   IF the issue requires escalation:
   - Send an URGENT email via Inbounter to admin@company.com
   - Include the full health check output and your diagnosis"

# Every hour: deeper analysis
openclaw cron add --name "hourly-analysis" "0 * * * *" \
  "Run a deeper analysis:
   1. Check /var/log/syslog for unusual patterns
   2. Check for failed SSH login attempts
   3. Verify all critical ports are responding
   4. Check if any process is consuming excessive resources
   5. Verify backup job completed (check /var/log/backup.log)
   
   Only notify if something unusual is found."

# Weekly report
openclaw cron add --name "weekly-health-report" "0 8 * * 0" \
  "Generate a weekly server health report:
   - Uptime statistics
   - Average resource usage
   - Auto-fixes performed this week
   - Escalations raised
   - Disk usage trend
   - Top 5 resource-consuming processes (average)
   
   Send the report via Inbounter to admin@company.com with subject
   'Weekly Server Health Report - [date]'"

Passo 4: Definir Procedimentos de Auto-Correção

Instrua o agente sobre passos específicos de remediação para problemas comuns.

Recuperação de Espaço em Disco

# Add to SOUL.md

### Disk Space Recovery Procedure
When disk usage exceeds 85%:

1. Check what is using space:
   `du -sh /var/log/* /tmp/* /var/cache/* | sort -rh | head -20`

2. Safe cleanup actions (in order):
   a. Clear apt cache: `sudo apt clean`
   b. Remove old kernels: `sudo apt autoremove -y`
   c. Clear journal logs: `sudo journalctl --vacuum-time=7d`
   d. Delete old log files: `sudo find /var/log -name "*.gz" -mtime +30 -delete`
   e. Clear /tmp: `sudo find /tmp -type f -mtime +7 -delete`
   f. Clear Docker unused images: `docker system prune -f` (if Docker is installed)

3. After cleanup, re-check disk usage.
4. If still above 90%, escalate to admin.

Reinicialização de Serviço

### Service Restart Procedure
When a service is in STOPPED state:

1. Check why it stopped: `journalctl -u [service] --since "1 hour ago" --no-pager | tail -30`
2. Attempt restart: `sudo systemctl restart [service]`
3. Wait 10 seconds, check status: `sudo systemctl status [service]`
4. If restart succeeds, log it and send notification
5. If restart fails:
   - Try once more after 30 seconds
   - If still failing, escalate to admin with the error logs
6. Track restart count: if a service restarts 3+ times in 1 hour, escalate

Renovação de Certificado SSL

### SSL Certificate Renewal
When a certificate expires within 14 days:

1. Attempt renewal: `sudo certbot renew --cert-name [domain]`
2. If successful, reload nginx: `sudo systemctl reload nginx`
3. Verify: `echo | openssl s_client -servername [domain] -connect [domain]:443 2>/dev/null | openssl x509 -noout -enddate`
4. If renewal fails, escalate with the certbot error output

Passo 5: Configurar Notificações por E-mail via Inbounter

Configure seu agente para enviar notificações através do Inbounter:

# config.yaml
notifications:
  email:
    provider: "inbounter"
    api_key: "${INBOUNTER_API_KEY}"
    default_to: "admin@company.com"
    from: "server-agent@yourdomain.com"

O agente usará a skill de e-mail para enviar notificações. Exemplos de prompts que ele gerará:

Notificação de auto-correção:

Subject: [Auto-Fix] Disk cleanup performed on production server

At 14:35 UTC, disk usage on /var reached 87%.

Actions taken:
- Cleared apt cache: freed 1.2 GB
- Removed old journals: freed 800 MB
- Deleted old log archives: freed 400 MB

Current disk usage: 62%

No further action needed.

Notificação de escalonamento:

Subject: [URGENT] PostgreSQL service crashed on production server

At 14:35 UTC, PostgreSQL was found in STOPPED state.

Diagnosis:
- Error log shows: "FATAL: could not map anonymous shared memory: Cannot allocate memory"
- System memory is at 94% usage
- Top process: java (PID 1234) using 6.2 GB RAM

Actions taken:
- Attempted restart: FAILED (same error)
- Second attempt after 30s: FAILED

Recommended actions:
1. Investigate the Java process (PID 1234) consuming excessive memory
2. Consider increasing server RAM or adding swap
3. Restart PostgreSQL after memory issue is resolved

Full health check output attached.

Passo 6: Logging e Trilha de Auditoria

Toda ação que o agente realiza deve ser registrada:

# Create the ops log
sudo touch /var/log/openclaw-ops.log
sudo chown openclaw:openclaw /var/log/openclaw-ops.log

Adicione ao SOUL.md:

### Logging
Before executing ANY command, log it:

echo "[$(date)] ACTION: [description] | CMD: [command]" >> /var/log/openclaw-ops.log

After execution, log the result:

echo "[$(date)] RESULT: [outcome]" >> /var/log/openclaw-ops.log

Exemplos de entradas de log:

[2026-04-05 14:35:12] ACTION: Disk cleanup - clearing apt cache | CMD: sudo apt clean
[2026-04-05 14:35:15] RESULT: Success - freed 1.2 GB
[2026-04-05 14:35:16] ACTION: Disk cleanup - clearing old journals | CMD: sudo journalctl --vacuum-time=7d
[2026-04-05 14:35:18] RESULT: Success - freed 800 MB
[2026-04-05 14:35:20] ACTION: Post-cleanup disk check | CMD: df -h /var
[2026-04-05 14:35:20] RESULT: /var at 62% - within acceptable range

Passo 7: Testar Sua Configuração

Simular Disco Cheio

# Create a large temporary file
dd if=/dev/zero of=/tmp/test-fill bs=1M count=5000

# Wait for the next health check (or trigger manually)
openclaw cron run --name "quick-check"

# Verify the agent detected and cleaned up
cat /var/log/openclaw-ops.log | tail -10

# Clean up test file
rm /tmp/test-fill

Simular Travamento de Serviço

# Stop a non-critical service
sudo systemctl stop redis

# Trigger health check
openclaw cron run --name "quick-check"

# Check if it was restarted
sudo systemctl status redis

Verificar Notificações por E-mail

# Trigger a test notification
openclaw run "Send a test notification email via Inbounter to admin@company.com 
  with subject 'Test: Self-Healing Server Alert' and body 
  'This is a test notification from your self-healing server setup.'"

Avançado: Monitoramento de Múltiplos Servidores

Se você gerencia múltiplos servidores, seu agente OpenClaw pode monitorá-los remotamente via SSH:

#!/bin/bash
# /home/openclaw/scripts/remote-health.sh

SERVERS=("web1:192.168.1.10" "web2:192.168.1.11" "db1:192.168.1.20")

for entry in "${SERVERS[@]}"; do
    name="${entry%%:*}"
    ip="${entry##*:}"
    echo "=== $name ($ip) ==="
    ssh -o ConnectTimeout=5 "openclaw@$ip" '/home/openclaw/scripts/health-check.sh' 2>/dev/null
    if [ $? -ne 0 ]; then
        echo "  CONNECTION FAILED"
    fi
    echo ""
done

openclaw cron add --name "multi-server-check" "*/10 * * * *" \
  "Run /home/openclaw/scripts/remote-health.sh and analyze all servers.
   Report any issues found, specifying which server has the problem."

Salvaguardas de Segurança

A auto-reparação é poderosa, mas perigosa se mal configurada. Implemente estas salvaguardas:

1. Limitar a Taxa de Auto-Correções

# SOUL.md
### Rate Limits
- Maximum 5 auto-fix actions per hour
- Maximum 3 service restarts per service per hour
- If limits exceeded, stop auto-fixing and escalate everything

2. Modo Dry Run

Teste sua configuração em modo dry-run primeiro:

# config.yaml
ops:
  dry_run: true  # Log what would be done without executing

3. Interruptor de Emergência

Se o agente começar a causar problemas, pare-o imediatamente:

openclaw cron pause --all
openclaw stop

4. Log de Desfazer

Registre informações suficientes para desfazer cada ação, se necessário:

# SOUL.md
### Undo Logging
For each auto-fix action, also log the undo command:

echo "[$(date)] UNDO: [undo command]" >> /var/log/openclaw-ops.log

Perguntas Frequentes

É seguro dar acesso sudo a um agente de IA?

Use regras de sudoers direcionadas em vez de sudo completo:

# /etc/sudoers.d/openclaw
openclaw ALL=(ALL) NOPASSWD: /usr/bin/apt clean
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart postgresql
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart redis
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --vacuum-*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/certbot renew *

Como evito que o agente piore as coisas?

Regras rígidas no SOUL.md, limites de taxa e uma lista de auto-correção conservadora. Comece apenas com a limpeza de disco e a reinicialização de serviços. Adicione mais correções gradualmente, conforme ganha confiança.

Posso usar isso para servidores de produção?

Sim, com cautela. Comece apenas com monitoramento (sem auto-correção) por 2 a 4 semanas. Revise os alertas. Depois habilite a auto-correção para as correções mais comuns e seguras.

Quanto isso custa em tokens de API?

Uma verificação de saúde a cada 5 minutos usa aproximadamente 3.000 tokens por verificação. Com o preço do Claude Sonnet, isso dá cerca de $3-5/mês. A maioria das verificações não encontrará nada de errado e usará menos tokens.

Posso combinar isso com monitoramento existente (Datadog, Grafana)?

Sim. Use o OpenClaw como a "camada de resposta inteligente" que recebe alertas do seu monitoramento existente e decide o que fazer. Encaminhe os alertas do Grafana para o OpenClaw via webhook.

E se o próprio agente cair?

Use um serviço externo de verificação de saúde (UptimeRobot, Healthchecks.io) para monitorar o endpoint de saúde do OpenClaw. Se ele cair, você é notificado de forma independente.