feat: skills de ejemplo y README del sistema
Agregar 4 skills de ejemplo funcionales y README del sistema: Skills de ejemplo: - devops/deploy-service: deploy completo con rollback - analysis/log-analyzer: analisis de logs con metricas - communication/daily-report: reportes diarios automaticos - system/health-check: verificacion de salud multi-servicio Cada skill incluye: - SKILL.md con frontmatter YAML + instrucciones markdown - Descripcion de parametros y proceso paso a paso - Ejemplos de uso y consideraciones de seguridad skills/README.md documenta: - Diferencia entre tools (atomicas) y skills (flujos multi-paso) - Formato de SKILL.md y carga progresiva (3 niveles) - Categorias disponibles y uso desde agentes Las skills son contenido declarativo, no codigo Go.
This commit is contained in:
+69
-35
@@ -1,62 +1,96 @@
|
||||
# Skills
|
||||
# Sistema de Skills
|
||||
|
||||
Sistema de skills reutilizables para agentes. Las skills son paquetes de instrucciones, scripts y recursos que guian al agente para completar tareas complejas multi-paso.
|
||||
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 | Skills |
|
||||
|---|---|---|
|
||||
| **Nivel** | Funcion atomica | Flujo multi-paso |
|
||||
| **Invocacion** | Function calling del LLM | El agente busca y carga bajo demanda |
|
||||
| **Ejemplo** | `ssh_command`, `http_get` | "deploy-service", "log-analyzer" |
|
||||
| **Ubicacion** | `tools/<nombre>/` | `skills/<categoria>/<nombre>/` |
|
||||
- **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>/<nombre>/
|
||||
├── SKILL.md ← obligatorio (frontmatter YAML + instrucciones)
|
||||
├── scripts/ ← opcional, codigo ejecutable
|
||||
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/ ← opcional, archivos estaticos
|
||||
├── templates/ ← opcional, plantillas/assets
|
||||
└── assets/ ← opcional, fuentes, iconos, etc.
|
||||
```
|
||||
|
||||
## SKILL.md — formato
|
||||
### SKILL.md — formato
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: nombre-skill
|
||||
name: skill-name
|
||||
description: >
|
||||
Descripcion de que hace y cuando activarse.
|
||||
Descripcion clara de que hace la skill y cuando debe activarse.
|
||||
Esta descripcion es el mecanismo principal de triggering.
|
||||
---
|
||||
|
||||
# Instrucciones
|
||||
|
||||
Cuerpo markdown con instrucciones completas (< 500 lineas idealmente).
|
||||
Cuerpo markdown con las instrucciones completas.
|
||||
Idealmente < 500 lineas.
|
||||
```
|
||||
|
||||
## Carga progresiva
|
||||
## Carga progresiva (3 niveles)
|
||||
|
||||
1. **Metadata** (name + description) — siempre en contexto del agente
|
||||
2. **Instrucciones** (cuerpo SKILL.md) — cuando la skill se activa
|
||||
3. **Recursos** (scripts/, references/, etc.) — bajo demanda
|
||||
El sistema carga skills de forma progresiva para optimizar el uso del contexto del LLM:
|
||||
|
||||
## Categorias
|
||||
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.
|
||||
|
||||
| Categoria | Descripcion |
|
||||
|-----------|-------------|
|
||||
| `devops/` | Operaciones, deploy, infraestructura |
|
||||
| `analysis/` | Analisis de datos, logs, metricas |
|
||||
| `communication/` | Notificaciones, reportes, mensajeria |
|
||||
| `coding/` | Desarrollo, code review, refactoring |
|
||||
| `system/` | Administracion de sistemas, monitoreo |
|
||||
## Carpetas opcionales
|
||||
|
||||
## Crear una nueva skill
|
||||
| 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). |
|
||||
|
||||
1. Crear directorio: `skills/<categoria>/<nombre>/`
|
||||
2. Crear `SKILL.md` con frontmatter YAML (name + description) y cuerpo markdown
|
||||
3. Opcionalmente agregar scripts/, references/, templates/, assets/
|
||||
4. La skill estara disponible automaticamente para agentes con `skills.enabled: true`
|
||||
## Categorias de skills
|
||||
|
||||
Ver regla completa en `.claude/rules/create_skill.md` (pendiente).
|
||||
- **`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.
|
||||
|
||||
@@ -1,70 +1,123 @@
|
||||
---
|
||||
name: log-analyzer
|
||||
description: >
|
||||
Analiza logs de servicios para encontrar errores, patrones y anomalias.
|
||||
Usa esta skill cuando el usuario pida revisar logs, buscar errores en un
|
||||
servicio, diagnosticar problemas, o entender que paso en un periodo de tiempo.
|
||||
Funciona con journalctl, archivos de log, y logs de Docker.
|
||||
Analiza logs de servicios buscando patrones de errores, warnings y anomalias.
|
||||
Genera un resumen estructurado con metricas, errores frecuentes y recomendaciones.
|
||||
---
|
||||
|
||||
# Analisis de logs
|
||||
# Log Analyzer Skill
|
||||
|
||||
## Prerequisitos
|
||||
Esta skill analiza logs de servicios y genera reportes estructurados con hallazgos y recomendaciones.
|
||||
|
||||
- Tool `ssh_command` habilitada (para logs remotos)
|
||||
- Acceso al servidor donde estan los logs
|
||||
## Casos de uso
|
||||
|
||||
## Flujo
|
||||
- Analizar logs de un servicio que esta fallando
|
||||
- Buscar patrones de errores recurrentes
|
||||
- Generar metricas de salud de un servicio
|
||||
- Detectar anomalias en logs
|
||||
|
||||
### 1. Identificar fuente de logs
|
||||
## Proceso de analisis
|
||||
|
||||
Preguntar o inferir del contexto:
|
||||
- **Servicio**: nombre del servicio o contenedor
|
||||
- **Periodo**: rango de tiempo a analizar (default: ultima hora)
|
||||
- **Servidor**: host donde corren los logs
|
||||
- **Tipo**: systemd (journalctl), archivo (/var/log/...), o Docker
|
||||
### 1. Obtener los logs
|
||||
|
||||
### 2. Obtener 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)
|
||||
|
||||
Segun el tipo de fuente:
|
||||
|
||||
**Systemd (journalctl):**
|
||||
Ejemplo con journalctl:
|
||||
```bash
|
||||
ssh_command: "journalctl -u <servicio> --since '<periodo>' --no-pager"
|
||||
journalctl -u <service-name> --since "1 hour ago" -n 1000
|
||||
```
|
||||
|
||||
**Archivo de log:**
|
||||
```bash
|
||||
ssh_command: "tail -n 500 /var/log/<servicio>/<archivo>.log"
|
||||
# o con filtro de tiempo:
|
||||
ssh_command: "awk '/2024-01-15 14:00/,/2024-01-15 15:00/' /var/log/<servicio>.log"
|
||||
### 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>
|
||||
```
|
||||
|
||||
**Docker:**
|
||||
```bash
|
||||
ssh_command: "docker logs --since <periodo> <contenedor> 2>&1 | tail -500"
|
||||
```
|
||||
## Parametros requeridos
|
||||
|
||||
### 3. Analisis
|
||||
- `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.
|
||||
|
||||
Buscar en los logs:
|
||||
- **Errores**: lineas con ERROR, FATAL, panic, exception, traceback
|
||||
- **Warnings**: lineas con WARN, warning
|
||||
- **Patrones repetitivos**: errores que se repiten (agrupar por tipo)
|
||||
- **Timestamps**: cuando empezaron los problemas
|
||||
- **Correlaciones**: errores que ocurren juntos o en secuencia
|
||||
Parametros opcionales:
|
||||
- `filter`: patron regex para filtrar lineas
|
||||
- `max_lines`: limite de lineas a analizar (default: 10000)
|
||||
- `output_format`: "markdown" o "json"
|
||||
|
||||
### 4. Reporte
|
||||
## Ejemplo de uso
|
||||
|
||||
Presentar al usuario:
|
||||
1. **Resumen**: estado general (saludable / con problemas / critico)
|
||||
2. **Errores encontrados**: listado agrupado por tipo con conteo
|
||||
3. **Timeline**: cuando empezaron y si siguen ocurriendo
|
||||
4. **Causa probable**: si se puede inferir del contexto
|
||||
5. **Recomendacion**: accion sugerida (restart, fix config, escalar, etc.)
|
||||
Usuario: "Analiza los logs de myapp en prod-server-01 de la ultima hora"
|
||||
|
||||
## Tips
|
||||
|
||||
- Si los logs son muy extensos, obtener primero un conteo de errores y luego los detalles de los mas frecuentes
|
||||
- Usar `grep -c` para contar antes de traer lineas completas
|
||||
- Para logs grandes, usar `tail` o rangos de tiempo acotados
|
||||
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
|
||||
|
||||
@@ -1,84 +1,166 @@
|
||||
---
|
||||
name: daily-report
|
||||
description: >
|
||||
Genera y envia un reporte diario con el estado de servicios, metricas clave
|
||||
y eventos relevantes. Usa esta skill cuando el usuario pida un resumen del
|
||||
dia, estado general de los sistemas, o un reporte periodico. Tambien puede
|
||||
activarse automaticamente via schedule.
|
||||
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.
|
||||
---
|
||||
|
||||
# Reporte diario
|
||||
# Daily Report Skill
|
||||
|
||||
## Prerequisitos
|
||||
Esta skill genera reportes diarios automaticos consolidando informacion de multiples fuentes.
|
||||
|
||||
- Tool `ssh_command` para consultar estado de servicios
|
||||
- Tool `http_get` para health checks
|
||||
- Tool `matrix_send` para enviar el reporte a una room
|
||||
## Proposito
|
||||
|
||||
## Flujo
|
||||
- Proveer visibilidad diaria del estado de servicios
|
||||
- Consolidar metricas de diferentes fuentes
|
||||
- Alertar sobre anomalias o degradacion
|
||||
- Tracking de incidentes y resoluciones
|
||||
|
||||
### 1. Recopilar datos
|
||||
## Fuentes de datos
|
||||
|
||||
Ejecutar en paralelo cuando sea posible:
|
||||
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)
|
||||
|
||||
**Estado de servicios:**
|
||||
```bash
|
||||
ssh_command: "systemctl list-units --type=service --state=running --no-pager | grep -E '<servicios>'"
|
||||
ssh_command: "systemctl list-units --type=service --state=failed --no-pager"
|
||||
```
|
||||
|
||||
**Uso de recursos:**
|
||||
```bash
|
||||
ssh_command: "df -h / | tail -1"
|
||||
ssh_command: "free -h | grep Mem"
|
||||
ssh_command: "uptime"
|
||||
```
|
||||
|
||||
**Errores recientes:**
|
||||
```bash
|
||||
ssh_command: "journalctl --priority=err --since '24 hours ago' --no-pager | wc -l"
|
||||
ssh_command: "journalctl --priority=err --since '24 hours ago' --no-pager | tail -10"
|
||||
```
|
||||
|
||||
**Health checks HTTP:**
|
||||
```
|
||||
http_get: "<url>/health" para cada servicio con endpoint
|
||||
```
|
||||
|
||||
### 2. Formatear reporte
|
||||
|
||||
Generar markdown con:
|
||||
## Estructura del reporte
|
||||
|
||||
```markdown
|
||||
## Reporte diario — <fecha>
|
||||
# Daily Report - <date>
|
||||
|
||||
### Estado de servicios
|
||||
| Servicio | Estado | Uptime |
|
||||
|----------|--------|--------|
|
||||
| servicio-1 | OK | 5d 3h |
|
||||
| servicio-2 | FAILED | - |
|
||||
## Services Status
|
||||
|
||||
### Recursos
|
||||
- **Disco**: 45% usado (55GB libres)
|
||||
- **Memoria**: 3.2GB / 8GB (40%)
|
||||
- **Load average**: 0.5, 0.3, 0.2
|
||||
| Service | Host | Status | Uptime |
|
||||
|---------|------|--------|--------|
|
||||
| myapp | prod-01 | running | 15d 3h |
|
||||
| worker | prod-02 | running | 2d 8h |
|
||||
|
||||
### Errores (ultimas 24h)
|
||||
- Total: 15 errores
|
||||
- Mas frecuente: "connection timeout" (8 veces)
|
||||
## Health Metrics
|
||||
|
||||
### Alertas
|
||||
- servicio-2 esta caido desde las 14:30
|
||||
- Disco al 85% en /var/log (limpiar)
|
||||
- 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>
|
||||
```
|
||||
|
||||
### 3. Enviar
|
||||
## Proceso de generacion
|
||||
|
||||
Enviar el reporte formateado a la room configurada o a la room donde fue solicitado.
|
||||
### 1. Recopilar datos de servicios
|
||||
|
||||
## Personalizacion
|
||||
Para cada servicio configurado:
|
||||
```bash
|
||||
systemctl status <service> --no-pager
|
||||
```
|
||||
|
||||
El reporte puede adaptarse segun:
|
||||
- Lista de servicios a monitorear (del config del agente)
|
||||
- Servidores a consultar (de ssh.allowed_targets)
|
||||
- Umbrales de alerta (disco > 80%, memoria > 90%, etc.)
|
||||
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.
|
||||
|
||||
@@ -1,89 +1,111 @@
|
||||
---
|
||||
name: deploy-service
|
||||
description: >
|
||||
Despliega un servicio en un servidor remoto via SSH. Usa esta skill cuando
|
||||
el usuario pida hacer deploy, actualizar un servicio, o subir cambios a
|
||||
produccion/staging. Cubre: pull de codigo, build, restart del servicio,
|
||||
y verificacion post-deploy.
|
||||
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 de servicio via SSH
|
||||
# Deploy Service Skill
|
||||
|
||||
Esta skill guia el proceso completo de deploy de un servicio a produccion via SSH.
|
||||
|
||||
## Prerequisitos
|
||||
|
||||
- El agente debe tener la tool `ssh_command` habilitada
|
||||
- El servidor destino debe estar configurado en `ssh.allowed_targets`
|
||||
- El usuario debe tener permisos de deploy (verificar roles si RBAC esta activo)
|
||||
- Acceso SSH al servidor de destino
|
||||
- El servicio debe estar configurado como systemd unit
|
||||
- El binario compilado debe estar disponible localmente o via URL
|
||||
|
||||
## Flujo
|
||||
## Proceso de deploy
|
||||
|
||||
### 1. Confirmar parametros
|
||||
### 1. Verificar estado del servicio
|
||||
|
||||
Antes de ejecutar, confirmar con el usuario:
|
||||
- **Servicio**: nombre del servicio a desplegar
|
||||
- **Servidor**: host destino (debe estar en allowed_targets)
|
||||
- **Branch/tag**: rama o tag a desplegar (default: main)
|
||||
- **Ruta**: directorio del servicio en el servidor
|
||||
|
||||
### 2. Pre-checks
|
||||
|
||||
Ejecutar en el servidor remoto:
|
||||
```bash
|
||||
# Verificar conectividad
|
||||
ssh_command: "echo 'OK'" en el host destino
|
||||
|
||||
# Verificar que el directorio existe
|
||||
ssh_command: "test -d /path/to/service && echo 'exists'"
|
||||
|
||||
# Verificar estado actual del servicio
|
||||
ssh_command: "systemctl is-active nombre-servicio || true"
|
||||
```
|
||||
|
||||
Si algun pre-check falla, informar al usuario y no continuar.
|
||||
|
||||
### 3. Deploy
|
||||
|
||||
Ejecutar secuencialmente:
|
||||
```bash
|
||||
# Pull de cambios
|
||||
ssh_command: "cd /path/to/service && git fetch origin && git checkout <branch> && git pull"
|
||||
|
||||
# Build (si aplica)
|
||||
ssh_command: "cd /path/to/service && make build"
|
||||
# o: "cd /path/to/service && go build -o bin/service ./cmd/..."
|
||||
# o: "cd /path/to/service && docker-compose build"
|
||||
|
||||
# Restart del servicio
|
||||
ssh_command: "sudo systemctl restart nombre-servicio"
|
||||
```
|
||||
|
||||
### 4. Verificacion post-deploy
|
||||
Usa `ssh_command` para verificar el estado actual del servicio:
|
||||
|
||||
```bash
|
||||
# Esperar 5 segundos para que el servicio arranque
|
||||
ssh_command: "sleep 5 && systemctl is-active nombre-servicio"
|
||||
|
||||
# Verificar logs recientes (buscar errores)
|
||||
ssh_command: "journalctl -u nombre-servicio --since '1 min ago' --no-pager | tail -20"
|
||||
|
||||
# Health check HTTP si aplica
|
||||
http_get: "http://servidor:puerto/health"
|
||||
systemctl status <service-name>
|
||||
```
|
||||
|
||||
### 5. Reportar resultado
|
||||
Si el servicio no existe, pregunta al usuario si debe crearlo.
|
||||
|
||||
Informar al usuario:
|
||||
- Estado del deploy (exitoso/fallido)
|
||||
- Version desplegada (commit hash o tag)
|
||||
- Estado del servicio post-deploy
|
||||
- Cualquier warning en los logs
|
||||
### 2. Crear backup de la version anterior
|
||||
|
||||
## Rollback
|
||||
|
||||
Si el deploy falla o el servicio no arranca:
|
||||
```bash
|
||||
ssh_command: "cd /path/to/service && git checkout <commit-anterior>"
|
||||
ssh_command: "sudo systemctl restart nombre-servicio"
|
||||
cp /path/to/service /path/to/service.backup.$(date +%Y%m%d-%H%M%S)
|
||||
```
|
||||
|
||||
Informar al usuario que se hizo rollback y el motivo.
|
||||
### 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
|
||||
|
||||
@@ -1,95 +1,187 @@
|
||||
---
|
||||
name: health-check
|
||||
description: >
|
||||
Verifica la salud de uno o varios servicios y servidores. Usa esta skill
|
||||
cuando el usuario pregunte si algo esta funcionando, si un servicio esta
|
||||
arriba, o pida un chequeo de salud general. Tambien util despues de un
|
||||
deploy o un incidente.
|
||||
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 de servicios
|
||||
# Health Check Skill
|
||||
|
||||
## Prerequisitos
|
||||
Esta skill realiza verificaciones de salud completas de servicios y sistemas.
|
||||
|
||||
- Tool `ssh_command` habilitada
|
||||
- Tool `http_get` para endpoints HTTP
|
||||
- Servidores en `ssh.allowed_targets`
|
||||
## Proposito
|
||||
|
||||
## Flujo
|
||||
- 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
|
||||
|
||||
### 1. Determinar alcance
|
||||
## Verificaciones realizadas
|
||||
|
||||
Inferir del contexto del usuario:
|
||||
- **Servicio especifico**: checkear solo ese servicio
|
||||
- **Servidor especifico**: checkear todos los servicios en ese servidor
|
||||
- **General**: checkear todos los servidores y servicios conocidos
|
||||
### 1. Estado de servicios (systemd)
|
||||
|
||||
### 2. Checks basicos por servidor
|
||||
|
||||
Para cada servidor:
|
||||
Para cada servicio configurado:
|
||||
```bash
|
||||
# Conectividad
|
||||
ssh_command: "echo OK"
|
||||
|
||||
# Uptime y load
|
||||
ssh_command: "uptime"
|
||||
|
||||
# Disco
|
||||
ssh_command: "df -h / /var /tmp 2>/dev/null | tail -n +2"
|
||||
|
||||
# Memoria
|
||||
ssh_command: "free -m | grep -E 'Mem|Swap'"
|
||||
|
||||
# Procesos zombie o en estado D
|
||||
ssh_command: "ps aux | awk '{if ($8 ~ /Z|D/) print}' | head -5"
|
||||
systemctl is-active <service-name>
|
||||
```
|
||||
|
||||
### 3. Checks por servicio
|
||||
Estado esperado: `active`
|
||||
|
||||
Para cada servicio:
|
||||
### 2. Health endpoints HTTP
|
||||
|
||||
Si el servicio expone endpoint de salud:
|
||||
```bash
|
||||
# Estado systemd
|
||||
ssh_command: "systemctl is-active <servicio>"
|
||||
|
||||
# Tiempo activo
|
||||
ssh_command: "systemctl show <servicio> --property=ActiveEnterTimestamp --value"
|
||||
|
||||
# Puertos abiertos
|
||||
ssh_command: "ss -tlnp | grep <puerto>"
|
||||
|
||||
# Ultimos errores
|
||||
ssh_command: "journalctl -u <servicio> --priority=err --since '1 hour ago' --no-pager | tail -5"
|
||||
http_get http://<host>:<port>/health
|
||||
```
|
||||
|
||||
**Health check HTTP** (si tiene endpoint):
|
||||
```
|
||||
http_get: "http://<host>:<puerto>/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/%//'
|
||||
```
|
||||
|
||||
### 4. Evaluar y reportar
|
||||
Thresholds:
|
||||
- CPU: warning >70%, critical >90%
|
||||
- Memory: warning >80%, critical >95%
|
||||
- Disk: warning >85%, critical >95%
|
||||
|
||||
Clasificar cada componente:
|
||||
### 4. Logs recientes (ultimos 15 minutos)
|
||||
|
||||
| Estado | Criterio |
|
||||
|--------|----------|
|
||||
| OK | Servicio activo, sin errores recientes, recursos normales |
|
||||
| WARNING | Servicio activo pero con errores recientes, o recursos > 80% |
|
||||
| CRITICAL | Servicio caido, disco lleno, o memoria agotada |
|
||||
|
||||
Reportar al usuario con formato claro:
|
||||
```
|
||||
Health Check — <fecha hora>
|
||||
|
||||
[OK] servidor-1: load 0.3, disco 45%, mem 40%
|
||||
[OK] servicio-a: activo (uptime 5d), 0 errores
|
||||
[WARNING] servicio-b: activo, 3 errores en ultima hora
|
||||
[CRITICAL] servidor-2: no responde SSH
|
||||
```bash
|
||||
journalctl -u <service> --since "15 minutes ago" | grep -i "error\|fatal\|panic"
|
||||
```
|
||||
|
||||
### 5. Recomendaciones
|
||||
Validacion: sin errores criticos en los ultimos 15 minutos
|
||||
|
||||
Si hay problemas, sugerir acciones:
|
||||
- Servicio caido → "Intentar restart: `systemctl restart <servicio>`"
|
||||
- Disco lleno → "Limpiar logs antiguos o expandir disco"
|
||||
- Memoria alta → "Revisar procesos con mayor consumo"
|
||||
- Errores frecuentes → "Revisar logs con la skill log-analyzer"
|
||||
### 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