AVAILABILITYAPPLICATION ENDPOINT
VISIBLE01.3MONITORING & OBSERVABILITY
No basta con sabersi un sistema está encendido.
Diseñamos señales, monitoreo y observabilidad para entender disponibilidad, comportamiento y cambios relevantes dentro de infraestructura y aplicaciones.
01.3.1OBSERVABILIDAD
Saber que algo fallóes distinto a entender por qué.
El monitoreo puede indicar que un servicio dejó de responder. La observabilidad busca aportar suficiente contexto para entender qué ocurrió alrededor.
Dependiendo del entorno, eso puede incluir estado de servicios, eventos, cambios, utilización de recursos y señales generadas por la propia aplicación.
El objetivo no es almacenar todo lo posible. Es conservar las señales que realmente ayudan a operar y diagnosticar el sistema.
01.3.2SEÑALES
Cada sistema necesita distintas señales. Diseñamos la visibilidad alrededor de su función y operación real.
01◉
AVAILABILITY
Disponibilidad
Señales que ayudan a saber si servicios y puntos relevantes responden como se espera.
02⌁
PERFORMANCE
Comportamiento
Indicadores que permiten observar cambios en tiempos de respuesta y funcionamiento general.
03▰
HOST
Estado del entorno
Recursos y señales del sistema operativo cuando aportan contexto a la operación.
04⌖
EVENTS
Eventos
Cambios y sucesos relevantes que pueden ayudar a reconstruir qué ocurrió.
05+
APPLICATION
Señales de aplicación
Información generada por el propio sistema cuando resulta útil para diagnosticar comportamiento.
06↺
RECOVERY
Estado de respaldos
Señales relacionadas con tareas que sostienen capacidad de recuperación.
01.3.3MONITORING ≠ OBSERVABILITY
STATUS IS ONLY THE BEGINNINGMonitorear pregunta“¿está funcionando?”
Observabilidad ayuda a responder una segunda pregunta: “¿qué está ocurriendo dentro del sistema?”
Ambas capacidades se complementan. El monitoreo genera señales de estado y la observabilidad aporta contexto para interpretar cambios y fallos.
SERVICE ANALYSISCORRELATING
MONITORENDPOINT UNAVAILABLE
DETECTEDEVENTDEPLOYMENT COMPLETED
CONTEXTHOSTPROCESS RESTART
OBSERVEDASSESSMENTINVESTIGATE DEPLOYMENT
REVIEW01.3.4DISEÑO DE OBSERVABILIDAD
Medir sólolo que ayuda a entender.
La observabilidad debe comenzar por preguntas operativas, no por la cantidad de datos que una herramienta puede recopilar.
QUESTION
Preguntar
Definimos qué necesita saber el equipo sobre el comportamiento del sistema.
SIGNALS
Seleccionar
Identificamos las señales necesarias para responder esas preguntas.
COLLECT
Recopilar
Configuramos mecanismos de captura y disponibilidad de telemetría.
PRESENT
Organizar
Estructuramos la información para reducir ruido y facilitar interpretación.
IMPROVE
Ajustar
Refinamos señales conforme conocemos mejor el comportamiento del sistema.
01.3.5 / ALERTINGREDUCE NOISE
Una alerta útildebe significar algo.
Si cada variación genera una notificación, el sistema termina entrenando a las personas para ignorarlo.
RELEVANCE
Relevancia
Alertar sobre condiciones que pueden requerir revisión o intervención.
CONTEXT
Contexto
Acompañar eventos con información suficiente para comenzar a entenderlos.
OWNERSHIP
Responsable
Saber quién debe revisar una señal cuando ésta requiere atención.
ITERATION
Ajuste
Las reglas necesitan modificarse conforme cambia el entorno.
01.3.6EVENT CONTEXT
Reconstruirqué ocurrió alrededor.
Cuando un servicio cambia de comportamiento, las señales aisladas pueden decir muy poco.
Relacionar eventos, despliegues, reinicios, cambios de configuración y comportamiento puede reducir el tiempo necesario para comprender dónde comenzar una investigación.
EVENT TIMELINEREFERENCE VIEW
DEPLOYAPPLICATION RELEASE
EVENTSERVICEPROCESS RESTART
EVENTHEALTHENDPOINT DEGRADED
SIGNALMONITORCHECK FAILED
REVIEW 01.3.7 / SCOPE
Observabilidadcon límites claros.
No todos los sistemas requieren la misma profundidad de telemetría ni el mismo periodo de conservación.
Definimos señales, frecuencia, almacenamiento y responsabilidades de acuerdo con la función del sistema y el alcance contratado.
La existencia de monitoreo automatizado tampoco implica, por defecto, supervisión humana permanente.
OBSERVABILITY SCOPEDEFINED RESPONSIBILITIES
SIGNALSDEFINED SOURCES
SCOPEDRETENTIONDEFINED PERIOD
SCOPEDALERTINGDEFINED RULES
SCOPEDRESPONSEDEFINED RESPONSIBILITY
SCOPED01.3.8CUÁNDO TIENE SENTIDO
Cuando “está arriba”ya no responde todas las preguntas.
Aplicaciones en producción
Sistemas que necesitan visibilidad posterior al despliegue.
Incidencias difíciles de explicar
Entornos donde existen fallos sin suficiente contexto técnico.
Cambios frecuentes
Sistemas donde despliegues y configuraciones evolucionan regularmente.
Infraestructura administrada
Entornos que necesitan mantener visibilidad durante la operación.
Preparación para recuperación
Validar que mecanismos esenciales continúan generando señales esperadas.
01.3.9 / MWS
Observar forma partede operar.
Dentro de MWS, el monitoreo automatizado y la observabilidad forman parte de la capa operativa definida para cada entorno.
Esto permite conectar despliegue, mantenimiento, señales operativas y recuperación dentro de una misma responsabilidad.
CONOCER MWS↗MWS / OPERATIONS LOOPOBSERVE TO OPERATE
↓
↓
↓
01.3.10PRINCIPIOS
Visibilidadcon propósito.
Preguntas antes que métricas
Medimos lo que ayuda a comprender el comportamiento del sistema.
Señal antes que ruido
Evitamos recopilar o alertar sólo porque una herramienta lo permite.
Contexto temporal
Los eventos son más útiles cuando pueden relacionarse entre sí.
Responsabilidad clara
Una alerta necesita saber quién debe revisarla y qué sigue después.
Iteración
Las necesidades de observabilidad cambian conforme cambia el sistema.
EVOFCS / MONITORING & OBSERVABILITYUNDERSTAND WHAT YOUR SYSTEM IS DOING
Construya visibilidadantes de necesitar respuestas.
Podemos revisar su entorno y definir qué señales ayudarían a operarlo, diagnosticarlo y entender cambios relevantes con mayor claridad.
HABLAR CON EVOFCS↗