Documentación de Oracle Cloud Infrastructure

Crear alarmas

Definición de alarmas

Cuando se cumple una condición de métrica, puede utilizar el sistema de alarma del servicio Monitoring para alertar a las partes interesadas sobre las condiciones. Puede crear alarmas en recursos individuales o en un compartimento completo.

Ops Insights proporciona un cómodo acceso a la funcionalidad de creación de alarmas del servicio Monitoring directamente desde cualquier página de recursos del conjunto.

Para crear una alarma:
  1. En el panel de la izquierda, haga clic en Administración.
  2. Haga clic en un recurso de conjunto. (Conjunto de bases de datos, conjunto de hosts, conjunto de Exadata, almacén de Ops Insights).
  3. Haga clic en el menú Acción (elipses verticales) de un recurso específico y seleccione Agregar alarmas. Se muestra la región Agregar alarmas a métricas. Amplíe la región Description debajo de cada métrica para ver los parámetros de disparador sugeridos, así como las dimensiones clave.
    En el gráfico se muestra la región Add Alarms to Metrics.

  4. Haga clic en Agregar alarma. Accederá a la página Crear alarma del servicio Monitoring con los detalles de métrica necesarios ya rellenados.
    Nota

    Por defecto, una alarma se aplica a un recurso individual. Si desea que la alarma se aplique a todo un compartimento, elimine resourceID.
  5. En Notificación>Destinos, seleccione un tema o canal que desee utilizar para enviar notificaciones cuando se dispare una alarma. También puede crear un tema.
  6. Proporcione un nombre de alarma y defina el umbral sugerido y el retraso del disparador.
  7. Haga clic en Guardar alarma.

Condiciones específicas de alarma

Alarmas SQL

Puede crear alertas para las condiciones definidas para la métrica NumSqlsNeedingAttention . Las alarmas deben crearse de una manera específica para que se limpien correctamente. Los siguientes ejemplos ilustran cómo disparar una alarma en varias condiciones de alerta.

Condición de alarma Definición de alarma MQL
Desea disparar una alarma si el número total de sentencias SQL en todos los recursos, que están degradados y tienen un cambio de plan, es mayor que 5. 
NumSqlsNeedingAttention[3h]
{isIncreasingCpu="1", isDegraded="1"}.absent()==0 && NumSqlsNeedingAttention[3h]{isIncreasingCpu="1", isDegraded="1"}
.sum() > 5
Desea disparar una alarma cada vez que algún recurso tenga un cambio de plan. 
NumSqlsNeedingAttention[3h]
{isPlanChanged = "1"}.absent()==0 && NumSqlsNeedingAttention[3h]{isPlanChanged = "1"}
.max() > 0
Desea disparar una alarma cada vez que el recurso tenga un cambio de plan. 
NumSqlsNeedingAttention[3h]
{isPlanChanged = "1", resourceId = "opsi.ocid"}
.absent()==0 && NumSqlsNeedingAttention[3h]
{isPlanChanged = "1", resourceId = "opsi.ocid}
.max() > 0

Se pueden utilizar patrones similares para cualquiera de las dimensiones. En general, para disparar una alarma en una condición específica, la sintaxis de definición de alarma genérica tendría el siguiente aspecto:

NumSqlsNeedingAttention[3h]
{dim1="val1", dim2="val2", ....}
.absent()==0 && NumSqlsNeedingAttention[3h]
{dim1="val1", dim2="val2, ...}
.sum() > 5
Nota

Debe especificar una condición ausente y una condición umbral como se muestra anteriormente, y la especificación de dimensión debe ser la misma en ambas cláusulas. Solo debe cambiar las dimensiones o el valor de umbral según sea necesario y dejar los demás valores tal cual.

Retrasos de flujo de datos

Puede crear alertas para las condiciones definidas para la métrica DataFlowDelayInHrs. En la siguiente tabla se muestran algunas alarmas recomendadas que puede configurar junto con un ejemplo de Monitoring Query Language (MQL) correspondiente que puede utilizar como plantilla para definir las alarmas. Para obtener más información sobre la configuración de alarmas, consulte Gestión de asignaciones.

Nombre de alarma Definición de alarma MQL Descripción
DataFlowSourceAlarmFor1HrData DataFlowDelayInHrs[1h]{dataProcessingFrequencyInHrs="1.00"}.grouping(telemetrySourceType , sourceIdentifier).mean() > 48

Duración pendiente: 1 h

 Para un valor sourceType, sourceIdentifier con una frecuencia de procesamiento de datos de 1 hora, el valor medio (entre destinos) de DataFlowDelayInHrs es superior a 48 horas para 6 horas continuas. Esto indica que el problema está en todo el nivel de origen.
DataFlowResourceAlarmFor1HrData DataFlowDelayInHrs[1h]{dataProcessingFrequencyInHrs="1.00"}.grouping(telemetrySourceType, resourceId,resourceDisplayName, sourceIdentifier).max() > 24

Duración pendiente: 1 h

 Para un valor sourceType, el recurso y sourceIdentifier, DataFlowDelayInHrs es más de 24 horas para 1 día continuo para el tipo de datos para el que la frecuencia de procesamiento de datos es cada hora.
DataFlowResourceAlarmFor3HrData DataFlowDelayInHrs[3h]{dataProcessingFrequencyInHrs="3.00"}.grouping(telemetrySourceType, resourceId, sourceIdentifier).max() > 48

Duración pendiente: 1 h

 Para un valor sourceType, el recurso y sourceIdentifier, DataFlowDelayInHrs es más de 48 horas para 1 día continuo para el tipo de datos para el que la frecuencia de procesamiento de datos es cada 3 horas.
DataFlowResourceAlarmForDailyData DataFlowDelayInHrs[3h]{dataProcessingFrequencyInHrs="24.00"}.grouping(telemetrySourceType, resourceId, sourceIdentifier).mean()

Duración pendiente: 1 h

 Para un valor sourceType, el recurso y sourceIdentifier, DataFlowDelayInHrs es más de 72 horas para 1 día continuo para el tipo de datos para el que la frecuencia de procesamiento de datos es cada 24 horas.

Acerca de las incidencias de previsión

Ops Insights proporciona métricas que ayudan a configurar alarmas para una utilización alta (valor por defecto >75%) o baja (valor por defecto <25%) para una métrica de recurso determinada. Además, puede personalizar estos umbrales de métricas de previsión. Ayudando a proporcionar una previsión de gestión de capacidad más granular, lo que le permite ser más proactivo en la gestión de recursos mediante la definición de valores de umbral más relevantes para un tipo de objetivo específico para una previsión más precisa. Para obtener más información sobre la configuración de valores de umbral, consulte: Cambio de umbrales de utilización.

Las métricas de previsión se generan con un máximo de 100 días de datos de historial y una ventana de previsión de 90 días. Puede verificar la previsión desde la consola de Ops Insights seleccionando 1 año en el filtro de rango de tiempo y la utilización alta o baja durante 90 días, como se muestra a continuación.


Selector de rango temporal

Utilización alta en 90 días

Utilización baja en 90 días

En la siguiente tabla se muestra un ejemplo de una alarma recomendada que puede configurar junto con un ejemplo de Monitoring Query Language (MQL) correspondiente que puede utilizar como plantilla para definir las alarmas. Para obtener más información sobre la configuración de alarmas, consulte Gestión de asignaciones.

Nombre de alarma MQL Descripción
DaysToReachHighUtilizationStorageLessThan30D DaysToReachHighUtilization[1D]{resourceMetric="STORAGE", resourceType="Database", exceededForecastWindow="false"}.grouping(telemetrySource,resourceId).mean() < 30," Para sourceType, resourceType, resourceMetric y sourceIdentifier, DaysToReachHighUtilization es inferior a 30 días.
DaysToReachHighUtilizationExaStorage DaysToReachHighUtilization[1D]{resourceMetric="STORAGE", resourceType="Database", exceededForecastWindow="false"}.grouping(telemetrySource,resourceId).mean() < 30, Para sourceType, resourceType, resourceMetric y sourceIdentifier, DaysToReachHighUtilization es inferior a 30 días.
Nota

Para las previsiones lineales y estacionales, la ventana de previsión es de 90 días, lo que significa que si un recurso específico tiene una previsión de más de 90 días, el valor de métrica mostrará por defecto 91 días. Para AutoML, esta previsión se realiza por número de puntos de datos disponibles.