Configura Cloud Alerts para Vigilar las Métricas de tus Servidores

Cloud Alerts vigila tus servidores y te avisa en cuanto una métrica cruza el límite que fijes: la CPU clavada al 90%, el disco llenándose, un pico de tráfico. Eliges qué vigilar y cómo quieres que te avisen (email, Slack, Discord), y la alerta hace el resto. Una alerta incluso puede ejecutar una acción por ti, como levantar otro servidor cuando la carga se mantiene alta.

Es la forma sencilla de dejar de vigilar gráficas y enterarte de los problemas antes que tus usuarios.

Cómo funciona

Defines una alerta sobre un servidor: una métrica (CPU, RAM, disco o red), una condición (por ejemplo "mayor que 90") y cuánto tiempo debe mantenerse así para que cuente. Cuando la condición se cumple durante esa duración, la alerta ejecuta sus acciones: avisarte por uno de tus canales de notificación, o crear o destruir un servidor. Tras dispararse espera un periodo de enfriamiento para no saturarte, y cuando la métrica se recupera vuelve a vigilar. Lo configuras todo en el panel o por la API.

Antes de empezar

• En el panel: my.cubepath.com → Cloud Alerts.
• Por la API: URL base https://api.cubepath.com, autentica con Authorization: Bearer <token> (scopes trigger:read / trigger:write) y añade X-Requested-With: XMLHttpRequest en las escrituras. Consigue un token en Cuenta → Tokens de API.
• Crea primero al menos un canal de notificación si quieres recibir avisos (abajo).

Paso 1: Añade un canal de notificación

Un canal de notificación es a dónde envían sus mensajes las alertas. Hay tres tipos:

curl -X POST https://api.cubepath.com/triggers/notificators \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Ops Slack",
    "type": "slack",
    "config": { "webhook_url": "https://hooks.slack.com/services/XXX/YYY/ZZZ" }
  }'

Para un canal email, deja config vacío. Los canales se comparten entre todas tus alertas, así que los configuras una vez y los reutilizas.

Paso 2: Crea una alerta

Una alerta vigila un objetivo, sobre una métrica, contra una condición, y ejecuta una o más acciones cuando salta.

curl -X POST https://api.cubepath.com/triggers \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": 1,
    "name": "CPU alta en web-1",
    "target_type": "vps",
    "target_id": "12345",
    "metric_type": "cpu",
    "operator": "gt",
    "threshold": 90,
    "duration_seconds": 300,
    "cooldown_seconds": 600,
    "actions": [
      { "action_type": "notify", "notificator_id": "<uuid-del-canal>" }
    ]
  }'

Esto dice: "si la CPU del VPS 12345 se mantiene por encima del 90% durante 5 minutos, avisa a mi canal de Slack, y luego espera al menos 10 minutos antes de volver a disparar."

Las piezas:

• target_type / target_id: vps, baremetal, o availability_group, y su id.
• metric_type: ver la tabla de abajo.
• operator: gt, lt, gte, lte, o eq.
• threshold: el valor con el que comparar (CPU/RAM/disco son porcentajes).
• duration_seconds: cuánto debe mantenerse la condición antes de disparar. Entre 60 y 3600 (por defecto 300).
• cooldown_seconds: tiempo mínimo entre disparos, para que una métrica inestable no te sature. Entre 60 y 86400 (por defecto 600).
• actions: de una a diez, se ejecutan en su order cuando la alerta salta.

Métricas que puedes vigilar

Los servidores bare metal admiten solo las métricas de red.

Acciones

Cada alerta ejecuta una o más acciones cuando salta:

Combínalas libremente (hasta diez por alerta) y ajusta el order de cada una para controlar la secuencia. notify es el caso común; create_vps / destroy_vps sirven para escalado o apagado automático sencillo.

Límites

Lo que esto no hace

• Es por umbral, no detección de anomalías. Tú le dices el límite a vigilar; no aprende por su cuenta qué es "normal".
• No es un panel de métricas. Vigila las mismas métricas que muestran las gráficas de tu servidor y actúa sobre ellas; para ver el historial y los gráficos, usa la vista de métricas del servidor. Cada alerta sí guarda un registro de cuándo saltó y se recuperó.
• Bare metal es solo red. Las alertas de CPU, RAM y disco aplican a VPS y availability groups.

Referencia de la API

GET    /triggers/notificators                 Listar canales de notificación.    (scope: trigger:read)
POST   /triggers/notificators   { name, type, config }   Añadir un canal.        (scope: trigger:write)
GET    /triggers/notificators/{id}            Ver un canal.                      (scope: trigger:read)
PUT    /triggers/notificators/{id}            Actualizar un canal.               (scope: trigger:write)
DELETE /triggers/notificators/{id}            Eliminar un canal.                 (scope: trigger:write)
GET    /triggers                              Listar tus alertas.                (scope: trigger:read)
POST   /triggers   { name, target_type, target_id, metric_type, operator, threshold, actions }  Crear una alerta. (scope: trigger:write)
GET    /triggers/{id}                         Ver una alerta.                    (scope: trigger:read)
PUT    /triggers/{id}                         Actualizar una alerta.             (scope: trigger:write)
DELETE /triggers/{id}                         Eliminar una alerta.               (scope: trigger:write)
GET    /triggers/{id}/history                 Ver cuándo saltó y se recuperó.    (scope: trigger:read)

Todas las peticiones se autentican con Authorization: Bearer <token> (o X-API-Key). Las peticiones de escritura necesitan además X-Requested-With: XMLHttpRequest.