trailofbits/debug-buttercup

¿Qué hace debug-buttercup?

Depura el sistema de razonamiento cibernético (CRS) Buttercup que se ejecuta en Kubernetes. Utilízalo al diagnosticar caídas de pods, bucles de reinicio, fallos de Redis, presión de recursos, saturación de disco, problemas con DinD o cualquier mal funcionamiento de servicios en el namespace crs. Cubre triaje, análisis de logs, inspección de colas y patrones de fallo comunes para: redis, fuzzer-bot, coverage-bot, seed-gen, patcher, build-bot, scheduler, task-server, task-downloader, program-model, litellm, dind, tracer-bot, merger-bot, competition-api, pov-reproducer, scratch-cleaner, registry-cache, image-preloader, ui.

Triaje Inicial

1. Verificar el estado del clúster:

   kubectl get nodes -o wide
   kubectl describe nodes
   # Buscar presión de recursos (MemoryPressure, DiskPressure, PIDPressure)
   

2. Verificar el estado general del namespace crs:

   kubectl -n crs get all
   kubectl -n crs get pods -o wide
   # Identificar pods en estado CrashLoopBackOff, Error, ImagePullBackOff, etc.
   

3. Analizar logs de los pods problemáticos:

   kubectl -n crs logs <pod-name> --tail=100
   kubectl -n crs logs <pod-name> --previous # Si el pod se reinició
   

Diagnóstico por Servicio

Redis (redis)

• Síntoma: Caídas o lentitud.
• Acción:
  1. Obtener métricas de Redis desde dentro del clúster:

     kubectl -n crs exec -it <redis-pod> -- redis-cli INFO all
     

  2. Revisar el uso de memoria (métrica used_memory_human), número de conexiones (connected_clients) y eventos expulsados (evicted_keys).
  3. Buscar en los logs del pod de Redis errores de persistencia (RDB/AOF) o falta de memoria.

Fuzzer-Bot (fuzzer-bot)

• Síntoma: Pods atascados, no procesa trabajo.
• Acción:
  1. Inspeccionar la cola de trabajo en Redis:

     kubectl -n crs exec -it <redis-pod> -- redis-cli LLEN fuzzer_queue
     

  2. Revisar logs del pod en busca de timeouts de conexión a Redis o errores de inicialización.
  3. Verificar el consumo de CPU y memoria; puede necesitar más recursos.

Coverage-Bot (coverage-bot)

• Síntoma: No actualiza la cobertura o falla.
• Acción:
  1. Verificar la conectividad con el almacenamiento de cobertura (por ejemplo, un bucket S3 o un volumen compartido).
  2. Revisar logs en busca de errores de escritura o permisos.
  3. Confirmar que el agente de cobertura (por ejemplo, sancov) esté instalado y en la versión correcta.

Seed-Gen (seed-gen)

• Síntoma: No genera seeds o se cuelga.
• Acción:
  1. Verificar que el directorio de entrada/salida de seeds exista y tenga los permisos adecuados.
  2. Revisar logs en busca de errores relacionados con el motor de generación (por ejemplo, AFL++ o libFuzzer).
  3. Asegurarse de que los binarios necesarios estén compilados correctamente.

Patcher (patcher)

• Síntoma: Fallos al aplicar parches.
• Acción:
  1. Verificar la lógica del parche y los archivos de configuración.
  2. Revisar logs en busca de errores de compilación o enlace.
  3. Confirmar que el repositorio de código fuente esté accesible.

Build-Bot (build-bot)

• Síntoma: Fallos en la compilación de imágenes o binarios.
• Acción:
  1. Verificar el espacio en disco del nodo donde se ejecuta.
  2. Revisar logs de Docker dentro del contenedor (si usa DinD) o logs de Kaniko/buildkit.
  3. Comprobar la conectividad con el registro de contenedores.

Scheduler (scheduler)

• Síntoma: No asigna tareas.
• Acción:
  1. Inspeccionar la cola de tareas en Redis:

     kubectl -n crs exec -it <redis-pod> -- redis-cli LLEN task_queue
     

  2. Revisar logs en busca de excepciones o configuraciones inválidas.

DinD (Docker in Docker) (dind)

• Síntoma: Fallos al construir imágenes o ejecutar contenedores.
• Acción:
  1. Verificar el espacio en disco del nodo, especialmente en /var/lib/docker.
  2. Revisar logs del daemon de Docker dentro del pod DinD:

     kubectl -n crs exec -it <dind-pod> -- docker info
     

  3. Reiniciar el pod DinD si es necesario: kubectl -n crs delete pod <dind-pod>.

Otros Servicios

Para servicios como tracer-bot, merger-bot, competition-api, pov-reproducer, scratch-cleaner, registry-cache, image-preloader y ui, el enfoque general es:

1. Revisar logs con kubectl -n crs logs <pod-name>.
2. Verificar conectividad con otros servicios (Redis, bases de datos, APIs).
3. Inspeccionar patrones de fallo conocidos (por ejemplo, timeouts de red, permisos insuficientes).
4. Aumentar recursos (límites de CPU/memoria) si se observa presión de recursos.

Problemas Comunes

Presión de Recursos

• Síntoma: Múltiples pods en estado CrashLoopBackOff o con OOMKilled.
• Acción:
  1. Describir el nodo para verificar MemoryPressure, DiskPressure, etc.
  2. Ajustar límites de recursos en las definiciones de los deployments.
  3. Considerar escalar el clúster o rebalancear pods.

Saturación de Disco

• Síntoma: Pods no pueden escribir logs o datos temporales.
• Acción:
  1. Verificar el uso de disco en los nodos:

     kubectl top nodes
     

  2. Limpiar imágenes Docker no utilizadas o pods antiguos.
  3. Aumentar el tamaño del volumen si es necesario.

Fallos de Redis

• Síntoma: Servicios que dependen de Redis se comportan erráticamente.
• Acción:
  1. Conectarse a Redis y verificar la salud (PING).
  2. Inspeccionar el uso de memoria y la persistencia.
  3. Reiniciar el pod de Redis como último recurso.

Comandos Útiles

# Ver todos los pods del namespace
kubectl -n crs get pods

# Ver logs de un pod específico
kubectl -n crs logs <pod-name>

# Ejecutar un comando dentro de un pod
kubectl -n crs exec -it <pod-name> -- /bin/sh

# Describir un pod para ver eventos y recursos
kubectl -n crs describe pod <pod-name>

# Ver el uso de recursos del clúster
kubectl top pods -n crs
kubectl top nodes

Notas Adicionales

• Siempre que sea posible, intenta reproducir el fallo de forma aislada antes de escalar.
• Documenta cualquier hallazgo inusual para mejorar futuras iteraciones del sistema.
• Si no encuentras una solución obvia, verifica las integraciones de monitoreo (Prometheus, Grafana) para obtener más contexto.