UD5 · Resolución de incidencias en plataformas de IA

Objetivos de aprendizaje

Al finalizar esta unidad, el alumno sera capaz de:

• Clasificar los tipos de incidencias que afectan a plataformas de IA y documentar correctamente los sintomas
• Analizar logs del sistema, de CUDA y de los frameworks de IA para diagnosticar la causa raiz de una incidencia
• Utilizar herramientas de monitorizacion (nvidia-smi, nvtop, htop, Prometheus) para identificar cuellos de botella
• Resolver incidencias de hardware GPU, instalacion, configuracion y aplicaciones siguiendo procedimientos estructurados
• Sustituir componentes averiados aplicando las medidas de seguridad correctas (ESD, validacion post-sustitucion)
• Priorizar incidencias segun su impacto y comunicar el estado de forma clara a los usuarios y al equipo tecnico

Resultado de aprendizaje: Resuelve incidencias de explotacion garantizando el funcionamiento segun los niveles de servicio establecidos.

Tipos de incidencias en plataformas de IA (I)

Clasificacion por categoria

Tipos de incidencias en plataformas de IA (II)

Impacto segun categoria

Nota: la prioridad puede verse afectada por el SLA contractual con el cliente, el horario (incidencia fuera de horas laborables puede ser P2 aunque en horario seria P1) y el numero de usuarios afectados.

Proceso de identificacion de la incidencia (I)

Documentar antes de actuar

El error mas comun en la gestion de incidencias es intentar resolver antes de haber comprendido completamente el problema. Un diagnostico incompleto genera soluciones erroneas que pueden agravar la situacion.

Que documentar al abrir una incidencia:

Proceso de identificacion de la incidencia (II)

Reproduccion controlada del comportamiento

# 1. Identificar la version exacta del entorno
uname -r                                    # version del kernel
nvidia-smi                                  # version del driver y CUDA
python --version
pip show torch transformers triton 2>/dev/null | grep -E "^Name|^Version"

# 2. Intentar reproducir el error de forma minima
# Si el error es "CUDA out of memory" durante inferencia:
python -c "
import torch
model = torch.load('/models/mi_modelo.pt', map_location='cuda:0')
x = torch.randn(1, 3, 224, 224, device='cuda:0')  # batch=1, sin presion
with torch.no_grad():
    out = model(x)
print('Inferencia OK:', out.shape)
"

# 3. Capturar el traceback completo para el ticket
python mi_script.py 2>&1 | tee /tmp/incidencia_20240615_traceback.txt

# 4. Recoger informacion del sistema en el momento del fallo
nvidia-smi -q > /tmp/incidencia_20240615_nvidia.txt
free -h >> /tmp/incidencia_20240615_nvidia.txt
df -h >> /tmp/incidencia_20240615_nvidia.txt

Herramientas de analisis de logs (I)

Logs del sistema operativo

# --- JOURNALCTL: logs del sistema con systemd ---

# Ver los ultimos 100 errores del sistema
sudo journalctl -p err -n 100

# Ver logs de las ultimas 2 horas filtrando por errores de NVIDIA
sudo journalctl --since "2 hours ago" | grep -i "nvidia\|cuda\|gpu"

# Ver logs de un servicio especifico en tiempo real
sudo journalctl -u triton-server -f

# Ver logs desde el ultimo arranque del sistema
sudo journalctl -b 0

# --- DMESG: mensajes del kernel ---

# Ver todos los mensajes del kernel relacionados con GPU
sudo dmesg | grep -i "nvidia\|NVRM\|cuda"

# Ejemplo de error critico en dmesg:
# NVRM: GPU at PCI:0000:01:00: GPU-a2b3c4d5-e6f7-...
# NVRM: GPU Board Serial Number: [not supported]
# NVRM: Xid (PCI:0000:01:00): 79, pid='<unknown>', ...
# (Xid 79 = GPU fallen off the bus — fallo hardware grave)

# --- SYSLOG ---
sudo tail -f /var/log/syslog | grep -i "error\|warn\|nvidia"

Herramientas de analisis de logs (II)

Logs de CUDA y frameworks de IA

# --- NVIDIA BUG REPORT: recoleccion completa de informacion ---
# Genera un informe comprimido con toda la informacion del sistema NVIDIA
sudo nvidia-bug-report.sh
# Genera: nvidia-bug-report.log.gz en el directorio actual

# --- PYTORCH: activar logs de depuracion ---
# Variable de entorno para logs detallados de CUDA
TORCH_CPP_LOG_LEVEL=INFO python mi_script.py

# Logs de NCCL (comunicacion multi-GPU)
NCCL_DEBUG=INFO python mi_script_multigpu.py 2>&1 | grep "NCCL"

# --- TRITON INFERENCE SERVER ---
# Logs del servidor con nivel de detalle maximo
tritonserver --model-repository=/models --log-verbose=1 \
  --log-info=true --log-warning=true --log-error=true \
  2>&1 | tee /logs/triton_$(date +%Y%m%d).log

# Filtrar solo errores en los logs de Triton
grep -E "error|failed|FAILED" /logs/triton_20240615.log

# --- CUDA ERROR CODES en el traceback de Python ---
# RuntimeError: CUDA error: device-side assert triggered
#   → Indica error en el kernel CUDA, normalmente por input fuera de rango
# RuntimeError: CUDA out of memory.
#   → VRAM insuficiente para la operacion solicitada
# RuntimeError: CUDA error: no kernel image is available for execution on the device
#   → El binario compilado no es compatible con la arquitectura de la GPU

Herramientas de monitorizacion (I)

Monitorizacion de GPU y sistema

# Instalacion de nvtop
sudo apt install nvtop

# nvidia-smi en modo de monitorizacion continua (refresco cada 1 s)
nvidia-smi -l 1

# Exportar metricas GPU en formato CSV para analisis posterior
nvidia-smi --query-gpu=timestamp,name,temperature.gpu,utilization.gpu,\
utilization.memory,memory.used,memory.free,power.draw \
--format=csv -l 5 >> /tmp/gpu_metrics.csv

Herramientas de monitorizacion (II)

Prometheus y Grafana para GPU — comandos clave

# Verificar que el exporter de NVIDIA Prometheus esta activo
systemctl status dcgm-exporter
# o alternativamente:
systemctl status nvidia-smi-exporter

# Consultar metricas GPU desde Prometheus (ejemplo con curl)
curl -s http://localhost:9090/api/v1/query \
  --data-urlencode 'query=DCGM_FI_DEV_GPU_TEMP' | python -m json.tool

# Metricas DCGM clave a monitorizar en Grafana:
# DCGM_FI_DEV_GPU_TEMP          → temperatura GPU (C)
# DCGM_FI_DEV_GPU_UTIL          → utilizacion GPU (%)
# DCGM_FI_DEV_MEM_COPY_UTIL     → utilizacion memoria (%)
# DCGM_FI_DEV_FB_USED           → VRAM usada (MB)
# DCGM_FI_DEV_POWER_USAGE       → potencia (W)
# DCGM_FI_DEV_SM_CLOCK          → frecuencia del SM (MHz)
# DCGM_FI_DEV_XID_ERRORS        → errores Xid (indica fallos hardware)

# Verificar estado de la red de un nodo de GPU cluster
ss -tulnp | grep -E "8000|8001|8002"   # puertos Triton HTTP/gRPC/Metrics
netstat -i                              # estadisticas de interfaz (paquetes perdidos)

Diagnostico de incidencias de hardware GPU (I)

Sintomas comunes y comandos de diagnostico

# Ver todos los errores Xid de la GPU (historico completo)
sudo dmesg | grep "Xid"

# Xid mas relevantes:
# Xid 13: Graph engine exception — posible fallo de kernel CUDA
# Xid 31: GPU memory page fault
# Xid 48: Double Bit ECC Error (DBE) — celula de VRAM corrupta
# Xid 63: Row remapper recording pending
# Xid 79: GPU fallen off the bus — fallo hardware grave
# Xid 94: Contained channel error — GPU puede seguir funcionando

# Ver el estado completo de ECC
nvidia-smi -q -d ECC | grep -A5 "Aggregate"

Diagnostico de incidencias de hardware GPU (II)

Acciones correctivas por tipo de fallo

# --- CUDA OOM: reducir el uso de VRAM ---
# Opcion 1: reducir el tamano del batch en el cliente
# Opcion 2: activar fp16 o int8 en el servidor de inferencia
# Opcion 3: liberar cache de PyTorch desde el proceso
python -c "import torch; torch.cuda.empty_cache(); print('Cache limpiada')"

# Verificar que no hay procesos zombis ocupando VRAM
nvidia-smi --query-compute-apps=pid,process_name,used_memory \
  --format=csv,noheader,nounits
# Matar un proceso que retiene VRAM innecesariamente
sudo kill -9 <PID>

# --- GPU NO DETECTADA: verificar a nivel de bus ---
# Ver si la GPU aparece en el bus PCIe aunque el driver no la vea
lspci -nn | grep -i "NVIDIA\|VGA\|3D"

# Recargar el modulo del kernel de NVIDIA sin reiniciar
sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia
sudo modprobe nvidia
nvidia-smi

# --- ERRORES ECC: retirar la GPU si los errores son uncorrectable ---
# Verificar si los errores ECC son corregibles (singlebit) o no corregibles (doublebit)
nvidia-smi -q -d ECC | grep -i "double\|uncorrectable"
# Si hay errores double-bit no corregibles → sustituir la GPU

Diagnostico de incidencias de instalacion y configuracion

Incompatibilidad de versiones y rutas mal configuradas

# --- INCOMPATIBILIDAD DRIVER / CUDA / PYTORCH ---
# Verificar la matriz de compatibilidad:
# Driver 525.xx → CUDA 12.0 max
# Driver 535.xx → CUDA 12.2 max
# Driver 545.xx → CUDA 12.3 max
# Driver 550.xx → CUDA 12.4 max

# Ver version del driver instalado
nvidia-smi | grep "Driver Version"

# Ver la version de CUDA que PyTorch espera
python -c "import torch; print(torch.version.cuda)"

# Ver la version de CUDA del toolkit instalado en el sistema
nvcc --version

# --- PATH VARIABLES MAL CONFIGURADAS ---
# Verificar que nvcc es accesible
which nvcc
echo $PATH | tr ':' '\n' | grep cuda

# Si nvcc no se encuentra, agregar CUDA al PATH
echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

# --- PERMISOS DE DISPOSITIVO ---
# Ver permisos de los nodos de dispositivo NVIDIA
ls -la /dev/nvidia*
# Salida esperada: crw-rw-rw- 1 root video 195, 0 ...

# Si los permisos son incorrectos
sudo chmod 666 /dev/nvidia*
sudo chmod 666 /dev/nvidiactl
sudo chmod 666 /dev/nvidia-uvm

# Alternativa: agregar el usuario al grupo video
sudo usermod -aG video $USER

Reparacion o sustitucion de componentes

Criterios para decidir: reparar vs. sustituir

Procedimiento de sustitucion de GPU en servidor

Antes de la intervencion fisica:

# 1. Anotar el estado actual
nvidia-smi -q > /backups/gpu_antes_sustitucion.txt

# 2. Detener todos los servicios que usen la GPU
sudo systemctl stop triton-server
sudo systemctl stop nvidia-persistenced

# 3. Descargar el modulo del kernel
sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia

Reparacion o sustitucion — procedimiento fisico y validacion

Intervencion fisica: medidas de seguridad (ESD)

• Apagar el servidor completamente y desconectar el cable de alimentacion de la red electrica
• Esperar al menos 30 segundos para que los condensadores se descarguen
• Usar pulsera antiESD conectada a una toma de tierra verificada antes de tocar cualquier componente
• No tocar los conectores dorados de la GPU ni el slot PCIe con las manos desnudas
• Sujetar la GPU por los bordes del PCB, nunca por el disipador ni los ventiladores
• Guardar la GPU retirada en bolsa antistatica

Validacion post-sustitucion

# 1. Arrancar el servidor y verificar que la GPU aparece en el POST (BIOS/UEFI)

# 2. Verificar que el sistema operativo detecta la nueva GPU
lspci -nn | grep -i nvidia
sudo dmesg | grep -i "NVRM\|nvidia"

# 3. Cargar el modulo del kernel
sudo modprobe nvidia
nvidia-smi   # debe mostrar la nueva GPU con su numero de serie

# 4. Ejecutar el test de estres de GPU para validar el hardware
sudo apt install -y gpu-burn
gpu-burn 300   # estres durante 5 minutos; verificar ausencia de errores ECC

# 5. Reiniciar los servicios
sudo systemctl start nvidia-persistenced
sudo systemctl start triton-server
sudo systemctl status triton-server

# 6. Actualizar el inventario (CMDB) con el nuevo numero de serie de la GPU
nvidia-smi --query-gpu=name,serial,uuid --format=csv

Resolucion de incidencias de aplicaciones (I)

Reconfigurar el servidor de inferencia

El servidor de inferencia (Triton, TorchServe, vLLM) puede requerir reconfiguracion cuando cambia el hardware o los modelos disponibles.

# --- TRITON INFERENCE SERVER: diagnostico de configuracion ---

# Ver que modelos tiene cargados Triton
curl -s http://localhost:8000/v2/models | python -m json.tool

# Ver el estado de un modelo especifico
curl -s http://localhost:8000/v2/models/bert_classifier | python -m json.tool

# Recargar un modelo sin reiniciar el servidor
curl -X POST http://localhost:8000/v2/repository/models/bert_classifier/load

# Descargar un modelo de la memoria
curl -X POST http://localhost:8000/v2/repository/models/bert_classifier/unload

# --- VLLM: ajustar parametros si hay OOM ---
# Reducir el gpu-memory-utilization para dejar margen
python -m vllm.entrypoints.openai.api_server \
  --model /models/mistral-7b \
  --gpu-memory-utilization 0.80 \
  --max-model-len 4096 \
  --tensor-parallel-size 1

# Ver el log de errores de vLLM
sudo journalctl -u vllm-server -n 200 --no-pager | grep -i error

Resolucion de incidencias de aplicaciones (II)

Reinstalacion limpia del entorno Python y actualizacion de libreria problematica

# --- REINSTALACION LIMPIA DEL ENTORNO VIRTUAL ---

# 1. Hacer una copia de los requisitos antes de borrar
/opt/venvs/inference/bin/pip freeze > /backups/requirements_$(date +%Y%m%d).txt

# 2. Eliminar el entorno virtual corrupto
rm -rf /opt/venvs/inference

# 3. Crear un entorno limpio con la version de Python correcta
python3.11 -m venv /opt/venvs/inference

# 4. Instalar las dependencias desde el fichero de requisitos
/opt/venvs/inference/bin/pip install --upgrade pip
/opt/venvs/inference/bin/pip install -r /backups/requirements_20240615.txt

# --- ACTUALIZACION DE UNA LIBRERIA PROBLEMATICA ---
# Ejemplo: transformers falla al cargar un modelo con la version actual

# Identificar la version que rompe
pip show transformers | grep Version
# Version: 4.36.0

# Ver el changelog para identificar breaking changes
# https://github.com/huggingface/transformers/blob/main/CHANGELOG.md

# Probar con la version anterior
pip install "transformers==4.35.2"
python -c "from transformers import AutoModelForCausalLM; print('OK')"

# Si funciona, anclar la version en requirements.txt
echo "transformers==4.35.2  # pinned: 4.36.0 rompe carga de modelos llama" \
  >> /opt/venvs/inference/requirements.txt

# Alternativamente, instalar desde el commit estable de git
pip install git+https://github.com/huggingface/transformers@v4.35.2

Pruebas finales de verificacion

Checklist de cierre de incidencia

# --- SMOKE TEST: verificacion rapida post-resolucion ---
nvidia-smi && echo "[OK] Driver NVIDIA activo"
python -c "import torch; assert torch.cuda.is_available(), 'CUDA no disponible'; \
  print(f'[OK] CUDA disponible: {torch.cuda.get_device_name(0)}')"
curl -sf http://localhost:8000/v2/health/ready && echo "[OK] Triton listo"

# --- TEST DE CARGA: verificar que el servicio aguanta la carga normal ---
# Herramienta: perf_analyzer de Triton
/opt/triton-client/bin/perf_analyzer \
  -m bert_classifier \
  --concurrency-range 1:16 \
  --measurement-interval 5000 \
  -u localhost:8001 \
  --protocol grpc

# --- VALIDACION DE SLA ---
# Verificar que la latencia p99 esta dentro del umbral definido en el SLA
# Ejemplo: SLA = p99 < 200 ms para inferencia de clasificacion de texto
curl -s http://localhost:8000/metrics | grep "nv_inference_request_duration_us"

Checklist de cierre formal

• [ ] Causa raiz identificada y documentada en el ticket
• [ ] Solucion aplicada y verificada mediante pruebas
• [ ] Latencia p99 dentro del umbral del SLA
• [ ] Servicio sin reinicios inesperados durante al menos 30 minutos
• [ ] Usuarios afectados notificados de la resolucion
• [ ] Ticket cerrado con la categoria de causa raiz correcta (ITIL: Root Cause)
• [ ] Accion preventiva creada si la incidencia es recurrente (Problem Management)

Priorizacion por criticidad

Matriz de priorizacion ITIL: P1 a P4

Regla de escalado: si en el 50 % del tiempo de resolucion no hay avance claro, escalar al siguiente nivel. Es mejor escalar pronto que llegar al fin del SLA sin resolucion.

Comunicacion asertiva en la gestion de incidencias

Principios de comunicacion durante una incidencia

• Ser factual: comunicar lo que se sabe con certeza; no especular sobre causas ante el cliente
• Ser proactivo: actualizar el estado segun el SLA aunque no haya novedades ("seguimos investigando")
• Ser claro: evitar jerga tecnica en las comunicaciones a usuarios no tecnicos
• Ser honesto sobre los tiempos: un tiempo estimado realista es mejor que uno optimista que no se cumple

Plantilla de actualizacion de estado de incidencia

Asunto: [INC-2024-0891] Actualizacion de estado — Servicio de inferencia degradado

Estimados usuarios,

Les informamos de que estamos trabajando activamente en la resolucion de la
incidencia INC-2024-0891, reportada a las 09:15 h de hoy.

Estado actual: EN RESOLUCION
Causa identificada: incompatibilidad entre el nuevo kernel de Linux (6.5.0-35)
y el controlador NVIDIA 535.x instalado.
Accion en curso: instalando el controlador NVIDIA 550.x compatible con el kernel.
Impacto: el servicio de inferencia no esta disponible para todos los usuarios.
Workaround disponible: no existe workaround en este momento.
Proximo estado: 14:00 h (o antes si se resuelve antes)

Pedimos disculpas por los inconvenientes causados.

Equipo de Sistemas de IA

Actividad practica

Escenario: "GPU no detectada tras actualizacion de kernel"

Situacion: tras una actualizacion automatica del kernel de Ubuntu de la version 6.5.0-28 a la 6.5.0-35, el servidor srv-inference-01 muestra que nvidia-smi devuelve el error NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. El servicio de Triton no arranca.

Tarea: diagnosticar y resolver la incidencia siguiendo los pasos aprendidos.

# Paso 1: verificar el kernel activo y el modulo NVIDIA
uname -r
lsmod | grep nvidia
# Resultado esperado: ninguna linea (el modulo no esta cargado)

# Paso 2: ver los errores del kernel relacionados
sudo dmesg | grep -i "nvidia\|NVRM\|module"
# Error probable: "nvidia: module verification failed: signature and/or required key missing"

# Paso 3: intentar cargar el modulo manualmente
sudo modprobe nvidia
# Error probable: "modprobe: ERROR: could not insert 'nvidia': Exec format error"

# Paso 4: verificar si el driver instalado tiene soporte para el nuevo kernel
dpkg -l | grep nvidia-driver
apt-cache policy nvidia-driver-535
# Ver si hay una version mas nueva compatible con el kernel 6.5.0-35

# Paso 5: solucionar — instalar el driver compatible
sudo apt update
sudo apt install --only-upgrade nvidia-driver-550
sudo reboot

Tras el reinicio: repetir los smoke tests de la diapositiva de pruebas finales y documentar la incidencia con causa raiz, solucion aplicada y accion preventiva (configurar apt-mark hold linux-image-* o sincronizar la ventana de actualizacion del kernel con la del driver).

Puntos clave

• Documentar antes de actuar: un diagnostico incompleto lleva a soluciones erroneas. Recoger el traceback exacto, el entorno y los cambios recientes antes de tocar nada.
• Los logs son la fuente de verdad: dmesg, journalctl, nvidia-bug-report.sh y los logs del framework contienen la causa raiz de la mayoria de las incidencias. Aprende a leerlos.
• Los errores Xid son senales criticas: Xid 79 (GPU off bus) y Xid 48 (ECC double-bit) indican fallo hardware; no se resuelven con reinicios ni con actualizaciones de software.
• La incompatibilidad kernel-driver es la causa mas frecuente de "GPU no detectada": siempre verificar que el driver NVIDIA soporta la version del kernel activo tras cualquier actualizacion del sistema.
• ESD no es opcional: la descarga electrostatica puede destruir una GPU de forma no visible e inmediata. Pulsera antiESD y descarga del servidor antes de cualquier intervencion fisica.
• Priorizar antes de ejecutar: una incidencia P1 requiere accion inmediata y comunicacion proactiva. Una P4 puede planificarse. Confundir prioridades genera insatisfaccion del cliente y uso ineficiente del equipo tecnico.
• Cerrar bien el ticket: la causa raiz documentada y la accion preventiva son la diferencia entre resolver una incidencia y evitar que se repita.

Criterios de evaluacion

Navegación

← UD4 · Actualización de componentes  ·  Volver al módulo  ·  UD6 · Prevención de riesgos y gesti… →