Configura pol�ticas de alertas basadas en registros

Puedes configurar una pol�tica de alertas para que te notifique cuando un mensaje espec�fico en tus registros incluidos. Por ejemplo, si deseas saber cu�ndo un registro de auditor�a registra un mensaje de acceso a los datos en particular, puedes recibir una notificaci�n cuando aparezca el mensaje. Estos tipos de pol�ticas de alertas se denominan pol�ticas de alertas basadas en registros. En este documento, se describe c�mo hacer lo siguiente: con la consola de Google Cloud y la API de Cloud Monitoring:

  • Crear y probar una pol�tica de alertas basada en registros
  • Edita una pol�tica de alertas basada en registros.
  • Borrar una pol�tica de alertas basada en registros

Antes de comenzar

Revisa la comparaci�n de alertas para determinar si las pol�ticas de alertas basadas en registros son adecuadas para los datos de tus registros. Por ejemplo:

  • Las pol�ticas de alertas basadas en registros no funcionan en registros excluidos.

  • No puedes usar pol�ticas de alertas basadas en registros para derivar recuentos de tus registros. Para derivar recuentos, debes usar m�tricas basadas en registros en su lugar.

Para crear y administrar pol�ticas de alertas basadas en registros, tu rol de Identity and Access Management debe incluir los permisos descritos en Permisos para pol�ticas de alertas basadas en registros.

Crea una pol�tica de alertas basada en registros con el Explorador de registros

Puedes crear una pol�tica de alertas basada en registros desde la p�gina Explorador de registros en la consola de Google Cloud o con la API de Monitoring. Esta secci�n se describe c�mo crear pol�ticas de alertas basadas en registros con el Explorador de registros. Para obtener m�s informaci�n sobre la API de Monitoring, consulta Crea una pol�tica de alertas basada en registros con la API de Monitoring.

La interfaz del Explorador de registros te gu�a a trav�s de los siguientes pasos:

  • Proporciona un nombre y una descripci�n para la pol�tica de alertas.
  • Elige los registros para los que quieres recibir notificaciones.
  • Establece el tiempo entre notificaciones.
  • Establece el tiempo para el cierre autom�tico de incidentes.
  • Especifica a qui�n notificar.

Por ejemplo, supongamos que tienes una aplicaci�n que escribe un syslog. entrada de registro con gravedad NOTICE cuando la aplicación cambia una dirección de red. Las entradas de registro para los cambios de dirección de red incluyen una carga útil de JSON que busca de la siguiente manera:

"jsonPayload": {
  "type": "Configuration change",
  "action": "Set network address",
  "result": "IP_ADDRESS",
}

Quieres crear una política de alertas basada en registros que te notifique cuando una dirección IPv4 no válida aparezca en el campo jsonPayload.result de entradas de registro en syslog con gravedad NOTICE.

Para crear esta política de alertas, haz lo siguiente:

  1. En la consola de Google Cloud, ve a la página Explorador de registros.

    Ir al Explorador de registros

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

  2. Usa el panel Consulta para compilar una consulta que coincida con el mensaje que deseas usar en tu política de alertas basada en registros.

    Por ejemplo, para encontrar entradas de registro con un nivel de gravedad de NOTICE en el syslog con direcciones IP no válidas en la carga útil de JSON, puedes usa la siguiente consulta:

    log_id("syslog")
    severity = "NOTICE"
    jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
    

    Usa Ejecutar consulta en el panel Resultados de la consulta para validar la consulta.

  3. En el encabezado del panel Resultados de la consulta, haz clic en  Crear alerta. Cuando la ventana esté específicas, la opción Crear alerta podría aparecer en la pestaña Acciones en su lugar.

  4. En el panel Detalles de la alerta, asigna un nombre a la política de alertas y descripción:

    1. Ingresa un nombre para tu política de alertas en el campo Nombre de la política de alertas. Por ejemplo, “Dirección de red: valor IPv4 no válido”.

    2. Selecciona una opción del menú Nivel de gravedad de la política. Incidentes e las notificaciones muestran el nivel de gravedad.

    3. Ingresa una descripción para tu política de alertas. También puedes incluir información que podría ayudar al destinatario de una notificaci�n a diagnosticar el problema. La siguiente cadena resume el motivo de la notificaci�n:

      Log-based alerting policy in project ${project} detected an invalid IPv4 value.
      

      Para obtener informaci�n sobre c�mo adaptar el contenido y darle formato de este campo, consulta Usa Markdown y variables en la documentaci�n plantillas.

  5. Para avanzar al paso siguiente, haz clic en Siguiente.

  6. En el panel Elegir registros para incluir en el alerta, haz clic en Obtener vista previa de los registros para verificar la consulta y los resultados.

    Recomendamos compilar la consulta en el panel Consulta del Explorador de registros. La consulta que creaste en el panel Consulta tambi�n se muestra en este panel, por ejemplo:

    log_id("syslog")
    severity = "NOTICE"
    jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
    

    Si es necesario, puedes editar la consulta en este panel. Si editas la consulta, haz clic en Obtener vista previa de los registros para verificar los resultados.

  7. Haz clic en Siguiente.

  8. Selecciona el tiempo m�nimo entre notificaciones. Este valor te permite controlar la cantidad de notificaciones que recibes Supervisa si se cumple esta condici�n varias veces. Para este ejemplo, selecciona 5 min de las opciones.

  9. Opcional: Selecciona la duraci�n del cierre autom�tico del incidente. De forma predeterminada, el incidente la duraci�n del cierre autom�tico se estableci� en 7 d�as.

  10. Haz clic en Siguiente.

  11. Selecciona uno o m�s canales de notificaciones para tu pol�tica de alertas. Para este ejemplo, selecciona un canal de notificaciones por correo electr�nico.

    Si ya tienes configurado un canal de notificaciones por correo electr�nico, puedes seleccionarlo de la lista. Si no es as�, haz clic en Administrar canales de notificaciones y agrega un canal de correo electr�nico. Para obtener informaci�n sobre la creaci�n de notificaciones canales, consulta Crea y administra canales de notificaciones.

  12. Haz clic en Guardar.

Tu pol�tica de alertas basada en registros ya est� lista para probarla.

Prueba la pol�tica de alertas basada en registros de ejemplo

Para probar la pol�tica de alertas que creaste, puedes escribir de forma manual una entrada de registro que coincida con la consulta. Para escribir la entrada de registro, haz lo siguiente:

  1. Para configurar la siguiente entrada de registro, cambia la variable PROJECT_ID por el ID de tu proyecto:

    {
      "entries": [
      {
        "logName": "projects/PROJECT_ID/logs/syslog",
        "jsonPayload": {
          "type": "Configuration change",
          "action": "Set network address",
          "result": "999.027.405.1",
        },
        "severity": "NOTICE",
        "resource": {
          "type": "generic_task",
          "labels" : {
            "project_id": "PROJECT_ID",
            "location": "us-east1",
            "namespace": "fake-task-2",
            "job": "write-log-entry",
            "task_id": "11",
          },
        },
      },
      ],
    }
  2. Ve a la p�gina de referencia de logEntries.write o haz clic en el siguiente bot�n:

    Ve a logEntries.write

  3. Copia la entrada de registro que configuraste anteriormente.

  4. En el panel Prueba esta API, haz lo siguiente:

    1. Reemplaza el contenido del campo Cuerpo de la solicitud. en el Explorador de APIs con la entrada de registro que copiaste en el paso anterior.

    2. Haz clic en Ejecutar. Si se te solicita, sigue el flujo de autenticaci�n.

      Si la llamada a logEntries.write se realiza correctamente, obtendr�s un 200 HTTP. y un cuerpo de respuesta vac�o, {}. M�s informaci�n sobre el Explorador de APIs, consulta C�mo usar el Explorador de APIs en la documentaci�n de Monitoring; el Explorador de APIs funciona de la misma manera con la API de Logging.

La entrada de registro coincide con el filtro especificado para la pol�tica de alertas. de las siguientes maneras:

  • El valor logName especifica el registro syslog que se encuentra en tu proyecto de Google Cloud.
  • El valor de severity para esta entrada de registro es NOTICE.
  • El valor de jsonPayload.result no es una direcci�n IPv4 v�lida.

Despu�s de escribir la entrada de registro, ocurre la siguiente secuencia:

  • La nueva entrada de registro aparecer� en el Explorador de registros. La entrada de registro cumple con la condici�n de la pol�tica de alertas.
  • Se abre un incidente en Cloud Monitoring.
  • Recibir�s una notificaci�n sobre el incidente. Si configuraste una direcci�n de correo electr�nico canal de notificaciones, la notificaci�n se ver� como siguiente captura de pantalla:

    La pol�tica de alertas basada en registros de ejemplo da como resultado una notificaci�n por correo electr�nico.

Puedes hacer clic en Ver incidente en el correo electr�nico para consultarlo en Cloud Monitoring Si deseas obtener m�s informaci�n sobre los incidentes, consulta Administra los incidentes de pol�ticas de alertas basadas en registros.

Otras situaciones: Alertas sobre registros de auditor�a

El ejemplo de la secci�n titulada Crear una pol�tica de alertas basada en registros es artificial; no sueles crear una pol�tica de alertas y, luego, escribir entradas de registro que cumplan con la condici�n de la pol�tica de alertas. Por lo general, las entradas de registro las escriben aplicaciones o alg�n otro servicio. Pero el origen de las entradas de registro no importa; para pol�ticas de alertas basadas en registros, lo que importa es la consulta que que usas para seleccionar las entradas de registro.

En las siguientes secciones, se describen situaciones realistas para las pol�ticas de alertasbasadas en registros seg�n el contenido de los registros de auditor�a. Cada escenario ilustra c�mo crear una consulta que seleccione las entradas de registro de auditor�a adecuadas. De lo contrario, el procedimiento para crear pol�ticas de alertas es lo mismo que se muestra en Crea una alerta basada en registros.

Pol�ticas de alertas que supervisan el acceso humano a los secretos

Supongamos que tu proyecto almacena Secrets Secret Manager y algunos de estos Secrets est�n destinadas solo para el uso de las cuentas de servicio. Excepto en circunstancias inusuales, usuarios humanos nunca accedan a estos Secrets.

Si habilitaste los registros de auditor�a para Secret Manager, cada intento exitoso de acceso a un secreto crea una entrada de registro de auditor�a. Cada entrada incluye el nombre del secreto y la identidad del emisor.

Puedes crear una pol�tica de alertas basada en registros que te notifique cuando un usuario humano accede a un Secret.

A continuaci�n, se muestra un extracto de una entrada de registro de auditor�a que escribi� Secret Manager. El extracto muestra los campos que son �tiles para Crea la consulta para una alerta basada en registros:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "serviceName": "secretmanager.googleapis.com",
    "methodName": "google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion",
    "authenticationInfo": {
      "principalEmail": "my-svc-account@PROJECT_ID.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [],
      "principalSubject": "serviceAccount:my-svc-account@PROJECT_ID.iam.gserviceaccount.com"
    },
    ...
  },
  ...
}

Los siguientes subcampos protoPayload son de especial inter�s:

  • @type: Indica que esta entrada de registro es una entrada de registro de auditor�a.
  • serviceName: Registra el servicio que escribi� la entrada del registro de auditor�a. Usar esta para identificar las entradas que escribi� Secret Manager.
  • methodName: Identifica el m�todo para el que se aplic� esta entrada de registro de auditor�a. escrita. Usa este campo para identificar la acci�n que provoc� que se generara esta entrada crear. En este ejemplo, es el m�todo AccessSecretVersion.
  • authenticationInfo.principalEmail: Registra la cuenta que invoc� la en el campo methodName. El valor esperado para este campo es una de servicio, que termina en gserviceaccount.com.

Para encontrar entradas de registro para el acceso secreto de un usuario humano, busca para las entradas de registro de auditor�a que escribi� Secret Manager. Deseas busca las entradas de registro en las que invoc� el m�todo AccessSecretVersion una principal que no termina en gserviceaccount.com. La siguiente consulta a�sla estas entradas de registro:

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "secretmanager.googleapis.com"
protoPayload.methodName =~ "AccessSecretVersion$"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

Para crear una pol�tica de alertas basada en registros para el acceso humano a los Secrets, usa este consulta en el panel Choose logs to include in the alert.

Pol�ticas de alertas que supervisan los eventos de desencriptaci�n

El an�lisis del ejemplo anterior puede adaptarse a otros servicios. Por ejemplo, si usas Cloud Key Management Service para encriptar y desencriptar datos sensibles, puedes usar registros de auditor�a generados por Cloud�KMS para detectar cu�ndo un usuario humano desencripta un valor.

Para encontrar entradas de registro de la desencriptaci�n que realiza un usuario humano, busca entradas de registro de auditor�a escritas por Cloud KMS. Quieres encontrar la entradas de registro en las que el m�todo Decrypt invoc� una principal que no termina en gserviceaccount.com, lo que indica una cuenta de servicio. La siguiente consulta a�sla estas entradas de registro:

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "cloudkms.googleapis.com"
protoPayload.methodName = "Decrypt"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

Para crear una pol�tica de alertas basada en registros para la desencriptaci�n que realiza un usuario humano, usa esta consulta en el panel Elige registros para incluir en la alerta.

Administra las pol�ticas de alertas basadas en registros en Monitoring

Puedes ver, editar y borrar pol�ticas de alertas basadas en registros con el la consola de Google Cloud para Monitoring API de Monitoring. En este documento, se describe c�mo administrar pol�ticas de alertas con la consola de Google Cloud. Informaci�n sobre el uso de la API de Monitoring para administrar las pol�ticas de alertas, consulta Administra las pol�ticas de alertas por API.

Para ver una lista de todas las pol�ticas de alertas de tu proyecto de Google Cloud, haz lo siguiente:

  • Para navegar desde Logging, sigue estos pasos:

    1. En la consola de Google Cloud, ve a la p�gina Explorador de registros.

      Ir al Explorador de registros

      Si usas la barra de b�squeda para encontrar esta p�gina, selecciona el resultado cuyo subt�tulo es Logging.

    2. En el encabezado del panel Resultados de la consulta, Acciones y selecciona Administrar alertas.

  • Para navegar desde Monitoring, haz lo siguiente:

    1. En la consola de Google Cloud, ve a la p�gina Alertas.

      Ir a las Alertas

      Si usas la barra de b�squeda para encontrar esta p�gina, selecciona el resultado cuyo subt�tulo es Monitoring.

    2. Para ver todas las pol�ticas y habilitar los filtros, en el panel Pol�ticas, Haz clic en Ver todas las pol�ticas.

Ambas acciones te llevan a las Pol�ticas de Monitoring en la que se enumeran todas las pol�ticas de alertas en tu proyecto de Google Cloud.

A fin de restringir las pol�ticas de alertas que se enumeran, agrega filtros. Cada filtro se compone de un nombre y un valor. Por ejemplo, puedes establecer que el valor sea una coincidencia exacta para un nombre de pol�tica o una coincidencia parcial. Las coincidencias no distinguen may�sculas de min�sculas. Si especificas varios filtros, estos se unen de manera impl�cita con un AND l�gico, a menos que insertes un filtro OR. En la siguiente captura de pantalla, se enumeran las pol�ticas de alertas que est�n habilitadas y que se crearon despu�s del 1 de enero de 2021:

Lista de pol�ticas de alertas habilitadas creadas despu�s del 1 de enero de 2021.

Desde la p�gina Pol�ticas, puedes editar, borrar, copiar, habilitar o inhabilitar una pol�tica de alertas:

  • Para editar o copiar una pol�tica, haz clic en M�s opciones. y selecciona una opci�n. La edici�n y copia de una pol�tica es similar al procedimiento descrito en Crea una pol�tica de alertas basada en registros. Puedes cambiar y, en en algunos casos, borrar los valores en los campos. Cuando termines, haz clic en Guardar.

    Tambi�n puedes editar una pol�tica de alertas basada en registros si haces clic en su nombre en la lista de pol�ticas.

  • Para borrar una pol�tica, haz clic en M�s opciones y selecciona Borrar. En el di�logo de confirmaci�n, selecciona Borrar.

  • Para habilitar o inhabilitar la pol�tica de alertas, haz clic en el bot�n de activaci�n ubicado en el encabezado Habilitada.

Crea una pol�tica de alertas basada en registros con la API de Monitoring

Puedes crear pol�ticas de alertas basadas en registros con el API de Monitoring. Debes proporcionar la misma informaci�n a la API de Monitoring proporcionan cuando usas el Explorador de registros en la consola de Google Cloud:

  • Un nombre y una descripci�n para la pol�tica de alertas.
  • Los registros para los que quieres recibir notificaciones.
  • El tiempo entre notificaciones.
  • Es el tiempo para el cierre autom�tico de incidentes.
  • A qui�n notificar.

Para crear pol�ticas de alertas con la API de Monitoring, puedes crea un objeto AlertPolicy y env�alo al alertPolicies.create.

Antes de poder usar la API de Monitoring, debes habilitarla y tienes autorizaci�n para usarla. Para obtener m�s informaci�n, consulta la siguiente documentaci�n:

Estructura de las pol�ticas de alertas

La API de Monitoring representa una pol�tica de alertas con el Estructura de AlertPolicy. La estructura AlertPolicy tiene varias estructuras incorporadas, incluida una descripci�n de la condici�n de la pol�tica de alertas. Alertas basadas en registros las pol�ticas se diferencian de las pol�ticas de alertas basadas en m�tricas de las siguientes maneras:

  • Para describir la condici�n, usa LogMatch. tipo de condici�n. Las pol�ticas de alertas basadas en m�tricas usan diferentes tipos de condiciones.
  • Una pol�tica de alertas basada en registros solo puede tener una condici�n.
  • Debes especificar el tiempo que transcurre entre las notificaciones y el cierre autom�tico de incidentes. incluyendo una estructura AlertStrategy. Las pol�ticas de alertas basadas en m�tricas no incluyen un tiempo entre notificaciones.

En esta secci�n, se describe c�mo crear una pol�tica de alertas basada en registros. Estos las pol�ticas difieren de las pol�ticas de alertas basadas en m�tricas en el tipo de condici�n que usas. Para las pol�ticas de alertas basadas en registros, el tipo de condici�n es LogMatch. Cuando usas la API de Monitoring para administrar las pol�ticas de alertas, hay no hay diferencias en la forma en que enumeras, editas o borras m�tricas y pol�ticas basadas en registros. En Administra las pol�ticas de alertas por API, se describe c�mo crear, enumerar, editar y borrar pol�ticas de alertas con la API de Monitoring

Reglas de notificaci�n

Cuando creas una pol�tica de alertas basada en registros, un objeto interno llamado regla de notificaci�n. Registro usa la regla de notificaci�n para buscar coincidencias al filtro de tu pol�tica de alertas y, luego, crear una notificaci�n cuando una entrada coincide con los criterios del filtro. No interact�as directamente con la regla de notificaciones. Sin embargo, para crear una pol�tica de alertas basada en registros, debes tener el permiso logging.notificationRules.create.

Dise�a la pol�tica de alertas

En la secci�n titulada Crea una pol�tica de alertas basada en registros mediante el Explorador de registros, se describe una forma de crear una pol�tica de alertas basada en registros. En esa secci�n, se muestra c�mo crear una pol�tica de alertas basada en registros que te notifica cuando una entrada de registro syslog tiene un gravedad, el nivel de NOTICE y una direcci�n IPv4 no v�lida en jsonPayload.result .

Para crear la misma pol�tica de alertas basada en registros con el de API�de�Monitoring, crea un objeto AlertPolicy que se vea como la siguiente estructura JSON:

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alerting policy in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },

  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\") severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",

  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },

  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

Este código JSON especifica la misma información que especificas cuando crees una política de alertas basada en registros con el Explorador de registros. Lo siguiente asignan el contenido de esta estructura AlertPolicy a los pasos seguir cuando uses el Explorador de registros para crear una alerta basada en registros. El valor del campo conditionMatchedLog es una estructura LogMatch.

Proporciona un nombre y una descripción

Una política de alertas tiene un nombre visible y documentación asociada notificaciones para ayudar a los responsables de la respuesta. En el Explorador de registros, estos campos se llaman Nombre de la alerta y Descripción de la alerta. Usted representa estos valores en una estructura AlertPolicy de la siguiente manera:

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alerting policy in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },
  ...
}

En este ejemplo, el valor de displayName incluye “(API)” para que pueda distinguir entre las dos políticas de ejemplo cuando veas la lista de políticas en la consola de Google Cloud. En la página Políticas de supervisión, se enumeran las políticas por nombre visible y se indica si se basan en métricas o registros. Para obtener más información, ver Administra las políticas de alertas basadas en registros en Monitoring.

En el subcampo content, el campo documentation incluye la descripción que puedes proporcionar cuando uses el Explorador de registros. El segundo subcampo, mimeType, es obligatorio cuando especificas un valor para el campo documentation. El único el valor válido es "text/markdown".

Elige los registros para los que quieres recibir notificaciones

Una política de alertas basada en registros tiene una sola condición. En el Explorador de registros, especificas la condición cuando proporcionas una consulta en la sección Define log entries to alerta activada. Debes representar estos valores en una estructura AlertPolicy de la siguiente manera: sigue:

{ ...
  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",
  ...
}

El campo conditions toma una lista de Condition de alertas, aunque una política de alertas basada en registros debe tener solo estado. Cada Condition tiene un nombre visible y una descripción de la condición.

  • El valor del campo displayName es una descripción breve de la condición. Cuando usas el Explorador de registros para crear políticas de alertas basadas en registros, el el nombre visible siempre es “Condición de coincidencia del registro”. Cuando uses API de Monitoring, puedes proporcionar un nombre visible más preciso. Es obligatorio ingresar un valor.

  • El valor del campo conditionMatchedLog es un la estructura de LogMatch y el valor de filter es la consulta que especificas en el Explorador de registros. Porque esta se proporciona la consulta como el valor de un campo JSON, se muestra toda la consulta entre comillas, y cualquier comillas en la consulta debe escaparse con el Carácter \ (barra invertida).

  • La estructura LogMatch también incluye un elemento labelExtractors. Puedes use extractores de etiquetas para redactar etiquetas personalizadas a partir de sus las entradas de registro y hacer referencia a ellas en las notificaciones.

    Por ejemplo, para extraer el valor de la etiqueta de recurso. labels."compute.googleapis.com/resource_id" de tu entrada de registro en una etiqueta llamada vm_identifier, la la condición anterior podría verse de la siguiente manera:

    "conditions": [
      {
        "displayName": "Log match condition: invalid IP addr (API)",
        "conditionMatchedLog": {
          "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
          "labelExtractors": {
            "vm_identifier": "EXTRACT(labels.\"compute.googleapis.com/resource_id\")"
          }
        },
      }
    ],
    

    Usa la función EXTRACT para hacer coincidir todo el valor, o bien usa REGEXP_EXTRACT para hacer coincidir las subcadenas con las expresiones regulares Estas funciones son las mismas que se usan para la extracción de etiquetas métricas; Consulta Crea una etiqueta para obtener más información.

    Puedes usar las etiquetas extraídas en la documentación del política de alertas, por lo que se informan en las notificaciones. En el campo documentation de tu política de alertas, puedes hacer referencia a las etiquetas extraídas con una variable del formato ${log.extracted_label.KEY}, en la que KEY es el nombre que le asignaste a la etiqueta extraída.

    En el siguiente ejemplo, se muestra cómo consultar la clave para la la etiqueta extraída vm_identifier, para que el valor del registro se incluye la etiqueta labels."compute.googleapis.com/resource_id" las notificaciones:

    "documentation": {
      "content": "Log-based alerting policy in project ${project} detected an
       invalid IPv4 value on VM with ID ${log.extracted_label.vm_identifier}.",
      "mimeType": "text/markdown"
    },
    

El valor del campo combiner especifica c�mo combinar los resultados de m�ltiples condiciones en pol�ticas de alertas basadas en m�tricas. Solo puedes usar una condici�n en las pol�ticas de alertas basadas en registros, y debes especificar el campo combiner con el valor "OR". No puedes crear pol�ticas de alertas basadas en registros con varias condiciones.

Establecer valores de notificaci�n y cierre autom�tico

Una pol�tica de alertas basada en registros especifica el tiempo m�nimo entre notificaciones. En el explorador de registros, selecciona un valor del men� Tiempo entre notificaciones. Para representar este valor en una estructura AlertPolicy, especifica un en segundos para el campo period de una una estructura de NotificationRateLimit incorporada en AlertStrategy.

Del mismo modo, la pol�tica de alertas incluye el per�odo para cerrar incidentes autom�ticamente. El valor predeterminado es de 7 d�as. En el Explorador de registros, puedes seleccionar un valor diferente del Men� Duraci�n del cierre autom�tico de incidentes. La opci�n corresponde al Campo autoclose en la estructura de la API de AlertStrategy. Cuando uses este campo, especifica el valor en segundos. El valor m�nimo es de 1,800 segundos o 30 minutos.

{ ...
  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },
  ...
}

El valor del campo period en este ejemplo, 300s, es equivalente a lo siguiente: 5 minutos. El valor autoclose, 604800s, equivale a 7 d�as.

Especifica a qui�n notificar

Una pol�tica de alertas puede incluir una lista de canales de notificaci�n. En el Explorador de registros, puedes seleccionar los canales de un men�. Para representar estos valores en una estructura AlertPolicy, proporciona una lista de uno o m�s nombres de recursos para Objetos NotificationChannel:

{ ...
  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

Cuando creas un canal de notificaciones, se le asigna un nombre de recurso. Para obtener informaci�n sobre c�mo recuperar la lista de canales de notificaci�n disponibles, que incluye sus nombres de recursos, consulta Recupera canales en Monitoring en la documentaci�n de Google Cloud. No puedes obtener los IDs de los canales con el Consola de Google Cloud

Env�a tu pol�tica de alertas a la API de Monitoring

Para crear una pol�tica de alertas con la API de Monitoring, debes crear un objeto AlertPolicy y enviarlo al m�todo alertPolicies.create. Puedes invocar el alertPolicies.create con Google Cloud CLI llamando directamente a la API de Monitoring.

Tambi�n puedes crear pol�ticas de alertas basadas en registros usando las bibliotecas cliente para C#, Go, Java, Python y Ruby. Tambi�n es posible que puedas usar otros clientes bibliotecas; la biblioteca de tu idioma deben incluir el Tipo de condici�n LogMatch.

Para crear una pol�tica de alertas con gcloud CLI, haz lo siguiente: lo siguiente:

  1. Coloca la representaci�n JSON de tu pol�tica de alertas en un archivo de texto. por ejemplo, en un archivo llamado alert-invalid-ip.json.

  2. Pasa este archivo JSON a gcloud CLI con el siguiente comando:

    gcloud alpha monitoring policies create --policy-from-file="alert-invalid-ip.json"
    
  3. Si se ejecuta correctamente, este comando muestra el nombre del recurso de la pol�tica nueva, por ejemplo:

    Created alerting policy [projects/PROJECT_ID/alertPolicies/POLICY_ID].
    

Para crear una pol�tica de alertas llamando directamente a alertPolicies.create, puedes usar la herramienta Explorador de APIs de la siguiente manera:

  1. Ve a la p�gina de referencia de alertPolicies.create.

  2. En el panel Prueba esta API, haz lo siguiente:

    1. En el campo name, ingresa el siguiente valor:

      projects/PROJECT_ID
      
    2. Copia la representaci�n JSON de tu pol�tica de alertas y reemplaza el contenido del campo Cuerpo de la solicitud en el Explorador de APIs con el copiaste la pol�tica de alertas.

    3. Haz clic en Ejecutar.

      Si la llamada a alertPolicies.create se realiza correctamente, obtienes un c�digo de respuesta HTTP 200 y un cuerpo de respuesta vac�o, {}. Para ver m�s sobre el Explorador de APIs, consulta Con el Explorador de APIs en Documentaci�n de Monitoring.

Para obtener m�s informaci�n sobre la creaci�n de pol�ticas de alertas con el API de Monitoring, consulta Crea pol�ticas. En los ejemplos de ese documento, se usan tipos de condiciones para alertas basadas en m�tricas. pol�ticas, pero los principios son los mismos.

Prueba la pol�tica de alertas

Para probar tu nueva pol�tica de alertas, puedes usar el mismo procedimiento que se describe en Prueba la alerta basada en registros de ejemplo.

Ejemplo: Crea una pol�tica de alertas cuando una entrada de registro contiene una string de texto

En este ejemplo, se usa la consola de Google Cloud para crear una pol�tica de alertas, la el Explorador de registros para ver entradas de registro y Google Cloud CLI escribir una entrada de registro:

  1. En la consola de Google Cloud, ve a la p�gina Explorador de registros.

    Ir al Explorador de registros

    Si usas la barra de b�squeda para encontrar esta p�gina, selecciona el resultado cuyo subt�tulo es Logging.

  2. En el panel Consulta, ingresa la siguiente consulta despu�s de actualizar el Valor de PROJECT_ID:

    logName="projects/PROJECT_ID/logs/test-log"
    textPayload:"Oops"
    

    La consulta busca en el registro con el nombre test-log las entradas de registro que tener un campo textPayload que contenga la cadena "Oops".

  3. Haz clic en Crear alerta y completa el cuadro de di�logo. Debes ingresar un nombre para la pol�tica, como Alert on Oops. La consulta que ingresaste en el paso anterior se incluye autom�ticamente en la pol�tica de alertas.

  4. Para probar la pol�tica de alertas, abre Cloud�Shell Ejecuta el siguiente comando:

    gcloud logging write test-log --severity=ERROR --payload-type=text 'This log entry contains Oops'
    

    El comando anterior escribe una entrada en el registro llamado test-log. El tiene un nivel de gravedad de ERROR y, adem�s, incluye un campo textPayload.

  5. En el Explorador de registros, haz clic en Ejecutar consulta.

    Cuando se actualice la pantalla, podr�s ver los detalles de la entrada de registro que escribiste en el paso anterior.

  6. En la consola de Google Cloud, ve a la p�gina Alertas.

    Ir a las Alertas

    Si usas la barra de b�squeda para encontrar esta p�gina, selecciona el resultado cuyo subt�tulo es Monitoring.

    En el panel Incidentes, se muestran el incidente y sus detalles. sobre la pol�tica de alertas.

    Si no ves un incidente cuando abres la p�gina Alertas, espera unos minutos y actualiza la p�gina.

No ver�s otro incidente ni recibir�s otra notificaci�n si repetir de inmediato el comando de Google Cloud CLI. La configuraci�n de la pol�tica de alertas especifica el per�odo m�nimo entre incidentes. Puedes verlas y cambiarlas de tu organizaci�n editando la pol�tica.