Panoramica del monitoraggio
Utilizza il servizio Oracle Cloud Infrastructure Monitoring per monitorare in modo attivo e passivo le risorse cloud utilizzando le funzioni Metriche e Allarmi. Scopri come funziona il monitoraggio.
Funzionamento del monitoraggio
Il servizio di monitoraggio utilizza le metriche per monitorare le risorse e gli allarmi per avvisare l'utente quando queste metriche soddisfano i trigger specificati dagli allarmi.
Le metriche vengono emesse al servizio di monitoraggio sotto forma di datapoint raw o di coppie data/ora-valore, insieme a dimensioni e metadati. Le metriche provengono da varie origini:
- Metriche delle risorse pubblicate automaticamente da Oracle Cloud Infrastructure risorse . Ad esempio, il servizio di computazione pubblica le metriche per le istanze di computazione abilitate al monitoraggio tramite lo spazio di nomi oci_computeagent. Una di queste metriche è
CpuUtilization
. Vedere Servizi supportati e Visualizzazione dei grafici delle metriche predefiniti. - Metriche personalizzate pubblicate utilizzando l'API di monitoraggio.
- Dati inviati a metriche nuove o esistenti utilizzando Connector Hub (con Monitoraggio come servizio di destinazione per un connettore).
È possibile trasferire le metriche dal servizio di monitoraggio utilizzando Connector Hub. Per ulteriori informazioni, vedere Creazione di un connettore con un'origine di controllo.
I dati delle metriche inviati al servizio di monitoraggio vengono presentati o utilizzati solo dalle funzioni di Oracle Cloud Infrastructure abilitate per l'uso dei dati delle metriche.
Quando si esegue una query su una metrica, il servizio di monitoraggio restituisce i dati aggregati in base ai parametri specificati. È possibile specificare un intervallo, ad esempio le ultime 24 ore, la statistica e l'intervallo. La console visualizza un grafico di monitoraggio per metrica per le risorse selezionate. I dati aggregati in ogni grafico riflettono la statistica e l'intervallo selezionati. Le richieste API possono facoltativamente filtrare in base alla dimensione e specificare una risoluzione . Le risposte API includono il nome della metrica e il relativo compartimento di origine e lo spazio di nomi metrica . È possibile inserire i dati aggregati in una libreria di visualizzazione o grafica.
I dati delle metriche e degli allarmi sono accessibili dalla console, dall'interfaccia CLI e dall'API. Per i periodi di conservazione, vedere Limiti di storage.
La funzione Allarmi del servizio di monitoraggio pubblica i messaggi di allarme nelle destinazioni configurate, ad esempio gli argomenti in Notifiche e i flussi in Streaming.
Panoramica della funzionalità Metriche
La funzione Metriche trasmette i dati delle metriche relativi allo stato, alla capacità e alle prestazioni delle risorse cloud.
Una metrica è una misurazione correlata allo stato, alla capacità o alle prestazioni di una risorsa . Risorse, servizi e applicazioni emettono metriche al servizio di monitoraggio. Le metriche comuni riflettono i dati correlati a:
- Disponibilità e latenza
- Tempo di attività e inattività dell'applicazione
- Transazioni complet.
- Operazioni non riuscite e riuscite
- Indicatori di performance chiave (KPI), quali i quantificatori di vendite e coinvolgimento
Eseguendo una query sul monitoraggio per questi dati, è possibile comprendere il funzionamento dei sistemi e dei processi per raggiungere i livelli di servizio che si impegnano per i clienti. Ad esempio, è possibile monitorare l'utilizzo della CPU e le letture su disco delle istanze di computazione . Puoi quindi utilizzare questi dati per decidere quando eseguire il provisioning di più istanze per gestire un aumento del carico, risolvere i problemi con l'istanza o comprendere meglio il comportamento del sistema.
Metrica di esempio: tasso di errore
Per lo stato dell'applicazione, uno dei KPI comuni è il tasso di errore, per il quale una definizione comune è il numero di transazioni non riuscite diviso per il totale delle transazioni. Questo KPI viene in genere fornito tramite il software di monitoraggio e gestione delle applicazioni.
Gli sviluppatori possono acquisire questo KPI dalle applicazioni utilizzando metriche personalizzate. Registra le osservazioni ogni volta che viene eseguita una transazione dell'applicazione e quindi contabilizza tali dati nel servizio di monitoraggio. In questo caso, impostare le metriche per acquisire le transazioni non riuscite, le transazioni riuscite e la latenza delle transazioni (tempo impiegato per ogni transazione completata).
Panoramica delle funzioni degli allarmi
Utilizza gli allarmi per monitorare lo stato, la capacità e le prestazioni delle risorse cloud.
La funzione Allarmi del servizio di monitoraggio funziona con il servizio di destinazione configurato per avvisare l'utente quando le metriche soddisfano i trigger specificati dall'allarme. Nella figura precedente viene illustrato il flusso, a partire dalle risorse che emettono i datapoint della metrica per il monitoraggio. Quando viene attivato, un allarme invia un messaggio di allarme alla destinazione configurata. Per le notifiche, i messaggi vengono inviati alle sottoscrizioni nell'argomento configurato. Per lo streaming, i messaggi vengono inviati al flusso configurato. (Questa figura non copre i dati delle metriche grezze e aggregate. Per questi dettagli, vedere l'illustrazione "Panoramica sul monitoraggio" nella parte superiore di questa pagina.
Quando sono configurate, le notifiche ripetute ricordano uno stato di attivazione continua all'intervallo di ripetizione configurato. Si riceve una notifica anche quando un allarme torna allo stato OK o quando viene reimpostato.
Valutazioni allarme
Il monitoraggio valuta gli allarmi una volta al minuto per trovare lo stato dell'allarme.
Quando l'allarme splende le notifiche, il monitoraggio valuta ogni flusso di metriche tracciato. Se la valutazione di tale flusso di metriche indica un nuovo stato FIRING
o un altro evento di qualifica, il monitoraggio invia un messaggio di allarme.
Il monitoraggio tiene traccia dei flussi di metriche per ogni allarme per gli eventi di qualifica, ma i messaggi sono soggetti ai limiti del servizio di destinazione.
Illustrazione della valutazione degli allarmi
Si consideri un allarme che misura il 90° percentile della metrica 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"
}
Note su questo allarme di esempio:
- Il percentile viene specificato nella query come statistica (grassetto):
CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
- Ogni datapoint è il 90° percentile (
percentile(0.9)
) di una finestra di un minuto, specificato nella query come intervallo (grassetto):CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
- I valori dei datapoint per questa statistica possono essere compresi tra valori nulli (assenti) e 100.
- Valutazioni dei datapoint:
- Per qualsiasi valore di datapoint maggiore di 85, la valutazione è vera (
1
). Una valutazione vera indica che la condizione della regola trigger è stata soddisfatta. - Per qualsiasi valore di datapoint non maggiore di 85, la valutazione è falsa (
0
).
- Per qualsiasi valore di datapoint maggiore di 85, la valutazione è vera (
- L'allarme non viene attivato finché la condizione regola di trigger non viene soddisfatta per tre minuti successivi. Questa configurazione indica il ritardo trigger dell'allarme (
pendingDuration
), impostato comePT3M
. - L'allarme aggiorna lo stato in OK quando la condizione di violazione è stata cancellata per l'ultimo minuto.
L'immagine seguente mostra un flusso di metriche aggregate per l'allarme di esempio. Ogni datapoint è indicato da un quadrato.
La tabella seguente mostra le valutazioni consecutive degli allarmi per l'allarme di esempio. L'allarme viene valutato su una finestra mobile di tre intervalli di un minuto.
Indicatore orario periodo valutazione | Minuti nel periodo | Valutazioni dei datapoint* | Stato |
---|---|---|---|
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 valore pari a un (1) indica che la condizione della regola di attivazione viene soddisfatta.
Modalità di conteggio dei datapoint
In questa sezione viene descritto come determinare il numero di datapoint (o datapoint) recuperati da un allarme. Questo numero consente di stimare i prezzi di monitoraggio.
Per trovare il numero di datapoint recuperati da un allarme, ottenere prima il numero di flussi di query e i minuti analizzati.
- Il numero di flussi di query dipende dai flussi di metriche restituiti dalla query di allarme.
- I minuti analizzati dipendono dagli attributi di allarme
interval
,resolution
ependingDuration
. Per le query di allarme, l'unico valore valido perresolution
è1m
. Per ulteriori informazioni suinterval
, vedere Intervallo. Per ulteriori informazioni suresolution
ependingDuration
, vedere API di monitoraggio.
Ogni allarme viene valutato una volta ogni minuto, e quindi ogni allarme viene valutato 1440 volte al giorno. Ogni valutazione esegue una query sui dati nella finestra temporale definita da interval
e controlla il periodo di tempo in cui l'allarme persiste definito da pendingDuration
. Pertanto, i minuti analizzati ogni minuto vengono calcolati dalla seguente espressione:
minuti analizzati ogni minuto = interval
* massimale (pendingDuration
/ resolution
)
Informazioni sul periodo di reimpostazione interno
Il periodo di reimpostazione interno determina quando un allarme smette di controllare la presenza di una metrica assente che ha attivato lo stato di attivazione nella valutazione precedente. Quando la metrica è assente per l'intero periodo, le valutazioni degli allarmi successive ignorano il flusso di metriche indicato. Se nessun altro flusso di metriche causa lo stato di attivazione dell'allarme, l'allarme passa a OK e invia un messaggio RESET. Per impostazione predefinita, il messaggio RESET arriva dopo 13 minuti (periodo di reimpostazione interna più il periodo slack predefinito di 3 minuti). È possibile personalizzare il periodo slack.
La durata del periodo di reimpostazione interno è configurata globalmente in 10 minuti, il che fa sì che la cronologia degli allarmi mostri una differenza di 10 minuti.
L'inizio di un periodo di ripristino interno dipende dal tipo di allarme. Per gli allarmi soglia, il periodo di reimpostazione interna inizia quando viene rilevata la prima assenza. Per gli allarmi di assenza, il periodo di reimpostazione interno inizia dopo il completamento del periodo di rilevamento dell'assenza (per impostazione predefinita, è possibile personalizzare).
Punti dati raccolti durante un periodo di reimpostazione interno
Ogni valutazione durante il periodo di ripristino interno di dieci minuti tiene conto di tutti i datapoint in quel periodo.
Ad esempio, si consideri un flusso di metriche (A
) che supera la soglia (linea rossa tratteggiata nei diagrammi seguenti). L'allarme si attiva (F
). Quando viene rilevata una mancanza di datapoint emessi, inizia un periodo di reimpostazione interno.
Il diagramma riportato di seguito mostra un singolo periodo di reimpostazione interno per il flusso di metriche A
, dalle volte t5
a t15
. All'ora t16
, il flusso di metriche A
non viene più valutato.
Il diagramma seguente mostra due periodi di reimpostazione interni per il flusso di metriche A
, dai tempi t3
a t5
, e da t6
a t16
. A
emette un datapoint in t6
, iniziando un altro periodo di reimpostazione interno. All'ora t17
, il flusso di metriche A
non viene più valutato.
Esempio di allarme soglia
Un allarme soglia indica i flussi di metriche che si verificano al di fuori della soglia. Quando un flusso di metriche precedentemente problematico è assente, l'allarme avvia il periodo di reimpostazione interno per il flusso di metriche.
In questo esempio, quattro flussi di metriche vengono valutati da un allarme soglia. La console mostra gli stati di transizione Firing (1:30) e Ok (1:51). Il periodo di reimpostazione interno si verifica quando l'allarme è in stato di attivazione.
Il periodo di reimpostazione interno e altri eventi significativi in questo esempio sono descritti nella tabella riportata di seguito.
Ora | Stato | Transizione | Eventi | Notifiche (vedere Tipi di messaggio) |
---|---|---|---|---|
12:0 | OK |
OK |
Tutte le emissioni sono entro la soglia. | FIRING_TO_OK |
1:30 | FIRING |
FIRING |
L'emissione da resource1 supera la soglia. | OK_TO_FIRING |
1:35 | FIRING |
-- |
Nessuna emissione rilevata per resource1. L'allarme avvia il periodo di ripristino interno per resource1. | -- |
1:38 | FIRING |
-- |
Nessuna emissione rilevata per resource2. L'allarme avvia il periodo di ripristino interno per resource2. | -- |
1:45 | FIRING |
-- |
Il periodo di ripristino interno termina per resource1, quindi l'allarme non controlla più le emissioni da resource1. Tuttavia, l'allarme è ancora in fase di attivazione perché resource2 è ancora nel proprio periodo di reimpostazione interno. | -- |
1:48 | OK |
OK |
Il periodo di ripristino interno termina per resource2, quindi l'allarme non controlla più le emissioni da resource2. Le emissioni delle risorse rimanenti (resource3 e resource4) rientrano nella soglia. | RESET (inviato dopo il periodo di slack di tre minuti, alle 1:51 circa) |
Esempio di allarme assenza
Un allarme di assenza indica i flussi di metriche assenti. Quando un flusso di metriche è assente, l'allarme avvia il periodo di rilevamento delle assenze per il flusso di metriche (per impostazione predefinita, è possibile personalizzare due ore). Al termine del periodo di rilevamento delle assenze, l'allarme avvia il periodo di reimpostazione interno per il flusso di metriche.
In questo esempio, un flusso di metriche viene valutato da un allarme di assenza che utilizza il periodo di rilevamento dell'assenza predefinito di due ore e il periodo slack predefinito di tre minuti. La console mostra gli stati di transizione iniziali Firing (2:00) e Ok (4:10). Il periodo di reimpostazione interno si verifica quando l'allarme è in stato di attivazione.
Il periodo di reimpostazione interno e altri eventi significativi in questo esempio sono descritti nella tabella riportata di seguito.
Ora | Stato | Transizione | Eventi | Notifiche (vedere Tipi di messaggio) |
---|---|---|---|---|
1:0 | OK |
-- | Sono state rilevate emissioni. | |
2:0 | FIRING |
FIRING |
Nessuna emissione rilevata per resource-z. L'allarme avvia il periodo di rilevamento delle assenze per resource-z. | OK_TO_FIRING |
4:0 | FIRING |
-- |
Il periodo di rilevamento delle assenze per la risorsa z termina. L'allarme avvia il periodo di reimpostazione interno per resource-z. | -- |
4:10 | OK |
OK |
Il periodo di reimpostazione interno termina per resource-z, quindi l'allarme non controlla più le emissioni da resource-z. Nessun flusso di metriche viene più monitorato dall'allarme, quindi l'allarme passa allo stato OK. | RESET (inviato dopo il periodo di slack di tre minuti, alle 4:13 circa) |
Tempo necessario per riflettere gli aggiornamenti dell'allarme
Gli aggiornamenti agli allarmi richiedono fino a cinque minuti per essere riflessi ovunque.
Ad esempio, se si aggiorna un allarme in dividi notifiche, potrebbero essere necessari fino a cinque minuti prima che lo stato del flusso di metriche venga popolato nella console.
Ricerca di allarmi
Cercare gli allarmi utilizzando gli attributi supportati.
Per ulteriori informazioni sulla ricerca, vedere Panoramica della ricerca. Per le descrizioni degli attributi, vedere Riferimento allarme.
-
id
-
displayName
-
compartmentId
-
metricCompartmentId
-
namespace
-
query
-
severity
-
destinations
-
suppression
-
isEnabled
-
lifecycleState
-
timeCreated
-
timeUpdated
-
tags
Il tipo di messaggio indica il motivo dell'invio del messaggio.
Il tipo di messaggio specificato viene inviato all'ora indicata più il ritardo di attivazione configurato dell'allarme, se presente.
I messaggi di ripetizione vengono inviati anche se configurati nell'allarme.
Nella tabella seguente sono elencati lo stato e la transizione dell'allarme per ciascun tipo di messaggio.
Tipo messaggio | Stato | Transizione | commenti |
---|---|---|---|
OK_TO_FIRING |
FIRING |
da OK a FIRING |
|
FIRING_TO_OK |
OK |
da FIRING a OK |
|
REPEAT |
FIRING |
-- | Questo tipo di messaggio viene inviato quando l'allarme mantiene lo stato FIRING e l'allarme viene configurato per le notifiche ripetute. |
RESET |
OK |
da FIRING a OK |
Importante: quando si verifica una modifica dello stato Questo tipo di messaggio viene inviato quando l'allarme passa allo stato Possibili cause di un flusso di metriche assente: la risorsa che stava emettendo la metrica potrebbe essere stata spostata o terminata oppure la metrica potrebbe essere emessa solo in caso di errore. Per ulteriori informazioni sul periodo di reimpostazione interno, vedere Informazioni sul periodo di reimpostazione interno. |
Formato ed esempi dei messaggi
Concetti sul monitoraggio
I seguenti concetti sono essenziali per l'utilizzo di Monitoring.
- dati aggregati
- Risultato dell'applicazione di una statistica e di un intervallo a una selezione di datapoint non elaborati per una metrica. Ad esempio, è possibile applicare statistica
max
e intervallo1h
(un'ora) alle ultime 24 ore di datapoint raw per la metricaCpuUtilization
. I dati aggregati vengono visualizzati nei grafici delle metriche predefiniti nella console. È inoltre possibile creare query di metriche per set specifici di dati aggregati. Per istruzioni, vedere Visualizzazione dei grafici delle metriche predefiniti e Creazione di query sulle metriche. - allarme
- La query di allarme da valutare e la destinazione della notifica da utilizzare quando l'allarme è in stato di attivazione, insieme ad altre proprietà dell'allarme.
- query di allarme
- Espressione MQL (Monitoring Query Language) da valutare per l'allarme. Una query di allarme deve specificare una metrica, una statistica, un intervallo e una regola di trigger (soglia o assenza). La funzione Allarmi del servizio di monitoraggio interpreta i risultati di ogni serie temporale restituita come valore booleano, dove zero rappresenta false e un valore diverso da zero rappresenta true. Un valore true indica che la condizione regola di trigger è stata soddisfatta.
- datapoint
- Una coppia indicatore orario-valore per la metrica specificata. Esempio:
2022-05-10T22:19:00Z, 10.4
- dimensione
- Qualificatore fornito in una definizione di metrica. Esempio: identificativo risorsa (
resourceId
), fornito nelle definizioni delle metriche oci_computeagent. Utilizzare le dimensioni per filtrare o raggruppare i dati delle metriche. Esempio di coppia nome-valore dimensione per filtrare in base al dominio di disponibilità:availabilityDomain = "VeBZ:PHX-AD-1"
- frequenza
- Il periodo di tempo tra ogni datapoint diretto registrato per una metrica. I datapoint raw vengono inviati dallo spazio di nomi metrica al servizio di monitoraggio. Mentre la frequenza varia in base alla metrica, le metriche di servizio predefinite in genere hanno una frequenza di 60 secondi (un datapoint pubblicato al minuto). Vedere anche risoluzione.
- intervallo
- Finestra temporale utilizzata per convertire il set di datapoint raw.
- messaggio
- Il contenuto che la funzione Allarmi del servizio di monitoraggio pubblica negli argomenti delle destinazioni di notifica configurate dell'allarme. Viene inviato un messaggio quando l'allarme passa a un altro stato, ad esempio da
OK
aFIRING
. - metadati
- Riferimento fornito in una definizione di metrica. Esempio: unità (byte), fornita nella definizione della metrica oci_computeagent metrica
DiskBytesRead
. Utilizzare i metadati per determinare informazioni aggiuntive su una metrica. Per le definizioni delle metriche, vedere Servizi supportati. - metrica
- Misurazione relativa all'integrità, alla capacità o alle prestazioni di una risorsa. Esempio: la
oci_computeagent
metricaCpuUtilization
, che misura l'uso di un'istanza di computazione. Per le definizioni delle metriche, vedere Servizi supportati. - definizione metrica
- Set di riferimenti, qualificatori e altre informazioni fornite da uno spazio di nomi delle metriche per una metrica. Ad esempio, oci_computeagent metrica
DiskBytesRead
è definito da dimensioni (ad esempio, identificativo risorsa) e metadati (specificando byte per unità) nonché dall'identificazione del relativo spazio di nomi metrica (oci_computeagent). Ogni set pubblicato di datapoint contiene queste informazioni. Utilizzare l'operazione API ListMetricData per ottenere le definizioni delle metriche. Per le definizioni delle metriche, vedere Servizi supportati. - spazio di nomi della metrica
- Indicatore della risorsa , servizio o applicazione che emette la metrica. Fornito nella definizione di metrica. Ad esempio, la definizione di metrica
CpuUtilization
emessa dal software Oracle Cloud Agent nelle istanze di computazione elenca lo spazio di nomi metricaoci_computeagent
come origine della metricaCpuUtilization
. Per le definizioni delle metriche, vedere Servizi supportati. - flusso di metriche
- Un singolo set di dati aggregati per valori di dimensione zero e zero o più.
- destinazione notifica
- Dettagli per l'invio di messaggi quando l'allarme passa a un altro stato, ad esempio da
OK
aFIRING
. I dettagli e l'impostazione possono variare in base al servizio di destinazione. I servizi di destinazione disponibili includono Notifiche e Streaming. - Software Oracle Cloud Agent
- Software utilizzato da un'istanza di computazione per inviare datapoint raw al servizio di monitoraggio. Installato automaticamente con le versioni più recenti delle immagini supportate. Vedere Abilitazione del monitoraggio per le istanze di computazione.
- query
- L'espressione MQL (Monitoring Query Language) e le informazioni associate, ad esempio lo spazio di nomi delle metriche, per valutare la restituzione di dati aggregati. La query deve specificare una metrica, una statistica e un intervallo.
- risoluzione
-
Il periodo tra le finestre temporali o la regolarità in cui le finestre temporali si spostano. Ad esempio, utilizzare una risoluzione di
1m
per recuperare le aggregazioni ogni minuto.Nota
Per le query sulle metriche, l'intervallo selezionato determina l'risoluzione predefinita della richiesta, che determina l'intervallo di tempo massimo di dati restituiti.Per le query di allarme, l'intervallo specificato non ha effetto sulla risoluzione della richiesta. L'unico valore valido della risoluzione per una richiesta di query di allarme è
1m
. Per ulteriori informazioni sul parametro di risoluzione utilizzato nelle query di allarme, vedere Allarme.Come illustrato nella figura seguente, risoluzione controlla l'ora di inizio di ciascuna finestra di aggregazione rispetto alla finestra precedente, mentre intervallo controlla la lunghezza delle finestre. Entrambe le richieste applicano la statistica
max
ai dati all'interno di ogni finestra di cinque minuti (dall'intervallo), risultando in un singolo datapoint aggregato che rappresenta il contatoreCPUutilization
più alto per quella finestra. Solo il valore di risoluzione è diverso. Questa risoluzione modifica la regolarità con cui le finestre di aggregazione si spostano o le ore di inizio delle finestre di aggregazione successive. La richiesta A non specifica una risoluzione e quindi utilizza il valore predefinito uguale all'intervallo (5 minuti). Le finestre di aggregazione di cinque minuti di questa richiesta vengono quindi prese dai set di datapoint emessi dalle 0:n alle 5:00, dalle 5:n alle 10:00 e così via. La richiesta B specifica una risoluzione di 1 minuto, quindi le relative finestre di aggregazione di cinque minuti vengono prese dal set di datapoint emessi ogni minuto dalle 0:n alle 5:00, dalle 1:n alle 6:00 e così via.Per specificare una risoluzione non predefinita diversa dall'intervallo, vedere Selezione di una risoluzione non predefinita per una query e Creazione di un allarme.
- gruppo di risorse
- Stringa personalizzata fornita con una metrica personalizzata che può essere utilizzata come filtro o per aggregare i risultati. Il gruppo di risorse deve esistere nella definizione della metrica contabilizzata. È possibile applicare un solo gruppo di risorse per metrica.
- statistico
- Funzione di aggregazione applicata al set di datapoint raw.
- soppressione
- Configurazione per interrompere la pubblicazione dei messaggi durante l'intervallo di tempo specificato. Utile per sospendere le notifiche di allarme durante la manutenzione del sistema.
- Intervallo di tempo
- I limiti (timestamp) dei dati delle metriche desiderati. Ad esempio, l'ultima ora.
- regola di trigger
- Condizione che deve essere soddisfatta perché uno stato allarme venga attivato. Una regola trigger può essere basata su una soglia o sull'assenza di una metrica.
Disponibilità
Il servizio di monitoraggio è disponibile in tutte le region commerciali di Oracle Cloud Infrastructure. Vedere Informazioni sulle aree e i domini di disponibilità per l'elenco delle aree disponibili, insieme alle posizioni associate, agli identificativi delle aree, alle chiavi delle aree e ai domini di disponibilità.
Servizi supportati
I servizi riportati di seguito dispongono di risorse o componenti che possono emettere metriche per il monitoraggio.
- Analytics Cloud - vedere Monitorare le metriche
- Gateway API - Visualizza Metriche gateway API
- Application Performance Monitoring - vedere Metriche di Application Performance Monitoring.
- Autonomous Recovery Service - Visualizza Metriche del servizio di recupero
- Bastion - vedere Metriche di base.
- Servizio Big Data: vedere Gestione delle metriche cluster.
- Volume a blocchi - vedere Metriche dei volumi a blocchi
- Piattaforma Blockchain - vedere Monitorare le metriche
-
Compute - vedere Metriche di computazione e monitoraggio
-
Compute Cloud@Customer - Visualizza le metriche di Compute Cloud@Customer
- Hub connettore: vedere Metriche hub connettore
- Istanze contenitore - vedere Metriche istanze contenitore
- Data Catalogo - vedere Metriche di Data Catalogo
- Flusso di dati - vedere Metriche di Data Flow
- Integrazione dei dati - vedere Metriche integrazione dati
- Data Science - vedere Metriche
- Database - vedere queste pagine:
- Monitorare le prestazioni con le metriche di Autonomous Database (Autonomous Database Serverless)
- Osservabilità del database con le metriche di Autonomous Database (Autonomous Database sull'infrastruttura Exadata dedicata)
- Metriche per Oracle Exadata Database Service on Dedicated Infrastructure nel servizio di monitoraggio (da Guide di riferimento per Exadata Cloud Infrastructure)
- Metriche per Base Database Service nel servizio Gestione database: Monitorare un database utilizzando le metriche di Gestione database
- Metriche per database esterno
- Gestione database - vedere Metriche di gestione del database per i database Oracle
- Migrazione del database - vedere Metriche di migrazione del database
- Database OCI con PostgreSQL - consulta Database OCI con metriche PostgreSQL
- DevOps - vedere DevOps Metrics
- Digital Assistant - vedere Metriche di Digital Assistant
- DNS - vedere Metriche DNS
- Consegna tramite e-mail - vedere Metriche di consegna tramite e-mail
- Eventi - vedere Metriche eventi
- Storage di file - vedere Metriche del file system
- Funzioni - vedere Metriche funzione
- Globally Distributed Autonomous Database - vedere Monitorare le prestazioni con le metriche di Autonomous Database
- Globally Distributed Exadata Database on Exascale Infrastructure (consulta le metriche di Oracle Exadata Database Service on Dedicated Infrastructure nel servizio di monitoraggio)
- GoldenGate - vedere Metriche di Oracle Cloud Infrastructure GoldenGate
- Controlli stato - vedere Metriche dei controlli dello stato
- Generazione 2 integrazione: Visualizza metriche messaggi
- Integrazione 3: Visualizza metriche messaggi e messaggi fatturabili
- Java Management - vedere Metriche di Java Management
- Kubernetes Engine - vedere Metriche OKE (Kubernetes Engine)
- Load balancer - vedere Metriche del load balance
- Log - vedere Metriche di log.
- Log Analytics - vedere Monitorare Log Analytics mediante le metriche dei servizi
- Media Streams (Media Services) - vedere Metriche Media Streams
- Management Agent - vedere Metriche Management Agent
- HeatWave - vedere Metriche
-
Networking - vedere Metriche di networking
- NoSQL Database Cloud - vedere Metriche dei servizi
- Notifiche - vedere Metriche delle notifiche
- Firewall di rete - vedere Monitoring Firewalls
- Storage degli oggetti - visualizza Metriche dello storage degli oggetti
- Ops Insights - vedere Metriche di Ops Insights
- Oracle APEX Application Development - vedere Monitorare le prestazioni del servizio APEX
- Hub di gestione del sistema operativo - vedere Metriche hub di gestione del sistema operativo
- Process Automation - vedere Monitorare Oracle Cloud Infrastructure Process Automation
- Coda - vedere Metriche coda.
- Mesh di servizio - vedere Metriche mesh di servizio
- Monitoraggio dello stack - vedere Riferimento alle metriche
- Streaming - vedere Metriche streaming
- Vault - vedere Monitoraggio delle risorse del vault
- Scansione delle vulnerabilità - vedere Scansione delle metriche
- WAF - vedere Metriche dei criteri di modifica
Identificativi risorsa
La maggior parte dei tipi di risorse Oracle Cloud Infrastructure ha un identificativo univoco assegnato da Oracle chiamato ID Oracle Cloud (OCID). Per informazioni sul formato OCID e su altri modi per identificare le risorse, vedere Identificativi delle risorse. Vedere Identificativi delle risorse.
Le risorse delle metriche non dispongono di OCID .
Modalità di accesso al monitoraggio
Puoi accedere a Oracle Cloud Infrastructure (OCI) utilizzando la console (un'interfaccia basata sul browser), l'API REST o l'interfaccia CLI OCI. Le istruzioni per l'uso della console, dell'API e dell'interfaccia CLI sono incluse negli argomenti di questa documentazione. Per esaminare un elenco di SDK disponibili, consulta Software Development Kits and Command Line Interface.
Console: per accedere al monitoraggio utilizzando la console, è necessario utilizzare un browser supportato. Per andare alla pagina di connessione della console, aprire il menu di navigazione nella parte superiore di questa pagina e selezionare Console infrastruttura. Viene richiesto di immettere il tenant cloud, il nome utente e la password. Aprire il menu di navigazione e selezionare Osservabilità e gestione. In Monitoraggio, selezionare Metriche servizio.
API: per accedere al monitoraggio tramite le API, utilizzare l'API di monitoraggio per le metriche e gli allarmi e l'API delle notifiche per le notifiche (utilizzate con gli allarmi).
CLI: Vedere Riferimento riga di comando per il monitoraggio e Riferimento riga di comando per le notifiche.
Autenticazione e autorizzazione
Ogni servizio in Oracle Cloud Infrastructure è integrato con IAM per l'autenticazione e l'autorizzazione di tutte le interfacce (console, SDK o CLI e API REST).
Un amministratore di un'organizzazione deve impostare gruppi , compartimenti e criteri che controllano gli utenti che possono accedere a quali servizi, quali risorse e il tipo di accesso. Ad esempio, i criteri controllano chi può creare nuovi utenti, creare e gestire la rete cloud, creare istanze, creare bucket, scaricare oggetti e così via. Per ulteriori informazioni, vedere Gestione dei domini di Identity. Per dettagli specifici sulla scrittura dei criteri relativi a ognuno dei vari servizi, consulta il riferimento per i criteri.
Se sei un utente normale (non un amministratore) che deve utilizzare le risorse di Oracle Cloud Infrastructure di proprietà dell'azienda, contatta un amministratore per impostare un ID utente. L'amministratore può confermare quale compartimento o compartimento è possibile utilizzare.
Per ulteriori informazioni sulle autorizzazioni utente per il monitoraggio, vedere Criteri IAM.
Amministratori: per i criteri comuni che consentono ai gruppi di accedere alle metriche, vedere Accesso alle metriche per i gruppi. Per i criteri di allarme comuni, vedere Accesso all'allarme per i gruppi. Per autorizzare le risorse, ad esempio le istanze, a effettuare chiamate API, aggiungere le risorse a un gruppo dinamico. Utilizzare le regole di corrispondenza del gruppo dinamico per aggiungere le risorse, quindi creare un criterio che consenta a tale gruppo dinamico di accedere alle metriche. Vedere Accesso alle metriche per le risorse.
Limiti al monitoraggio
Per visualizzare un elenco dei limiti applicabili e le istruzioni per richiedere un incremento del limite, consulta l'elenco dei limiti applicabili.
Di seguito sono riportati altri limiti.
Limiti memoria
Elemento | Intervallo di tempo memorizzato |
---|---|
Definizioni delle metriche | 90 giorni |
Voci cronologia allarmi | 90 giorni |
Limiti dati restituiti (metriche)
Quando si metriche di query e grafici delle metriche di visualizzazione, i dati restituiti sono soggetti a determinati limiti. Le informazioni sui limiti per i dati restituiti includono il massimo di 100.000 datapoint e il massimo dell'intervallo di tempo (determinato dalla risoluzione, che si riferisce all'intervallo). Vedere MetricData.
Limiti messaggi di allarme
Il numero massimo di messaggi per valutazione allarme dipende dalla destinazione dell'allarme. I limiti sono associati al servizio Oracle Cloud Infrastructure utilizzato per la destinazione.
Il monitoraggio tiene traccia di 200.000 flussi di metriche per allarme per gli eventi di qualifica. Per ulteriori informazioni sulle valutazioni degli allarmi, vedere Valutazioni degli allarmi in questa pagina.
Destinazione allarme | Delivery | Numero massimo di messaggi di allarme per valutazione |
---|---|---|
topic (Notifiche) | Almeno una | 60 |
stream (Streaming) | Almeno una | 100.000 |
Ad esempio, prendere in considerazione le seguenti valutazioni di un allarme che distribuisce le notifiche tra 200 flussi di metriche, utilizzando un argomento come destinazione.
Valutazione allarmi (tempo) | Transizione flusso metrico | Messaggi generati | Messaggi inviati | Messaggi eliminati |
---|---|---|---|---|
0:1:0 | I flussi di 110 metriche passano da OK a FIRING. | 110 | 60 | 50 |
0:2:0 | I flussi di 90 metriche passano da OK a FIRING. | 90 | 60 | 30 |
Quando un argomento o un flusso viene utilizzato in modo eccessivo, possono verificarsi notifiche di allarme ritardate. L'uso eccessivo può verificarsi quando più risorse utilizzano tale argomento o flusso.
Migliori pratiche per lavorare entro i limiti
Quando si prevede un elevato volume di notifiche di allarme, seguire queste procedure ottimali per evitare il superamento dei limiti dei messaggi di allarme e i ritardi associati.
- Riserva un singolo argomento o flusso per l'uso con un allarme ad alto volume. Non utilizzare un argomento o un flusso per più allarmi ad alto volume.
- Se si prevedono più di 60 messaggi al minuto, specificare Streaming come destinazione dell'allarme.
- Streams:
- Crea partizioni in base al carico previsto. Vedere Limiti sulle risorse di streaming.
- Se i messaggi di allarme superano lo spazio del flusso, aggiornare l'allarme per utilizzare un flusso diverso con più partizioni. Ad esempio, se il flusso originale contiene cinque partizioni, creare un flusso con dieci partizioni e quindi aggiornare l'allarme per utilizzare il nuovo flusso.Nota
Per evitare messaggi mancanti, continuare a utilizzare il flusso originale fino a quando non vengono ricevuti altri messaggi.
- Aumentare i limiti per la tenancy:
- Argomenti: vedere Limiti per la pubblicazione dei messaggi (operazione PublishMessage).
- Flussi: vedere Limiti sulle risorse di streaming.
Risoluzione dei problemi relativi ai limiti
Per risolvere un errore di query relativo a troppi flussi di metriche, vedere Errore: Superamento del numero massimo di flussi di metriche.
Per informazioni sulla risoluzione dei problemi, vedere Risoluzione dei problemi di monitoraggio.
Sicurezza
Questo argomento descrive la sicurezza per il monitoraggio.
Per informazioni su come proteggere il monitoraggio, incluse le informazioni sulla sicurezza e i suggerimenti, vedere Protezione del monitoraggio.