Présentation de Monitoring
Utilisez le service Oracle Cloud Infrastructure Monitoring pour surveiller activement et passivement les ressources cloud à l'aide des fonctionnalités de mesures et d'alarmes. Découvrez le fonctionnement de Monitoring.
Fonctionnement de Monitoring
Le service Monitoring utilise des mesures pour surveiller les ressources et des alarmes pour vous avertir lorsque ces mesures répondent aux déclencheurs spécifiés par l'alarme.
Les mesures sont émises vers le service Monitoring sous forme de points de données bruts ou de paires horodatage-valeur, avec des dimensions et des métadonnées. Les mesures proviennent de diverses sources :
- Mesures de ressource automatiquement publiées par les ressources Oracle Cloud Infrastructure Par exemple, le service Compute publie des mesures pour les instances de calcul dont la surveillance est activée via l'espace de noms oci_computeagent. L'une de ces mesures est
CpuUtilization. Reportez-vous à Services pris en charge et à Affichage des graphiques de mesures par défaut. - Mesures personnalisées publiées à l'aide de l'API Monitoring.
- Données envoyées vers des mesures existantes ou nouvelles à l'aide de Connector Hub (avec Monitoring comme service cible pour un connecteur).
Vous pouvez transférer des mesures à partir du service Monitoring à l'aide de Connector Hub. Pour plus d'informations, reportez-vous à Création d'un connecteur avec une source de surveillance.
Les données de mesure publiées sur le service Monitoring sont visibles par vous uniquement ou utilisées par les fonctionnalités Oracle Cloud Infrastructure auxquelles vous permettez de les utiliser.
Lorsque vous interrogez une mesure, le service Monitoring renvoie les données agrégées en fonction des paramètres indiqués. Vous pouvez spécifier une plage (par exemple, les dernières 24 heures), une statistique et un intervalle . La console affiche un graphique de surveillance par mesure pour les ressources sélectionnées. Les données agrégées de chaque graphique reflètent la statistique et l'intervalle sélectionnés. Les demandes d'API peuvent éventuellement filtrer les données par dimension et spécifier une résolution . Les réponses d'API incluent le nom de la mesure, ainsi que le compartiment source et l'espace de noms de mesure associés. Vous pouvez intégrer les données agrégées dans une bibliothèque de visualisations ou de graphiques.
Les données de mesure et d'alarme sont accessibles à partir de la console, de l'interface de ligne de commande et de l'API. Pour connaître les périodes de conservation, reportez-vous à Limites de stockage.
La fonctionnalité Alarmes du service Monitoring publie des messages d'alarme vers des destinations configurées, telles que des rubriques dans Notifications et des flux dans Streaming.
Présentation de la fonctionnalité Mesures
La fonctionnalité Mesures relaie les données de mesure concernant l'état, la capacité et les performances des ressources cloud.
Une mesure est une mesure liée à l'état, à la capacité ou aux performances d'une ressource . Les ressources, les services et les applications émettent les mesures vers le service Monitoring. Les mesures courantes reflètent les données associées aux aspects suivants :
- Disponibilité et latence
- Temps d'activité et temps d'inactivité de l'application
- Transactions terminées
- Opérations ayant échoué et ayant réussi
- Indicateurs clés de performance (KPI), tels que les quantificateurs de vente et d'engagement
En interrogeant Monitoring sur ces données, vous pouvez comprendre à quel point les systèmes et les processus sont en mesure d'atteindre les niveaux de service auxquels vous vous engagez auprès de vos clients. Par exemple, vous pouvez surveiller l'utilisation de la CPU et les lectures sur disque des instances de calcul. Vous pouvez ensuite utiliser ces données pour déterminer quand provisionner davantage d'instances afin de gérer une charge accrue, résoudre les problèmes liés à l'instance ou mieux comprendre le comportement du système.
Exemple de mesure : Taux d'échec
Pour connaître l'état de l'application, l'un des KPI courants est le taux d'échec, qui se définit communément par le nombre de transactions en échec divisé par le nombre total de transactions. Ce KPI est généralement fourni par le logiciel de gestion et de surveillance de l'application.
En tant que développeur, vous pouvez capturer ce KPI pour vos applications à l'aide de mesures personnalisées. Enregistrez des observations à chaque transaction d'application, puis publiez ces données vers le service Monitoring. Dans ce cas, configurez des mesures pour capturer les transactions en échec, les transactions réussies et la latence des transactions (temps passé par transaction terminée).
Présentation de la fonctionnalité Alarmes
Utilisez des alarmes pour surveiller l'état, la capacité et les performances des ressources cloud.
La fonctionnalité Alarmes du service Monitoring fonctionne avec le service de destination configuré pour vous avertir lorsque les mesures répondent aux déclencheurs spécifiés par l'alarme. L'illustration précédente représente le flux, en commençant par les ressources émettant des points de données de mesure vers Monitoring. Lorsqu'elle est déclenchée, une alarme envoie un message d'alarme à la destination configurée. Pour Notifications, les messages sont envoyés aux abonnements dans le sujet configuré. Pour Streaming, les messages sont envoyés au flux configuré. (Cette illustration ne couvre pas les données de mesure brutes et agrégées. Pour plus d'informations, reportez-vous à l'illustration "Monitoring Overview" en haut de cette page.)
Lorsqu'elle est configurée, la répétition des notifications vous rappelle un état de déclenchement continu à l'intervalle défini. Vous êtes également averti lorsqu'une alarme revient à l'état OK ou est réinitialisée.
Evaluations d'alarme
Monitoring évalue les alarmes toutes les minutes pour déterminer leur statut.
Lorsque l'alarme sépare les notifications, Monitoring évalue chaque flux de données de mesure suivi. Si l'évaluation de ce flux de données de mesure indique un nouveau statut FIRING ou un autre événement qualifiant, Monitoring envoie un message d'alarme.
Monitoring suit les flux de données de mesure par alarme pour qualification d'événements, mais les messages sont soumis aux limites de service de destination.
Illustration de l'évaluation des alarmes
Envisagez une alarme qui mesure le 90e centile de la mesure 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"
}Remarques concernant cet exemple d'alarme :
- Le centile est spécifié dans la requête en tant que statistique (gras) :
CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85 - Chaque point de données correspond au 90e centile (
percentile(0.9)) d'une fenêtre d'une minute, indiquée dans la requête en tant qu'intervalle (en gras) :CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85 - Les valeurs de point de données de cette statistique peuvent être comprises entre NULL (absent) et 100.
- Evaluations de point de données :
- Pour toute valeur de point de données supérieure à 85, l'évaluation est vraie (
1). Une évaluation True signifie que la condition de la règle de déclencheur est remplie. - Pour toute valeur de point de données qui n'est pas supérieure à 85, l'évaluation est fausse (
0).
- Pour toute valeur de point de données supérieure à 85, l'évaluation est vraie (
- L'alarme ne se déclenche pas tant que la condition de la règle de déclencheur n'est pas remplie pendant trois minutes successives. Cette configuration correspond au délai de déclenchement (
pendingDuration) de l'alarme, défini surPT3M. - L'alarme met à jour son état sur OK lorsque la condition de violation est claire depuis la dernière minute.
L'image suivante présente un flux de mesure agrégé pour l'exemple d'alarme. Chaque point de données est indiqué par un carré.
Le tableau suivant présente des évaluations d'alarme consécutives pour l'exemple d'alarme. L'alarme est évaluée sur une fenêtre mobile de trois intervalles d'une minute.
| Horodatage de la période d'évaluation | Minutes de la période | Evaluations de points de données* | Statut |
|---|---|---|---|
| 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] | DÉCLENCHEMENT |
| 7 | [5 6 7] | [1 1 1] | DÉCLENCHEMENT |
| 8 | [6 7 8] | [1 1 0] | OK |
| 9 | [7 8 9] | [1 0 0] | OK |
| 10 | [8 9 10] | [0 0 0] | OK |
*Une valeur de un (1) signifie que la condition de la règle de déclencheur est remplie.
A propos de la période de réinitialisation interne
La période de réinitialisation interne détermine quand une alarme cesse de vérifier une mesure absente qui a déclenché l'état de déclenchement dans l'évaluation précédente. Lorsque la mesure est absente pendant toute la période, les évaluations d'alarme suivantes ignorent le flux de mesure indiqué. Si aucun autre flux de données de mesure ne provoque l'état de déclenchement de l'alarme, celle-ci passe à OK et envoie un message RESET. Le message RESET arrive après 13 minutes (période de réinitialisation interne plus la période de repos de 3 minutes).
La durée de la période de réinitialisation interne est configurée globalement à 10 minutes, ce qui entraîne l'affichage d'une différence de 10 minutes dans l'historique des alarmes.
Le début d'une période de réinitialisation interne dépend du type d'alarme. Pour les alarmes avec seuil, la période de réinitialisation interne commence lorsque la première absence est détectée. Pour les alarmes d'absence, la période de réinitialisation interne commence après la fin de la période de détection des absences (2 heures).
Points de données collectés au cours d'une période de réinitialisation interne
Chaque évaluation au cours de la période de réinitialisation interne de dix minutes tient compte de tous les points de données de cette période.
Par exemple, prenons un flux de données de mesure (A) qui dépasse le seuil (ligne rouge en pointillés dans les diagrammes suivants). L'alarme se déclenche (F). Lorsqu'un manque de points de données émis est détecté, une période de réinitialisation interne commence.
Le diagramme suivant présente une seule période de réinitialisation interne pour le flux de données de mesure A, de t5 à t15. A l'heure t16, le flux de données de mesure A n'est plus évalué.
Le diagramme suivant présente deux périodes de réinitialisation internes pour le flux de données de mesure A, de t3 à t5, et de t6 à t16. A émet un point de données à l'emplacement t6, en commençant une autre période de réinitialisation interne. A l'heure t17, le flux de données de mesure A n'est plus évalué.
Exemple d'alarme de seuil
Une alarme de seuil signale les flux de données de mesure qui se produisent en dehors du seuil. Lorsqu'un flux de données de mesure précédemment problématique est absent, l'alarme démarre la période de réinitialisation interne du flux de données de mesure.
Dans cet exemple, quatre flux de données de mesure sont évalués par une alarme de seuil. La console affiche les états de transition initiaux de déclenchement (1:30) et OK (1:51). La période de réinitialisation interne se produit lorsque l'alarme est à l'état de déclenchement.
La période de réinitialisation interne et les autres événements importants de cet exemple sont décrits dans le tableau suivant.
| Heure | Etat | Transition | Evénements | Notifications (reportez-vous à Types de message) |
|---|---|---|---|---|
| 12:0 | OK | OK | Toutes les émissions sont comprises dans le seuil. | FIRING_TO_OK |
| 1:30 | Déclenchement | Déclenchement | Les émissions de resource1 dépassent le seuil. | OK_TO_FIRING |
| 1:35 | Déclenchement | -- | Aucune émission n'est détectée pour resource1. L'alarme démarre la période de réinitialisation interne pour resource1. | -- |
| 1:38 | Déclenchement | -- | Aucune émission n'est détectée pour resource2. L'alarme démarre la période de réinitialisation interne pour resource2. | -- |
| 1:45 | Déclenchement | -- | La période de réinitialisation interne se termine pour resource1, de sorte que l'alarme ne vérifie plus les émissions de resource1. Cependant, l'alarme est toujours en cours de déclenchement car resource2 est toujours dans sa propre période de réinitialisation interne. | -- |
| 1:48 | OK | OK | La période de réinitialisation interne se termine pour resource2, de sorte que l'alarme ne vérifie plus les émissions de resource2. Les émissions provenant des ressources restantes (resource3 et resource4) sont comprises dans le seuil. | RESET (envoyé après la période de relâche de trois minutes, vers 1:51) |
Exemple d'alarme d'absence
Une alarme d'absence signale les flux de données de mesure absents. Lorsqu'un flux de données de mesure est absent, l'alarme démarre la période de détection d'absence de deux heures pour le flux de données de mesure. Une fois la période de détection d'absence terminée, l'alarme démarre la période de réinitialisation interne du flux de données de mesure.
Dans cet exemple, un flux de mesure est évalué par une alarme d'absence. La console affiche les états de transition initiaux de déclenchement (2:00) et OK (4:10). La période de réinitialisation interne se produit lorsque l'alarme est à l'état de déclenchement.
La période de réinitialisation interne et les autres événements importants de cet exemple sont décrits dans le tableau suivant.
| Heure | Etat | Transition | Evénements | Notifications (reportez-vous à Types de message) |
|---|---|---|---|---|
| 1:00 | OK | -- | Les émissions sont détectées. | |
| 2:00 | Déclenchement | Déclenchement | Aucune émission n'est détectée pour resource-z. L'alarme démarre la période de détection d'absence pour resource-z. | OK_TO_FIRING |
| 4:0 | Déclenchement | -- | La période de détection d'absence pour resource-z se termine. L'alarme démarre la période de réinitialisation interne pour resource-z. | -- |
| 4:10 | OK | OK | La période de réinitialisation interne se termine pour resource-z, de sorte que l'alarme ne vérifie plus les émissions de resource-z. Aucun flux de données de mesure n'est surveillé par l'alarme. L'alarme passe alors à l'état OK. | RESET (envoyé après la période de relâche de trois minutes, vers 4:13) |
Temps nécessaire au reflet des mises à jour d'alarme
Les mises à jour des alarmes prennent jusqu'à cinq minutes pour être reflétées partout.
Par exemple, si vous mettez à jour une alarme sur fractionner les notifications, le statut de flux de mesure peut prendre jusqu'à cinq minutes pour être renseigné dans la console.
Recherche d'alarmes
Recherchez des alarmes à l'aide des attributs pris en charge.
Pour plus d'informations sur Search, reportez-vous à Présentation de Search. Pour obtenir la description des attributs, reportez-vous à Référence des alarmes.
-
id -
displayName -
compartmentId -
metricCompartmentId -
namespace -
query -
severity -
destinations -
suppression -
isEnabled -
lifecycleState -
timeCreated -
timeUpdated -
tags
Le type de message indique le motif d'envoi du message.
Le type de message spécifié est envoyé à l'heure indiquée plus le délai de déclenchement configuré de l'alarme, le cas échéant.
Des messages répétés sont également envoyés s'ils sont configurés dans l'alarme.
Le tableau suivant répertorie l'état de l'alarme et la transition pour chaque type de message.
| Type de message | Etat | Transition | Commentaires |
|---|---|---|---|
OK_TO_FIRING |
FIRING |
de OK à FIRING |
|
FIRING_TO_OK |
OK |
de FIRING à OK |
|
REPEAT |
FIRING |
-- | Ce type de message est envoyé lorsque l'alarme conserve l'état FIRING et que l'alarme est configurée pour les notifications répétées. |
RESET |
OK |
de FIRING à OK |
Important : Lorsque le statut Ce type de message est envoyé lorsque l'alarme passe à l'état Causes possibles d'un flux de mesures absent : la ressource qui émettait la mesure a pu être déplacée ou interrompue, ou la mesure peut être émise uniquement en cas d'échec. Pour plus d'informations sur la période de réinitialisation interne, voir A propos de la période de réinitialisation interne. |
Format de message et exemples
Reportez-vous aux sections Example Alarm Messages et Alarm Message Format.
Concepts relatifs à Monitoring
Les concepts suivants sont essentiels pour une bonne utilisation du service Monitoring.
- Données agrégées
- Résultat de l'application d'une statistique et d'un intervalle à une sélection de points de données bruts pour une mesure. Par exemple, vous pouvez appliquer la statistique
maxet l'intervalle1h(une heure) aux dernières 24 heures de points de données bruts pour la mesureCpuUtilization. Les données agrégées sont affichées dans les graphiques de mesures par défaut de la console. Vous pouvez également créer des requêtes de mesure pour des ensembles spécifiques de données agrégées. Pour obtenir des instructions, reportez-vous à Affichage des graphiques de mesures par défaut et Construction de requêtes de mesure. - Alarme
- Requête d'alarme à évaluer et destination de notification à utiliser lorsque l'alarme est à l'état de déclenchement, ainsi que d'autres propriétés d'alarme.
- Requête d'alarme
- Expression MQL (Monitoring Query Language) à évaluer pour l'alarme. Une requête d'alarme doit indiquer une mesure, une statistique, un intervalle et une règle de déclencheur (seuil ou absence). La fonctionnalité Alarmes du service Monitoring interprète les résultats pour chaque série temporelle renvoyée sous forme de valeur booléenne, où zéro représente la valeur False et une valeur différente de zéro représente la valeur True. La valeur True signifie que la condition de la règle de déclencheur est remplie.
- Point de données
- Paire horodatage-valeur pour la mesure indiquée. Exemple :
2022-05-10T22:19:00Z, 10.4 - Dimension
- Qualificatif fourni dans une définition de mesure. Exemple : identificateur de ressource (
resourceId), indiqué dans les définitions des mesures oci_computeagent. Utilisez des dimensions pour filtrer ou regrouper les données de mesure. Exemple de paire nom-valeur de dimension pour le filtrage par domaine de disponibilité :availabilityDomain = "VeBZ:PHX-AD-1". - Fréquence
- Période entre chaque point de données brut publié pour une mesure. (Les points de données brutes sont publiés par l'espace de noms de mesure vers le service Monitoring.) Alors que la fréquence varie en fonction de la mesure, la fréquence des mesures de service par défaut est généralement de 60 secondes (autrement dit, un point de données publié par minute). Reportez-vous également au concept Résolution.
- Intervalle
- Fenêtre de temps utilisée pour convertir l'ensemble de points de données bruts.
- Message
- Contenu publié par la fonctionnalité Alarmes du service Monitoring vers les sujets des destinations de notification configurées de l'alarme. Un message est envoyé lorsque l'alarme passe à un autre état, par exemple de
OKàFIRING. - Métadonnées
- Référence fournie dans une définition de mesure. Exemple : unité (octets) indiquée dans la définition de la mesure oci_computeagent
DiskBytesRead. Utilisez des métadonnées pour déterminer des informations supplémentaires sur une mesure. Pour obtenir les définitions des mesures, reportez-vous à la section Services pris en charge. - Mesure
- Mesure liée à l'état, à la capacité ou aux performances d'une ressource. Exemple :
oci_computeagentmesureCpuUtilization, qui mesure l'utilisation d'une instance de calcul. Pour obtenir les définitions des mesures, reportez-vous à la section Services pris en charge. - Définition de mesure
- Ensemble de références, de qualificatifs et d'autres informations fournies par un espace de noms de mesure pour une mesure. Par exemple, la mesure oci_computeagent
DiskBytesReadest définie par des dimensions (comme l'identificateur de ressource) et des métadonnées (indiquant les octets comme unité), ainsi que par l'identification de son espace de noms de mesure (oci_computeagent). Chaque ensemble publié de points de données contient ces informations. Utilisez l'opération d'API ListMetricData pour obtenir les définitions de mesure. Pour obtenir la définition des mesures, reportez-vous à Services pris en charge. - Espace de noms de mesure
- Indicateur de la ressource , du service ou de l'application émettant la mesure. Fourni dans la définition de mesure. Par exemple, la définition de mesure
CpuUtilizationémise par le logiciel d'agent Oracle Cloud sur les instances de calcul indique l'espace de noms de mesureoci_computeagentcomme source de la mesureCpuUtilization. Pour obtenir les définitions des mesures, reportez-vous à la section Services pris en charge. - Flux de données de mesure
- Ensemble individuel de données agrégées pour une mesure et des valeurs de dimension, le cas échéant.
- L'image suivante présente des flux de données de mesure dans un graphique. Chaque ligne du graphique correspond à un flux de données de mesure.
- Destination de notification
- Détails d'envoi de messages lorsque l'alarme passe à un autre état, par exemple de
OKàFIRING. Les détails et la configuration peuvent varier en fonction du service de destination. Les services de destination disponibles incluent Notifications et Streaming. - Logiciel Oracle Cloud Agent
- Logiciel utilisé par une instance de calcul pour publier des points de données bruts vers le service Monitoring. Installé automatiquement avec les dernières versions des images prises en charge. Reportez-vous à Activation de la surveillance pour les instances Compute.
- query
- Expression MQL (Monitoring Query Language) et informations associées (telles que l'espace de noms de mesure) à évaluer pour renvoyer les données agrégées. La requête doit spécifier une mesure, une statistique et un intervalle.
- Résolution
-
Période entre les fenêtres de temps, ou régularité de décalage des fenêtres de temps. Par exemple, utilisez la résolution
1mpour extraire les agrégations toutes les minutes.Remarque
Pour les requêtes de mesure, l'intervalle que vous sélectionnez détermine la résolution par défaut de la demande, qui détermine la période maximale des données renvoyées.Pour les requêtes d'alarme, l'intervalle indiqué n'a aucun effet sur la résolution de la demande. La seule valeur valide de résolution pour une demande de requête d'alarme est
1m. Pour plus d'informations sur le paramètre de résolution utilisé dans les requêtes d'alarme, reportez-vous à Alarme.Comme le montre l'illustration suivante, la résolution contrôle l'heure de début de chaque fenêtre d'agrégation par rapport à la fenêtre précédente, tandis que l'intervalle contrôle la durée des fenêtres. Les deux demandes appliquent la statistique
maxaux données de chaque fenêtre de cinq minutes (à partir de l'intervalle), ce qui aboutit à un point de données agrégé unique représentant le compteurCPUutilizationle plus élevé pour cette fenêtre. Seule la valeur de résolution diffère. Cette résolution change la régularité de décalage des fenêtres d'agrégation ou l'heure de début des fenêtres d'agrégation successives. La demande A n'indique pas de résolution et utilise donc la valeur par défaut égale à l'intervalle (5 minutes). Les fenêtres d'agrégation de cinq minutes de cette demande s'appuient donc sur les ensembles de points de données émis de 0 h n à 5 h 00, de 5 h n à 10 h 00, etc. La demande B indique une résolution de 1 minute, de sorte que ses fenêtres d'agrégation de cinq minutes s'appuient sur l'ensemble de points de données émis toutes les minutes entre 0 h n et 5 h 00, entre 1 h n et 6 h 00, etc.
Pour spécifier une résolution autre que celle par défaut qui diffère de l'intervalle, reportez-vous à Sélection d'une résolution autre que celle par défaut pour une requête et à Création d'une alarme.
- Groupe de ressources
- Chaîne personnalisée fournie avec une mesure personnalisée pouvant être utilisée comme filtre ou pour l'agrégation des résultats. Le groupe de ressources doit exister dans la définition de la mesure publiée. Un seul groupe de ressources peut être appliqué par mesure.
- statistique
- Fonction d'agrégation appliquée à l'ensemble de points de données bruts.
- suppression
- Configuration permettant d'arrêter la publication des messages au cours de la période indiquée. Utile pour suspendre les notifications d'alarme pendant la maintenance système.
- Période
- Limites (horodatages) des données de mesure voulues. Par exemple, la dernière heure.
- règle de déclencheur
- Condition à remplir pour que l'alarme atteigne l'état de déclenchement. Une règle de déclencheur peut reposer sur un seuil ou sur l'absence d'une mesure.
Disponibilité
Le service Monitoring est disponible dans toutes les régions commerciales Oracle Cloud Infrastructure. Reportez-vous à A propos des régions et des domaines de disponibilité pour obtenir la liste des régions disponibles, ainsi que les emplacements associés, les identificateurs de région, les clés de région et les domaines de disponibilité.
Services pris en charge
Les services suivants possèdent des ressources ou des composants pouvant émettre des mesures vers Monitoring :
- Analytics Cloud : reportez-vous à A propos des mesures pour Oracle Analytics Cloud
- API Gateway : reportez-vous à Mesures d'API Gateway
- Application Performance Monitoring : reportez-vous à Mesures d'Application Performance Monitoring
- Autonomous Recovery Service : reportez-vous à Mesures de Recovery Service
- Bastion : reportez-vous à Mesures de Bastion
- Big Data Service : reportez-vous à Affichage des mesures de cluster
- Volume de blocs : reportez-vous à Mesures de volume de blocs
- Blockchain Platform : reportez-vous à Surveillance des mesures (Blockchain Platform)
-
Compute : reportez-vous aux pages suivantes :
-
Compute Cloud@Customer : reportez-vous à Mesures de Compute Cloud@Customer
- Connector Hub : reportez-vous à Mesures de Connector Hub
- Container Engine for Kubernetes : reportez-vous à Mesures de Container Engine for Kubernetes
- Container Instances : reportez-vous à Mesures de Container Instances.
- Data Catalog : reportez-vous à Mesures de Data Catalog
- Data Flow : reportez-vous à Mesures de Data Flow
- Data Integration : reportez-vous à Mesures de Data Integration
- Data Science : reportez-vous à A propos des mesures de session de bloc-notes
- Transfert de données : reportez-vous aux pages suivantes :
- Import de données basé sur le disque : Affichage des mesures basées sur le disque de transfert de données
- Import de données basé sur l'appliance : Affichage des mesures basées sur l'import d'appliance de transfert de données
- Export de données : Affichage des mesures basées sur l'export d'appliance de transfert de données
- Base de données : reportez-vous aux pages suivantes :
- Surveillance des performances avec les mesures Autonomous Database (Autonomous Database sans serveur)
- Surveillance des bases de données avec les mesures de base de données autonome (Autonomous Database on Dedicated Exadata Infrastructure)
- Mesures pour Oracle Exadata Database Service on Dedicated Infrastructure dans le service Monitoring (dans Guides de référence pour l'infrastructure Exadata Cloud)
- Mesures pour Base Database Service dans Database Management Service : Surveiller une base de données à l'aide des mesures Database Management
- Mesures pour la base de données externe
- Database Management : reportez-vous à Mesures de Database Management
- Database Migration : reportez-vous à Mesures de Database Migration
- Base de données OCI avec PostgreSQL : reportez-vous à Base de données OCI avec mesures PostgreSQL
- DevOps : reportez-vous à Mesures de DevOps
- Digital Assistant : reportez-vous à Mesures de Digital Assistant
- DNS : reportez-vous à Mesures de DNS
- Email Delivery : reportez-vous à Mesures d'Email Delivery
- Events : reportez-vous à Mesures d'Events
- File Storage : reportez-vous à Mesures de système de fichiers
- Functions : reportez-vous à Mesures de Functions
- Autonomous Database distribué à l'échelle mondiale : reportez-vous à Surveillance des performances avec les mesures d'Autonomous Database
- GoldenGate : reportez-vous à Mesures d'Oracle Cloud Infrastructure GoldenGate
- Health Checks : reportez-vous à Mesures de Health Checks
- Intégration - voir les pages suivantes :
- Integration Generation 2 : Visualisation des mesures de message
- Integration 3 : Visualiser les mesures de message et les messages facturables
- Java Management : reportez-vous à Mesures de Java Management
- Load Balancer : reportez-vous à Mesures de Load Balancer
- Logging : reportez-vous à Mesures de Logging
- Logging Analytics : reportez-vous à Surveillance de Logging Analytics à l'aide des mesures de service
- Media Streams : reportez-vous à Mesures de Media Streams
- Management Agent : reportez-vous à Mesures de Management Agent
- MySQL Heatwave : reportez-vous à Mesures
-
Fonctions de réseau : reportez-vous aux pages suivantes :
- NoSQL Database Cloud : reportez-vous à Mesures de service
- Notifications : reportez-vous à Mesures de Notifications.
- Network Firewall : reportez-vous à Mesures de Network Firewall
- Object Storage : reportez-vous à Mesures d'Object Storage
- Ops Insights : reportez-vous à Mesures d'Operations Insights
- Oracle APEX Application Development : reportez-vous à Mesures (APEX)
- OS Management : reportez-vous à Mesures d'OS Management
- OS Management Hub : reportez-vous à Mesures d'OS Management Hub
- Process Automation : reportez-vous à Mesures de Process Automation
- Queue : reportez-vous à Mesures de Queue
- Service Mesh : reportez-vous à Mesures de Service Mesh
- Stack Monitoring : reportez-vous à Référence de mesure dans Stack Monitoring
- Streaming : reportez-vous à Mesures de Streaming
- Vault : reportez-vous à Surveillance des ressources Vault
- Vulnerability Scanning : reportez-vous à Mesures de Scanning.
- WAF : reportez-vous à Mesures de stratégie en périphérie
Identificateurs de ressource
La plupart des types de ressource Oracle Cloud Infrastructure ont un identificateur unique affecté par Oracle appelé ID Oracle Cloud (OCID). Pour plus d'informations sur le format OCID et d'autres façons d'identifier vos ressources, reportez-vous à Identificateurs de ressource., reportez-vous à Identificateurs de ressource.
Les ressources de mesure n'ont pas d'OCID .
Méthodes d'accès à Monitoring
Vous pouvez accéder à Oracle Cloud Infrastructure (OCI) à l'aide de la console (interface basée sur un navigateur), d'une API REST ou d'une interface de ligne de commande OCI. Les instructions d'utilisation de la console, de l'API et de l'interface de ligne de commande sont incluses dans les rubriques de cette documentation. Pour obtenir la liste des kits SDK disponibles, reportez-vous à Kits SDK et interface de ligne de commande.
Console : pour accéder à Monitoring à l'aide de la console, vous devez utiliser un navigateur pris en charge. Pour accéder à la page de connexion à la console, ouvrez le menu de navigation en haut de cette page et cliquez sur Console Infrastructure. Vous êtes invité à saisir votre locataire cloud, votre nom utilisateur et votre mot de passe. Ouvrez le menu de navigation et cliquez sur Observation & gestion. Sous Surveillance, cliquez sur Mesures de service.
API : pour accéder à Monitoring via des API, utilisez l'API Monitoring pour les mesures et les alarmes, et l'API Notifications pour les notifications (utilisées avec des alarmes).
Interface de ligne de commande : reportez-vous à Référence de ligne de commande pour Monitoring et à Référence de ligne de commande pour Notifications.
Authentification et autorisation
Chaque service d'Oracle Cloud Infrastructure s'intègre à IAM à des fins d'authentification et d'autorisation pour toutes les interfaces (console, kit SDK ou CLI, et API REST).
Un administrateur de votre organisation doit configurer des groupes , des compartiments et des stratégies qui déterminent quels utilisateurs peuvent accéder à quels services et à quelles ressources, ainsi que le type d'accès. Par exemple, les stratégies déterminent qui peut créer des utilisateurs, créer et gérer le réseau cloud, lancer des instances, créer des buckets, télécharger des objets, etc. Pour plus d'informations, reportez-vous à Introduction aux stratégies. Afin d'obtenir des détails spécifiques sur l'élaboration de stratégies pour chacun des différents services, reportez-vous à Référence de stratégie.
Si vous êtes un utilisateur standard (et non un administrateur) et que vous avez besoin d'utiliser les ressources Oracle Cloud Infrastructure de votre entreprise, contactez l'administrateur afin qu'il configure un ID utilisateur pour vous. L'administrateur peut confirmer les compartiments que vous devez utiliser.
Pour plus d'informations sur les autorisations utilisateur liées à la surveillance, reportez-vous à Stratégies IAM.
Administrateurs : pour les stratégies courantes qui permettent aux groupes d'accéder aux mesures, reportez-vous à Accès aux mesures pour les groupes. Pour connaître les stratégies d'alarme courantes, reportez-vous à Accès aux alarmes pour les groupes. Pour autoriser des ressources, telles que les instances, à effectuer des appels d'API, ajoutez les ressources à un groupe dynamique. Utilisez les règles de mise en correspondance du groupe dynamique pour ajouter les ressources, puis créez une stratégie permettant à ce groupe dynamique d'accéder aux mesures. Reportez-vous à Accès aux mesures pour les ressources.
Limites relatives à Monitoring
Reportez-vous aux limites relatives à Monitoring pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.
Les autres limites sont les suivantes.
Limites de stockage
| Elément | Période de stockage |
|---|---|
| Définitions de mesure | 90 jours |
| Entrées d'historique d'alarme | 90 jours |
Limites sur les données renvoyées (mesures)
Lorsque vous interrogez des mesures et visualisez des graphiques de mesures, les données renvoyées sont soumises à certaines limites. Les informations sur les limites concernant les données renvoyées incluent la valeur maximale de 100 000 points de données et les valeurs maximales de plage (déterminées par la résolution, associée à l'intervalle). Voir MetricData.
Limites de message d'alarme
Le nombre maximal de messages par évaluation d'alarme dépend de la destination de l'alarme. Les limites sont associées au service Oracle Cloud Infrastructure utilisé pour la destination.
Monitoring effectue le suivi de 200 000 flux de données de mesure par alarme pour les événements qualifiants. Pour plus d'informations sur les évaluations d'alarme, reportez-vous à Evaluations d'alarme sur cette page.
| Destination de l'alarme | Distribution | Nombre maximal de messages d'alarme par évaluation |
|---|---|---|
| Sujet (Notifications) | Au moins une fois | 60 |
| Flux de données (Streaming) | Au moins une fois | 100 000 |
Par exemple, prenons les évaluations suivantes d'une alarme qui sépare les notifications sur 200 flux de données de mesure et utilise un sujet comme destination.
| Evaluation de l'alarme (durée) | Transition de flux de données de mesure | Messages générés | Messages envoyés | Messages supprimés |
|---|---|---|---|---|
| 00:01:00 | 110 flux de données de mesure passent de OK à FIRING. | 110 | 60 | 50 |
| 00:02:00 | 90 flux de données de mesure passent de OK à FIRING. | 90 | 60 | 30 |
L'utilisation excessive d'un sujet ou d'un flux de données peut entraîner un retard des notifications d'alarme. Une utilisation excessive peut survenir lorsque plusieurs ressources emploient ce sujet ou ce flux.
Meilleures pratiques pour une utilisation dans les limites
Lorsque vous attendez un grand nombre de notifications d'alarme, suivez ces meilleures pratiques pour éviter de dépasser les limites de message d'alarme et les retards associés.
- Réservez un seul sujet ou flux de données pour une alarme à volume élevé. N'utilisez pas un seul sujet ou flux de données pour plusieurs alarmes à volume élevé.
- Si vous attendez plus de 60 messages par minute, indiquez Streaming comme destination d'alarme.
- Flux de données :
- Créez des partitions en fonction de la charge attendue. Reportez-vous à Limites relatives aux ressources Streaming.
- Si le nombre de messages d'alarme dépasse l'espace de flux de données, mettez à jour l'alarme de sorte à utiliser un autre flux de données comportant davantage de partitions. Par exemple, si le flux de données d'origine contient cinq partitions, créez un flux de données avec dix partitions, puis mettez à jour l'alarme de sorte à utiliser le nouveau flux de données.Remarque
Pour éviter de manquer des messages, continuez à utiliser le flux de données d'origine jusqu'à ce qu'aucun autre message ne soit reçu.
- Augmentez les limites de la location :
- Sujets : reportez-vous à Limites de publication des messages (opération PublishMessage).
- Flux de données : reportez-vous à Limites relatives aux ressources Streaming.
Dépannage des limites
Pour corriger une erreur de requête relative à un nombre trop élevé de flux de données de mesure, reportez-vous à Erreur : nombre maximal de flux de données de mesure dépassé.
Pour obtenir des informations sur le dépannage, reportez-vous à Dépannage de Monitoring.
Sécurité
Cette rubrique décrit la sécurité de Monitoring.
Pour plus d'informations sur la sécurisation de Monitoring, y compris les informations de sécurité et les recommandations, reportez-vous à Sécurisation de Monitoring.