Visión general de Monitoring
Utilice el servicio Oracle Cloud Infrastructure Monitoring para supervisar de forma activa y pasiva los recursos en la nube mediante las funciones de métricas y alarmas. Descubra cómo funciona Monitoring.
Cómo funciona Monitoring
El servicio Monitoring utiliza métricas para supervisar recursos y alarmas a fin de notificarle en caso de que estas métricas alcancen los disparadores especificados por las alarmas.
Las métricas se emiten al servicio Monitoring en forma de puntos de datos no procesados o pares de marca de tiempo-valor junto con las dimensiones y los metadatos. Las métricas provienen de una variedad de fuentes:
- 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 la supervisión habilitada mediante el espacio de nombres 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 Hub de conector (con Supervisión como servicio de destino para un conector).
Puede transferir métricas del servicio Monitoring mediante Connector Hub. Para obtener más información, consulte Creación de un Conector con un Origen de Control.
Los datos de métricas publicados en el servicio Monitoring solo se le muestran a usted o son consumidos por funciones de Oracle Cloud Infrastructure que le permiten usar datos de métricas.
Cuando consulte 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 de cada gráfico reflejan la estadística y el intervalo seleccionados. Las solicitudes de API pueden filtrar por dimensión y especifican una resolución . Las respuestas de API incluyen el nombre de la métrica junto con su compartimento de origen y el espacio de nombre de métrica . Puede suministrar los datos agregados a una biblioteca de visualización o de gráficos.
Se puede acceder a los datos 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 Supervisión publica mensajes de alarma en destinos configurados, como temas de Notificaciones y flujos de Flujo.
Visión general de la función de métricas
La función Métricas transmite datos de métricas sobre el estado, la capacidad y el rendimiento de los recursos en la nube.
Una métrica es una medida relacionada con el estado, la capacidad o el rendimiento de un recurso. Los recursos, los servicios y las aplicaciones 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 estos datos en Monitoring, podrá averiguar cómo funcionan los sistemas y procesos para alcanzar los niveles de servicio que promete a los clientes. Por ejemplo, puede supervisar el uso de CPU y las lecturas de disco de las instancias informáticas. A continuación, puede utilizar estos datos para determinar cuándo aprovisionar más instancias para gestionar una mayor carga, solucionar problemas con la instancia o comprender mejor el comportamiento del 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 del software de gestión y supervisión de las aplicaciones.
Como desarrollador, puede capturar este KPI en sus aplicaciones mediante métricas personalizadas. Solo tiene que registrar lo observado cada vez que se produce una transacción de la aplicación y luego enviar dichos datos al 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 el rendimiento de los recursos en la nube.
La función de alarmas del servicio Monitoring funciona junto al servicio de destino configurado para notificarle cuando las métricas alcanzan los disparadores especificados para la alarma. En la ilustración anterior se muestra el flujo, empezando por los recursos que emiten puntos de datos de métricas a Supervisión. Cuando se dispara, una alarma envía un mensaje de alarma al destino configurado. En Notificaciones, los mensajes se envían a las suscripciones en el tema configurado. Para Flujo, los mensajes se envían al flujo configurado. (En esta ilustración no se incluyen los datos de métricas raw ni agregados. 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 le notificará cuando una alarma regrese al estado OK o cuando se restablezca una alarma.
Evaluaciones de alarma
Monitoring evalúa las alarmas una vez por minuto para determinar el estado de la alarma.
Cuando la alarma divide las notificaciones, Monitoring evalúa cada flujo de métricas con seguimiento. Si la evaluación de ese flujo de métricas indica un nuevo estado FIRING
u otro evento de cualificación, Monitoring envía un mensaje de alarma.
La supervisión realiza un seguimiento de los flujos de métricas por alarma para eventos de calificació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 esta alarma de ejemplo:
- El percentil se especifica en la consulta como estadística (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, especificado en la consulta como el 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 desde nulos (ausentes) hasta 100.
- Evaluaciones de puntos de datos:
- Para cualquier valor de punto de datos mayor que 85, la evaluación es verdadera (
1
). Una verdadera evaluación significa que se ha cumplido la condición de 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 activa hasta que se cumpla 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 estado clara durante el minuto más reciente.
En la siguiente imagen se muestra un flujo de métricas agregadas para la alarma de ejemplo. Cada punto de datos se indica mediante un cuadrado.
En la siguiente tabla, se muestran 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] | ACTIVADA |
7 | [5 6 7] | [1 1 1] | ACTIVADA |
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.
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 ha disparado el estado Firing en la evaluación anterior. Cuando la métrica está ausente durante 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 de activación de la alarma, la alarma pasa a OK (Correcto) y envía un mensaje RESET. El mensaje RESET llega después de 13 minutos (período de restablecimiento interno más el período de inactividad de 3 minutos).
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 comienza cuando se detecta la primera ausencia. Para las alarmas de ausencia, el período de restablecimiento interno comienza después de la finalización del período de detección de ausencias (2 horas).
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
, de las horas t5
a 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
, de las horas t3
a t5
y de 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 flujos de métricas que se producen fuera del umbral. Cuando un flujo de métricas anteriormente problemático está ausente, 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 inicial Firing (1:30) y Ok (1:51). 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 | Inicio | Inicio | La emisión de resource1 supera el umbral. | OK_TO_FIRING |
1:35 | Inicio | -- | No se detecta ninguna emisión para resource1. La alarma inicia el período de restablecimiento interno para resource1. | -- |
1:38 | Inicio | -- | No se detecta ninguna emisión para resource2. La alarma inicia el período de restablecimiento interno para resource2. | -- |
1:45 | Inicio | -- | 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 sigue encendiéndose porque resource2 aún está 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 inactividad de tres minutos, aproximadamente a la 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 de dos horas para el flujo de métricas. Una vez finalizado 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. La consola muestra los estados de transición inicial Firing (2:00) y Ok (4:10). 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 | Inicio | Inicio | 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 | Inicio | -- | Finaliza el período de detección de ausencias para el recurso-z. La alarma inicia el período de restablecimiento interno para el recurso-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 inactividad 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 en que se rellene el estado del 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 de repetición también se envían si se configuran en la alarma.
En la siguiente tabla, se muestra el estado de la 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 se configura para notificaciones repetidas. |
RESET |
OK |
de FIRING a OK |
Importante: Cuando se produzca un cambio en el estado Este tipo de mensaje se envía cuando la alarma pasa al estado Posibles causas de un flujo de métricas ausente: es posible que el recurso que emitió la métrica se haya movido o haya terminado, o que la métrica se haya emitido solo 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
Consulte Example Alarm Messages y Alarm Message Format.
Conceptos de Monitoring
Los siguientes conceptos son esenciales para trabajar con Monitoring.
- datos agregados
- El resultado de aplicar una estadística e intervalo a una selección de puntos de datos sin procesar para una métrica. Por ejemplo, puede aplicar la estadística
max
y el intervalo1h
(una hora) a las últimas 24 horas de puntos de 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
- La 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 de alarmas del servicio Monitoring interpreta los resultados para cada serie de tiempo devuelta como un valor booleano, donde cero representa falso y un valor distinto de cero 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
- Período entre cada punto de datos no procesado publicado para una métrica. (El espacio de nombres de la métrica publica los puntos de datos no procesados en el servicio Monitoring.) Aunque la frecuencia varía según la métrica, las métricas de servicio por defecto suelen tener una frecuencia de 60 segundos (es decir, un punto de datos publicado por minuto). Consulte también resolución.
- intervalo
- Ventana de tiempo utilizada para convertir el juego de puntos de datos sin procesar.
- mensaje
- Contenido que la función Alarmas del servicio Monitoring publica en temas en los destinos de notificación configurados para la alarma. Un mensaje se envía cuando la alarma pasa a otro estado, por ejemplo, de
OK
aFIRING
. - metadatos
- Referencia proporcionada en una definición de métrica. Ejemplo: unidad (bytes), proporcionada en la definición de la oci_computeagent métrica
DiskBytesRead
. 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 estado, la capacidad o el rendimiento de un recurso. Ejemplo:
oci_computeagent
métricaCpuUtilization
, 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, calificadores y otra información proporcionada por un espacio de nombres de métrica para una métrica. Por ejemplo, la métrica de oci_computeagent
DiskBytesRead
se define mediante dimensiones (como el identificador del recurso) y metadatos (especificando bytes para la unidad), así como mediante la identificación de su espacio de nombres de métrica (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
CpuUtilization
emitida por el software de Oracle Cloud Agent en instancias informáticas muestra el espacio de nombres de métricaoci_computeagent
como 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 de dimensión.
- destino de notificación
- Detalles para enviar mensajes cuando la alarma pasa a otro estado, como de
OK
aFIRING
. Los detalles y la configuración pueden variar según el servicio de destino. Los servicios de destino disponibles incluyen Notificaciones y Flujo. - Software del agente de Oracle Cloud
- Software utilizado por una instancia informática para publicar puntos de datos no procesados en el servicio de supervisión. 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 lenguaje Monitoring Query Language (MQL) e información asociada (como el espacio de nombres de métricas) que se evalúa para la obtención de 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
1m
para recuperar agregaciones cada minuto.Nota
Para consultas de métricas, el intervalo seleccionado controla la resolución por defecto de la solicitud, que determina el rango de tiempo máximo de 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 periodo de agregación en relación con el periodo anterior, mientras que el intervalo controla la duración de cada periodo. Ambas solicitudes aplican la estadística
max
a los datos de cada intervalo de cinco minutos (dentro del intervalo), lo que da como resultado un único punto de datos agregado que representa el contadorCPUutilization
más alto para el intervalo en cuestión. 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 no especifica una resolución y, por lo tanto, utiliza el valor por defecto igual al intervalo (5 minutos). Los periodos 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 no por defecto que difiera del intervalo, consulte Selecting a Nondefault Resolution for a Query y Creating an Alarm.
- 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
- Función de agregación aplicada al conjunto de puntos de datos sin procesar.
- suppression
- Configuración para evitar la publicación de 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 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 Acerca de las métricas de Oracle Analytics Cloud
- API Gateway: consulte Métricas de API Gateway
- Application Performance Monitoring: consulte Métricas de Application Performance Monitoring
- Autonomous Recovery Service: consulte Métricas de Recovery Service
- Bastion: consulte Métricas de Bastion
- Big Data Service: consulte Visualización de métricas de cluster
- Volumen en bloque: consulte Métricas de volumen en bloque
- Blockchain Platform: consulte Supervisión de métricas (Blockchain Platform)
-
Recursos informáticos: consulte estas páginas:
-
Compute Cloud@Customer: consulte Métricas de Compute Cloud@Customer
- Hub de conector: consulte Métricas de hub de conector
- Container Engine for Kubernetes: consulte Métricas de Container Engine for Kubernetes
- Instancias de contenedor: consulte Métricas de instancias de contenedor
- Data Catalog: consulte Métricas de Data Catalog
- Data Flow: consulte Métricas de Data Flow
- Data Integration: consulte Métricas de Data Integration
- Data Science - consulte Acerca de las métricas de sesión de Notebook
- Transferencia de datos: consulte estas páginas:
- Importación de datos basada en discos: Visualización de métricas basadas en discos de Data Transfer
- Importación de datos basada en dispositivo: Visualización de métricas basadas en importación de dispositivo de transferencia de datos
- Data Export: Visualización de métricas basadas en exportación del dispositivo de transferencia de datos
- Base de datos: consulte estas páginas:
- Supervisión del rendimiento mediante las métricas de Autonomous Database (Autonomous Database on Dedicated Exadata Infrastructure)
- Supervisión de bases de datos con métricas de Autonomous Database (Autonomous Database on Dedicated Exadata Infrastructure)
- Métricas para Oracle Exadata Database Service on Dedicated Infrastructure en el servicio de control (de Guías de referencia para Exadata Cloud Infrastructure)
- Métricas para el servicio de base de datos en el servicio de gestión de bases de datos: Supervisión de una base de datos mediante métricas de gestión de bases de datos
- Métricas para base de datos externa
- Database Management: consulte Métricas de Database Management
- Database Migration: consulte Métricas de Database Migration
- OCI Database con PostgreSQL: consulte OCI Database con PostgreSQL Métricas
- 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 Email Delivery
- Events: consulte Métricas de Events
- File Storage: consulte Métricas del sistema de archivos
- Funciones: consulte Métricas de funciones
- Autonomous Database distribuida globalmente: consulte Supervisión del rendimiento mediante las métricas de Autonomous Database
- GoldenGate: consulte Métricas de Oracle Cloud Infrastructure GoldenGate
- Health Checks: consulte Métricas de Health Checks
- Integración: consulte estas páginas:
- Integration Generation 2: Visualización de métricas de mensajes
- Integración 3: Ver métricas de mensajes y mensajes facturables
- Java Management: consulte Métricas de Java Management
- Load Balancer: consulte Métricas de Load Balancer
- Registro: consulte Métricas de registro
- Logging Analytics: consulte Supervisión de Logging Analytics con métricas de servicio
- Media Streams: consulte Media Streams Metrics
- Management Agent: consulte Métricas de Management Agent
- MySQL Heatwave: consulte Metrics
-
Redes: consulte estas páginas:
- NoSQL Database Cloud: consulte Métricas de servicio
- Notifications: consulte Métricas de Notifications
- Firewall de red: consulte Métricas de firewall de red.
- Object Storage: consulte Métricas de Object Storage
- Ops Insights: consulte Métricas de Operations Insights
- Oracle APEX Application Development: consulte Métricas (APEX)
- Gestión del sistema operativo: consulte Métricas de gestión del sistema operativo
- Process Automation: consulte Métricas de Process Automation
- Queue: consulte Métricas de Queue
- Service Mesh: consulte Métricas de Service Mesh
- Stack Monitoring: consulte Referencia de métricas de Stack Monitoring.
- Streaming: consulte Métricas de Streaming
- Almacén: consulte Supervisión de recursos de almacén.
- Vulnerability Scanning: consulte Métricas de Scanning
- 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 Oracle Cloud ID (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) mediante la consola (una interfaz basada en explorador), la API de REST o la CLI de OCI. En esta documentación se incluyen instrucciones para utilizar la consola, la API y la 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 de conexión de la Consola, abra el menú de navegación situado en la parte superior de esta página y haga clic en Consola de Infrastructure. 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 haga clic en Observación y gestión. En Supervisión, haga clic en Métricas de servicio.
API: para acceder a Monitoring a través de las API, use la API Monitoring para las métricas y las alarmas, y la API Notifications para las notificaciones (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
Cada servicio de Oracle Cloud Infrastructure se integra con IAM con fines de autenticación y autorización para todas las interfaces (la consola, el SDK o la CLI, y la API de REST).
Un administrador de la organización debe 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 usuarios, crear y gestionar la red en la nube, iniciar instancias, crear cubos, descargar objetos, etc. Para obtener más información, consulte Introducción a las políticas. 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 su compañía, póngase en contacto con el administrador para que configure su identificador de usuario. El administrador le confirmará qué compartimentos debe usar.
Para obtener más información sobre las autorizaciones de usuario para la supervisión, consulte la sección sobre Políticas de IAM (supervisión).
Administradores: Para políticas comunes que otorgan a grupos acceso a métricas, consulte Acceso a métricas para grupos. Para conocer las políticas de alarma comunes, consulte Alarm Access for Groups. 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 evaluación de alarma depende del destino de la alarma. Los límites están asociados al servicio de Oracle Cloud Infrastructure utilizado 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 (Notifications) | 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 del arrendamiento:
- Temas: consulte Límites para publicar 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 la supervisión, incluida la información de seguridad y las recomendaciones, consulte Protección de la supervisión.