Auditoría de uso de recursos por cuenta para justificar actualizaciones de plan

Auditoría de uso de recursos por cuenta para justificar actualizaciones de plan

Como reseller debes tomar decisiones basadas en datos: auditar el uso de recursos por cuenta es la forma más objetiva de justificar una actualización de plan. En este artículo explico qué métricas medir, cómo recogerlas de forma fiable, cómo presentar resultados a clientes y a tu equipo comercial, y qué umbrales o señales deberías considerar para proponer un cambio de plan.

Por qué hacer una auditoría por cuenta

Una auditoría detallada evita decisiones arbitrarias. En lugar de ofrecer upgrades porque «el sitio es lento», podrás mostrar evidencia: uso sostenido de CPU, picos de I/O, límites de procesos simultáneos o agotamiento de inodos. Esto mejora la conversión de propuestas de venta y reduce disputas con clientes.

Métricas clave a auditar por cuenta

  • CPU: porcentaje de uso en promedio y picos sostenidos.
  • Memoria RAM: consumo residente, uso de swap y picos de memoria.
  • Disco: espacio utilizado, crecimiento mensual y uso de inodos.
  • I/O: latencia de lectura/escritura y IOPS por cuenta.
  • Conexiones simultáneas: conexiones web activas (Nginx/Apache) y conexiones a base de datos.
  • Procesos/threads: nº de procesos activos por usuario (limites de cPanel/WHM o ulimit).
  • Errores y logs: 5xx, timeouts, rechazos por límites de recursos.
  • Ancho de banda y tráfico: volumen mensual y picos por hora.

Cómo recolectar datos: métodos y herramientas

La auditoría puede ser manual o automatizada. Aquí describo métodos fiables a distintos niveles (OS, servicio y aplicación).

1) Nivel sistema operativo

  • Comandos útiles: top, htop, vmstat, iostat, sar. Estos muestran consumo agregado y tendencias en CPU, memoria y I/O.
  • Per-account: en entornos Linux con cuentas de usuario, ps -u usuario -o %cpu,%mem,cmd ayuda a identificar procesos que consumen recursos por cuenta.
  • Contenedores/VMs: consulta métricas de cgroups o del hypervisor para aislar consumo por instancia.

2) Servicios web y PHP

  • Registros de acceso y error de Nginx/Apache para medir conexiones concurrentes y errores 5xx. Revisa límites de workers y tiempo de respuesta.
  • Para sitios PHP, monitorea PHP-FPM (pools por usuario) y el estado de OPcache. Documentación sobre comportamiento de PHP en producción en PHP.net.

3) Base de datos

  • Métricas críticas: conexiones simultáneas, queries lentas, uso de buffers, I/O de almacenamiento. Ejecuta SHOW PROCESSLIST; y revisa SHOW GLOBAL STATUS para tendencias.
  • Consulta guías oficiales en MySQL para métricas de rendimiento y contadores.

4) Networking y ancho de banda

  • Registra bytes por IP/cuenta en los logs del servidor web o con herramientas de red (ntop, iftop o registros de router).
  • Si se usan CDN o servicios externos, mide tráfico origen vs tráfico CDN y reporta ahorro. Documentación sobre optimización de cache en Cloudflare Docs puede ayudar a justificar soluciones alternativas a un upgrade.

Periodo de medición y muestreo

Para justificar un upgrade necesitas datos representativos:

  • Periodo mínimo recomendado: 14–30 días para captar patrones semanales y picos.
  • Muestreo: registra métricas clave en intervalos de 1–5 minutos para CPU/memoria y cada hora para resumen diario de disco y ancho de banda.
  • Logs históricos: conserva métricas por al menos 90 días para comparar antes/después y explicar crecimiento.

Umbrales prácticos para recomendar una actualización

No existe un umbral universal, pero estos valores funcionan como guía accionable:

  • CPU: uso sostenido > 70% durante ventanas de 10+ minutos en picos regulares.
  • RAM: consumo > 80% con uso de swap constante o picos que provocan OOM (out-of-memory).
  • I/O: latencia de disco promedio > 20-30 ms y IOPS saturadas que generan colas.
  • Conexiones: cerca del límite de workers de Nginx/Apache o del pool de PHP-FPM (ej. 80–90% de ocupación).
  • Inodos: uso > 75% en discos compartidos o cuentas con muchos pequeños archivos (WordPress con muchos attachments o caches).

Cómo presentar el informe al cliente

Un informe efectivo combina visuales y texto claro. Estructura recomendada:

  • Resumen ejecutivo: 3-5 líneas con la recomendación (upgrade, optimización, o ambos).
  • Métricas clave: gráficos de CPU, memoria, disco y conexiones con fechas y picos relevantes.
  • Casos concretos: ejemplos de minutos/hours donde el servicio degradó o falló.
  • Opciones y coste/beneficio: upgrade de plan, optimización (cache, CDN, BYO DB), o combinación.
  • Acciones propuestas y cronograma: pasos técnicos y tiempos estimados.

Ejemplo real y recomendación

Ejemplo: cuenta «clienteA» muestra picos de CPU al 95% entre 10:00–10:15 y 14:00–14:20 durante 12 de los últimos 30 días; uso de memoria promedio 78% con swap ocasional y más de 1000 conexiones MySQL en picos. Con esos datos la recomendación sería:

  • Actualizar a un plan con mayor CPU y límites de procesos.
  • Implementar cache a nivel aplicación o CDN para reducir picos de tráfico dinámico.
  • Revisar índices y queries en la base de datos para reducir conexiones simultáneas.

Automatización y escalado del proceso de auditoría

Para manejar múltiples cuentas automáticamente:

  • Implementa una solución de métricas centralizada (Prometheus+Grafana, Elastic Stack o equivalentes) que agregue métricas por etiqueta de cuenta.
  • Crea alertas basadas en umbrales y reglas de correlación (CPU alto + I/O elevado + errores 5xx).
  • Genera reportes periódicos automatizados y plantillas que el equipo de soporte pueda enviar a clientes con un solo clic.

Errores comunes y cómo evitarlos

  • Confiar solo en una métrica: la combinación CPU+I/O+memoria da una imagen real.
  • Tomar decisiones por un pico aislado: verifica repetición en el tiempo.
  • No pedir permiso para cambios drásticos: documenta implicaciones (costes, downtime).

Aspectos legales y de privacidad

Si auditas contenido o logs debes respetar la privacidad del cliente y la legislación aplicable (GDPR, etc.). Anota el consentimiento para acceder a datos sensibles y asegura que los informes comparten solo lo necesario.

Conclusión

Una auditoría de uso de recursos por cuenta bien ejecutada transforma una conversación comercial en una propuesta técnica justificada. Mide CPU, memoria, disco, I/O y conexiones durante al menos 14–30 días, automatiza la recolección y presenta resultados con umbrales claros. Combina recomendaciones de actualización de plan con medidas de optimización (cache, CDN, optimización de DB) para ofrecer alternativas de menor coste al cliente. Documenta todo y utiliza reportes visuales para aumentar la aceptación de las propuestas.

Tags: