Métricas
Objetivo del Reporte
Implementar un sistema de monitoreo que permita observar en tiempo real y con reportes automáticos el estado de los recursos tecnológicos críticos: servidores, bases de datos, servicios auxiliares (como Redis) y, en una segunda fase, la red interna y externa. El objetivo es asegurar disponibilidad, detectar problemas antes de que impacten al negocio y facilitar decisiones informadas para mantenimiento y mejora.
Componentes monitoreados
Actualmente se monitorean:
Servidores (VMs)
Bases de datos
Redis (memoria cache de alto rendimiento)
En fase futura:
Red y conectividad interna/externa
Métricas por componente
1.SERVIDORES
Métrica | Descripción | Importancia |
|---|---|---|
Uso de CPU | Nivel de carga de procesamiento. | Si está muy alto, el servidor se vuelve lento o inestable. |
Uso de Memoria (RAM) | Cuánta memoria está siendo utilizada. | Baja disponibilidad genera errores y lentitud. |
Uso de Disco | Porcentaje del almacenamiento utilizado. | Un disco lleno puede causar caída de servicios. |
Servicios activos | Revisión de que los procesos clave estén corriendo. | Permite actuar ante caídas o bloqueos de servicios. |
2. BASES DE DATOS
Métrica | Descripción | Importancia |
|---|---|---|
Conexiones activas | Número de usuarios y sistemas conectados simultáneamente. | Evita sobrecarga del servidor de base de datos. |
Consultas lentas | Búsquedas o escrituras que tardan demasiado. | Indica posibles problemas de optimización. |
Latencia de respuesta | Tiempo promedio en responder una consulta. | Relacionado con la experiencia del usuario final. |
Espacio ocupado | Tamaño de la base y su ritmo de crecimiento. | Para anticipar necesidad de ampliar capacidad. |
3. REDIS
Métrica | Descripción | Importancia |
|---|---|---|
Uso de memoria | Redis opera solo en memoria RAM. | Si se llena, borra datos o lanza errores. |
Claves almacenadas | Número de registros activos. | Mide carga del sistema. |
Latencia de operaciones | Tiempos de respuesta por operación. | Afecta velocidad del sistema en general. |
Conexiones activas | Sistemas accediendo a Redis. | Controla saturaciones. |
Reinicios o fallas | Redis se reinicia o pierde datos por falta de recursos. | Alerta crítica que puede generar caída temporal. |
Infraestructura Actual
Actualmente se cuenta con 4 máquinas virtuales configuradas así:
VMs de producción:
Cantidad: 4
CPU: 2 vCores por VM
RAM: 8 GB por VM
Disco raíz: 20 GB
Sistema Operativo: Ubuntu
Red Virtual (vnet-idbi-production)
Subred | Nombre | Rango de IPs | Descripción |
|---|---|---|---|
Intranet |
|
| Tráfico interno entre servidores |
Privada |
|
| Servicios con NAT a internet |
Pública |
|
| Servicios con acceso desde internet |
El tráfico NAT está habilitado solo en la subred privada.
CIDR de la red principal:
10.100.0.0/16
Frecuencia de Muestreo
En tiempo real: Alertas críticas (caídas, uso elevado, errores graves)
Cada 5 minutos: CPU, Memoria, Disco, Conexiones, Redis
Diariamente: Consultas lentas, uso de espacio, latencia
Semanalmente: Reporte resumido por correo o dashboard
Alertas Proactivas
🔴 CPU > 70% durante más de 10 minutos
🔴 Memoria < 20% disponible
🟡 Espacio en disco > 70%
Visualización Sugerida
Dashboard con colores (verde/amarillo/rojo) según estado
Gráficas por hora y por día de cada métrica
Paneles sugeridos: Grafana
Fase Futura: Monitoreo de Red y Tasa de Errores
Aunque la red ya está bien segmentada, actualmente no se están monitoreando métricas de red ni errores en la capa de respuesta HTTP. Se proyecta implementar las siguientes observaciones clave:
Métricas de Red (capa de infraestructura)
Latencia entre subredes o entre servicios críticos
Ancho de banda utilizado por cada VM o interfaz de red
Tráfico saliente e interno a través del NAT gateway
Rutas activas, saltos y resolución DNS
Tasa de paquetes perdidos o retransmitidos
Detección de interrupciones breves o inestabilidad
Métricas de Error por Respuesta HTTP (capa de aplicación)
Se comenzará a medir la tasa de errores por tipo de respuesta HTTP para tener una visión clara de los fallos experimentados por los clientes:
Errores 5xx (servidor): Indican fallos internos, caídas de servicios o falta de recursos.
Errores 4xx (cliente): Pueden reflejar configuraciones incorrectas, endpoints mal llamados o autenticaciones fallidas.
Agrupación por endpoint y volumen, para priorizar los más afectados.
Historial y tendencia diaria/semanal para detectar regresiones o nuevas incidencias.
Esto permitirá:
Diagnosticar problemas de red y conectividad entre servicios o hacia internet.
Detectar fallos silenciosos que afectan la experiencia de usuario.
Prevenir impactos mayores mediante alertas automáticas.
Tomar decisiones basadas en datos reales de disponibilidad y calidad.