Manual de consola — Observabilidad y confiabilidad del servicio

Este manual se hace desde la consola de OCI, haciendo clic. No usa Terraform y usa la CLI solo para verificar lo que la consola ya mostró. Está escrito para alguien que administra infraestructura, conoce AWS o Azure y nunca ha entrado a OCI.

---

1. Qué se construye y para qué

Este laboratorio no crea infraestructura. Se monta encima de un servicio que ya está corriendo: un balanceador con un grupo de instancias detrás, con autoescalamiento configurado. Lo que se construye es la capa que convierte una métrica en una alarma con dueño.

La diferencia importa. Una métrica es un número. Una alarma es un número, un umbral, un destinatario y una acción escrita. Sin esas cuatro cosas hay una gráfica bonita y un teléfono que suena de madrugada sin que nadie sepa qué hacer.

Al terminar, tres piezas quedan funcionando:

1. Un tema de notificaciones con una suscripción de correo confirmada.
2. Dos alarmas de métrica con umbral, ventana y severidad distintas, que escriben en ese tema.
3. Los registros de servicio (logs) habilitados y consultables, para bajar del síntoma al detalle cuando la alarma no se explica sola.

        ┌──────────────────────────────────────────────────────┐
        │  Servicio observado (ya existe, no se toca)           │
        │                                                      │
        │   balanceador  ──►  grupo de instancias  ──►  app     │
        │        │                    │                        │
        └────────┼────────────────────┼────────────────────────┘
                 │ oci_lbaas          │ oci_computeagent
                 ▼                    ▼
        ┌──────────────────────────────────────────────────────┐
        │  Monitoring · métricas de plataforma                  │
        └──────────┬─────────────────────────┬─────────────────┘
                   │                         │
     UnHealthyBackendServers            CpuUtilization
     [1m].max() > 0   · 2 min           [1m].mean() > 45 · 3 min
                   │                         │
                   ▼                         ▼
        ┌──────────────────────────────────────────────────────┐
        │  Alarmas                                              │
        │    lab05-backends-no-saludables   CRITICAL            │
        │    lab05-saturacion-cpu           WARNING             │
        └───────────────────────┬──────────────────────────────┘
                                ▼
        ┌──────────────────────────────────────────────────────┐
        │  Notifications · tema lab05-alarmas-operacion         │
        │  suscripción de correo   ← PENDING hasta el clic      │
        └───────────────────────┬──────────────────────────────┘
                                ▼
                  correo con el ENLACE AL RUNBOOK dentro

La decisión que este laboratorio ayuda a tomar

No es «qué herramienta de monitoreo compramos». Es esta:

¿Qué merece despertar a alguien de madrugada y qué puede esperar al día siguiente?

Todo el laboratorio está construido para hacer visible esa pregunta con un caso concreto. La demostración central es un ciclo completo que se midió de punta a punta:

La alarma sonó, el autoescalamiento agregó capacidad, la CPU por instancia bajó y la alarma se cerró sin que nadie hiciera nada. Esa secuencia es el argumento del laboratorio: una alarma que se resuelve sola no debía despertar a nadie, pero tampoco debía desaparecer sin dejar rastro. Distinguir lo que se atiende ahora de lo que hay que saber es lo que separa a un equipo que apaga incendios de uno que opera.

El entregable no es la alarma: es la matriz de señales del capítulo 13.

---

2. Equivalencias con otras nubes

Solo los servicios que aparecen en este manual.

Tres diferencias que cuestan tiempo si se llega con el modelo mental de otra nube:

• La alarma y el recurso observado pueden vivir en compartimentos distintos, y en la práctica conviene que así sea. En la pantalla de creación de la alarma hay dos campos de compartimento y no significan lo mismo. Es el error de configuración más frecuente de este laboratorio.
• El compartimento no es un grupo de recursos de Azure ni una cuenta de AWS. Es un contenedor lógico con jerarquía y políticas propias, dentro de un solo tenancy.
• Audit está siempre encendido. No hay que habilitar un «trail». Los registros de red y de servicio sí hay que habilitarlos uno por uno, y por eso tienen su propio capítulo.

---

3. Prerrequisitos

3.1 Lo que debe existir antes de empezar

Los dos compartimentos podrían ser el mismo, pero se separan a propósito: la operación mira todo desde un solo lugar aunque los recursos vivan repartidos. Ese es el modelo que sirve cuando hay más de un ambiente.

3.2 Permisos

Si usted es administrador del tenancy, puede saltarse esta sección. Si no, el grupo al que pertenece necesita al menos estas sentencias, expresadas en el lenguaje de políticas de OCI:

Allow group Operacion to manage alarms in compartment lab-05-observabilidad
Allow group Operacion to manage ons-topics in compartment lab-05-observabilidad
Allow group Operacion to read metrics in compartment lab-laboratorio
Allow group Operacion to manage log-groups in compartment lab-05-observabilidad
Allow group Operacion to manage log-content in compartment lab-05-observabilidad
Allow group Operacion to read instance-family in compartment lab-laboratorio
Allow group Operacion to read load-balancers in compartment lab-laboratorio

Dos detalles fáciles de pasar por alto:

• read metrics va sobre el compartimento del servicio observado, no sobre el de las alarmas. Sin ese permiso la pantalla de creación de la alarma se ve completa pero el desplegable de métricas aparece vacío.
• manage ons-topics es necesario para que la alarma pueda escribir en el tema.

Consola de OCIIdentity & Security › Policies

3.3 Verificar el plugin de monitoreo

Las métricas de CPU del espacio de nombres oci_computeagent las publica un plugin del agente que corre dentro de cada instancia. Si está deshabilitado, no hay métrica; si no hay métrica, la alarma se crea igual y nunca suena.

Consola de OCICompute › Instances › (una instancia del grupo) › Oracle Cloud Agent

1. Abra una de las instancias que están detrás del balanceador.
2. Entre a la pestaña del agente de Oracle Cloud.
3. Confirme que el plugin de monitoreo de la instancia de cómputo está habilitado.
4. Repita en una segunda instancia. Si el grupo crece por autoescalamiento, las instancias nuevas heredan la configuración de la plantilla del grupo: si la plantilla lo tiene apagado, las nuevas nacen ciegas.

Una alarma sobre una métrica que no existe se crea sin ningún error. La consola acepta cualquier nombre de métrica. Si el nombre está mal escrito, si el espacio de nombres no es el correcto o si el plugin está apagado, la alarma queda creada, se ve perfecta en la lista y nunca dispara.

Es la peor forma de fallar, porque parece que funciona. Por eso el capítulo 6 explora la métrica en el gráfico antes de crear la alarma: si el número no se ve dibujado en pantalla, la alarma no va a servir.

3.4 Cuotas y límites en una cuenta de prueba

El ensayo completo del laboratorio midió 0,13 USD de cómputo en total, y la capa de observabilidad no movió esa cifra de forma apreciable.

3.5 Una advertencia sobre el ambiente observado

El servicio que se observa tiene el puerto 22 y el bastión abiertos a 0.0.0.0/0. Está así a propósito, por ser un ambiente desechable que se destruye al final del día y no tiene datos. No es una recomendación.

En un ambiente con datos, el acceso administrativo se restringe a los bloques CIDR concretos desde los que se administra, el bastión lleva su propia lista de clientes permitidos y el puerto 22 no se expone a internet en ninguna subred. Lo señalamos aquí porque más adelante, en los registros de red, ese 0.0.0.0/0 va a aparecer en forma de tráfico que nadie esperaba.

---

4. El tema de notificaciones

El tema es el buzón al que las alarmas escriben. Las alarmas no envían correos: publican en un tema, y el tema reparte a sus suscriptores. Esa indirección es la que permite cambiar destinatarios sin tocar ninguna alarma.

Consola de OCIObservability & Management › Notifications › Topics › Create Topic

1. Abra el menú de navegación de la consola. Si no encuentra Notifications en el menú, escríbalo en la barra de búsqueda de la consola: en algunas versiones el servicio aparece además bajo la categoría de integración de aplicaciones. Es el mismo servicio.
2. Verifique en el selector de compartimento de la izquierda que está parado en el compartimento de observabilidad. Todo lo que cree a continuación nace ahí.
3. Presione Create Topic.
4. En Name, escriba lab05-alarmas-operacion. El nombre admite letras, números, guiones y guiones bajos; no admite espacios.
5. En Description, escriba una línea que diga de quién son estas alarmas. En seis meses, con cuatro temas creados, la descripción es lo único que los distingue.
6. Agregue etiquetas de forma libre. Para un laboratorio son útiles tres:

La tercera es la que permite encontrar y borrar después todo lo que era desechable. Un recurso sin etiqueta de dueño sobrevive a todas las limpiezas.

1. Presione Create. El tema aparece en la lista en estado activo, con su OCID visible en la página de detalle: algo de la forma ocid1.onstopic.oc1..aaaaEJEMPLO.

Un tema por audiencia, no por alarma. La tentación es crear un tema por alarma. Termina en veinte temas y nadie sabe quién está suscrito a qué.

El criterio útil es la audiencia: un tema para lo que atiende el turno de operación, otro para lo que va a seguridad, otro para lo que le interesa a quien mira el presupuesto. Las alarmas cambian; las audiencias, casi nunca.

---

5. La suscripción de correo, y el clic que no se puede saltar

Este capítulo tiene un solo paso que importa, y es el que más veces se salta.

Consola de OCIObservability & Management › Notifications › Topics › lab05-alarmas-operacion › Create Subscription

1. Entre al tema que acaba de crear.
2. En el panel de recursos de la izquierda, seleccione la lista de suscripciones.
3. Presione Create Subscription.
4. En Protocol, elija el protocolo de correo electrónico. El desplegable trae también mensajería, funciones y llamadas HTTPS; para este laboratorio es correo.
5. Escriba la dirección de destino. Por ejemplo, operacion@ejemplo.com.
6. Presione Create.
7. Mire la columna de estado en la lista de suscripciones. Dice Pending.

El estado que decide si todo esto sirve

1. Abra el correo. El remitente es el servicio de notificaciones de Oracle Cloud y el cuerpo trae un enlace de confirmación.
2. Haga clic en el enlace. Se abre una página que confirma la suscripción.
3. Vuelva a la consola y refresque la lista. El estado debe decir Active.

1. Si el correo no aparece en unos minutos, revise la carpeta de no deseados. Los filtros corporativos son especialmente aficionados a los correos con enlaces de confirmación.
2. Si aun así no llega, el menú de acciones de la suscripción permite reenviar la confirmación. Úselo antes de borrar y volver a crear: una suscripción borrada y recreada genera otro correo idéntico, y termina con dos pendientes.

Verificación por CLI

La consola ya lo dice, pero este es el comando que conviene dejar anotado, porque es el que se corre sin abrir el navegador antes de una jornada importante:

COMP07="ocid1.compartment.oc1..aaaaEJEMPLO"

oci ons subscription list --compartment-id "$COMP07" \
  --query 'data[].{correo:endpoint,estado:"lifecycle-state"}' --output table

En el ensayo de este laboratorio, esta verificación fue el único punto pendiente de toda la preparación, y se resolvió confirmando la suscripción el mismo día en que se creó. La regla que salió de ahí: crear la suscripción y confirmarla son el mismo paso, no dos.

Una prueba de 30 segundos que ahorra una madrugada

1. En la página del tema, use la acción de publicar un mensaje de prueba.
2. Escriba cualquier texto en el cuerpo y envíelo.
3. El correo debe llegar en menos de un minuto.

Si llega, la cadena tema → suscripción → bandeja de entrada está probada y ya no va a ser la causa de que una alarma no se vea. Si no llega, el problema está aquí y no en la alarma que todavía no ha creado. Probar la cadena por partes, en orden, es lo que evita diagnosticar tres cosas a la vez.

---

6. La métrica antes de la alarma: el explorador y su lenguaje de consulta

Antes de crear la alarma hay que ver la métrica dibujada. Este capítulo no crea nada: prepara la consulta que el siguiente capítulo va a usar.

6.1 Ver la métrica

Consola de OCIObservability & Management › Monitoring › Metrics Explorer

1. Abra el explorador de métricas.
2. En Compartment, seleccione el compartimento donde viven las instancias. No el de observabilidad. Si se equivoca aquí, el desplegable de métricas aparece vacío y parece un problema de permisos.
3. En Metric namespace, elija oci_computeagent. Los espacios de nombres son la forma en que OCI separa las métricas por servicio: oci_computeagent para lo que publica el agente dentro de la instancia, oci_lbaas para el balanceador, oci_vcn para la red, y así.
4. En Metric name, elija CpuUtilization.
5. Deje Interval en 1m y Statistic en el promedio.
6. Actualice el gráfico.
7. Debe ver una línea con datos. Si el gráfico está vacío:

1. Fíjese en que hay varias líneas, una por instancia. Cada combinación de dimensiones es una serie distinta. Esto va a importar en el capítulo 9.

6.2 Cómo se arma la expresión

La consola tiene dos formas de decir lo mismo. En el modo básico usted llena campos; al activar el modo avanzado, la consola le muestra la consulta que esos campos producen, escrita en MQL, el lenguaje de consulta de métricas de OCI.

Vale la pena mirarla una vez, porque es la que va a leer cuando algo no dispare:

  CpuUtilization  [1m]   .mean()       >       45
  ───────┬──────  ──┬──  ───┬───       ┬       ─┬
         │          │       │          │        │
         │          │       │          │        └─ valor del umbral
         │          │       │          └────────── operador del disparador
         │          │       └───────────────────── estadística
         │          └───────────────────────────── intervalo (la ventana)
         └──────────────────────────────────────── nombre de la métrica

Y la equivalencia con los campos de la consola:

6.3 El intervalo

El intervalo es la ventana sobre la que se agrupan los datos crudos antes de aplicar la estadística. Con [1m], cada punto de la serie resume un minuto de mediciones.

Un intervalo más corto no es «mejor»: es más sensible. Y más sensible, en una señal ruidosa, significa más correos que nadie va a leer.

Hay un piso que no se puede bajar: el intervalo no puede ser más fino que la frecuencia con la que el servicio publica la métrica. Pedir [10s] sobre una métrica que se publica cada minuto no da más resolución; da huecos.

6.4 La estadística

La estadística resuelve los puntos de la ventana en un solo número. La elección cambia por completo lo que la alarma significa.

La regla práctica, y es la que se aplica en las dos alarmas de este manual:

• Para causas —CPU, memoria, disco— se usa mean(). Un pico de un minuto no es un problema; un promedio sostenido sí.
• Para síntomas —backends caídos, errores— se usa max(). Si pasó una sola vez, ya pasó, y el usuario ya lo sintió.

La latencia promedio esconde justamente lo que hay que ver. Un promedio de 200 ms puede ser un servicio impecable o uno donde el 5 % de los usuarios espera 8 segundos. El promedio no los distingue; el percentil 95 sí.

Para cualquier señal de experiencia de usuario —latencia, tiempo de respuesta, tiempo de proceso— la estadística por defecto debería ser un percentil alto y no el promedio. Es el cambio de una sola casilla que más mejora un modelo de observabilidad heredado.

6.5 Dimensiones y agrupación

Una métrica no es una línea: es un conjunto de líneas, una por combinación de dimensiones. CpuUtilization trae, entre otras, el identificador del recurso y su nombre visible.

En la consulta, las dimensiones se filtran entre llaves:

CpuUtilization[1m]{resourceDisplayName = "lab01-app"}.mean() > 45

Y hay una decisión de fondo, que es la que explica por qué la alarma de este laboratorio se cierra sola:

• Sin agrupar (lo que hace este manual), la alarma evalúa la condición por cada instancia. Si una instancia pasa del umbral, la alarma dispara.
• Agrupando con .grouping(), todas las series se colapsan en una sola y la condición se evalúa sobre el conjunto.

Como aquí se evalúa por instancia y el promedio de CPU por instancia baja cuando el grupo crece, el autoescalamiento apaga la alarma sin que nadie intervenga. Si se agrupara por suma, el total no bajaría al crecer el grupo y la alarma no se cerraría nunca. La misma métrica, el mismo umbral, y un comportamiento opuesto.

6.6 La función que detecta la ceguera

MQL tiene una función que casi nadie usa y que resuelve el estado más peligroso de todos:

CpuUtilization[5m].absent()

Dispara cuando la métrica deja de llegar. Es la alarma sobre la alarma: avisa de que el plugin se apagó, de que la instancia desapareció o de que alguien cambió el nombre de algo.

No la vamos a crear en este laboratorio, pero conviene saber que existe, porque el capítulo 14 muestra por qué hace falta: una alarma sin datos se ve exactamente igual que una alarma tranquila.

---

7. La alarma de saturación de CPU

Primera alarma. Es una causa: avisa de que algo puede estar por degradarse, no de que el usuario ya lo esté sintiendo. Por eso su severidad es WARNING.

Consola de OCIObservability & Management › Monitoring › Alarm Definitions › Create Alarm

7.1 Definición de la alarma

1. Entre a las definiciones de alarma y presione Create Alarm.
2. En Alarm name, escriba lab05-saturacion-cpu. El nombre viaja en el asunto del correo: si no se entiende en el asunto, no se entiende a las tres de la mañana.
3. En Alarm severity, elija Warning.

1. Confirme que el compartimento de la alarma es el de observabilidad.

7.2 Descripción de la métrica — los dos compartimentos

1. Baje a la sección donde se describe la métrica.
2. Cambie el compartimento al del servicio observado. Este campo viene precargado con el compartimento de la alarma y ahí está la trampa.

1. Elija el espacio de nombres oci_computeagent y la métrica CpuUtilization. Si el desplegable aparece vacío, vuelva al paso 6: casi siempre es el compartimento.
2. Deje Interval en 1m y Statistic en el promedio.
3. No agregue dimensiones. Queremos que la alarma evalúe instancia por instancia, por la razón de la sección 6.5.
4. Si quiere confirmar la consulta, active el modo avanzado. Debe leerse:

CpuUtilization[1m].mean() > 45

7.3 La regla del disparador

1. En Operator, elija «mayor que».
2. En Value, escriba 45.

El número no es arbitrario. El servicio observado tiene autoescalamiento configurado con un umbral de 55 %. La alarma se pone por debajo: en 45. Así la alarma suena primero y el autoescalamiento la apaga después. Si la alarma estuviera por encima del umbral de escalamiento, la plataforma reaccionaría antes de que la CPU llegara al umbral de la alarma y la alarma no sonaría nunca.

1. En el retardo del disparador, escriba 3 minutos. Es la traducción del valor ISO-8601 PT3M: la condición tiene que sostenerse tres minutos seguidos antes de que la alarma pase a FIRING.

Sin ese retardo, cualquier pico de treinta segundos genera un correo. En dos semanas nadie los lee, y entre esos correos que nadie lee va a estar el que sí importaba.

7.4 A dónde llega

1. En la sección de destino, elija el servicio de notificaciones.
2. Seleccione el compartimento de observabilidad y el tema lab05-alarmas-operacion. Si no aparece, revise que el selector de compartimento sea el correcto.
3. Deje el formato de mensaje en la opción de mensaje formateado —la que corresponde al valor ONS_OPTIMIZED—. Las otras opciones entregan el evento en crudo o en JSON, que sirven cuando el destino es una función o un sistema de tiquetes, no un ser humano.

7.5 El cuerpo del mensaje — el paso que de verdad baja el tiempo de recuperación

1. En el cuerpo de la alarma, escriba un texto que sirva a alguien con sueño:

La CPU del servicio superó el 45 % durante 3 minutos.

QUE HACER (runbook): https://<su-repo>/runbooks/RUNBOOK-saturacion-cpu.md

Antes de escalar manualmente, verificar si el autoescalamiento ya reaccionó:
si el grupo creció y la carga es legítima, esta alarma se cierra sola y NO
requiere acción — solo queda registrada para la revisión semanal.

Tres cosas, y ninguna es decorativa:

• El enlace al runbook viaja dentro del correo. Quien lo recibe de madrugada no tiene que buscar en ningún wiki. Esto es lo que baja el tiempo de recuperación: no el tablero, no la herramienta, sino que la instrucción viaje con la alarma.
• La primera instrucción es descartar, no diagnosticar. «¿La plataforma ya lo está resolviendo sola?» es la pregunta que ahorra la mitad de las madrugadas.
• Dice explícitamente que puede no requerir acción. Un runbook que solo contempla la rama «hay que hacer algo» entrena al equipo a hacer algo siempre.

El cuerpo del mensaje es el runbook de emergencia. Si mañana el repositorio de runbooks no abre —porque es privado, porque cambió la ruta, porque la VPN no levanta—, lo único que queda es el texto del correo.

Escríbalo pensando en eso: tres líneas que digan qué significa la alarma, qué revisar primero y a quién llamar si eso no alcanza. El enlace es el detalle; el texto es el respaldo del enlace.

7.6 Repetición y cierre

1. Habilite la repetición de la notificación y póngale 30 minutos. Mientras la alarma siga disparada, llega un recordatorio cada media hora.

Más frecuente cansa y se convierte en ruido. Menos frecuente deja que algo se olvide durante un turno entero.

1. Deje habilitada la alarma.
2. Agregue las mismas etiquetas del tema.
3. Presione Save alarm.

La alarma aparece en la lista. En la página de detalle verá su OCID (ocid1.alarm.oc1..aaaaEJEMPLO) y un gráfico con la métrica y la línea del umbral dibujada encima. Ese gráfico es la primera validación: si la línea del umbral está muy por encima de todo lo que se ve, la alarma nunca va a sonar; si está por debajo del ruido de fondo, va a sonar siempre.

---

8. La alarma de backends no saludables

Segunda alarma. Esta es un síntoma: si hay servidores que no pasan la verificación de salud, el usuario ya está viendo errores o lentitud. Por eso su severidad es mayor aunque el número sea más pequeño.

Consola de OCIObservability & Management › Monitoring › Alarm Definitions › Create Alarm

1. Cree una alarma nueva con el nombre lab05-backends-no-saludables.
2. En severidad, elija Critical.
3. En la descripción de la métrica, vuelva a cambiar el compartimento al del servicio observado.
4. Elija el espacio de nombres oci_lbaas y la métrica UnHealthyBackendServers.
5. Deje el intervalo en 1m y elija la estadística máximo, no el promedio. Con el promedio, un backend caído entre cuatro daría 0,25 y no pasaría el umbral de cero. Con el máximo, basta con que uno esté caído en cualquier punto de la ventana.
6. Operador «mayor que», valor 0.
7. Retardo del disparador: 2 minutos. Más corto que el de CPU, porque el impacto es inmediato. Pero no cero: cuando el grupo crece, una instancia recién creada aparece como no saludable durante unos segundos hasta que la aplicación levanta, y sin esos dos minutos el autoescalamiento generaría una alarma crítica cada vez que hace su trabajo.
8. La consulta, en modo avanzado, debe leerse:

UnHealthyBackendServers[1m].max() > 0

1. Destino: el mismo tema lab05-alarmas-operacion.
2. Cuerpo del mensaje:

Hay servidores detrás del balanceador que no pasan la verificación de salud.
El usuario final puede estar viendo errores o lentitud.

QUE HACER (runbook): https://<su-repo>/runbooks/RUNBOOK-backends-caidos.md

1. Guarde.

Por qué esta es CRITICAL y la de CPU es WARNING

La severidad la define el impacto, no la magnitud de la métrica. Es la confusión más frecuente al heredar un modelo de monitoreo: alguien pone CRITICAL en la CPU porque 90 % suena más grave que 1, y termina con un turno de guardia que se despierta por cosas que se resuelven solas.

Nadie llama al soporte para decir «su CPU está al 80 %». Llaman porque no les carga una pantalla.

---

9. Umbral, ventana y retardo: ajustar sin fabricar ruido

Las alarmas ya existen. Este capítulo es sobre editarlas, que es lo que de verdad se hace durante las primeras semanas de operación.

Consola de OCIObservability & Management › Monitoring › Alarm Definitions › (la alarma) › Edit

9.1 Los tres números y qué mueve cada uno

El tiempo total hasta el correo es aproximadamente la suma de tres cosas:

  tiempo hasta el correo  ≈   publicación de la métrica
                            + intervalo
                            + retardo del disparador
                            + entrega del correo (< 1 min)

Con los valores de este manual —1m de intervalo y 3 minutos de retardo— la alarma de CPU tarda del orden de cuatro a cinco minutos desde que la carga empieza hasta que el correo llega. Ese número hay que medirlo, no estimarlo, y el capítulo 14 explica cómo.

9.2 El umbral y la ventana deciden juntos si la alarma sirve

9.3 Ajustes según el síntoma

Esta tabla viene del laboratorio y resuelve casi todo lo que aparece al ajustar:

Los dos últimos son los interesantes.

Que no suene nunca casi siempre es configuración: umbral inalcanzable, compartimento equivocado o métrica que no se publica.

Que no se cierre nunca casi nunca es configuración: normalmente significa que la plataforma hizo todo lo que podía y no alcanzó. Esa alarma sí merece a alguien despierto.

9.4 Que la alarma se cierre sola es tan importante como que dispare

Una alarma tiene dos transiciones, no una: entra en FIRING y vuelve a OK. La segunda casi nunca se diseña, y es la que decide si el equipo le va a hacer caso a la primera.

• Si se cierra sola, quien la recibió sabe que la plataforma reaccionó. La alarma queda registrada para la revisión semanal y nadie se levanta.
• Si no se cierra sola nunca, cada alarma queda abierta para siempre. El panel se llena de rojo permanente, y el rojo permanente es indistinguible del rojo nuevo. A las tres semanas nadie mira el panel.

Para que se cierre sola hacen falta dos condiciones, y las dos se configuran en esta pantalla:

1. Que la condición pueda dejar de cumplirse. Una alarma sobre un contador acumulado —sum() de errores desde siempre— nunca baja. Si la métrica solo crece, la alarma no se cierra jamás: hay que medir tasa, no total.
2. Que la agrupación deje bajar el número. Es el caso de la sección 6.5: sin agrupar, la CPU por instancia baja al crecer el grupo y la alarma se cierra; agrupando por suma, el total no baja y la alarma se queda encendida.

9.5 Ventanas de silencio para mantenimientos

La pantalla de la alarma permite suprimir notificaciones durante un rango de fechas. Sirve para un mantenimiento planificado.

Dos advertencias de uso:

• Supresión con fecha de fin, siempre. Una supresión indefinida es una alarma apagada que todo el mundo cree encendida.
• La alarma sigue evaluando durante la supresión; lo que se silencia es la notificación. En el histórico va a poder ver que disparó, lo cual es exactamente lo que se quiere para el informe posterior.

---

10. El tablero: ver varias señales juntas

Un tablero no reemplaza a una alarma. La alarma es para lo que no se está mirando; el tablero es para cuando ya se está mirando. Confundirlos produce equipos que tienen pantallas enormes y se enteran por el cliente.

10.1 El panel rápido: métricas por servicio

Consola de OCIObservability & Management › Monitoring › Service Metrics

1. Seleccione el compartimento y el espacio de nombres.
2. La página dibuja de una vez todas las métricas de ese espacio de nombres, cada una en su gráfico: CPU, memoria, red, disco.
3. Cambie el espacio de nombres a oci_lbaas y va a ver las del balanceador: peticiones, backends saludables y no saludables, bytes.
4. En el menú de opciones de cada gráfico hay una acción para crear una alarma a partir de esa consulta. Es el camino corto: en vez de llenar la pantalla de creación desde cero, se parte de una consulta que ya está dibujada y que, por estar dibujada, se sabe que tiene datos.

10.2 El estado de las alarmas

Consola de OCIObservability & Management › Monitoring › Alarm Status

1. La página lista las alarmas con su estado actual. Es la pantalla que se deja abierta en una jornada de operación.
2. Entre a una alarma. En su página de detalle está el histórico de transiciones: cuándo pasó a FIRING, cuándo volvió a OK. Ese histórico es la evidencia del ciclo completo y es lo que se guarda para la revisión semanal.

10.3 Un tablero propio

Consola de OCIObservability & Management › Dashboards

1. Cree un tablero nuevo en el compartimento de observabilidad. [VALIDAR] la ruta exacta del menú en la versión de consola que tenga: en algunas versiones los tableros se alcanzan desde el propio servicio de monitoreo.
2. Agregue widgets. Para este servicio, cuatro alcanzan:

1. El cuarto es el que casi nadie pone y el que más explica: viendo la CPU y el tamaño del grupo en la misma pantalla, el ciclo «sube la carga, crece el grupo, baja la CPU» se lee de un vistazo, sin narración.

Cuatro widgets que se miran valen más que veinte que se ignoran. El tablero útil cabe en una pantalla y responde cinco preguntas: ¿está arriba?, ¿va rápido?, ¿está fallando?, ¿aguanta lo que viene?, ¿cuánto cuesta?

La quinta es la que casi siempre falta, y es la que más agradece quien firma el presupuesto.

---

11. Los registros: logs de servicio y flow logs

Las métricas dicen que algo pasa. Los registros dicen qué pasó. La cadena completa de un diagnóstico es: alarma → métrica → registro → recurso. Sin el tercer eslabón, cuando algo no se resuelve solo, hay que entrar a las máquinas a mirar archivos, y eso a las tres de la mañana no escala.

En OCI los registros se organizan en grupos de registro (log groups) que contienen registros (logs). Los de servicio se habilitan uno por uno: no vienen encendidos.

11.1 Crear el grupo de registro

Consola de OCIObservability & Management › Logging › Log Groups › Create Log Group

1. Entre a los grupos de registro y presione Create Log Group.
2. Nómbrelo lab05-logs.
3. Presione Create.

El grupo es un contenedor: no ingiere nada por sí mismo y no cobra. Sirve para aplicar permisos y retención a un conjunto de registros de una vez.

11.2 Habilitar los flow logs de la subred

Los flow logs registran quién habló con quién dentro de la red: origen, destino, puerto, si se aceptó o se rechazó. Es el registro que responde la pregunta «¿esto llegó a entrar?» sin tener que entrar a ninguna máquina.

Consola de OCIObservability & Management › Logging › Logs › Enable service log

1. En la lista de registros, presione la acción de habilitar un registro de servicio.
2. Seleccione el compartimento del servicio observado.
3. En el desplegable de servicio, elija el de registros de flujo de red. Ese desplegable es, además, el catálogo de qué servicios de OCI pueden publicar registros: vale la pena abrirlo una vez y mirarlo entero.
4. En el recurso, elija la subred de aplicación. Los flow logs se habilitan por subred o por VCN, no por instancia.
5. Elija la categoría que incluye todos los registros.
6. Nombre el registro lab05-flowlogs-app.
7. Abra las opciones avanzadas y seleccione el grupo lab05-logs. Si no lo hace, la consola va a crear o elegir otro grupo y el registro va a terminar donde no lo va a buscar.
8. Deje la retención en 30 días. Es suficiente para investigar un incidente, y la retención es el principal multiplicador de la factura de registros.
9. Presione Enable log.

11.3 Habilitar los registros del balanceador

1. Repita la operación con el balanceador como recurso. Sus categorías de registro son dos y sirven para cosas distintas:

1. El registro de acceso es el que permite responder «¿cuántos 5xx hubo entre las 14:10 y las 14:20 y en qué rutas?», que es la pregunta que sigue a casi cualquier alarma de errores.

11.4 Lo que ya está registrado sin hacer nada

Audit merece una mención aparte, porque resuelve solo la pregunta más frecuente después de una caída: ¿qué cambió? La causa más probable de una caída total no es una avería: es un cambio. Audit está encendido desde el primer día del tenancy y nadie tiene que acordarse de habilitarlo.

---

12. Consultar los registros

Habilitar registros que nadie sabe consultar es gastar dinero en almacenamiento. Este capítulo es el que convierte el gasto en capacidad de diagnóstico.

Consola de OCIObservability & Management › Logging › Search

1. Abra la búsqueda de registros.
2. Seleccione el rango de tiempo. Empiece por la última hora: los rangos amplios sobre registros grandes tardan y casi nunca hacen falta al principio.
3. Seleccione qué registros buscar. Puede elegir un compartimento entero, un grupo de registro o un registro concreto. Para empezar, elija lab05-flowlogs-app.
4. La consola arma una consulta base y muestra los resultados más recientes. Verifique que hay líneas. Si no hay ninguna después de diez minutos, el registro está habilitado pero no está recibiendo: revise que la subred elegida sea la que tiene tráfico.

12.1 El lenguaje de consulta

La consulta base tiene esta forma:

search "<compartimento>/<grupo de registro>/<registro>"

Y se encadenan operaciones con barras verticales, igual que en una tubería de shell:

search "lab-laboratorio/lab05-logs/lab05-flowlogs-app"
  | sort by datetime desc

Filtrar por un campo:

search "lab-laboratorio/lab05-logs/lab05-flowlogs-app"
  | where data.destinationPort = 80
  | sort by datetime desc

Agrupar y contar, que es lo que responde «¿quién está generando este tráfico?»:

search "lab-laboratorio/lab05-logs/lab05-flowlogs-app"
  | where data.destinationPort = 80
  | summarize count() by data.sourceAddress

Los campos propios de cada registro van bajo el prefijo data. Para los flow logs, los más usados son la dirección de origen, la de destino, el puerto de destino, el protocolo y el resultado (si el paquete se aceptó o se rechazó). [VALIDAR] el nombre exacto del campo de resultado en su versión: cambió entre versiones del formato de flow logs, y la forma segura de averiguarlo es expandir una línea de resultado en la consola y leer los nombres reales.

Ese, de hecho, es el método general y vale para cualquier registro nuevo:

1. Corra la consulta base sin filtros.
2. Expanda una línea de resultado.
3. Lea los nombres de campo que trae.
4. Escriba el filtro con esos nombres.

Es más rápido que buscar el esquema en la documentación, y no se equivoca.

12.2 Tres consultas que vale la pena dejar guardadas

Tráfico rechazado en la última hora. Responde «¿alguien está tocando puertas que no debería?»:

search "lab-laboratorio/lab05-logs/lab05-flowlogs-app"
  | where <campo de resultado> = 'REJECT'
  | summarize count() by data.sourceAddress

En el servicio observado, con el puerto 22 abierto a 0.0.0.0/0, esta consulta devuelve tráfico de escaneo desde internet a las pocas horas de levantar el ambiente. Es la demostración más concreta de por qué esa apertura es aceptable en un laboratorio desechable y no lo es en un ambiente con datos.

Códigos de respuesta del balanceador, sobre el registro de acceso:

search "lab-laboratorio/lab05-logs/<registro de acceso del balanceador>"
  | summarize count() by <campo del codigo de respuesta>

Qué cambió en la última hora, sobre Audit. Es la primera consulta después de cualquier caída inesperada:

search "lab-laboratorio/_Audit"
  | sort by datetime desc

1. Cada consulta útil se guarda. La consola permite guardar búsquedas; una búsqueda guardada con un nombre claro es, en la práctica, un runbook de una sola línea.

12.3 La cadena completa, con un ejemplo

Así se ve el diagnóstico cuando las tres capas están puestas:

  1. Llega el correo          alarma lab05-backends-no-saludables · CRITICAL
           │
  2. Métrica                  UnHealthyBackendServers: de 0 a 2 a las 14:12
           │
  3. Registro de acceso       5xx desde las 14:11, en dos backends
           │
  4. Audit                    a las 14:09 alguien modificó una regla de red
           │
  5. Recurso                  se revierte el cambio · el servicio vuelve

Sin el paso 4, el equipo habría reiniciado instancias durante veinte minutos. La causa más probable de una caída total es un cambio, no una avería, y el registro que lo dice ya estaba encendido.

---

13. La matriz: qué despierta a alguien y qué no

Este es el entregable del laboratorio. Las alarmas de los capítulos 7 y 8 son dos ejemplos; la matriz es el método.

La idea es simple y difícil de sostener: una alarma sin acción escrita no es una alarma, es ruido. Y el ruido tiene un costo que se paga tarde: dentro de seis meses nadie mira las alarmas, incluidas las buenas.

13.1 Síntoma y causa

La distinción que ordena todo lo demás:

La mayoría de los equipos empieza por las causas, porque son las fáciles de medir: la nube las regala. Pero nadie llama al soporte para decir que una CPU está al 80 %.

13.2 Las cuatro preguntas por señal

Por cada señal candidata se responden cuatro cosas, en este orden:

1. ¿Qué umbral?
2. ¿Quién responde?
3. ¿Qué hace? (el runbook, aunque sea de tres líneas)
4. ¿Esto despierta a alguien de madrugada?

La cuarta es la que hace trabajar a la matriz. En cuanto alguien dice «sí, despierta» y la casilla de acción está vacía, esa fila es ruido — y tiene exactamente dos salidas válidas: escribirle la acción, o bajarle la severidad. Dejarla como está no es una de ellas.

13.3 El catálogo de partida

Dieciséis señales candidatas en diez categorías. Las dos que este manual construyó son la S-06 y la S-07.

Dos filas donde conviene detenerse:

• S-13, el costo. Casi nadie la tiene como señal de operación, y es la que más agradece quien firma el presupuesto. Se implementa con presupuestos y alertas, no con alarmas de métrica.
• S-11 y S-12, las de negocio. Son las únicas que detectan que el servicio está roto para el cliente aunque toda la infraestructura esté verde. Salen de una consulta a la base de datos, no de una métrica de plataforma.

13.4 Cómo se lee el resultado

Con la matriz llena, tres lecturas:

1. Señales que despiertan sin acción escrita. Si el número no es cero, esa es la primera semana de trabajo — y es la más barata de todas, porque consiste en escribir, no en construir.
2. Cobertura por categoría. Las categorías vacías son puntos ciegos. Disponibilidad y Errores no se pueden quedar vacías: son las dos que el cliente nota primero.
3. Señales que despiertan 24x7. Si son más de seis o siete, es una promesa que ningún equipo pequeño sostiene. Mejor menos alarmas y que se les haga caso.

13.5 El número que casi nadie mide

Cuatro indicadores rodean esta conversación, y el más útil es el que menos se mide:

Si el cliente avisa antes que la alarma, el problema no fue la caída: fue la observabilidad. Y ese es un problema que se arregla con configuración, no con más infraestructura.

Y sobre los «nueves», la conversación honesta:

Cada nueve adicional cuesta del orden de diez veces más. Prometer 99,9 % sin guardia ni redundancia no es un compromiso: es una esperanza.

---

14. Validación de extremo a extremo

Nada de lo anterior está validado hasta que la alarma complete el ciclo: OK → FIRING → OK. Este capítulo lo provoca y lo mide.

14.1 Antes de generar carga

Consola de OCIObservability & Management › Monitoring › Alarm Status

1. Confirme que las dos alarmas aparecen y que su estado es OK.
2. Confirme que la suscripción está en ACTIVE, no en PENDING. Si se saltó el capítulo 5, este es el momento en que el laboratorio deja de funcionar.
3. Anote la hora. Va a necesitarla.

La verificación equivalente por CLI, que es la que se deja corriendo en una pantalla durante una jornada de operación:

COMP07="ocid1.compartment.oc1..aaaaEJEMPLO"

oci monitoring alarm-status list-alarms-status --compartment-id "$COMP07" \
  --query 'data[].{alarma:"display-name",estado:status}' --output table

Dos detalles del comando, que costaron una corrección en el laboratorio:

• El subcomando es list-alarms-status, no list. oci monitoring alarm-status list no existe.
• Para la salud de los backends el comando es oci lb backend-set-health get. oci lb backend-health list tampoco existe.

14.2 Provocar el ciclo

1. Genere carga contra el balanceador. Cualquier generador sirve mientras sostenga la CPU por encima del umbral durante varios minutos; lo importante es que la carga sea suficiente para pasar de 45 % y no tanta como para saturar de inmediato.
2. Quédese mirando la pantalla de estado de alarmas y cronometre.

Esto es lo que debe pasar, y en este orden:

  t0         empieza la carga
   │
   ├─ ~1 min   el agente publica el primer punto por encima de 45 %
   │
   ├─ +3 min   se cumple el retardo del disparador → la alarma pasa a FIRING
   │
   ├─ <1 min   el correo llega a la bandeja de entrada
   │
   ├─ ~7 min   el autoescalamiento agrega instancias
   │           (medido en el laboratorio de elasticidad: 410 s para pasar de 2 a 4)
   │
   ├─ ~12 min  la capacidad nueva ya atiende tráfico
   │           (medido: 707 s)
   │
   └─ la CPU por instancia baja de 45 % → la alarma vuelve a OK, sola

1. Cuando el estado cambie a FIRING, abra el correo. Debe haber llegado en menos de un minuto. Mire el cuerpo: trae el enlace al runbook. Eso es lo que va a leer alguien de madrugada, y es la pieza que de verdad baja el tiempo de recuperación.
2. No haga nada más. Deje correr.
3. El grupo de instancias crece, la CPU por instancia baja y la alarma vuelve a OK sin intervención.

14.3 Los números medidos

Este es el resultado real del ensayo de este laboratorio, y es el que se cita en vez de estimar:

Del laboratorio de elasticidad, que es lo que explica los tiempos del diagrama:

14.4 Evidencia que conviene guardar

Antes de compartir cualquier captura del correo, revise que no aparezcan direcciones de correo ni identificadores internos.

---

15. Qué puede salir mal

Los errores de esta tabla están documentados en el laboratorio. No son hipótesis.

El error que más cuesta, aunque no aparezca como error

Una alarma huérfana: apunta a un servicio que ya no existe. Queda en estado «sin datos» para siempre, en un panel que alguien mira de reojo, y es indistinguible de una alarma sana.

Es exactamente el antipatrón del que habla este laboratorio: parece observabilidad, ocupa lugar en el panel, y no vigila nada. Por eso el capítulo siguiente importa más de lo que parece.

---

16. Limpieza

El orden importa. Borrar el tema antes que las alarmas deja alarmas apuntando a un destino que no existe.

1. Deshabilite o borre las alarmas.

Consola de OCIObservability & Management › Monitoring › Alarm Definitions

Seleccione cada alarma y bórrela. Si va a volver a usar el laboratorio, deshabilitarlas es suficiente: una alarma deshabilitada no evalúa ni notifica.

1. Borre la suscripción y después el tema.

Consola de OCIObservability & Management › Notifications › Topics

Entre al tema, borre la suscripción y luego el tema. Un tema con suscripciones se borra igual, pero dejar la suscripción huérfana en la cuenta de correo de alguien es una descortesía innecesaria.

1. Deshabilite los registros de servicio.

Consola de OCIObservability & Management › Logging › Logs

Deshabilite el flow log y los registros del balanceador. Este es el paso que de verdad detiene un cobro: mientras el registro esté habilitado, sigue ingiriendo.

1. Borre el grupo de registro. No se borra si todavía tiene registros dentro: por eso va después del paso 3.

1. Borre el tablero, si creó uno.

1. El servicio observado se destruye con su propio procedimiento. Este manual no lo creó y no debe borrarlo desde aquí.

Qué se queda cobrando si la limpieza se hace mal

El orden de magnitud, medido: el ensayo completo del laboratorio —incluyendo el servicio observado— costó 0,13 USD de cómputo. La capa de observabilidad no movió esa cifra. Lo que puede crecer, si se deja habilitado sobre una red con tráfico real, son los registros.

---

17. Documentación oficial

---

Anexo · Qué falta para que esto sea un modelo completo

Lo que este manual construye es la cadena mínima: señal → umbral → destinatario → acción. Es el mínimo viable, y el mínimo viable es justamente lo que se puede tener funcionando en dos semanas.

Un modelo completo para producción añade al menos:

Y para un equipo que hoy no mide nada, el orden que da resultados más rápido no empieza por ninguna herramienta nueva:

1. Una prueba sintética desde fuera, cada minuto, del recorrido más importante.
2. Registrar los incidentes en una hoja de cálculo: cuándo empezó, cuándo se detectó, cuándo se resolvió, qué lo causó. Cuatro columnas.
3. Una revisión mensual de 30 minutos con esa hoja delante.

En dos meses eso produce los números que hoy no existen — y sin esos números, cualquier discusión sobre compromisos de servicio es una discusión de opiniones.