feat: import agents_and_robots platform as unibots (Matrix-out, unibus transport)
Reemplaza el scaffold del echobot por la plataforma completa de bots traida desde ~/DataProyects/Github/agents_and_robots tras la operacion Matrix-out: los bots ya no hablan por Matrix sino por el bus unibus (modelo todo-rooms + E2E via shell/transportunibus sobre github.com/enmanuel/unibus/pkg/client). - go.mod: replace de unibus -> ../unibus y de fn-registry -> ../../../.. (paths relativos reajustados a la nueva ubicacion dentro de fn_registry). - app.md: bump a 0.2.0, descripcion + arquitectura + comandos + gotchas reales. - modulo Go conservado como github.com/enmanuel/agents (sin reescribir imports). agents_and_robots queda archivado como museo de la era Matrix.
This commit is contained in:
agent
@@ -0,0 +1,96 @@
|
||||
# Sistema de Skills
|
||||
|
||||
Sistema de skills reutilizables para agentes Matrix. Las skills son paquetes de instrucciones, scripts y recursos que amplian las capacidades de un agente mas alla de las tools de function calling.
|
||||
|
||||
## Diferencia entre Tools y Skills
|
||||
|
||||
- **Tools** (`tools/`) — funciones atomicas que el LLM invoca via function calling (ssh_command, http_get, clock, etc.)
|
||||
- **Skills** (`skills/`) — flujos completos de trabajo multi-paso que combinan tools, logica condicional y conocimiento de dominio
|
||||
|
||||
Ejemplo:
|
||||
- Tool: `ssh_command` — ejecuta un comando SSH
|
||||
- Skill: `deploy-service` — usa ssh_command, http_get y logica para hacer un deploy completo
|
||||
|
||||
## Estructura de una skill
|
||||
|
||||
```
|
||||
skills/<categoria>/<skill-name>/
|
||||
├── SKILL.md ← obligatorio (frontmatter YAML + instrucciones markdown)
|
||||
├── LICENSE.txt ← opcional
|
||||
├── scripts/ ← opcional, codigo ejecutable (bash, python, etc.)
|
||||
├── references/ ← opcional, docs de referencia
|
||||
├── templates/ ← opcional, plantillas/assets
|
||||
└── assets/ ← opcional, fuentes, iconos, etc.
|
||||
```
|
||||
|
||||
### SKILL.md — formato
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: skill-name
|
||||
description: >
|
||||
Descripcion clara de que hace la skill y cuando debe activarse.
|
||||
Esta descripcion es el mecanismo principal de triggering.
|
||||
---
|
||||
|
||||
# Instrucciones
|
||||
|
||||
Cuerpo markdown con las instrucciones completas.
|
||||
Idealmente < 500 lineas.
|
||||
```
|
||||
|
||||
## Carga progresiva (3 niveles)
|
||||
|
||||
El sistema carga skills de forma progresiva para optimizar el uso del contexto del LLM:
|
||||
|
||||
1. **Metadata** (name + description) — siempre en contexto (~100 palabras). El agente la lee para decidir si activar la skill.
|
||||
2. **Cuerpo del SKILL.md** — se carga cuando la skill se activa. Instrucciones principales.
|
||||
3. **Recursos bundled** (scripts/, references/, etc.) — se cargan bajo demanda. El SKILL.md indica cuando leer cada archivo.
|
||||
|
||||
## Carpetas opcionales
|
||||
|
||||
| Carpeta | Proposito |
|
||||
|---------|-----------|
|
||||
| `scripts/` | Codigo ejecutable que el agente corre (bash, python). Puede ejecutarlos sin cargarlos en contexto. |
|
||||
| `references/` | Documentacion extensa, leida solo cuando es relevante. Si > 300 lineas, agregar TOC al inicio. |
|
||||
| `templates/` | Plantillas que la skill usa como base para generar outputs. |
|
||||
| `assets/` | Archivos estaticos (fuentes, iconos, imagenes). |
|
||||
|
||||
## Categorias de skills
|
||||
|
||||
- **`devops/`** — operaciones y deploy
|
||||
- **`analysis/`** — analisis de datos/logs
|
||||
- **`communication/`** — comunicacion y notificaciones
|
||||
- **`coding/`** — desarrollo y code review
|
||||
- **`system/`** — administracion del sistema
|
||||
|
||||
## Uso desde agentes
|
||||
|
||||
Los agentes pueden interactuar con skills via function calling:
|
||||
|
||||
1. **`skill_search`** — busca skills relevantes por query
|
||||
2. **`skill_load`** — carga instrucciones completas de una skill
|
||||
3. **`skill_read_resource`** — lee un recurso especifico (script, reference, template)
|
||||
4. **`skill_run_script`** — ejecuta un script de la skill con argumentos
|
||||
|
||||
## Configuracion
|
||||
|
||||
Las skills se configuran por agente en el YAML de configuracion:
|
||||
|
||||
```yaml
|
||||
skills:
|
||||
enabled: true
|
||||
path: "skills/"
|
||||
categories: ["devops", "system"] # filtro opcional
|
||||
```
|
||||
|
||||
## Seguridad
|
||||
|
||||
- Los scripts de skills tienen las mismas restricciones que ssh_command
|
||||
- Allowlist de interpreters permitidos (bash, python3, sh)
|
||||
- Timeout obligatorio en ejecucion
|
||||
- Sin acceso directo a secretos
|
||||
|
||||
## Crear nuevas skills
|
||||
|
||||
Ver `.claude/rules/create_skill.md` para la guia completa de creacion de skills.
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
name: log-analyzer
|
||||
description: >
|
||||
Analiza logs de servicios buscando patrones de errores, warnings y anomalias.
|
||||
Genera un resumen estructurado con metricas, errores frecuentes y recomendaciones.
|
||||
---
|
||||
|
||||
# Log Analyzer Skill
|
||||
|
||||
Esta skill analiza logs de servicios y genera reportes estructurados con hallazgos y recomendaciones.
|
||||
|
||||
## Casos de uso
|
||||
|
||||
- Analizar logs de un servicio que esta fallando
|
||||
- Buscar patrones de errores recurrentes
|
||||
- Generar metricas de salud de un servicio
|
||||
- Detectar anomalias en logs
|
||||
|
||||
## Proceso de analisis
|
||||
|
||||
### 1. Obtener los logs
|
||||
|
||||
Opciones:
|
||||
- Via SSH: `ssh_command` con `journalctl` o `tail`
|
||||
- Via HTTP: `http_get` si el servicio expone logs via API
|
||||
- Desde archivo local: `file_read` (si el agente tiene la tool)
|
||||
|
||||
Ejemplo con journalctl:
|
||||
```bash
|
||||
journalctl -u <service-name> --since "1 hour ago" -n 1000
|
||||
```
|
||||
|
||||
### 2. Parsear los logs
|
||||
|
||||
Identifica el formato de logs:
|
||||
- JSON estructurado
|
||||
- Formato de systemd
|
||||
- Logs planos con timestamp
|
||||
|
||||
Extrae campos clave:
|
||||
- Timestamp
|
||||
- Nivel de log (ERROR, WARN, INFO, DEBUG)
|
||||
- Mensaje
|
||||
- Stack traces (si aplica)
|
||||
|
||||
### 3. Analizar patrones
|
||||
|
||||
Busca:
|
||||
- Errores recurrentes (agrupa por mensaje similar)
|
||||
- Picos de actividad (timeframes con muchos logs)
|
||||
- Errores criticos (FATAL, PANIC, segfaults)
|
||||
- Timeouts y connection errors
|
||||
- Excepciones no manejadas
|
||||
|
||||
### 4. Generar metricas
|
||||
|
||||
Calcula:
|
||||
- Total de lineas analizadas
|
||||
- Conteo por nivel (ERROR, WARN, INFO)
|
||||
- Top 10 errores mas frecuentes
|
||||
- Timeline de errores (distribucion temporal)
|
||||
- Rate de errores (errores por minuto)
|
||||
|
||||
### 5. Generar reporte
|
||||
|
||||
Formato del reporte:
|
||||
|
||||
```markdown
|
||||
## Log Analysis Report
|
||||
|
||||
**Service**: <service-name>
|
||||
**Period**: <start> - <end>
|
||||
**Total lines**: <N>
|
||||
|
||||
### Metrics
|
||||
|
||||
- Errors: <N> (<percentage>%)
|
||||
- Warnings: <N> (<percentage>%)
|
||||
- Info: <N> (<percentage>%)
|
||||
- Error rate: <N> errors/min
|
||||
|
||||
### Top Errors
|
||||
|
||||
1. <error-message> (<N> occurrences)
|
||||
2. <error-message> (<N> occurrences)
|
||||
...
|
||||
|
||||
### Critical Issues
|
||||
|
||||
- <description>
|
||||
- <description>
|
||||
|
||||
### Recommendations
|
||||
|
||||
- <recommendation>
|
||||
- <recommendation>
|
||||
```
|
||||
|
||||
## Parametros requeridos
|
||||
|
||||
- `source`: "ssh", "http", o "file"
|
||||
- `service_name`: nombre del servicio (si source=ssh)
|
||||
- `host`: servidor (si source=ssh)
|
||||
- `log_url`: URL de logs (si source=http)
|
||||
- `file_path`: ruta al archivo (si source=file)
|
||||
- `timeframe`: "1 hour", "24 hours", "7 days", etc.
|
||||
|
||||
Parametros opcionales:
|
||||
- `filter`: patron regex para filtrar lineas
|
||||
- `max_lines`: limite de lineas a analizar (default: 10000)
|
||||
- `output_format`: "markdown" o "json"
|
||||
|
||||
## Ejemplo de uso
|
||||
|
||||
Usuario: "Analiza los logs de myapp en prod-server-01 de la ultima hora"
|
||||
|
||||
Agente:
|
||||
1. skill_search("analyze logs")
|
||||
2. skill_load("log-analyzer")
|
||||
3. ssh_command para obtener logs via journalctl
|
||||
4. Parsear y analizar logs
|
||||
5. Generar reporte markdown
|
||||
6. Enviar reporte al usuario
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: code-review
|
||||
description: >
|
||||
Revisa codigo fuente buscando bugs, problemas de seguridad, y mejoras.
|
||||
Usa esta skill cuando el usuario pida revisar un archivo, un diff, o
|
||||
cambios recientes en un repositorio. Tambien cuando pregunte "que opinas
|
||||
de este codigo" o "revisa esto".
|
||||
---
|
||||
|
||||
# Code review
|
||||
|
||||
## Prerequisitos
|
||||
|
||||
- Tool `ssh_command` o `read_file` para acceder al codigo
|
||||
- Contexto sobre el lenguaje y framework del proyecto
|
||||
|
||||
## Flujo
|
||||
|
||||
### 1. Obtener el codigo
|
||||
|
||||
Segun el contexto:
|
||||
|
||||
**Archivo especifico:**
|
||||
```bash
|
||||
read_file: "<ruta>"
|
||||
```
|
||||
|
||||
**Diff de cambios recientes:**
|
||||
```bash
|
||||
ssh_command: "cd <repo> && git diff HEAD~1"
|
||||
# o:
|
||||
ssh_command: "cd <repo> && git diff --staged"
|
||||
```
|
||||
|
||||
**PR o branch:**
|
||||
```bash
|
||||
ssh_command: "cd <repo> && git diff main..<branch>"
|
||||
```
|
||||
|
||||
### 2. Analisis
|
||||
|
||||
Revisar el codigo buscando:
|
||||
|
||||
**Bugs y errores logicos:**
|
||||
- Variables no inicializadas o no usadas
|
||||
- Condiciones de carrera (acceso concurrente sin mutex)
|
||||
- Nil/null pointer dereferences
|
||||
- Off-by-one errors
|
||||
- Resource leaks (archivos, conexiones no cerradas)
|
||||
|
||||
**Seguridad (OWASP top 10):**
|
||||
- Inyeccion SQL o de comandos
|
||||
- XSS, CSRF
|
||||
- Secretos hardcodeados
|
||||
- Permisos demasiado amplios
|
||||
- Input no validado
|
||||
|
||||
**Calidad:**
|
||||
- Funciones demasiado largas (> 50 lineas)
|
||||
- Duplicacion de codigo
|
||||
- Nombres poco claros
|
||||
- Complejidad innecesaria
|
||||
- Errores silenciados (catch vacio, err ignorado)
|
||||
|
||||
**Estilo y convenciones:**
|
||||
- Consistencia con el resto del codebase
|
||||
- Patrones del proyecto (ej: pure core / impure shell en este repo)
|
||||
|
||||
### 3. Reporte
|
||||
|
||||
Formato del review:
|
||||
|
||||
```markdown
|
||||
## Code Review — <archivo o scope>
|
||||
|
||||
### Critico
|
||||
- **[L42]** SQL injection: el parametro `userID` se concatena directamente en la query
|
||||
- **[L78]** Resource leak: `file` se abre pero nunca se cierra
|
||||
|
||||
### Mejoras sugeridas
|
||||
- **[L15-20]** Esta logica se repite en handler.go:45 — considerar extraer funcion
|
||||
- **[L33]** El error de `json.Unmarshal` se ignora silenciosamente
|
||||
|
||||
### Positivo
|
||||
- Buena separacion de responsabilidades
|
||||
- Tests cubren los casos principales
|
||||
|
||||
### Resumen
|
||||
X issues criticos, Y mejoras sugeridas. Prioridad: resolver los criticos antes de merge.
|
||||
```
|
||||
|
||||
### 4. Seguimiento
|
||||
|
||||
Si el usuario quiere aplicar las sugerencias:
|
||||
- Generar los patches concretos para cada issue
|
||||
- Aplicar cambios uno por uno con confirmacion
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
name: daily-report
|
||||
description: >
|
||||
Genera y envia un reporte diario con metricas de servicios, estado de salud,
|
||||
incidentes recientes y tareas pendientes. Puede enviarse via Matrix a un room
|
||||
especifico o guardarse como archivo.
|
||||
---
|
||||
|
||||
# Daily Report Skill
|
||||
|
||||
Esta skill genera reportes diarios automaticos consolidando informacion de multiples fuentes.
|
||||
|
||||
## Proposito
|
||||
|
||||
- Proveer visibilidad diaria del estado de servicios
|
||||
- Consolidar metricas de diferentes fuentes
|
||||
- Alertar sobre anomalias o degradacion
|
||||
- Tracking de incidentes y resoluciones
|
||||
|
||||
## Fuentes de datos
|
||||
|
||||
El reporte puede incluir datos de:
|
||||
- Estado de servicios (via SSH + systemctl)
|
||||
- Metricas HTTP (via health endpoints)
|
||||
- Analisis de logs (via log-analyzer skill)
|
||||
- Uso de recursos (CPU, memoria, disco via SSH)
|
||||
- Incidentes recientes (desde base de datos o API)
|
||||
|
||||
## Estructura del reporte
|
||||
|
||||
```markdown
|
||||
# Daily Report - <date>
|
||||
|
||||
## Services Status
|
||||
|
||||
| Service | Host | Status | Uptime |
|
||||
|---------|------|--------|--------|
|
||||
| myapp | prod-01 | running | 15d 3h |
|
||||
| worker | prod-02 | running | 2d 8h |
|
||||
|
||||
## Health Metrics
|
||||
|
||||
- Total requests: <N>
|
||||
- Error rate: <percentage>%
|
||||
- Avg response time: <N>ms
|
||||
- P99 latency: <N>ms
|
||||
|
||||
## Incidents
|
||||
|
||||
- [RESOLVED] Database connection timeout - 14:30 - Fixed by restarting pool
|
||||
- [OPEN] High memory usage on worker - Since 18:00
|
||||
|
||||
## Warnings
|
||||
|
||||
- Service X disk usage: 85%
|
||||
- Service Y error rate: 3.2% (threshold: 2%)
|
||||
|
||||
## System Resources
|
||||
|
||||
| Host | CPU | Memory | Disk |
|
||||
|------|-----|--------|------|
|
||||
| prod-01 | 45% | 62% | 71% |
|
||||
| prod-02 | 23% | 48% | 55% |
|
||||
|
||||
## Recommendations
|
||||
|
||||
- Investigate memory leak in worker service
|
||||
- Plan disk cleanup on prod-01
|
||||
|
||||
---
|
||||
Generated by <agent-name> at <timestamp>
|
||||
```
|
||||
|
||||
## Proceso de generacion
|
||||
|
||||
### 1. Recopilar datos de servicios
|
||||
|
||||
Para cada servicio configurado:
|
||||
```bash
|
||||
systemctl status <service> --no-pager
|
||||
```
|
||||
|
||||
Extrae: estado, uptime, ultimos logs
|
||||
|
||||
### 2. Verificar health endpoints
|
||||
|
||||
Si el servicio expone /health o /metrics:
|
||||
```bash
|
||||
http_get http://<host>:<port>/health
|
||||
```
|
||||
|
||||
### 3. Analizar logs recientes
|
||||
|
||||
Usa `log-analyzer` skill para cada servicio:
|
||||
- Ultimas 24h de logs
|
||||
- Conteo de errores/warnings
|
||||
- Errores criticos
|
||||
|
||||
### 4. Obtener metricas de sistema
|
||||
|
||||
```bash
|
||||
# CPU y memoria
|
||||
top -bn1 | head -20
|
||||
|
||||
# Disco
|
||||
df -h
|
||||
```
|
||||
|
||||
### 5. Consolidar y formatear
|
||||
|
||||
- Genera el markdown del reporte
|
||||
- Aplica template si existe (templates/daily-report.md)
|
||||
- Incluye timestamp y firma del agente
|
||||
|
||||
### 6. Enviar reporte
|
||||
|
||||
Opciones:
|
||||
- Enviar a Matrix room (via send_message)
|
||||
- Guardar como archivo (via file_write)
|
||||
- Enviar via email (si hay tool de email)
|
||||
|
||||
## Configuracion
|
||||
|
||||
El agente debe tener configurado:
|
||||
- Lista de servicios a monitorear
|
||||
- Hosts donde corren
|
||||
- Health endpoints (opcional)
|
||||
- Destination room o file path para el reporte
|
||||
|
||||
Ejemplo de config (en el agent config YAML):
|
||||
```yaml
|
||||
daily_report:
|
||||
services:
|
||||
- name: myapp
|
||||
host: prod-01
|
||||
health_url: http://localhost:8080/health
|
||||
- name: worker
|
||||
host: prod-02
|
||||
destination:
|
||||
type: matrix
|
||||
room_id: "!reportroom:matrix.org"
|
||||
schedule: "0 9 * * *" # 9am diario
|
||||
```
|
||||
|
||||
## Parametros
|
||||
|
||||
Parametros opcionales al ejecutar manualmente:
|
||||
- `date`: fecha del reporte (default: today)
|
||||
- `services`: lista de servicios a incluir (default: todos configurados)
|
||||
- `destination`: override del destino (room_id o file_path)
|
||||
- `include_recommendations`: true/false (default: true)
|
||||
|
||||
## Ejemplo de uso
|
||||
|
||||
Usuario: "Genera el reporte diario"
|
||||
|
||||
Agente:
|
||||
1. skill_search("daily report")
|
||||
2. skill_load("daily-report")
|
||||
3. Recopilar datos de todos los servicios configurados
|
||||
4. Generar markdown del reporte
|
||||
5. Enviar al room configurado o mostrar al usuario
|
||||
|
||||
## Automatizacion
|
||||
|
||||
Esta skill esta disenada para ejecutarse via cron. Ver `crons/daily-report/` para la configuracion de la automatizacion.
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
name: deploy-service
|
||||
description: >
|
||||
Deploy de un servicio via SSH a un servidor remoto. Verifica que el servicio
|
||||
este corriendo, hace backup de la version anterior, actualiza el binario,
|
||||
reinicia el servicio y valida que responda correctamente.
|
||||
---
|
||||
|
||||
# Deploy Service Skill
|
||||
|
||||
Esta skill guia el proceso completo de deploy de un servicio a produccion via SSH.
|
||||
|
||||
## Prerequisitos
|
||||
|
||||
- Acceso SSH al servidor de destino
|
||||
- El servicio debe estar configurado como systemd unit
|
||||
- El binario compilado debe estar disponible localmente o via URL
|
||||
|
||||
## Proceso de deploy
|
||||
|
||||
### 1. Verificar estado del servicio
|
||||
|
||||
Usa `ssh_command` para verificar el estado actual del servicio:
|
||||
|
||||
```bash
|
||||
systemctl status <service-name>
|
||||
```
|
||||
|
||||
Si el servicio no existe, pregunta al usuario si debe crearlo.
|
||||
|
||||
### 2. Crear backup de la version anterior
|
||||
|
||||
```bash
|
||||
cp /path/to/service /path/to/service.backup.$(date +%Y%m%d-%H%M%S)
|
||||
```
|
||||
|
||||
### 3. Detener el servicio
|
||||
|
||||
```bash
|
||||
systemctl stop <service-name>
|
||||
```
|
||||
|
||||
### 4. Actualizar el binario
|
||||
|
||||
Opciones:
|
||||
- Si el binario esta local: usa `scp` o `ssh_command` con heredoc
|
||||
- Si el binario esta en URL: usa `ssh_command` con `wget` o `curl`
|
||||
|
||||
```bash
|
||||
# Ejemplo con URL
|
||||
wget -O /path/to/service <binary-url>
|
||||
chmod +x /path/to/service
|
||||
```
|
||||
|
||||
### 5. Reiniciar el servicio
|
||||
|
||||
```bash
|
||||
systemctl start <service-name>
|
||||
```
|
||||
|
||||
### 6. Verificar que el servicio responde
|
||||
|
||||
Espera 5 segundos y verifica:
|
||||
|
||||
```bash
|
||||
systemctl is-active <service-name>
|
||||
```
|
||||
|
||||
Si el servicio expone un endpoint HTTP, usa `http_get` para verificar que responde:
|
||||
|
||||
```bash
|
||||
curl -f http://localhost:<port>/health
|
||||
```
|
||||
|
||||
### 7. Rollback en caso de error
|
||||
|
||||
Si el servicio no arranca o no responde:
|
||||
|
||||
1. Detener el servicio
|
||||
2. Restaurar el backup
|
||||
3. Reiniciar con la version anterior
|
||||
4. Notificar al usuario del error
|
||||
|
||||
## Parametros requeridos
|
||||
|
||||
El usuario debe proporcionar:
|
||||
- `host`: servidor de destino (ej: "prod-server-01")
|
||||
- `service_name`: nombre del systemd unit (ej: "myapp.service")
|
||||
- `service_path`: ruta al binario en el servidor (ej: "/usr/local/bin/myapp")
|
||||
- `binary_source`: "local" o URL del binario
|
||||
|
||||
Parametros opcionales:
|
||||
- `health_endpoint`: endpoint HTTP para verificar salud (ej: "http://localhost:8080/health")
|
||||
- `post_deploy_command`: comando adicional a ejecutar despues del deploy
|
||||
|
||||
## Seguridad
|
||||
|
||||
- Valida que el host este en la allowlist de SSH del agente
|
||||
- Valida que el binario tenga checksum correcto (si se proporciona)
|
||||
- Nunca ejecutes comandos arbitrarios sin validar
|
||||
|
||||
## Ejemplo de uso
|
||||
|
||||
Usuario: "Haz deploy de myapp a prod-server-01"
|
||||
|
||||
Agente:
|
||||
1. skill_search("deploy service")
|
||||
2. skill_load("deploy-service")
|
||||
3. Preguntar parametros faltantes
|
||||
4. Ejecutar el proceso paso a paso
|
||||
5. Reportar resultado
|
||||
@@ -0,0 +1,187 @@
|
||||
---
|
||||
name: health-check
|
||||
description: >
|
||||
Verifica la salud de servicios y sistemas. Valida que servicios esten corriendo,
|
||||
endpoints HTTP respondan, uso de recursos este dentro de limites, y no haya
|
||||
errores criticos en logs recientes.
|
||||
---
|
||||
|
||||
# Health Check Skill
|
||||
|
||||
Esta skill realiza verificaciones de salud completas de servicios y sistemas.
|
||||
|
||||
## Proposito
|
||||
|
||||
- Verificar que servicios criticos esten corriendo
|
||||
- Validar que endpoints HTTP respondan correctamente
|
||||
- Detectar uso excesivo de recursos (CPU, memoria, disco)
|
||||
- Identificar errores criticos en logs recientes
|
||||
- Generar reporte de salud con score y recomendaciones
|
||||
|
||||
## Verificaciones realizadas
|
||||
|
||||
### 1. Estado de servicios (systemd)
|
||||
|
||||
Para cada servicio configurado:
|
||||
```bash
|
||||
systemctl is-active <service-name>
|
||||
```
|
||||
|
||||
Estado esperado: `active`
|
||||
|
||||
### 2. Health endpoints HTTP
|
||||
|
||||
Si el servicio expone endpoint de salud:
|
||||
```bash
|
||||
http_get http://<host>:<port>/health
|
||||
```
|
||||
|
||||
Validaciones:
|
||||
- Status code: 200
|
||||
- Response time: < 1000ms
|
||||
- Body contiene: `"status": "ok"` (o similar)
|
||||
|
||||
### 3. Recursos del sistema
|
||||
|
||||
```bash
|
||||
# CPU usage
|
||||
top -bn1 | grep "Cpu(s)" | awk '{print $2}'
|
||||
|
||||
# Memory usage
|
||||
free -m | awk 'NR==2{printf "%.0f", $3*100/$2}'
|
||||
|
||||
# Disk usage
|
||||
df -h / | awk 'NR==2{print $5}' | sed 's/%//'
|
||||
```
|
||||
|
||||
Thresholds:
|
||||
- CPU: warning >70%, critical >90%
|
||||
- Memory: warning >80%, critical >95%
|
||||
- Disk: warning >85%, critical >95%
|
||||
|
||||
### 4. Logs recientes (ultimos 15 minutos)
|
||||
|
||||
```bash
|
||||
journalctl -u <service> --since "15 minutes ago" | grep -i "error\|fatal\|panic"
|
||||
```
|
||||
|
||||
Validacion: sin errores criticos en los ultimos 15 minutos
|
||||
|
||||
### 5. Conectividad de red (opcional)
|
||||
|
||||
Si el servicio depende de servicios externos:
|
||||
```bash
|
||||
# Test conectividad
|
||||
curl -f --max-time 5 http://<dependency-host>/health
|
||||
```
|
||||
|
||||
## Formato del reporte
|
||||
|
||||
```markdown
|
||||
# Health Check Report - <timestamp>
|
||||
|
||||
## Overall Health: <HEALTHY|DEGRADED|CRITICAL>
|
||||
|
||||
Score: <N>/100
|
||||
|
||||
## Service Status
|
||||
|
||||
| Service | Status | Health Endpoint | Response Time |
|
||||
|---------|--------|----------------|---------------|
|
||||
| myapp | running | OK (200) | 45ms |
|
||||
| worker | running | OK (200) | 32ms |
|
||||
|
||||
## System Resources
|
||||
|
||||
| Metric | Value | Status |
|
||||
|--------|-------|--------|
|
||||
| CPU Usage | 45% | OK |
|
||||
| Memory Usage | 62% | OK |
|
||||
| Disk Usage | 71% | OK |
|
||||
|
||||
## Issues Found
|
||||
|
||||
- None
|
||||
|
||||
## Warnings
|
||||
|
||||
- Disk usage on / approaching 75% threshold
|
||||
|
||||
## Recommendations
|
||||
|
||||
- Monitor disk usage trend
|
||||
- Consider log rotation policy
|
||||
|
||||
---
|
||||
Next check: <timestamp>
|
||||
```
|
||||
|
||||
## Score calculation
|
||||
|
||||
Score total (0-100):
|
||||
- Services running: 40 puntos (dividido entre servicios)
|
||||
- Health endpoints OK: 30 puntos (dividido entre endpoints)
|
||||
- Resources within limits: 20 puntos
|
||||
- No critical errors in logs: 10 puntos
|
||||
|
||||
Estado general:
|
||||
- HEALTHY: score >= 90
|
||||
- DEGRADED: score >= 70 && < 90
|
||||
- CRITICAL: score < 70
|
||||
|
||||
## Parametros
|
||||
|
||||
Parametros requeridos:
|
||||
- `services`: lista de servicios a verificar (default: todos configurados)
|
||||
|
||||
Parametros opcionales:
|
||||
- `include_resources`: verificar recursos del sistema (default: true)
|
||||
- `include_logs`: verificar logs recientes (default: true)
|
||||
- `log_timeframe`: ventana de logs a verificar (default: "15 minutes ago")
|
||||
- `output_format`: "markdown" o "json" (default: "markdown")
|
||||
|
||||
## Configuracion
|
||||
|
||||
Ejemplo de configuracion en agent YAML:
|
||||
|
||||
```yaml
|
||||
health_check:
|
||||
services:
|
||||
- name: myapp
|
||||
host: localhost
|
||||
health_url: http://localhost:8080/health
|
||||
dependencies:
|
||||
- http://db.example.com:5432
|
||||
- name: worker
|
||||
host: localhost
|
||||
health_url: http://localhost:8081/health
|
||||
thresholds:
|
||||
cpu_warning: 70
|
||||
cpu_critical: 90
|
||||
memory_warning: 80
|
||||
memory_critical: 95
|
||||
disk_warning: 85
|
||||
disk_critical: 95
|
||||
check_interval: "5m"
|
||||
```
|
||||
|
||||
## Ejemplo de uso
|
||||
|
||||
Usuario: "Verifica la salud de todos los servicios"
|
||||
|
||||
Agente:
|
||||
1. skill_search("health check")
|
||||
2. skill_load("health-check")
|
||||
3. Ejecutar verificaciones en orden
|
||||
4. Calcular score
|
||||
5. Generar reporte
|
||||
6. Enviar al usuario
|
||||
|
||||
## Alertas automaticas
|
||||
|
||||
Esta skill puede configurarse para ejecutarse periodicamente via cron y alertar solo si:
|
||||
- Score < 90 (DEGRADED o CRITICAL)
|
||||
- Algun servicio esta down
|
||||
- Recursos exceden threshold critico
|
||||
|
||||
Ver `crons/health-check/` para la configuracion de automatizacion.
|
||||
Reference in New Issue
Block a user