Cómo interpretar los indicadores básicos de una base de datos

Introducción

Interpretar los indicadores de una base de datos exige relacionar latencia, actividad, capacidad y contexto. Un número aislado puede ser exacto y, aun así, conducir a una decisión equivocada. Doscientas conexiones no significan necesariamente doscientas consultas ejecutándose; una memoria muy ocupada no demuestra falta de RAM; y un porcentaje de aciertos de caché elevado no garantiza que la aplicación responda bien.

Esta diferencia importa cuando administras una infraestructura pequeña y debes decidir si una señal merece atención, si necesitas ampliar recursos o si el panel simplemente está mostrando el comportamiento habitual. Sin una lectura correcta, resulta fácil invertir tiempo en perseguir cifras que no representan el problema del usuario.

El propósito de este artículo es ayudarte a leer los indicadores básicos de una base de datos: comprender qué cuentan, qué unidades utilizan, qué periodo representan y qué conclusiones permiten. No es una guía para instalar herramientas de monitorización ni para optimizar consultas. Es el paso intermedio entre disponer de métricas y utilizarlas con criterio.

Los ejemplos numéricos son supuestos didácticos, no resultados de una empresa concreta ni umbrales recomendados. Los conceptos se aplican a distintos motores, aunque cada producto define sus contadores y sus ámbitos de forma particular. Antes de trasladar una fórmula a un panel real hay que comprobar esa definición.

Índice

• Qué necesitas saber antes de interpretar una métrica
• Valores instantáneos, contadores y tasas: tres lecturas diferentes
• Cómo comparar periodos sin fabricar una degradación
• Latencia: media, mediana, percentiles y experiencia real
• Actividad y rendimiento: qué significan consultas y transacciones por segundo
• Conexiones: ocupación, actividad y margen de admisión
• Esperas y bloqueos: tiempo detenido no es trabajo útil
• CPU, memoria y caché: utilización no equivale a problema
• Entrada y salida: operaciones, volumen y latencia de almacenamiento
• Tamaño, espacio libre y crecimiento: cantidades que no debes confundir
• Errores, cancelaciones y transacciones revertidas
• Replicación y copias: qué evidencia aporta cada indicador
• Caso práctico: leer un panel sin saltar a la solución
• Una plantilla breve para convertir cifras en conclusiones útiles
• Preguntas frecuentes
• Conclusión

Qué necesitas saber antes de interpretar una métrica

Imagina que un panel muestra el valor «85». No puedes decidir nada hasta saber si significa milisegundos, conexiones, porcentaje de CPU o gigabytes. Incluso con la unidad falta información: 85 conexiones en toda la instancia no es lo mismo que 85 conexiones pertenecientes a una sola aplicación.

Una métrica útil debe acompañarse de su definición, unidad, ámbito, instante o intervalo de observación y origen. También conviene conocer qué eventos quedan fuera. Un tiempo medido dentro del motor puede excluir la espera para conseguir una conexión, mientras que el tiempo de una petición web incorpora otros componentes.

Si todavía necesitas situar tablas, transacciones y consultas, comienza por los fundamentos de una base de datos. Para seleccionar herramientas y organizar la recogida periódica, el complemento es cómo monitorizar bases de datos de forma sencilla. Aquí interesa aprender a interpretar la información que esas herramientas entregan.

Valores instantáneos, contadores y tasas: tres lecturas diferentes

Un valor actual describe un estado

El número de conexiones abiertas o el espacio libre pueden aumentar y disminuir. La pregunta es cuánto hay en ese momento, cómo ha cambiado y cuál es su relación con una referencia. En instrumentación este tipo de medida suele llamarse gauge. Su valor no debe interpretarse automáticamente como trabajo acumulado.

Un contador describe eventos acumulados

Un contador de operaciones terminadas acumula eventos hasta que se reinicia o cambia la serie. Tener diez millones de operaciones acumuladas no indica por sí solo mucha carga actual: podrían haberse producido durante un día o durante varios años. La documentación de tipos de métricas de Prometheus distingue expresamente contadores acumulativos y valores que pueden subir o bajar.

Para conocer la actividad de un periodo necesitas dos observaciones compatibles. Si el contador pasa de 1.200.000 a 1.236.000 entre las 10:00 y las 10:05, hubo 36.000 eventos en 300 segundos:

Eventos del intervalo = 1.236.000 − 1.200.000 = 36.000
Tasa media = 36.000 / 300 = 120 eventos por segundo

Ese promedio no demuestra que cada segundo tuviera exactamente 120 eventos. Puede esconder un minuto muy intenso y cuatro minutos tranquilos. La granularidad de la observación determina cuánto detalle puedes recuperar.

Un reinicio no es actividad negativa

Si el siguiente valor baja a 500, no significa que hayan ocurrido millones de transacciones negativas. Puede haberse reiniciado el contador, sustituido la instancia o mezclado series distintas. El tratamiento correcto depende de la herramienta, pero no debes aplicar una resta simple entre valores que ya no comparten continuidad.

Conserva el identificador de la instancia y, cuando exista, la referencia de reinicio estadístico. Reiniciar el proceso, reiniciar las estadísticas y cambiar de nodo son acontecimientos diferentes; no presupongas que todos los motores conservan o reinician sus contadores del mismo modo.

Cómo comparar periodos sin fabricar una degradación

Una comparación solo resulta útil si mantiene razonablemente estable aquello que quieres comparar. Contrastar la media de un domingo con el máximo del cierre mensual mezcla actividad, agregación y periodo. La diferencia resultante puede ser real, pero no describe necesariamente un empeoramiento técnico.

Conviene comparar la misma operación, desde el mismo punto de medida, con unidades iguales y periodos de actividad semejantes. Cuando cambie la carga, anótalo: una importación extraordinaria, más usuarios o un informe nuevo pueden explicar una variación sin que el servidor esté funcionando peor.

El denominador también debe viajar con el porcentaje

En un ejemplo ficticio, una franja registra un error entre diez operaciones: 10 %. Otra registra nueve errores entre 990 operaciones: aproximadamente 0,91 %. La tasa conjunta es diez errores entre mil operaciones, es decir, 1 %. Promediar directamente los dos porcentajes produciría aproximadamente 5,45 %, una conclusión incorrecta.

La misma precaución se aplica a porcentajes de aciertos y medias de duración. Para combinar periodos necesitas los totales y las poblaciones correspondientes, o una agregación que conserve correctamente su peso. Cuantas más bases agrupe el panel, más importante es revisar cómo se calcula la cifra global.

La ausencia de muestras no equivale a cero

Un hueco puede indicar fallo del recolector, permisos insuficientes, un contador no habilitado o una interrupción de conectividad. Dibujarlo como cero puede hacer parecer que desaparecieron los errores o que la base dejó de consumir recursos. Conserva la distinción entre cero observado, dato no disponible y comprobación fallida.

También debes comprobar la antigüedad del último valor. Un panel con datos de hace cuarenta minutos puede parecer estable cuando en realidad ha dejado de actualizarse. La frescura de la observación forma parte de su significado.

Latencia: media, mediana, percentiles y experiencia real

La latencia es el tiempo que tarda una operación, pero debe indicarse dónde comienza y dónde termina la medición. Una consulta puede ejecutarse rápidamente en el motor y llegar tarde al usuario por la espera en el pool, la red, el procesamiento de resultados o la lógica de la aplicación.

Una media aceptable puede ocultar esperas importantes

Supón cien operaciones: 95 tardan 40 ms y cinco tardan 2.000 ms. La media es 138 ms. Ese valor resume correctamente el conjunto, pero no expresa bien la experiencia de las cinco operaciones lentas. La mediana está en 40 ms y la parte más lenta de la distribución merece una lectura separada.

El percentil 95, o p95, representa un valor de duración bajo el cual se sitúa aproximadamente el 95 % de las observaciones, según el método de cálculo. El p99 se concentra más en la cola lenta. En conjuntos pequeños o distribuciones con saltos, distintos algoritmos de interpolación pueden producir diferencias; por eso conviene mantener el mismo método al comparar.

No sumes ni promedies los p95 de varias instancias para obtener un supuesto p95 global. Debes combinar observaciones o distribuciones compatibles y calcular el percentil sobre el conjunto. Esta limitación se explica en la documentación sobre histogramas y resúmenes de Prometheus.

Comparar lo comparable, no todas las consultas mezcladas

Una búsqueda interactiva, una exportación y una tarea de conciliación tienen expectativas distintas. Si el porcentaje de exportaciones aumenta, la media global puede crecer aunque cada tipo de operación conserve su duración habitual. Separa al menos las familias de operaciones cuyo uso y coste sean claramente diferentes.

Lee también el número de observaciones. Un p99 calculado sobre muy pocas consultas no tiene la misma estabilidad que otro basado en miles. Y comprueba si las operaciones que agotan el tiempo de espera quedan incluidas: excluirlas podría mejorar artificialmente el indicador justo cuando la experiencia empeora.

Actividad y rendimiento: qué significan consultas y transacciones por segundo

La tasa de consultas indica cuántas sentencias procesa el sistema en un intervalo; la de transacciones describe unidades de trabajo transaccional según la definición del contador. No son magnitudes intercambiables. Una transacción puede contener varias sentencias, y una petición de negocio puede desencadenar varias transacciones.

Tampoco todas las consultas exigen el mismo esfuerzo. Resolver una búsqueda por clave y agregar millones de registros cuentan como operaciones, pero no consumen recursos equivalentes. Por eso comparar motores únicamente por consultas por segundo, sin describir la carga, no permite valorar su comportamiento en una aplicación concreta.

Más operaciones no siempre significan más productividad

Supón que una pantalla pasa de ejecutar cinco consultas a ejecutar cincuenta y mantiene el mismo número de usuarios. La tasa de consultas puede multiplicarse por diez sin que el negocio complete más trabajo. Algo parecido ocurre cuando aumentan los reintentos: el motor parece más ocupado, pero una parte de esa actividad repite operaciones que ya fallaron.

La lectura útil combina volumen técnico y resultado funcional. ¿Se registran más pedidos correctos? ¿Se completan más búsquedas? ¿Ha cambiado el número de consultas por petición? Esta relación permite distinguir crecimiento real de amplificación innecesaria de trabajo.

Una caída de actividad también admite varias explicaciones

Menos transacciones puede significar menos usuarios, una caché eficaz, un proceso terminado o una cola atascada antes de llegar al motor. Si la actividad baja mientras crecen los tiempos de respuesta y los errores, no conviene interpretar el descenso como una mejora. Si baja con tiempos estables y operaciones de negocio correctas, la lectura puede ser muy distinta.

Conexiones: ocupación, actividad y margen de admisión

Una conexión abierta mantiene una sesión con el motor, pero no tiene por qué estar ejecutando SQL en ese instante. Las aplicaciones pueden conservar conexiones para reutilizarlas. Distinguir conexiones abiertas, sesiones ejecutando trabajo y sesiones esperando evita tratar toda ocupación como saturación.

Como ejemplo de semántica específica, PostgreSQL diferencia estados como active, idle e idle in transaction. Además, estado y evento de espera son independientes: una sesión activa puede estar esperando. La referencia es su vista de actividad de sesiones, no una equivalencia automática entre «activo» y «consumiendo CPU».

El porcentaje necesita el límite correcto

Con 160 conexiones sobre un máximo configurado de 200, la ocupación nominal es del 80 %. Sin embargo, eso no demuestra que existan cuarenta plazas utilizables por cualquier aplicación. Puede haber conexiones reservadas, límites por usuario, límites del servicio o un pool agotado antes de alcanzar el máximo del motor.

Por tanto, conviene mostrar el límite al que se refiere el porcentaje y la distribución por aplicación. Una instancia compartida puede tener capacidad nominal suficiente mientras un consumidor concentra casi todas las sesiones disponibles.

Observa también apertura y duración

Unas pocas conexiones que se abren y cierran miles de veces pueden representar más trabajo de establecimiento que un pool estable más numeroso. A la inversa, sesiones antiguas pueden ser normales, pero una transacción abierta sin actividad merece una interpretación distinta de una conexión ociosa sin transacción.

La primera conclusión no debe ser «aumentar el máximo», sino «identificar qué clase de ocupación ha aumentado y si está impidiendo admitir o completar trabajo». El ajuste del límite pertenece a una decisión posterior, no al significado inicial de la métrica.

Esperas y bloqueos: tiempo detenido no es trabajo útil

Una sesión puede pasar gran parte de su duración esperando. Esa espera puede corresponder a otra transacción, al almacenamiento, al cliente o a coordinación interna del motor. Agrupar todas esas situaciones bajo «consulta lenta» elimina una parte importante de la explicación.

Interesa distinguir el número de sesiones que esperan, la duración de la espera más antigua y el tiempo acumulado. Son perspectivas diferentes. Una espera de veinte segundos que afecta a una sola operación no produce el mismo alcance que veinte sesiones detenidas durante ese mismo periodo.

El tiempo acumulado puede superar al tiempo de reloj

Si diez sesiones esperan simultáneamente durante diez segundos, acumulan cien segundos de espera aunque solo hayan transcurrido diez segundos reales. Una suma superior al periodo de observación no demuestra necesariamente que el contador esté mal: puede sumar tiempos de participantes concurrentes.

Comprueba si un panel presenta duración total, promedio por espera o porcentaje de tiempo por sesión. Antes de compararlo con CPU o latencia, identifica la población y la forma de agregación.

Un interbloqueo no es cualquier bloqueo

Un bloqueo temporal puede formar parte del funcionamiento normal. Un interbloqueo, o deadlock, implica dependencias circulares que requieren una resolución por el motor. Su contador debe interpretarse por intervalo y frecuencia, no como un total histórico sin contexto.

Estas señales orientan una investigación, pero no autorizan a cancelar sesiones a ciegas. Cuando necesitas identificar la causa y evaluar una intervención, el siguiente paso es el diagnóstico de problemas de rendimiento en bases de datos.

CPU, memoria y caché: utilización no equivale a problema

CPU: comprueba de qué cien por cien se habla

Algunas herramientas expresan CPU como porcentaje de toda la máquina; otras permiten que un proceso multinúcleo supere el 100 %. Un límite de contenedor introduce otro ámbito. Antes de comparar un proceso con el host, revisa la normalización utilizada y los recursos realmente asignados.

Una utilización elevada con respuestas correctas puede representar trabajo útil. Una utilización moderada con respuestas lentas puede coexistir con esperas. La CPU es una señal de utilización, no una medida directa de satisfacción de usuarios ni una prueba suficiente de cuál es el cuello de botella.

Memoria: distingue ocupación de presión

La RAM utilizada por cachés puede mejorar el acceso a los datos. El hecho relevante no es conseguir una memoria vacía, sino detectar si el sistema carece de margen para su trabajo y empieza a recuperar memoria o intercambiar páginas de forma problemática.

Evita sumar indiscriminadamente cifras de procesos, memoria compartida y caché: puedes contar la misma memoria más de una vez. Para profundizar en esa capa, consulta cómo analizar el consumo de memoria de un servidor Linux.

Caché: el porcentaje solo describe una capa

Un cociente de aciertos se interpreta sobre los accesos que realmente incluye su definición. En PostgreSQL, blks_hit se refiere a su caché de buffers y no a la caché del sistema operativo; una lectura fuera de esa caché no implica necesariamente acceso físico al dispositivo. Esta distinción figura en la documentación de estadísticas por base.

Con 99.000 aciertos y 1.000 fallos de una misma población durante el intervalo, la proporción de aciertos es 99 %. Si ese conjunto procesa diez veces más accesos manteniendo el porcentaje, los fallos también se multiplican por diez. El porcentaje permanece estable, pero el trabajo que llega a la siguiente capa no.

Además, acertar en caché no elimina el coste de procesar datos. Una consulta puede recorrer muchísima información en memoria y seguir siendo costosa. No conviertas un porcentaje atractivo en un certificado de buen rendimiento.

Entrada y salida: operaciones, volumen y latencia de almacenamiento

La entrada y salida, o I/O, se describe con varias magnitudes. Las operaciones por segundo indican frecuencia; los bytes por segundo indican volumen; la latencia informa del tiempo de atención; y la cola describe trabajo pendiente en la capa observada. Ninguna sustituye automáticamente a las otras.

Como ejercicio, 1.000 operaciones por segundo de 8 KiB equivalen a unos 7,81 MiB/s de datos por esas operaciones. Diez operaciones de 1 MiB equivalen a 10 MiB/s. El segundo caso mueve más volumen con muchas menos operaciones. Comparar solo IOPS habría ocultado esa diferencia.

La latencia cambia el significado de la utilización

Un almacenamiento puede transferir muchos datos con tiempos aceptables o transferir pocos mientras las operaciones pequeñas esperan demasiado. Para una transacción interactiva, el tiempo de confirmación puede ser más importante que un gran caudal secuencial.

También debes localizar la capa de medida: proceso, sistema de archivos, dispositivo virtual, volumen del proveedor o almacenamiento físico. Una máquina virtual no necesariamente ve todas las causas de espera que existen por debajo. Los límites del servicio y la competencia con otras cargas completan la interpretación.

No diagnostiques el disco únicamente por un porcentaje denominado «utilización». Averigua qué considera ocupado esa herramienta y crúzalo con latencia, cola y experiencia de las operaciones. La finalidad es saber si existe una espera relevante, no perseguir un dispositivo permanentemente ocioso.

Tamaño, espacio libre y crecimiento: cantidades que no debes confundir

El tamaño de una base y el espacio ocupado en el volumen no suelen describir exactamente lo mismo. El almacenamiento puede contener varias bases, índices, registros de transacciones, temporales, copias locales y otros archivos. Asimismo, algunas medidas incluyen espacio asignado que no equivale a datos lógicos actualmente útiles.

Por eso no debes sumar cifras sin conocer si se solapan. Un indicador de tamaño total que ya incluye índices no puede sumarse nuevamente al tamaño de esos índices para obtener un total «más completo».

Porcentaje y cantidad absoluta responden preguntas distintas

Un 20 % libre son 20 GiB en un volumen de 100 GiB y 400 GiB en otro de 2.000 GiB. La proporción indica ocupación relativa; la cantidad permite valorar operaciones concretas. Ninguna expresa por sí sola cuánto tiempo queda antes de alcanzar un límite.

Supón 120 GiB libres, una reserva operativa elegida de 40 GiB y un crecimiento neto observado de 4 GiB al día. El margen hasta consumir la parte disponible por encima de la reserva sería de veinte días, siempre que el ritmo se mantenga. Es una proyección condicionada, no una fecha de fallo garantizada.

Las importaciones, las reescrituras y las tareas de mantenimiento pueden romper ese supuesto de crecimiento regular. El valor de la estimación consiste en hacer explícitas las hipótesis. La planificación detallada y las decisiones de retención se desarrollan en cómo controlar el crecimiento de una base de datos.

Errores, cancelaciones y transacciones revertidas

Una cifra de errores necesita clasificación. No significan lo mismo una autenticación fallida, una restricción que impide introducir datos inválidos, un tiempo de espera agotado, una desconexión de cliente y un problema de almacenamiento. Sumarlos puede servir como señal general, pero no como descripción suficiente del riesgo.

Las reversiones de transacciones tampoco equivalen automáticamente a fallos del negocio. Una aplicación puede usar una reversión de forma deliberada, mientras que otra puede ocultar errores mediante reintentos. Debes conocer qué cuenta el motor y qué interpreta la aplicación como operación completada correctamente.

Relaciona frecuencia, alcance y consecuencia

En un supuesto, doce fallos entre 60.000 intentos representan un 0,02 %. El porcentaje es pequeño, pero todavía falta saber si afectaron a doce consultas auxiliares o a doce operaciones irrepetibles. La importancia no se deduce únicamente del porcentaje.

A la inversa, una validación que rechaza entradas incorrectas puede estar protegiendo la integridad. El aumento de rechazos merece analizarse, pero no implica que debas desactivar la restricción para conseguir una gráfica más limpia.

Presenta los errores por categoría y, cuando sea posible, junto a las operaciones de negocio afectadas. Conservar ejemplos depurados de mensajes ayuda a interpretar, pero no incluyas credenciales ni valores sensibles en un panel accesible a personas que no necesitan verlos.

Replicación y copias: qué evidencia aporta cada indicador

Un indicador de replicación puede expresar bytes pendientes, distancia entre posiciones, tiempo de aplicación o antigüedad del último evento. Antes de leer «retraso: cero» debes saber a cuál se refiere y si la medición sigue actualizándose.

Una distancia en bytes no se convierte directamente en segundos sin conocer la velocidad efectiva de transferencia y aplicación. Tampoco la edad del último cambio demuestra retraso si el origen no ha producido trabajo nuevo. Lo importante para una lectura concreta es qué información debería estar visible y cuál está disponible en el destino.

El éxito de una copia y la capacidad de restaurar son diferentes

La hora de finalización de un trabajo indica que una tarea terminó, no necesariamente el punto de datos recuperable ni el tiempo para restablecer una aplicación. Una copia iniciada antes puede representar un estado anterior, y algunas estrategias necesitan registros adicionales para alcanzar un punto posterior.

La interpretación debe separar tres evidencias: ejecución correcta del proceso, cobertura del punto recuperable y restauración comprobada. Un archivo grande y reciente solo aporta una parte de esa información. El procedimiento específico se explica en cómo comprobar que una copia de seguridad puede restaurarse.

Cuando se utilizan objetivos de pérdida tolerable de datos y tiempo de recuperación, los indicadores deben relacionarse con esos objetivos. No es suficiente mostrar «backup correcto» si nadie sabe desde qué punto podría recuperarse o cuánto tardó la última prueba representativa.

Caso práctico: leer un panel sin saltar a la solución

Considera este escenario ficticio de una aplicación de pedidos. Las dos observaciones corresponden a intervalos de cinco minutos, al mismo servicio y a la misma familia de operaciones. El cambio aparece después de incorporar un informe utilizado durante la jornada.

Qué puede afirmarse

La experiencia de la operación interactiva ha empeorado en su p95, mientras el número de operaciones de negocio apenas cambia. Las consultas por operación pasan de veinte a cuarenta en este conjunto. Hay más conexiones y se observan sesiones esperando bloqueos. La CPU media no presenta un aumento proporcional al de la latencia.

Estas afirmaciones describen los datos. No convierten todavía al informe nuevo en culpable demostrado, pero justifican estudiar su relación temporal con la actividad adicional y con las esperas.

Qué sería prematuro concluir

No puede afirmarse que falte CPU, que deban duplicarse las conexiones máximas ni que el almacenamiento sea el origen. Tampoco una única muestra de sesiones demuestra que los bloqueos hayan durado todo el intervalo. Hacen falta duración, cronología y detalle de las operaciones implicadas.

Una nota técnica razonable sería: «Se observa mayor latencia con duplicación aproximada de consultas por operación y presencia de esperas por bloqueo. Debe revisarse qué consultas añade el nuevo informe y qué transacciones mantienen esas esperas». Describe evidencia e hipótesis por separado.

La utilidad para una microempresa

Este tipo de lectura evita gastar primero y preguntar después. Quizá sea necesario ampliar capacidad, pero los indicadores disponibles no lo demuestran todavía. La mejora inmediata consiste en formular una investigación concreta en lugar de modificar parámetros al azar.

Una plantilla breve para convertir cifras en conclusiones útiles

Puedes utilizar una ficha de interpretación para las señales importantes. No pretende sustituir al panel ni copiar todas sus series: conserva la definición y el razonamiento que permitirán leerlo correctamente dentro de varios meses.

Indicador: latencia p95 de guardar pedido
Ámbito: aplicación de producción, operación interactiva
Punto de medida: desde recibir la petición hasta responder
Unidad y ventana: milisegundos, últimos cinco minutos
Población: intentos medidos; errores mostrados por separado
Referencia: franjas comparables de actividad habitual
Observación: aumento acompañado de más espera por conexión
Conclusión: empeora el tiempo total percibido
Hipótesis pendiente: espera en el pool o dentro del motor
Dato necesario: separar ambos tiempos y comprobar errores

La diferencia entre conclusión e hipótesis es esencial. «Ha aumentado el p95» puede estar demostrado; «necesitamos más memoria» exige evidencias adicionales. Escribir ambas cosas en apartados separados reduce la tentación de presentar una explicación plausible como certeza.

Antes de actuar, comprueba que conoces la unidad, el periodo, el ámbito y la población; que la serie está actualizada; que no cruza un reinicio; y que la comparación usa una referencia relevante. Después relaciona la señal con el impacto operativo y con otra métrica independiente.

Una interpretación bien formulada suele terminar con una de estas decisiones: no hay desviación relevante, conviene seguir observando, hace falta una comprobación específica o existe una condición que requiere intervención. No todas las cifras necesitan convertirse en una alarma ni todos los cambios necesitan una modificación.

Preguntas frecuentes

Conclusión

Leer los indicadores de una base de datos consiste en transformar medidas técnicas en afirmaciones que puedan defenderse. Para hacerlo necesitas conocer definición, unidad, ámbito, periodo, población y cobertura. Después debes comparar referencias equivalentes y separar lo observado de lo que todavía es una hipótesis.

La latencia requiere distribuciones y puntos de medida; la actividad necesita distinguir consultas de trabajo de negocio; las conexiones deben leerse por estado; las esperas no equivalen a consumo de CPU; y la memoria, la caché y el almacenamiento representan capas diferentes. Las copias y la replicación, por su parte, aportan evidencias concretas, no garantías completas por el mero hecho de aparecer en verde.

El criterio más valioso no es memorizar un porcentaje «bueno» para cada gráfico. Es poder explicar qué ha cambiado, a quién afecta, qué incertidumbre permanece y qué comprobación tiene sentido realizar a continuación. Esa capacidad permite administrar con más precisión incluso cuando las herramientas y los recursos son modestos.