Este documento describe cómo puedes organizar y priorizar tus incidentes al proporcionarles etiquetas definidas por el usuario. Estas etiquetas se configuran en y se enumeran en políticas de alertas de seguridad sobre posibles incidentes. Según tu configuración, las etiquetas también se en ciertas notificaciones.
Acerca de las etiquetas
Las etiquetas, que son pares clave-valor, se usan para adjuntar 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 específica de la máquina virtual (VM) desde la que se recopilaron 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 especificas. 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 cuando configuras una política de alertas la consola de Google Cloud o la API de Cloud Monitoring. Para obtener más información, consulta los siguientes documentos:
Las etiquetas dinámicas definidas por el usuario tienen valores que pueden cambiar en función de los valores de los datos de series temporales. Puedes crear etiquetas definidas por el usuario dinámicas cuando configures la condición de una política de alertas con MQL. Para ver un ejemplo, consulta Ejemplo: Agrega etiquetas definidas por el usuario con valores dinámicos.
Las claves de etiquetas deben comenzar con una letra en minúscula. Claves y etiquetas de recurso los valores 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 ser que se propagan cuando se escriben los datos de series temporales. Estas etiquetas muestran información acerca de la métrica que se recopila o el recurso con el que se calcula la métrica escrita. Por ejemplo, las etiquetas en una serie temporal podrían identificar un una máquina virtual (VM), una zona, un proyecto de Google Cloud y un tipo de dispositivo. Cuando Monitoring crea un incidente en función de esa serie temporal, el incidente hereda esas etiquetas.
Cómo ver las etiquetas
Puedes ver las etiquetas de una política de alertas o un incidente en la página de detalles de un incidente 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 enumeran en Etiquetas de usuario. Etiquetas dinámicas definidas por el usuario y etiquetas predefinidas no son visibles.
- Incidentes: Las etiquetas estáticas definidas por el usuario se enumeran en Etiquetas de política. y las etiquetas dinámicas definidas por el usuario se enumeran en la sección Etiquetas de métrica sección. Las etiquetas predefinidas se enumeran en Etiquetas de recursos supervisados y Etiquetas de métricas.
Notificaciones: Las etiquetas predefinidas y las definidas por el usuario se enumeran en los siguientes tipos de notificaciones:
- Correo electrónico
- Google Chat
- PagerDuty
- Pub/Sub
- Webhook
Ejemplo: Agrega etiquetas definidas por el usuario con valores dinámicos
Puedes usar MQL para configurar una etiqueta de modo que su valor
cambian de forma dinámica según los datos de series temporales. Por ejemplo, quieres que
tus incidentes tengan una etiqueta criticality
cuyo valor cambie
según el valor de la métrica de uso de CPU supervisado:
fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
add[
criticality:
if(val() >= 90 '%', 'CRITICAL',
if(val() >= 80 '%', 'WARNING',
if(val() >= 70 '%', 'INFO', 'GOOD')))
]
| condition val() >= 70 '%'
En la siguiente figura, se ilustra cómo las políticas de alertas que usan Las consultas de MQL procesan los datos de las series temporales que supervisan:
El controlador de políticas procesa los datos de uso de CPU y genera un series temporales que indican cuándo se cumple la condición. En el anterior ejemplo, la condición se cumple cuando el uso de CPU es de al menos 70% Para cada serie temporal de entrada, el controlador de políticas genera una de estas cuatro series temporales:
Nombre de la serie temporal de salida | Se cumplió la condición | Descripción |
---|---|---|
"BUENO" | 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 CPU es de al menos un 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "CRÍTICA". |
"ADVERTENCIA" | Sí | El uso de CPU es de al menos 80%, pero menor que 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "ADVERTENCIA". |
"INFO" | Sí | El uso de CPU es de al menos el 70%, pero inferior al 80%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "INFO". |
Los datos de series temporales que genera el controlador de políticas son la entrada de la
administrador de incidentes, que determina cuándo se crean y se cierran los incidentes.
Para determinar cuándo cerrar un incidente, el administrador de incidentes usa la
valores de duration
, evaluationMissingData
,
y autoClose
.
Prácticas recomendadas
Para garantizar que como máximo un incidente esté abierto a la vez cuando crees etiquetas cuyos valores se establezcan de forma dinámica, haz lo siguiente:
En el objeto
MetricThreshold
, anula la valores predeterminados para los siguientes campos:- Campo
duration
: Establece un valor distinto de cero. - Campo
evaluationMissingData
: Configúralo para que los incidentes se cierren cuando dejen de llegar datos. Cuando usas la API de Cloud Monitoring, establece este campo enEVALUATION_MISSING_DATA_INACTIVE
. Cuando usas la consola de Google Cloud, configura el campo como “Datos faltantes que se tratan como valores que no infrinjan la condición de la política".
- Campo
En el objeto
AlertStrategy
, configuraautoClose
a su valor mínimo de 30 minutos. Cuando uses la API de Cloud Monitoring, establece este campo en30m
.
Para obtener más información, consulta Datos parciales de la métrica.
Flujo de incidentes
Supongamos que las mediciones del uso de la CPU son inferiores al 70% cuando se crea la política de alertas. En la siguiente secuencia, se ilustra cómo los incidentes están abiertos y cerrados:
Debido a que las mediciones del uso de CPU son inferiores al 70%, el controlador de políticas genera el error series temporales y de que no se abran incidentes.
A continuación, supongamos que el uso de CPU aumenta al 93%. El controlador de políticas deja de generar el estado "BUENO" datos de series temporales y comienza a generar datos para el “CRÍTICO” series temporales.
El administrador de incidentes ve un mensaje “CRÍTICO” nuevo series temporales que cumplen con los y, luego, abre un incidente. La notificación incluye la etiqueta de gravedad con un valor de
CRITICAL
.Supongamos que el uso de CPU cae al 75%. El controlador de políticas deja de generar el error "CRITICAL" de series temporales y empieza a generar el campo "INFO" series temporales.
El administrador de incidentes ve una nueva serie temporal "INFO" que cumple con la condición y, luego, abre un incidente. El incluye la etiqueta de gravedad con un valor de
INFO
.El administrador de incidentes ve que no llegan datos para la respuesta “CRÍTICA” series temporales y que hay un incidente abierto para esa serie temporal. Debido a que el está configurada para cerrar incidentes cuando los datos dejan de llegar el administrador de incidentes cierra asociado con el error “CRITICAL” series temporales. Por lo tanto, Solo el incidente cuya etiqueta de gravedad tiene un valor de
INFO
permanece abierto.Por último, supongamos que el uso de CPU disminuye al 45%. Este valor es menor que los umbrales, por lo que el controlador de políticas deja de generar "INFORMACIÓN" series temporales y empieza a generar el informe “BUENO” series temporales.
El administrador de incidentes ve que no llegan datos para la información “INFO”. series temporales y que hay un incidente abierto para esa serie temporal. Como la política usa la configuración recomendada, se cierra el incidente.
Si no usas el valor recomendado para el campo evaluationMissingData
, haz lo siguiente:
y, cuando los datos dejan de llegar,
los incidentes abiertos no se cierran de inmediato.
Como resultado, es posible que veas varios incidentes abiertos para la misma entrada.
series temporales. Para obtener más información, consulta Datos parciales de la métrica.
¿Qué sigue?
- Crea políticas de alertas con la API de Monitoring
- Políticas de alertas con MQL
- Maneja datos de métricas parciales