En este documento se describe cómo puedes organizar y priorizar tus incidentes asignándoles etiquetas definidas por el usuario. Estas etiquetas se configuran en las políticas de alertas y se muestran en las políticas de alertas y en los incidentes. Según tu configuración, las etiquetas también se muestran en determinadas notificaciones.
Acerca de las etiquetas
Las etiquetas, que son pares clave-valor, se usan para asociar información a una serie temporal, una política de alertas, un incidente o una notificación. Por ejemplo, las etiquetas de una serie temporal pueden identificar la instancia de máquina virtual específica de la que se recogieron los datos. Las etiquetas pueden ser definidas por el usuario o predefinidas.
Etiquetas definidas por el usuario
Las etiquetas definidas por el usuario contienen la información que especifiques. Estas etiquetas pueden tener valores estáticos o dinámicos:
Las etiquetas estáticas definidas por el usuario tienen valores que no se pueden cambiar. Puedes crear etiquetas estáticas definidas por el usuario al configurar una política de alertas mediante la Google Cloud consola o la API Cloud Monitoring. Para obtener más información, consulte los documentos siguientes:
Las etiquetas dinámicas definidas por el usuario tienen valores que pueden cambiar en función de los valores de los datos de serie temporal. Puedes crear etiquetas dinámicas definidas por el usuario cuando configures la condición de una política de alertas con PromQL. Para ver un ejemplo, consulte Ejemplo: añadir etiquetas definidas por el usuario con valores dinámicos.
Las claves de etiqueta deben comenzar con una letra minúscula. Tanto las claves como los valores de las etiquetas solo pueden contener letras minúsculas, dígitos, guiones bajos y guiones.
Etiquetas predefinidas
Las etiquetas predefinidas se incluyen en los descriptores de recursos. Estas etiquetas deben rellenarse cuando se escriben datos de serie temporal. Estas etiquetas muestran información sobre la métrica que se está recogiendo o el recurso en el que se escribe la métrica. Por ejemplo, las etiquetas de una serie temporal pueden identificar una máquina virtual, una zona, un proyecto y un tipo de dispositivo. Google Cloud Cuando Monitoring crea un incidente basado en esa serie temporal, el incidente hereda esas etiquetas.
Etiquetas de App Hub
App Hub asigna etiquetas a los datos de registro, métricas y trazas generados por una aplicación, sus servicios y sus cargas de trabajo. Estas etiquetas permiten que la Google Cloud infraestructura creepaneles de control de aplicaciones, servicios y cargas de trabajo que muestran datos de métricas y registros. Para obtener más información, consulta uno de los siguientes documentos:
- Google Cloud Consola: asocia una política de alertas a una aplicación de App Hub.
- API Cloud Monitoring: asociar una política de alertas a una aplicación de App Hub.
Cómo ver etiquetas
Puedes ver las etiquetas de una política de alertas o de un incidente en la página de detalles de un incidente, en la página de detalles de una política de alertas y en algunas notificaciones.
- Políticas de alertas: las etiquetas estáticas definidas por el usuario se muestran en la sección Etiquetas de usuario. Las etiquetas dinámicas definidas por el usuario y las etiquetas predefinidas no se muestran.
- Incidencias: las etiquetas estáticas definidas por el usuario se muestran en la sección Etiquetas de la política, y las etiquetas dinámicas definidas por el usuario se muestran en la sección Etiquetas de la métrica. Las etiquetas predefinidas se muestran en las secciones Etiquetas de recursos monitorizados y Etiquetas de métricas.
Notificaciones: las etiquetas predefinidas y las definidas por el usuario se muestran en los siguientes tipos de notificaciones:
- Correo electrónico
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook
Ejemplo: añadir etiquetas definidas por el usuario con valores dinámicos
Puedes usar PromQL para configurar una etiqueta de forma que su valor cambie dinámicamente en función de los datos de series temporales. Por ejemplo, supongamos que quiere que sus incidencias tengan una etiqueta criticality
cuyo valor cambie
en función del valor de la métrica de utilización de la CPU monitorizada:
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.9,
"criticality", "CRITICAL", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.8,
"criticality", "WARNING", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]) >= 0.7,
"criticality", "INFO", "", ""
)
or ignoring (criticality)
label_replace(
avg_over_time({"compute.googleapis.com/instance/cpu/utilization", monitored_resource="gce_instance"}[5m]),
"criticality", "GOOD", "", ""
)
En la siguiente imagen se muestra cómo procesan los datos de series temporales las políticas de alertas que usan consultas de PromQL:
El gestor de políticas procesa los datos de utilización de la CPU y genera una serie temporal que indica cuándo se cumple la condición. En el ejemplo anterior, la condición se cumple cuando el uso de la CPU es de al menos el 70%. Por cada serie temporal de entrada, el controlador de la política puede generar una de las cuatro series temporales siguientes:
Nombre de la serie temporal de salida | Condición cumplida | Descripción |
---|---|---|
"GOOD" | No | Esta serie temporal tiene las mismas etiquetas que la serie temporal de entrada. No tiene una etiqueta de gravedad. |
"CRITICAL" | Sí | El uso de la CPU es de al menos el 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "GOOD" más una etiqueta de gravedad con el valor "CRITICAL". |
"WARNING" | Sí | El uso de la CPU es de al menos el 80 %, pero inferior al 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "GOOD", además de una etiqueta de gravedad con el valor "WARNING". |
"INFO" | Sí | El uso de la CPU es de al menos el 70 %, pero inferior al 80%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "GOOD" más una etiqueta de gravedad con el valor "INFO". |
Los datos de serie temporal generados por el controlador de la política son la entrada del gestor de incidentes, que determina cuándo se crean y se cierran los incidentes. Para determinar cuándo cerrar un incidente, el gestor de incidentes usa los valores de los campos duration
, evaluationMissingData
y autoClose
.
Prácticas recomendadas
Para comprobar que solo hay un incidente abierto a la vez al crear etiquetas cuyos valores se definen de forma dinámica, haga lo siguiente:
En el objeto
MetricThreshold
, cambia los valores predeterminados de los siguientes campos:- Campo
duration
: asigna un valor distinto de cero. - Campo
evaluationMissingData
: se define para que los incidentes se cierren cuando dejen de llegar datos. Cuando uses la API Cloud Monitoring, asigna el valorEVALUATION_MISSING_DATA_INACTIVE
a este campo. Cuando uses la consola, define el campo como "Missing data points treated as values that don't violate the policy condition". Google Cloud
- Campo
En el objeto
AlertStrategy
, asigna al campoautoClose
el valor mínimo de 30 minutos. Cuando uses la API Cloud Monitoring, asigna el valor30m
a este campo.
Para obtener más información, consulta Datos de métricas parciales.
Flujo de incidentes
Supongamos que las mediciones de uso de CPU son inferiores al 70% cuando se crea la política de alertas. En la siguiente secuencia se muestra cómo se abren y cierran los incidentes:
Como las mediciones de utilización de la CPU son inferiores al 70%, el controlador de la política genera la serie temporal "GOOD" y no se abre ningún incidente.
A continuación, supongamos que el uso de la CPU aumenta al 93%. El controlador de la política deja de generar datos de serie temporal "GOOD" y empieza a generar datos de serie temporal "CRITICAL".
El gestor de incidentes ve una nueva serie temporal "CRÍTICA" que cumple la condición y, a continuación, abre un incidente. La notificación incluye la etiqueta de gravedad con el valor
CRITICAL
.Supongamos que el uso de la CPU se reduce al 75%. El controlador de la política deja de generar la serie temporal "CRITICAL" y empieza a generar la serie temporal "INFO".
El gestor de incidentes ve una nueva serie temporal "INFO" que cumple la condición y, a continuación, abre un incidente. La notificación incluye la etiqueta de gravedad con el valor
INFO
.El gestor de incidentes ve que no llegan datos de la serie temporal "CRITICAL" y que hay un incidente abierto para esa serie temporal. Como la política está configurada para cerrar los incidentes cuando dejan de llegar datos, el gestor de incidentes cierra el incidente asociado a la serie temporal "CRITICAL". Por lo tanto, solo permanece abierto el incidente cuya etiqueta de gravedad tiene el valor
INFO
.Por último, supongamos que el uso de la CPU se reduce al 45%. Este valor es inferior a todos los umbrales, por lo que el controlador de la política deja de generar la serie temporal "INFO" y empieza a generar la serie temporal "GOOD".
El gestor de incidentes ve que no llegan datos de la serie temporal "INFO" y que hay un incidente abierto para esa serie temporal. Como la política usa los ajustes recomendados, el incidente se cierra.
Si no usa el valor recomendado para el campo evaluationMissingData
, cuando dejen de llegar datos, los incidentes abiertos no se cerrarán inmediatamente.
Como resultado, es posible que veas varios incidentes abiertos para la misma serie temporal de entrada. Para obtener más información, consulta Datos de métricas parciales.
Siguientes pasos
- Crear políticas de alertas con la API Monitoring
- Crear políticas de alertas con PromQL
- Gestionar datos de métricas parciales