Saltar al contenido principal

Alertas

Las alertas le informan cuando se está consumiendo un presupuesto antes de que se agote. Un canal describe a dónde va un mensaje, una regla de presupuesto describe cuándo se envía, y el registro de eventos registra cada intento de entrega con su resultado. Las reglas y los canales son independientes, por lo que un canal puede servir a muchas reglas y una regla puede enviarse a varios canales a la vez.

La página está organizada en tres pestañas — Channels, Budget Rules y Events — que corresponden a esas tres áreas en ese orden.

Canales​

Un canal es un destino de entrega con nombre. La tabla muestra el nombre, tipo, estado y fecha de creación de cada canal, con acciones por fila para enviar una prueba, editar, activar o desactivar, y eliminar.

Se admiten seis tipos de canales:

  • Slack — Publica en un webhook entrante de Slack. Requiere la URL del webhook, más una anulación opcional del canal (p. ej., #alerts) y un nombre de usuario para mostrar.
  • Microsoft Teams — Publica en una URL de webhook entrante de Teams.
  • Email — Envía a una lista de destinatarios, con un prefijo de asunto opcional y una dirección de remitente por canal opcional. La entrega utiliza el relay SMTP del tenant configurado en Settings.
  • PagerDuty — Activa un incidente en PagerDuty Events API v2 mediante una clave de enrutamiento, con una de cuatro severidades: critical, error, warning o info.
  • Webhook — Envía JSON a cualquier endpoint HTTPS mediante POST o PUT, con un nombre y valor de encabezado de autenticación personalizado opcional para esquemas de bearer o secreto compartido.
  • Discord — Publica en una URL de webhook de Discord, con un nombre de usuario para mostrar opcional.

Seleccione Add Channel para crear uno. El formulario solicita primero un nombre y un tipo, y luego muestra únicamente los campos que ese tipo necesita. El tipo de canal queda fijo una vez guardado; para cambiarlo, cree un nuevo canal y actualice las reglas para que apunten a él.

Probar un Canal​

Cada fila incluye una acción Send test alert. Envía un mensaje real a través de la configuración activa del canal e informa Test alert sent en caso de éxito, o el error de entrega en caso de fallo. Úsela después de crear un canal y después de cualquier rotación de credenciales: una URL de webhook mal escrita resulta invisible hasta que un incumplimiento de presupuesto real no logra notificar a nadie.

Nota: Los secretos — URLs de webhook, claves de enrutamiento de PagerDuty y valores de encabezado de autenticación de webhook — están cifrados en reposo y se eliminan de todas las respuestas de la API. El formulario muestra la presencia del valor almacenado, nunca el valor en sí.

Desactivar y Eliminar​

Desactivar un canal lo mantiene a él y a sus referencias de reglas intactos, pero detiene la entrega. Eliminarlo es permanente, y cualquier regla de alerta que aún lo referencie simplemente omitirá ese canal en el momento del envío — la regla sigue funcionando a través de sus canales restantes, por lo que una regla puede perder silenciosamente su único destino. Verifique qué reglas usan un canal antes de eliminarlo.

Reglas de Presupuesto​

Una regla se activa cuando el gasto de un ámbito supera un porcentaje de su límite de presupuesto. La tabla muestra el nombre, ámbito, ID de ámbito, umbral, número de canales y estado de cada regla.

Ámbito​

Hay cuatro ámbitos disponibles, y determinan el presupuesto contra el que se mide el umbral:

  • Project — Gasto de un proyecto. Requiere el ID del proyecto.
  • Team — Gasto de un equipo. Requiere el ID del equipo.
  • Virtual Key — Gasto de una clave emitida individual. Requiere el ID o hash de la clave.
  • Tenant (all) — Gasto agregado de todo el tenant. No requiere ID.

Todos los ámbitos excepto Tenant (all) requieren un ID de ámbito, y tanto el ámbito como su ID quedan fijos tras la creación; el umbral, el nombre, los canales y el estado activo siguen siendo editables.

Umbral​

El umbral es un porcentaje del presupuesto del ámbito, válido de 1 a 200. Se ofrecen valores predeterminados de 50, 75, 80, 90, 100 y 110, y el control deslizante acepta cualquier valor dentro del rango. Los valores superiores a 100 están permitidos deliberadamente para que una regla pueda detectar un gasto excesivo que ya ha superado el límite.

Canales​

Una regla debe indicar al menos un canal y acepta hasta veinte. Cada canal seleccionado recibe la alerta cuando la regla se activa, lo que permite que un único umbral llegue tanto a un canal de Slack como a un servicio de PagerDuty de guardia.

Eventos​

La pestaña Eventos es el registro de entregas: la prueba de lo que se envió realmente. Cada fila registra:

  • When — Marca de tiempo en que se activó la alerta.
  • Scope y Scope ID — Qué entidad superó su umbral.
  • Threshold — El porcentaje que desencadenó la regla.
  • Spend / Budget — Gasto observado frente al límite de presupuesto en el momento en que se activó la regla.
  • Channel — El tipo de canal en el que se intentó la entrega.
  • Status — El resultado del intento de entrega.
  • Error — El detalle del fallo cuando una entrega no tuvo éxito.

La pestaña se actualiza automáticamente cada 30 segundos y cuenta con un control manual de Refresh. Este registro es el lugar para confirmar que una alerta llegó genuinamente a su destino: una regla puede activarse correctamente y aun así no entregar el mensaje si una URL de webhook ha expirado o el relay SMTP está mal configurado.

Permisos​

Las acciones de alertas están controladas individualmente: alerts:read para ver canales, reglas y eventos; alerts:create, alerts:update y alerts:delete para los cambios correspondientes; y alerts:test para enviar una alerta de prueba. Asígnelos a través de Users & Roles.

Mejores Prácticas​

  • Configure el relay SMTP antes de crear canales de Email — Los canales de Email se guardan sin un relay, pero no tienen a dónde enviar. Consulte Settings.
  • Envíe una prueba en cada canal nuevo — Es la única forma de verificar que el destino es accesible antes de que un incumplimiento real dependa de él.
  • Escalone los umbrales en lugar de depender de uno solo — Una regla al 80 da tiempo para reaccionar y una segunda al 100 confirma que se alcanzó el límite; una única regla al 100 solo reporta el problema después de que ya ha ocurrido.
  • Adapte el canal a la urgencia — Dirija las advertencias de presupuesto de proyectos y equipos a un canal de FinOps o de plataforma, y reserve PagerDuty para umbrales a nivel de tenant que justifiquen genuinamente despertar a alguien.
  • Revise los Eventos después de cambiar cualquier destino — Rotar una URL de webhook o una contraseña SMTP es la causa más común de alertas que se activan correctamente pero nunca llegan.
  • Revise las reglas después de eliminar un canal — El envío omite los canales faltantes de forma silenciosa, por lo que una regla puede sobrevivir sin ningún destino funcional.
  • Combine las alertas con Spend para investigar — Las alertas indican que algo ocurrió; Spend muestra exactamente qué consumió el presupuesto.

Páginas Relacionadas​

  • Settings — El relay SMTP del tenant por el que envía cada canal de Email.
  • Spend — Análisis por solicitud para investigar qué provocó el incumplimiento de un umbral.
  • Teams — Donde se establecen los presupuestos y límites de velocidad de los equipos.
  • Projects — Donde se establecen los presupuestos de los proyectos.
  • Virtual Keys — Presupuestos por clave que mide una regla con ámbito Virtual Key.
  • Users & Roles — Otorga los permisos alerts:*.