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 les mesures pour surveiller les ressources et les alarmes pour vous avertir lorsque ces mesures répondent aux déclencheurs spécifiés par l'alerte.
Les mesures sont émises vers le service Monitoring sous forme de points de données bruts , ou paires horodatage-valeur, avec des métadonnées et des dimensions . Les mesures proviennent de différentes 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 avec surveillance activées 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 à des mesures nouvelles ou existantes à l'aide de Connector Hub (avec Monitoring en tant que 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 à la section Création d'un connecteur avec une source Monitor.
Les données de mesure postées sur le service Monitoring sont uniquement visibles par vous ou utilisés 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 informations par dimension et spécifier une résolution . Les réponses d'API incluent le nom de la mesure, ainsi que son compartiment source et son espace de noms de mesure. 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 les messages d'alarme vers les destinations configurées, telles que des sujets dans Notifications et des flux de données dans Streaming.
Présentation de la fonctionnalité Mesures
La fonctionnalité Mesures permet de relayer la donnée de mesure concernant l'état, la capacité et les performances des ressources cloud.
Une mesure est liée à l'état, la capacité ou les performances d'une ressource donnée. Les ressources, les services et l'application é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 que vous engagez envers vos clients. Par exemple, vous pouvez surveiller l'utilisation de l'UC et les lectures de disque des instances de calcul. Vous pouvez ensuite utiliser ces données pour décider à quel moment provisionner d'autres instances afin de gérer l'augmentation de charge, de résoudre les problèmes liés à l'instance ou de mieux comprendre le comportement de votre 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 fourni par le logiciel de gestion et de surveillance des applications.
En tant que développeur, vous pouvez capturer ce KPI pour les applications à l'aide de mesures personnalisées. Enregistrez des observations chaque fois qu'une transaction d'application a lieu, 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 configuré de destination pour vous avertir lorsque des mesures correspondent aux déclencheurs spécifiés par l'alarme. L'illustration précédente représente le flux, en commençant par des ressources émettant des point 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 Présentation de Monitoring 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 recevez également une notification lorsqu'une alarme revient à l'état OK ou est réinitialisée.
Evaluations d'alarme
Monitoring évalue les alarmes une fois par minute pour identifier leur statut.
Lorsque l'alarme sépare les notifications, Monitoring évalue chaque flux d'informations de mesure suivi. Si l'évaluation de ce flux de données FIRING ou d'un autre événement qualifiant est indiquée, Monitoring envoie un message d'alarme.
Monitoring assure le suivi des flux de données des mesures par alarme pour les événements qualifiants mais les messages sont soumis aux limites de service de destination.
Illustration de l'évaluation des alarmes
Considérez 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 sur cet exemple d'alarme :
- Le centile est indiqué 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 est le 90e centile (
percentile(0.9)) d'une fenêtre d'une minute, spécifié dans la requête comme 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 des points 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 ne dépassant pas 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 règle de déclenchement n'est pas remplie pendant trois minutes consécutives. Cette configuration est le délai de déclenchement de l'alarme (
pendingDuration), défini commePT3M. - L'alarme met à jour son état sur OK lorsque la condition de violation a été claire pour la dernière minute.
L'image suivante présente un flux de données de mesure agrégé pour l'exemple d'alarme. Chaque point de données est indiqué par un carré.
Le tableau suivant présente les é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 | Évaluations des 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] | 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 |
*Une valeur de un (1) signifie que la condition de règle de déclencheur est remplie.
Mode de comptage des points de données
Cette section explique comment déterminer le nombre de points de données (ou de points de données) récupérés par une alarme. Ce numéro peut vous aider à estimer la tarification Monitoring.
Pour rechercher le nombre de points de données extraits par une alarme, obtenez d'abord le nombre de flux de requête et les minutes analysées.
- Le nombre de flux de données de requête dépend des flux de données de mesure renvoyés par la requête d'alarme.
- Les minutes analysées dépendent des attributs d'alarme
interval,resolutionetpendingDuration. Pour les requêtes d'alarme, la seule valeur valide pourresolutionest1m. Pour plus d'informations surinterval, reportez-vous à Intervalle. Pour plus d'informations surresolutionetpendingDuration, reportez-vous à API Monitoring.
Chaque alarme est évaluée une fois par minute, et donc chaque alarme est évaluée 1440 fois par jour. Chaque évaluation interroge les données dans la fenêtre de temps définie par interval et vérifie la période pendant laquelle l'alarme persiste définie par pendingDuration. Par conséquent, les minutes analysées à chaque minute sont calculées par l'expression suivante :
minutes analysées à chaque minute = interval * plafond(pendingDuration / resolution)
A propos de la période de réinitialisation interne
La période de réinitialisation interne détermine le moment où une alarme cesse de rechercher 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 ultérieures ignorent le flux de données 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. Par défaut, le message RESET arrive après 13 minutes (période de réinitialisation interne plus la période slack par défaut de 3 minutes). Vous pouvez personnaliser la période slack.
La durée de la période de réinitialisation interne est configurée globalement à 10 minutes, ce qui fait que l'historique des alarmes affiche une différence de 10 minutes.
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 d'absence (la valeur par défaut de 2 heures peut être personnalisée).
Points de données collectés pendant une période de réinitialisation interne
Chaque évaluation au cours de la période de réinitialisation interne de dix minutes prend en compte 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 période de réinitialisation interne unique pour le flux de données de mesure A, des fois t5 à t15. Au moment t16, le flux de données de mesure A n'est plus évalué.
Le diagramme suivant présente deux périodes de réinitialisation interne 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. Au moment 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 de déclenchement initial (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 | Département | Transition | Evénements | Notifications (reportez-vous à Types de message) |
|---|---|---|---|---|
| 12:0 | OK |
OK |
Toutes les émissions sont à l'intérieur du seuil. | FIRING_TO_OK |
| 1:30 | FIRING |
FIRING |
L'émission de resource1 dépasse le seuil. | OK_TO_FIRING |
| 1:35 | FIRING |
-- |
Aucune émission n'est détectée pour resource1. L'alarme démarre la période de réinitialisation interne pour resource1. | -- |
| 1:38 | FIRING |
-- |
Aucune émission n'est détectée pour resource2. L'alarme démarre la période de réinitialisation interne pour resource2. | -- |
| 1:45 | FIRING |
-- |
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 des ressources restantes (resource3 et resource4) sont inférieures au seuil. | RESET (envoyé après la période slack 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 du flux de données de mesure (vous pouvez personnaliser la valeur par défaut de deux heures). 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 données de mesure est évalué par une alarme d'absence qui utilise la période de détection des absences de deux heures par défaut et la période slack de trois minutes par défaut. La console affiche les états de transition de déclenchement initial (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 | Département | Transition | Evénements | Notifications (reportez-vous à Types de message) |
|---|---|---|---|---|
| 1:00 | OK |
-- | Des émissions sont détectées. | |
| 2:00 | FIRING |
FIRING |
Aucune émission n'est détectée pour la ressource-z. L'alarme démarre la période de détection d'absence pour la ressource-z. | OK_TO_FIRING |
| 4:0 | FIRING |
-- |
La période de détection des absences pour la ressource-z se termine. L'alarme démarre la période de réinitialisation interne de la ressource-z. | -- |
| 4:10 | OK |
OK |
La période de réinitialisation interne se termine pour la ressource-z, de sorte que l'alarme ne vérifie plus les émissions de la ressource-z. Plus aucun flux de données de mesure n'est surveillé par l'alarme, l'alarme passe donc à l'état OK. | RESET (envoyé après la période slack 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 pour les notifications de fractionnement, l'état de flux de données 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 à la rubrique 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 de répétition sont également envoyés s'ils sont configurés dans l'alarme.
Le tableau suivant répertorie l'état et la transition des alarmes pour chaque type de message.
| Type de message | Département | 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 la répétition des notifications. |
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 données de mesure absent : la ressource qui émettait la mesure peut avoir été 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 Exemple de messages d'alarme et Format de message d'alarme.
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 point de données bruts pour une mesure donnée. Par exemple, vous pouvez appliquer la statistique
maxet l'"intervalle1h(une heure) aux dernières 24 heures de point 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 écoulée entre chaque Point de données brut publié pour un mesure spécifique. (Les point de données brutes sont publiés par l'espace de noms des mesures vers le service Monitoring.) Alors que cette fréquence varie en fonction de l'indicateur, la fréquence des indicateurs de service par défaut varie généralement de 60 secondes (c'est-à-dire un point par minute). Reportez-vous également au concept résolution.
- Intervalle
- Fenêtre de temps utilisée pour convertir l'ensemble de points d'informations brut.
- Message
- Contenu publié par la fonctionnalité Alarmes du service Monitoring vers les sujets des destinations de notifications configurées de lalarme. 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
DiskBytesReadoci_computeagent. 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, à une capacité ou à des performances d'une ressource. Exemple :
CpuUtilization, mesureoci_computeagent, 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 des mesures pour une mesure donnée. Par exemple, oci_computeagent metric
DiskBytesReadest défini par desdimensions (comme l'identificateur de ressource) et desmétadonnées (indiquant les octets comme unité), ainsi que l'identification de son espace de noms (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 instances de calcul indique l'espace de nomsoci_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, zéro ou plus.
- 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 pour l'envoi des 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 des mesures) à é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 d'indicateur, l'intervalle que vous sélectionnez entraîne la résolution par défaut de la demande, qui détermine la période maximale de 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 aucune 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:n à 5:00, de 5:n à 10: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:n et 5:00, entre 1:n et 6:00, etc.
Pour indiquer une résolution qui diffère de l'intervalle par défaut, reportez-vous à la section Sélection d'une résolution différente par défaut pour une requête et à la section 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 spécifique de points d'informations bruts.
- suppression
- Configuration permettant d'arrêter la publication de 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 à Mesures de Monitoring
- 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 Récupération Service
- Bastion : reportez-vous à Mesures de bastion
- Big Data Service : reportez-vous à Gestion des mesures de cluster
- Block Volume : reportez-vous à Mesures de Blockchain Volume
- Blockchain Platform - reportez-vous à Surveillance des mesures
-
Compute - reportez-vous à Mesures de Compute et surveillance
-
Compute Cloud@Customer - reportez-vous à Mesures de Compute Cloud@Customer
- Connector Hub - reportez-vous à Mesures de Connector Hub
- Instances de conteneur : reportez-vous à Mesures de Container Instance.
- Data Catalog : reportez-vous à Mesures deData Catalog
- Data Flow : reportez-vous à Mesures deData Flow
- Data Integration : reportez-vous à Mesures de data Integration
- Data Science : reportez-vous à Mesures
- Base de données : reportez-vous aux pages suivantes :
- Surveillance des performances avec les mesures Autonomous Database (Autonomous Database sans serveur)
- Observabilité de la base de données avec les mesures Autonomous Database (Autonomous Database on Dedicated Exadata Infrastructure)
- Mesures pour Oracle Exadata Database Service on Dedicated Infrastructure dans le service Monitoring (à partir des guides de référence pour Exadata Cloud Infrastructure)
- Mesures pour Base Database Service dans le service Database Management : surveillance d'une base de données à l'aide de mesures Database Management
- Mesures pour la base de données externe
- Database Management : reportez-vous à Mesures de Database Management pour les base de données Oracle
- Database Migration : reportez-vous à Mesures de database Migration
- OCI Database with PostgreSQL - reportez-vous à Mesures d'OCI Database with 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 fichier
- Fonctions : reportez-vous à Mesures de fonctions
- Globally Distributed Autonomous Database - reportez-vous à Surveillance des performances avec les mesures Autonomous Database
- Base de données Exadata distribuée à l'échelle mondiale sur une infrastructure Exascale (reportez-vous à Mesures d'Oracle Exadata Database Service on Dedicated Infrastructure dans l'instance Monitoring)
- GoldenGate : reportez-vous à Mesures d'Oracle Cloud Infrastructure GoldenGate
- Health Checks : reportez-vous à Mesures de Health Checks
- Integration Generation 2 : Visualiser des mesures de message
- Integration 3 : Visualisation des mesure de messages et des message facturables
- Java Management : reportez-vous à Mesures de Java Management
- Moteur Kubernetes : reportez-vous à Mesures de Kubernetes Engine (OKE)
- Load Balancer : reportez-vous à Mesures deLoad Balancer
- Journalisation : reportez-vous àMesures de journalisation
- Log Analytics : reportez-vous à Surveillance de Log Analytics à l'aide des mesures de service
- Media Streams (Media Services) : reportez-vous à Media Streams Metrics
- Management Agent : reportez-vous à Mesures de Management Agent
- HeatWave : reportez-vous à Mesures.
-
Networking : reportez-vous à Mesures de Networking.
- NoSQL Database Cloud : reportez-vous à Mesures de service
- Notifications : reportez-vous à Mesures de Notification
- Pare-feu réseau - reportez-vous à Monitoring Firewalls
- Object Storage - reportez-vous à Mesures d'Object Storage
- Ops Insights - Voir Mesures d'Ops Insights
- Oracle APEX Application Development : reportez-vous à Surveillance des performances du service APEX
- OS Management Hub : reportez-vous à Mesures d'OS Management Hub
- Automatisation des processus - reportez-vous à Surveillance d'Oracle Cloud Infrastructure Process Automation
- File d'attente : reportez-vous à Mesures de Queue
- Service Mesh : reportez-vous à Mesures de service Mesh
- Stack Monitoring : reportez-vous à Référence de mesure
- Streaming : reportez-vous à Mesures de Streame
- Vault : reportez-vous à Surveillance des ressources Vault
- Vulnerability Scanning : reportez-vous à Mesures de Scannage
- WAF : reportez-vous à Mesures de stratégie en périphérie
Identificateurs de ressource
La plupart des types de ressource Oracle Cloud Infrastructure possèdent un identificateur unique affecté par Oracle appelé ID Oracle Cloud (OCID). Pour plus d'information sur le format OCID et d'autres façons d'identifier vos ressources, reportez-vous à Identificateurs des ressources. Reportez-vous à Identificateurs des ressources.
Les ressources de mesure n'ont pas d'OCID .
Méthodes d'accès à Monitoring
Pour accéder à Oracle Cloud Infrastructure (OCI), vous pouvez utiliser la console (interface basée sur un navigateur), l'API REST ou l'interface de ligne de commandeOCI. Les instructions d'utilisation de la console, de l'API et de la CLI sont incluses dans les rubriques du présent document. Pour obtenir la liste des kits SDK disponibles, reportez-vous à Kits de développement logiciel 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 des connexions à la console, ouvrez le menu de navigation en haut de cette page et sélectionnez Console Infrastructure. Vous êtes invité à saisir votre locataire cloud, votre nom utilisateur et votre mot de passe. Ouvrez le menu de navigation et sélectionnez Observation & gestion. Sous Surveillance, sélectionnez Mesures de service.
API : pour accéder à Monitoring via des API, utilisez l'API Monitoring pour les mesures et les alarmes, et l'API Notification 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 interface de ligne de commande et API REST).
Un administrateur d'une organisation doit configurer des groupes , des compartiments et desstratégies qui déterminent lesquels les utilisateurs peuvent accéder à quels services, quelles ressources et quel type d'accès. Par exemple, les stratégies indiquent qui peut créer les utilisateurs, créer et gérer le réseau cloud, créer les instances, créer les buckets, télécharger les objets, etc. Pour plus d'informations, reportez-vous à Gestion des domaines d'identité. 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 l'entreprise a besoin des ressources Oracle Cloud Infrastructure, contactez l'administrateur afin qu'il configure un ID utilisateur pour vous. L'administrateur peut confirmer les compartiments que vous pouvez utiliser.
Pour plus d'informations sur les autorisations utilisateurs liées à la surveillance, reportez-vous à Stratégies IAM.
Administrateurs : pour les stratégies courantes qui donnent aux groupes accès 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 alarme 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). Reportez-vous à MetricData.
Limites de message d'alarme
Le nombre maximal de messages par évaluation d'alarme dépend de la destination d'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 qualifiés. Pour plus d'informations sur les évaluations d'alarme, reportez-vous à la section 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 et recommandations de sécurité, reportez-vous à la section Sécurisation de Monitoring.