Visión general de Monitoring
El servicio Oracle Cloud Infrastructure Monitoring le permite supervisar de manera activa y pasiva los recursos en la nube mediante las funciones de métricas y alarmas. Conozca cómo funciona Monitoring.
Cómo funciona Monitoring
El servicio Monitoring utiliza métricas para supervisar recursos y alarmas a fines de notificarle en caso de Que estas métricas alcancen los disparadores especificados por la alarma.
Las métricas se emiten al servicio Monitoring en forma de puntos de datos no procesados o pares de marcas de tiempo-valor junto con las dimensiones y las metadatos. Las métricas provienen de varias fuentes:
- Las métricas de recursos publicadas automáticamente por los recursos de Oracle Cloud Infrastructure. Por ejemplo, el servicio Compute publica métricas de instancias informáticas con supervisión habilitada a través del del espacio oci_computeagent. Una de estas métricas es
CpuUtilization. Consulte Servicios soportados y Visualización de gráficos de métricas por defecto. - Métricas personalizadas publicadas mediante la API de Monitoring.
- Datos enviados a métricas nuevas o existentes mediante Connector Hub (con Monitoring como servicio de destino para un conector).
Puede transferir métricas del servicio Monitoring mediante Connector Hub. Para obtener más información, consulte Crear un conector con un origen de Monitoring.
Los datos de métricas publicados en el servicio Monitoring solo se le presentan a usted o son consumidos por funciones de Oracle Cloud Infrastructure que le permiten usar datos de métricas.
Cuando consulta una métrica, el servicio Monitoring devuelve datos agregados según los parámetros especificados. Puede especificar un rango (por ejemplo, las últimas 24 horas), una estadística y un intervalo . La Consola muestra un gráfico de supervisión por métrica para los recursos seleccionados. Los datos agregados en cada gráfico reflejan el intervalo y la estadística seleccionados. Las solicitudes de API pueden filtrar por dimensión y especificar una resolución . Las respuestas a API incluyen el nombre de la métrica junto con su compartimento de origen y elespacio de nombre de métrica. Puede suministrar los datos agregados a una biblioteca de visualización o de gráficos.
Es posible acceder a la información de métricas y alarmas desde la consola, la CLI y la API. Para obtener información sobre los periodos de retención, consulte Límites de almacenamiento.
La función Alarmas del servicio Monitoring publica mensajes de alarma en destinos configurados, como temas de Notificaciones y flujos de Streaming.
Visión general de la función de métricas
La función Métricas transmite datos de métricas sobre el sistema, la capacidad y la capacidad de los recursos de la nube.
Una métrica es una medición relacionada con el sistema, la capacidad o el rendimiento de un recurso . Los recursos, los servicios y la aplicación emiten métricas al servicio Monitoring. Las métricas comunes reflejan datos relacionados con:
- Disponibilidad y latencia
- Tiempo de actividad e inactividad de las aplicaciones
- Transacciones finalizadas
- Operaciones fallidas y correctas
- Indicadores clave de rendimiento (KPI), como los cuantificadores de ventas e interacción
Al consultar los datos en Monitoring, podrá comprender cómo funcionan los sistemas y procesos para alcanzar los niveles de servicio que prometa a los clientes. Por ejemplo, puede supervisar el uso y la lectura de disco de la CPU de las instancias informáticas. Posteriormente, puede utilizar estos datos para determinar cuándo hay que aprovisionar más instancias para gestionar un aumento en la carga, solucionar problemas con la instancia o conocer mejor el comportamiento de sistema.
Métrica de ejemplo: ratio de fallos
Para conocer el estado de la aplicación, uno de los KPI habituales es la ratio de fallos, que puede definirse como el número de transacciones fallidas dividido entre el número total de transacciones. Este KPI suele proporcionarse por medio de la supervisión y la gestión de las aplicaciones.
Como desarrollador, puede capturar este KPI en las aplicaciones mediante métricas personalizadas. Registre las observaciones cada vez que se produzca una transacción en la aplicación y luego publique dichos datos en el servicio Monitoring. En este caso, configure métricas para capturar transacciones fallidas, transacciones correctas y la latencia de las transacciones (tiempo empleado por transacción finalizada).
Visión general de la función Alarmas
Utilice alarmas para supervisar el estado, la capacidad y la eficacia de los recursos de la nube.
La función Alarmas del servicio Monitoring funciona junto al servicio del destino configurado para informarle en caso de Que las métricas alcancen los disparadores especificados para las alarmas. La ilustración anterior muestra el flujo, empezando por los recursos de métricas que emiten puntos de datos para Monitoring. Cuando se dispara, una alarma envía un mensaje para alarma al destino configurado. Para Notifications, los mensajes se envían a lassuscripciones en el tema configurado. Para Streaming, los mensajes se envían al flujo configurado. (En esta ilustración no se incluyen los datos de métricas brutas y agregadas. Para obtener más información, consulte la ilustración "Visión general de supervisión" en la parte superior de esta página.
Cuando se configura, las notificaciones repetidas le recuerdan un estado de activación continuo durante el intervalo de repetición configurado. También se te notificará cuando una alarma regrese al estado OK o cuando se restablezca una alarma.
Evaluaciones de alarma
La supervisión evalúa las alarmas una vez por minuto para encontrar el estado de las alarmas.
Cuando la alarma divide las notificaciones, Monitoring evalúa cada flujo de métricas con seguimiento. Si la evaluación de ese flujos de métricas indica un nuevo estado FIRING u otro evento de cualificación, Monitoring envía un mensaje a la alarma.
Monitoring realiza el seguimiento de los flujos de métricas por alarma para eventos de cualificación, pero los mensajes están sujetos a los límites de servicio de destino.
Ilustración de la evaluación de alarmas
Considere una alarma que mida el percentil 90 de la métrica CpuUtilization.
{
"compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
"destinations": ["ocid1.onstopic.exampleuniqueID"],
"displayName": "High CPU Utilization",
"id": "ocid1.alarm.oc1..exampleuniqueID",
"lifecycleState": "ACTIVE",
"metricCompartmentId": "ocid1.compartment.oc1..exampleuniqueID",
"namespace": "oci_computeagent",
"pendingDuration": "PT3M",
"query": "CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85",
"repeatNotificationDuration": "PT2H",
"severity": "WARNING",
"isEnabled": true,
"timeCreated": "2023-02-01T01:02:29.600Z",
"timeUpdated": "2023-02-03T01:02:29.600Z"
}Notas sobre este ejemplo de alarma:
- El percentil se especifica en la consulta como statistic (negrita):
CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85 - Cada punto de datos es el percentil 90 (
percentile(0.9)) de una ventana de un minuto, especificada en la consulta como intervalo (negrita):CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85 - Los valores de punto de datos para esta estadística pueden ser cualquier valor, desde nulo (ausente) hasta 100.
- Evaluaciones de puntos de datos:
- Para cualquier valor de punto de datos mayor que 85, la evaluación es verdadera (
1). Una evaluación verdadera significa que se ha cumplido la condición de la regla del disparador. - Para cualquier valor de punto de datos que no sea mayor que 85, la evaluación es falsa (
0).
- Para cualquier valor de punto de datos mayor que 85, la evaluación es verdadera (
- La alarma no se dispara hasta que se cumple la condición de regla de disparador durante tres minutos sucesivos. Esta configuración es el retraso del disparador de la alarma (
pendingDuration), definido comoPT3M. - La alarma actualiza su estado a OK cuando la condición de incumplimiento ha sido clara durante el minuto más reciente.
En la siguiente imagen se muestra un flujo de métricas agregado para la alarma de ejemplo. Cada punto de datos se indica mediante un cuadrado.
En la siguiente tabla, se muestran las evaluaciones de alarma consecutivas para la alarma de ejemplo. La alarma se evalúa en una ventana móvil de tres intervalos de un minuto.
| Registro de hora de período de evaluación | Minutos en el período | Evaluaciones de puntos de datos* | Estado |
|---|---|---|---|
| 3 | [1 2 3] | [0 0 0] | OK |
| 4 | [2 3 4] | [0 0 1] | OK |
| 5 | [3 4 5] | [0 1 1] | OK |
| 6 | [4 5 6] | [1 1 1] | FIRING |
| 7 | [5 6 7] | [1 1 1] | FIRING |
| 8 | [6 7 8] | [1 1 0] | OK |
| 9 | [7 8 9] | [1 0 0] | OK |
| 10 | [8 9 10] | [0 0 0] | OK |
*Un valor de uno (1) significa que se cumple la condición de regla de disparador.
Cómo se cuentan los puntos de datos
En esta sección, se describe cómo determinar el número de puntos de datos (o puntos de datos) recuperados por una alarma. Este número puede ayudarle a estimar los precios de supervisión.
Para buscar el número de puntos de datos recuperados por una alarma, primero obtenga el número de flujos de consulta y los minutos analizados.
- El número de flujos de consulta depende de los flujos de métricas devueltos por la consulta de alarma.
- Los minutos analizados dependen de los atributos de alarma
interval,resolutionypendingDuration. Para las consultas de alarma, el único valor válido pararesolutiones1m. Para obtener más información sobreinterval, consulte Intervalo. Para obtener más información sobreresolutionypendingDuration, consulte API de Monitoring.
Cada alarma se evalúa una vez cada minuto y, por lo tanto, cada alarma se evalúa 1440 veces al día. Cada evaluación consulta los datos en el período de tiempo definido por interval y comprueba el período de tiempo que la alarma persiste definido por pendingDuration. Por lo tanto, los minutos analizados a cada minuto se calculan mediante la siguiente expresión:
minutos analizados a cada minuto = interval * techo(pendingDuration / resolution)
Acerca del período de restablecimiento interno
El período de restablecimiento interno determina cuándo una alarma deja de comprobar una métrica ausente que disparó el estado de activación en la evaluación anterior. Cuando la métrica está ausente para todo el período, las evaluaciones de alarma posteriores ignoran el flujo de métricas indicado. Si ningún otro flujo de métricas está causando el estado Firing para la alarma, la alarma pasa a OK y envía un RESET message. Por defecto, el mensaje RESET llega después de 13 minutos (período de restablecimiento interno más el período de slack por defecto de 3 minutos). Puede personalizar el período de slack.
La duración del período de restablecimiento interno se configura globalmente en 10 minutos, lo que hace que el historial de alarmas muestre una diferencia de 10 minutos.
El inicio de un período de restablecimiento interno depende del tipo de alarma. Para las alarmas de umbral, el período de restablecimiento interno se inicia cuando se detecta la primera ausencia. Para las alarmas de ausencia, el período de restablecimiento interno comienza después de completar el período de detección de ausencia (el valor por defecto es 2 horas, se puede personalizar).
Puntos de datos recopilados durante un período de restablecimiento interno
Cada evaluación durante el período de restablecimiento interno de diez minutos contabiliza todos los puntos de datos de ese período.
Por ejemplo, considere un flujo de métricas (A) que supere el umbral (línea roja con guiones en los siguientes diagramas). La alarma se dispara (F). Cuando se detecta una falta de puntos de datos emitidos, comienza un período de restablecimiento interno.
En el siguiente diagrama se muestra un único período de restablecimiento interno para el flujo de métricas A, desde los tiempos t5 hasta t15. En el momento t16, el flujo de métricas A ya no se evalúa.
En el siguiente diagrama se muestran dos períodos de restablecimiento internos para el flujo de métricas A, desde las horas t3 a t5 y desde t6 a t16. A emite un punto de datos en t6, iniciando otro período de restablecimiento interno. En el momento t17, el flujo de métricas A ya no se evalúa.
Ejemplo de alarma de umbral
Una alarma de umbral informa sobre los flujos de métricas que se producen fuera del umbral. Cuando no hay un flujo de métricas previamente problemático, la alarma inicia el período de restablecimiento interno para el flujo de métricas.
En este ejemplo, cuatro flujos de métricas se evalúan mediante una alarma de umbral. La consola muestra los estados de transición Firing (1:30) y Ok (1:51) iniciales. El período de restablecimiento interno se produce mientras la alarma está en estado de activación.
El período de restablecimiento interno y otros eventos significativos de este ejemplo se describen en la siguiente tabla.
| Hora | Estado | Transición | Eventos | Notificaciones (consulte Tipos de Mensajes) |
|---|---|---|---|---|
| 12:0 | OK |
OK |
Todas las emisiones están dentro del umbral. | FIRING_TO_OK |
| 1:30 | FIRING |
FIRING |
Las emisiones de resource1 superan el umbral. | OK_TO_FIRING |
| 1:35 | FIRING |
-- |
No se ha detectado ninguna emisión para resource1. La alarma inicia el período de restablecimiento interno para resource1. | -- |
| 1:38 | FIRING |
-- |
No se ha detectado ninguna emisión para resource2. La alarma inicia el período de restablecimiento interno para resource2. | -- |
| 1:45 | FIRING |
-- |
El período de restablecimiento interno finaliza para resource1, por lo que la alarma ya no comprueba las emisiones de resource1. Sin embargo, la alarma se sigue disparando porque resource2 aún se encuentra en su propio período de restablecimiento interno. | -- |
| 1:48 | OK |
OK |
El período de restablecimiento interno finaliza para resource2, por lo que la alarma ya no comprueba las emisiones de resource2. Las emisiones de los recursos restantes (resource3 y resource4) están dentro del umbral. | RESET (enviado después del período de slack de tres minutos, aproximadamente a las 1:51) |
Ejemplo de alarma de ausencia
Una alarma de ausencia informa sobre flujos de métricas ausentes. Cuando un flujo de métricas está ausente, la alarma inicia el período de detección de ausencias para el flujo de métricas (el valor por defecto de dos horas se puede personalizar). Después de finalizar el período de detección de ausencias, la alarma inicia el período de restablecimiento interno para el flujo de métricas.
En este ejemplo, un flujo de métricas se evalúa mediante una alarma de ausencia que utiliza el período de detección de ausencias de dos horas por defecto y el período de slack de tres minutos por defecto. La consola muestra los estados de transición Firing (2:00) y Ok (4:10) iniciales. El período de restablecimiento interno se produce mientras la alarma está en estado de activación.
El período de restablecimiento interno y otros eventos significativos de este ejemplo se describen en la siguiente tabla.
| Hora | Estado | Transición | Eventos | Notificaciones (consulte Tipos de Mensajes) |
|---|---|---|---|---|
| 1:00 | OK |
-- | Se detectan emisiones. | |
| 2:00 | FIRING |
FIRING |
No se ha detectado ninguna emisión para el recurso-z. La alarma inicia el período de detección de ausencias para el recurso-z. | OK_TO_FIRING |
| 4:0 | FIRING |
-- |
El período de detección de ausencias para el recurso-z finaliza. La alarma inicia el período de restablecimiento interno para resource-z. | -- |
| 4:10 | OK |
OK |
El período de restablecimiento interno finaliza para el recurso-z, por lo que la alarma ya no comprueba las emisiones del recurso-z. La alarma ya no supervisa ningún flujo de métricas, por lo que la alarma pasa al estado correcto. | RESET (enviado después del período de slack de tres minutos, aproximadamente a las 4:13) |
Tiempo necesario para reflejar las actualizaciones de alarma
Las actualizaciones de las alarmas tardan hasta cinco minutos en reflejarse en todas partes.
Por ejemplo, si actualiza una alarma para dividir notificaciones, puede tardar hasta cinco minutos para que se rellene el estado de flujo de métricas en la consola.
Búsqueda de alarmas
Busque alarmas utilizando atributos soportados.
Para obtener más información sobre la función de búsqueda, consulte Visión general de búsqueda. Para ver una descripción de los atributos, consulte Referencia de alarmas.
-
id -
displayName -
compartmentId -
metricCompartmentId -
namespace -
query -
severity -
destinations -
suppression -
isEnabled -
lifecycleState -
timeCreated -
timeUpdated -
tags
El tipo de mensaje indica el motivo por el que se envió el mensaje.
El tipo de mensaje especificado se envía a la hora indicada más el retraso del disparador configurado de la alarma, si lo hay.
Los mensajes repetidos también se envían si están configurados en la alarma.
En la siguiente tabla, se muestran el estado de alarma y la transición para cada tipo de mensaje.
| Tipo de mensaje | Estado | Transición | Comentarios |
|---|---|---|---|
OK_TO_FIRING |
FIRING |
de OK a FIRING |
|
FIRING_TO_OK |
OK |
de FIRING a OK |
|
REPEAT |
FIRING |
-- | Este tipo de mensaje se envía cuando la alarma mantiene el estado FIRING y la alarma está configurada para las notificaciones de repetición. |
RESET |
OK |
de FIRING a OK |
Importante: Cuando se produzca un cambio de estado Este tipo de mensaje se envía cuando la alarma pasa al estado Causas posibles de un flujo de métricas ausente: puede que el recurso que emitió la métrica se haya movido o terminado, o que la métrica solo se haya emitido en caso de fallo. Para obtener más información sobre el período de restablecimiento interno, consulte Acerca del período de restablecimiento interno. |
Formato del mensaje y ejemplos
Conceptos de Monitoring
Los siguientes conceptos son esenciales para trabajar con Monitoring.
- datos agregados
- The result of applying a statistic and interval to a selection of raw data points for a metric. Por ejemplo, puede aplicar la estadística
maxy la intervalo1h(una hora) a las últimas 24 horas de puntos datos no procesados para la métricaCpuUtilization. Los datos agregados se muestran en los gráficos de métricas por defecto de la Consola. También puede crear consultas de métricas para conjuntos específicos de datos agregados. Para obtener instrucciones, consulte Visualización de gráficos de métricas por defecto y Creación de consultas de métricas. - alarma
- Consulta de alarma que se va a evaluar y el destino de notificación que se va a utilizar cuando la alarma está en estado de activación, así como otras propiedades de la alarma.
- consulta de alarma
- Expresión en lenguaje Monitoring Query Language (MQL) que se evalúa para la alarma. Una consulta de alarma debe especificar una métrica, una estadística, un intervalo y una regla de disparador (umbral o ausencia). La función Alarmas del servicio Monitoring interpreta los resultados para cada serie del tiempo devuelta como un valor booleano, donde cero representa falso y un valor distinto de nulo representa verdadero. Un valor verdadero significa que se ha cumplido la condición de regla del disparador.
- punto de datos
- Par de marca de tiempo-valor para la métrica especificada. Ejemplo:
2022-05-10T22:19:00Z, 10.4 - dimensión
- Cualificador proporcionado en una definición de métrica. Ejemplo: identificador de recurso (
resourceId), proporcionado en las definiciones de las métricas oci_computeagent. Utilice dimensiones para filtrar o agrupar datos de métricas. Ejemplo de par nombre de dimensión-valor para filtrar por dominio de disponibilidad:availabilityDomain = "VeBZ:PHX-AD-1" - frecuencia
- Periodo de tiempo entre cada punto a datos no publicado para una métrica determinada. (El espacio de nombres de la métrica publica el punto de datos sin procesar en el servicio Monitoring.) Si bien la frecuencia varía en función de la métrica, las métricas del servicio por defecto suelen tener una frecuencia de 60 segundos (un punto de datos publicado por minuto). Consulte también resolución.
- intervalo
- Intervalo de tiempo utilizado para convertir el conjunto de puntos del dato no procesado.
- mensaje
- Contenido que la función Alarmas del servicio Monitoring publica en temas en los destinos de notificaciones configurados para los alarma. Un mensaje se envía cuando la alarma pasa a otro estado, por ejemplo, de
OKaFIRING. - metadatos
- Referencia proporcionada en una definición de métrica. Ejemplo: unidad (bytes), proporcionada en la definición de la métrica
DiskBytesReadoci_computeagent. Utilice metadatos para determinar información adicional sobre una métrica. Para conocer la definición de las métricas, consulte Servicios admitidos. - métrica
- Medida relacionada con el sistema, la capacidad o la capacidad de un recurso. Ejemplo:
CpuUtilizationde métricaoci_computeagent, que mide el uso de una instancia informática. Para conocer la definición de las métricas, consulte Servicios admitidos. - definición de métrica
- Conjunto de referencias, cualificadores y otra información proporcionada por un espacio De Nombres De Métrica para una métrica. Por ejemplo, la métrica
DiskBytesReadde oci_computeagent se define mediante dimensiones (por ejemplo, el identificador de recursos) y metadatos (especificando bytes para el recurso), así como por medio de la identificación de su espacio del nombre de métricas (oci_computeagent). Cada conjunto publicado de puntos de datos posee esta información. Utilice la operación de la API ListMetricData para obtener las definiciones de las métricas. Para conocer la definición de las métricas, consulte Servicios admitidos. - espacio de nombre de métricas
- Indicador del recurso, el servicio o la aplicación que emite la métrica. Se indica en la definición de métrica. Por ejemplo, la Definición de métrica de
CpuUtilizationemitida por el software de Oracle Cloud Agent en instancias informáticas muestra el espacio del nombre de métricaoci_computeagentcomo origen de la métricaCpuUtilization. Para conocer la definición de las métricas, consulte Servicios admitidos. - flujo de métrica
- Juego individual de datos agregados para una métrica y cero o más valores del tamaño.
- En la siguiente imagen se muestran los flujos de métricas en un gráfico. Cada línea del gráfico se corresponde con un flujo de métricas.
- destino de notificación
- Detalles para enviar mensajes cuando la alarma pasa a otro estado, como de
OKaFIRING. Los detalles y la configuración podrían variar según el servicio de destino. Los servicios de destino disponibles incluyen Notifications y Streaming. - Software del agente de Oracle Cloud
- Software utilizado por una instancia informática para publicar puntos de datos no procesados en el servicio Monitoring. Se instala automáticamente con las versiones más recientes de las imágenes admitidas. Consulte Activación de la supervisión para instancias de Compute.
- query
- Expresión en el lenguaje Monitoring Query Language (MQL) e información asociada (como los espacios de nombre de métricas) que se evalúa para la obtención de los datos agregados. La consulta debe especificar una métrica, una estadística y un intervalo.
- resolución
-
Periodo entre intervalos de tiempo o regularidad con la que cambian los intervalos de tiempo. Por ejemplo, utilice una resolución de
1mpara recuperar agregaciones cada minuto.Nota
En la consulta de métricas, el intervalo que seleccione controla la resolución por defecto de la solicitud, lo cual determina el intervalo máximo del tiempo de los datos devueltos.En las consultas de alarmas, el intervalo especificado no tiene efecto alguno en la resolución de la solicitud. El único valor válido de la resolución para una solicitud de consulta de alarma es
1m. Para obtener más información acerca del uso del parámetro de resolución en las consultas de alarmas, consulte Alarma.Como se muestra en la siguiente ilustración, la resolución controla la hora de inicio de cada intervalo de agregación en relación con el intervalo anterior, mientras que el intervalo controla la duración de cada intervalo. Ambas solicitudes aplican la estadística
maxa los datos de cada ventana de cinco minutos (dentro del intervalo), lo que da como consecuencia un único punto del dato agregado que representa el contadorCPUutilizationmás alto para esa ventana. Solo varía el valor de resolución. La resolución varía la regularidad con la que cambian los intervalos de agregación, o las horas de inicio de los intervalos de agregación sucesivos. La solicitud A ya no especifica una resolución y, por tanto, usa el valor por defecto, es decir, el mismo que para el intervalo (5 minutos). Los intervalos de agregación de cinco minutos de esta solicitud se obtienen de los conjuntos de puntos de datos emitidos de 0:n a 5:00, 5:n a 10:00, y así sucesivamente. La solicitud B especifica una resolución de 1 minuto, por tanto, los intervalos de agregación de cinco minutos se obtienen de los conjuntos de puntos de datos emitidos cada minuto de 0:n a 5:00, 1:n a 6:00, y así sucesivamente.
Para especificar una resolución que no sea la predeterminada y que difiera del intervalo, consulte Selección de una resolución no predeterminada para una consulta y Creación de una alarma.
- grupo de recursos
- Cadena personalizada proporcionada con una métrica personalizada que se puede utilizar como filtro o para agregar resultados. El grupo de recursos debe existir en la definición de la métrica publicada. Solo se puede aplicar un grupo de recursos por métrica.
- estadística
- La función de agregación aplicada al conjunto de puntos_datos sin procesar.
- suppression
- Configuración para evitar la publicación de los mensajes durante el rango temporal especificado. Es útil para suspender notificaciones de alarma durante el mantenimiento del sistema.
- rango temporal
- Límites (registros de hora) de los datos de métrica que desea. Por ejemplo, la última hora.
- regla de disparador
- Condición que se debe cumplir para poner la alarma en estado de activación. Una regla de disparador se puede basar en un umbral o en una ausencia de una métrica.
Disponibilidad
El servicio Monitoring está disponible en todas las regiones comerciales de la Oracle Cloud Infrastructure. Consulte Acerca de las regiones y los dominios de disponibilidad para obtener la lista de regiones disponibles, junto con las ubicaciones, identificadores de región, claves de región y dominios de disponibilidad asociados.
Servicios soportados
Los siguientes servicios tienen recursos o componentes que pueden emitir métricas a Monitoring:
- Analytics Cloud: consulte Supervisión de métricas
- API Gateway: consulte Métricas deAPI Gateway
- Application Performance Monitoring: consulte Métrica de Application Performance Monitoring
- Autonomous Recovery Service: consulte Métricas de Recovery Service
- Bastion: consulte Métricas de Bastion
- Big Data Service: consulte Gestión de métricas de cluster
- Block Volume: consulte Métricas de bloque de volumen
- Blockchain Platform: consulte Supervisión de métricas
-
Recursos informáticos: consulte Supervisión y métricas de recursos informáticos
-
Compute Cloud@Customer: consulte Métricas de Compute Cloud@Customer
- Connector Hub: consulte Métricas de Connector Hub
- Container Instances: consulte Métricas de instancia de contenedor
- Data Catalog: consulte Métricas de catálogo de datos
- Data Flow: consulte Métricas de flujo de datos
- Integración de datos: consulte Métricas de integración de datos
- Data Science: consulte Métricas
- Base de datos: consulte estas páginas:
- Supervisión del rendimiento mediante métricas de Autonomous Database (Autonomous Database sin servidor)
- Observabilidad de bases de datos con métricas de Autonomous Database (Autonomous Database en infraestructura de Exadata dedicada)
- Métricas para Oracle Exadata Database Service on Dedicated Infrastructure en el servicio Monitoring (de Guías de referencia para Exadata Cloud Infrastructure)
- Métricas para Base Database Service en el servicio Database Management: supervisión de una base de datos mediante métricas de Database Management
- Métricas para base de datos externa
- Database Management: consulte Métricas de Database Management para bases de datos Oracle
- Database Migration: consulte Métricas de migración de base de datos
- OCI Database with PostgreSQL: consulte Métricas de OCI Database with PostgreSQL
- DevOps: consulte Métricas de DevOps
- Digital Assistant: consulte Métricas de Digital Assistant
- DNS: consulte Métricas de DNS
- Email Delivery: consulte Métricas de Correo Electrónico Delivery
- Events: consulte Métricas de Eventos
- File Storage: consulte Métricas del sistema de ficheros
- Funciones: consulte Métricas de funciones
- Globally Distributed Autonomous Database: consulte la sección sobre supervisión del rendimiento mediante las métricas de Autonomous Database
- Base de datos de Exadata distribuida globalmente en infraestructura de Exascale (consulte Métricas de Oracle Exadata Database Service on Dedicated Infrastructure en Monitoring Service)
- GoldenGate: consulte Métricas de Oracle Cloud Infrastructure GoldenGate
- Comprobaciones del sistema: consulte Métricas de Comprobaciones del sistema
- Integration Generation 2: visualización de métricas de mensajes
- Integración 3: Visualización de métricas de Mensajes y Mensajes Facturables
- Java Management: consulte Métricas de Java Management
- Kubernetes Engine: consulte Métricas de Kubernetes Engine (OKE)
- Equilibrador de carga: consulte Métricas de Load Balancer
- Logging: consulte Métricas de Logging
- Log Analytics: consulte Supervisión de Log Analytics con métricas de servicio
- Media Streams (Media Services): consulte Métricas de Media Streams
- Management Agent: consulte Métricas de agente de gestión
- HeatWave: consulte Métricas
-
Networking: consulte Métricas de Networking
- NoSQL Database Cloud: consulte Métricas de servicio
- Notificaciones: consulte Métricas de notificaciones
- Firewall de red: consulte Supervisión de firewalls
- Object Storage: consulte Métricas de Object Storage
- Ops Insights: consulte Métricas de Ops Insights
- Oracle APEX Application Development: consulte Supervisión del rendimiento del servicio APEX
- OS Management Hub: consulte Métricas de OS Management Hub
- Automatización de procesos: consulte Supervisión de Oracle Cloud Infrastructure Process Automation
- Queue: consulte Métricas de Queue
- Service Mesh - consulte Métricas de malla de servicios
- Stack Monitoring: consulte Referencia de métricas
- Streaming: consulte Métricas de Streaming
- Vault: consulte Supervisión de Recursos de Vault
- Vulnerability Scanning: consulte Métricas de Exploración
- WAF: consulte Métricas de política de perímetro
Identificadores de recursos
La mayoría de los tipos de recursos de Oracle Cloud Infrastructure tienen un identificador único asignado por Oracle denominado ID de Oracle Cloud (OCID). Para obtener información sobre el formato de OCID y otras formas de identificar los recursos, consulte Identificadores de Recursos. Consulte Identificadores de Recursos.
Los recursos de métricas no tienen OCID .
Maneras de acceder a Monitoring
Puede acceder a Oracle Cloud Infrastructure (OCI) utilizando la consola (una interfaz basada en explorador), la API de REST o la CLI deOCI. En los temas de esta documentación, se incluyen instrucciones para utilizar la consola, la API y CLI. Para obtener una lista de los SDK disponibles, consulte Software development kits e interfaz de línea de comandos.
Consola: para acceder a Monitoring con la consola, debe usar un explorador soportado. Para ir a la página en la que se conecta la consola, abra el menú en la parte superior de esta página y seleccione Consola de Infraestructura. Se le solicitará que introduzca el inquilino en la nube, el nombre de usuario y la contraseña. Abra el menú de navegación y seleccione Observación y gestión. En Supervisión, seleccione Métricas de servicio.
API: para acceder a Monitoring a través de las API, utilice la API de supervisión para los parámetros y las alarmas, así como la API de notificaciones para los avisos (utilizadas con alarmas).
CLI: consulte Referencia de línea de comandos para Monitoring y Referencia de línea de comandos para Notifications.
Autenticación y autorización
Todos los servicios de Oracle Cloud Infrastructure se integran con IAM con fines de autenticación y autorización de todas las interfaces (la consola, el SDK o la CLI y la API de REST).
Un administrador de una organización tiene que configurar grupos, compartimentos y políticas que controlen qué usuarios pueden acceder a qué servicios, qué recursos y el tipo de acceso. Por ejemplo, las políticas controlan quién puede crear nuevos usuarios, crear y gestionar la red de la nube, crear instancias, crear cubos, descargar objetos, etc. Para obtener más información, consulte Gestión de dominios de identidad. Para obtener detalles específicos sobre la escritura de políticas de los distintos servicios, consulte Referencia de políticas.
Si es un usuario normal (no un administrador) que necesita utilizar los recursos de Oracle Cloud Infrastructure que posee la compañía, póngase al contacto con el administrador para que configure el identificador de usuario. El administrador puede confirmar qué compartimento o compartimentos puede utilizar.
Para obtener más información sobre la autorización de usuario para la supervisión, consulte Políticas de IAM.
Administradores: para políticas comunes que proporcionan a los grupos acceso a métricas, consulte Acceso a métricas para grupos. Para políticas de alarma comunes, consulte Acceso a alarmas para grupos. Para autorizar recursos, como instancias, y realizar llamadas de API, agregue los recursos a un grupo dinámico. Utilice las reglas de coincidencia de grupo dinámico para agregar los recursos y, a continuación, crear una política que permita el acceso del grupo dinámico a las métricas. Consulte Acceso a métricas para recursos.
Límites de Monitoring
Consulte Límites de Monitoring para ver una lista de límites aplicables e instrucciones para solicitar un aumento del límite.
Existen otros límites como, por ejemplo, los descritos a continuación.
Límites de almacenamiento
| Elemento | Intervalo de tiempo de almacenamiento |
|---|---|
| Definiciones de métricas | 90 días |
| Entradas del historial de alarmas | 90 días |
Límites de datos devueltos (métricas)
Cuando consulte métricas y vea gráficos de métricas, los datos devueltos están sujetos a determinados límites. Los límites para los datos devueltos incluyen 100.000 puntos de datos máximo e intervalos de tiempo máximos (determinados por la resolución, lo cual está relacionado con el intervalo). Consulte MetricData.
Límites de mensajes de alarma
El número máximo de mensajes por valoración de alarma depende del destino de la alarma. Los límites están asociados al servicio de Oracle Cloud Infrastructure que se utiliza para el destino.
Monitoring realiza un seguimiento de 200 000 flujos de métricas por alarma para eventos de cualificación. Para obtener más información sobre las evaluaciones de alarmas, consulte Evaluaciones de alarma en esta página.
| Destino de alarma | Entrega | Máximo de mensajes de alarma por evaluación |
|---|---|---|
| tema (Notificaciones) | Al menos una vez | 60 |
| flujo (Streaming) | Al menos una vez | 100.000 |
Por ejemplo, tenga en cuenta las siguientes evaluaciones de una alarma que divide las notificaciones entre 200 flujos de métricas, utilizando un tema como destino.
| Evaluación de alarma (tiempo) | Transición de flujo de métricas | Mensajes generados | Mensajes enviados | Mensajes borrados |
|---|---|---|---|---|
| 00:01:00 | 110 flujos de métricas pasan del estado OK a FIRING. | 110 | 60 | 50 |
| 00:02:00 | 90 flujos de métricas pasan del estado OK a FIRING. | 90 | 60 | 30 |
Cuando un tema o flujo se usa en exceso, puede generar notificaciones de alarma retrasadas. El uso excesivo se puede producir cuando varios recursos utilizan ese tema o flujo.
Mejores prácticas para trabajar cumpliendo los límites
Cuando tenga previsto un gran volumen de notificaciones de alarma, siga estas mejores prácticas para evitar exceder los límites de mensajes de alarma y los retrasos asociados.
- Reserve un único tema o flujo para utilizarlo con una alarma de gran volumen. No utilice un tema o flujo para varias alarmas de gran volumen.
- Si espera más de 60 mensajes por minuto, especifique Flujo como destino de alarma.
- Flujos:
- Cree particiones según la carga esperada. Consulte Límites sobre el flujo de recursos.
- Si los mensajes de alarma exceden el espacio del flujo, actualice la alarma para que utilice un flujo diferente que tenga más particiones. Por ejemplo, si el flujo original contiene cinco particiones, cree un flujo con diez particiones y, a continuación, actualice la alarma para utilizar el nuevo flujo.Nota
Para evitar que falten mensajes, siga consumiendo el flujo original hasta que no se reciban más mensajes.
- Aumente los límites para el arrendamiento:
- Temas: consulte Límites de la publicación de mensajes (operación PublishMessage).
- Flujos: consulte Límites de recursos de Streaming.
Solución de problemas relacionados con los límites
Para solucionar un error de consulta de demasiados flujos de métricas, consulte Error: se ha excedido el máximo de flujos de métricas.
Para obtener información sobre la solución de problemas, consulte Solución de problemas de Monitoring.
Seguridad
En este tema se describe la seguridad de Monitoring.
Para obtener información sobre cómo proteger Monitoring, incluida la información y la recomendación de seguridad, consulte Protección de Monitoring.