Aperçu du service de surveillance
Utilisez le service Oracle Cloud Infrastructure Monitoring pour surveiller les ressources en nuage, de manière active et passive, au moyen des fonctions de mesures et d'alarmes. Voyez comment le service de surveillance fonctionne.
Fonctionnement du service de surveillance
Le service de surveillance utilise des mesures pour surveiller les ressources et des alarmes pour vous aviser lorsque ces mesures déclenchent celles spécifiées par l'alarme.
Les mesures sont émises dans le service de surveillance en tant que points de données bruts, ou en tant que paires valeur-horodatage, avec les dimensions et les métadonnées. Les mesures proviennent de diverses sources :
- Mesures de ressources automatiquement reportées par les ressources Oracle Cloud Infrastructure. Par exemple, le service Calcul publie des mesures pour surveiller les instances de calcul activées pour la surveillance au moyen de l'espace de noms oci_computeagent. L'une de ces mesures est
CpuUtilization. Voir Services pris en charge et Affichage des graphiques de mesure par défaut. - Mètres personnalisés publiés à l'aide de l'API du service Surveillance.
- Données envoyées à des mesures nouvelles ou existantes à l'aide du Centre de connecteurs (avec le service Surveillance comme service cible pour un connecteur).
Vous pouvez transférer des mesures à partir du service Surveillance à l'aide du centre de connecteurs. Pour plus d'informations, voir Création d'un connecteur avec une source de surveillance.
Les données de mesure publiées dans le service Surveillance ne sont présentées qu'à vous ou sont consommées par les fonctions d'Oracle Cloud Infrastructure que vous activez pour les utiliser.
Lors de l'interrogation d'une mesure, le service Surveillance retourne des données agrégées en fonction des paramètres indiqués. Vous pouvez spécifier une période (comme 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 dans chaque graphique reflètent la statistique et l'intervalle sélectionnés. API requests can optionally filter by dimension and specify a resolution . Les réponses d'API incluent le nom de la mesure ainsi que son compartiment source et l'espace de noms de mesure. Vous pouvez introduire les données agrégées dans une visualisation ou dans une bibliothèque de graphiques.
Les données des mesures et des alarmes sont accessibles à partir de la console, de l'interface de ligne de commande et de l'API. Pour les périodes de conservation, voir Limites de stockage.
La fonction d'alarmes du service Surveillance publie des messages d'alarme dans les destinations configurées, telles que des sujets dans le service Avis et des flux dans le service Service de flux.
Aperçu de la fonction de mesures
La fonction de mesures transmet les données de mesure concernant l'état, la capacité et la performance des ressources en nuage.
Une mesure est une mesure de l'état, de la capacité ou de la performance d'une ressource. Les ressources, les services et les applications émettent des mesures dans le service Monitoring. Les mesures communes reflètent les données concernant les éléments suivants :
- Disponibilité et latence
- Temps d'activité et temps d'arrêt des applications
- Transactions terminées
- Opérations non réussies et réussies
- Indicateurs clés de rendement (ICR), tels que les quantificateurs de ventes et d'engagements
En interrogeant la surveillance pour ces données, vous pouvez comprendre si les systèmes et les processus fonctionnent bien pour atteindre les niveaux de service que vous engagez auprès de vos clients. Par exemple, vous pouvez surveiller l'utilisation de l'UC et les lectures du disque des instances de calcul. Vous pouvez ensuite utiliser ces données pour décider quand provisionner des instances supplémentaires pour 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 l'état de l'application, un des ICR communs est le taux d'échec, pour lequel une définition commune est le nombre de transactions en échec divisé par le nombre total de transactions. Cet ICR est généralement offert par les logiciels de surveillance et de gestion d'application.
En tant que développeur, vous pouvez saisir cet ICR pour des applications à l'aide de mesures personnalisées. Enregistrez les observations chaque fois qu'une transaction de demande a lieu, puis publiez ces données dans le service de surveillance. Dans ce cas, configurez des mesures pour saisir les transactions en échec, les transactions réussies et la latence des transactions (temps passé par transaction terminée).
Aperçu de la fonction d'alarmes
Utilisez des alarmes pour surveiller l'état, la capacité et la performance de vos ressources en nuage.
La fonction d'alarme du service Surveillance fonctionne avec le service de destination configuré pour vous aviser lorsque des mesures déclenchent les alarmes. L'illustration précédente représente le flux, en commençant par les ressources émettant des points de données de mesure dans le service Surveillance. When triggered, an alarm sends an alarm message to the configured destination. Pour le service Avis, les messages sont envoyés aux abonnements dans le sujet configuré. Pour le service de flux, 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 de détails, voir l'illustration "Aperçu du service de surveillance en haut de cette page).)
Lorsqu'ils sont configurés, les avis renvoyés vous rappellent l'état de déclenchement continu à l'intervalle de renvoi configuré. Vous êtes également avisé lorsqu'une alarme retourne à l'état OK ou lorsqu'elle est réinitialisée.
Évaluations d'alarme
Le service de surveillance évalue les alertes une fois par minute pour trouver leur statut.
Lorsque l'alarme fractionne les avis, le service de surveillance évalue chaque flux de mesure suivi. Si l'évaluation de ce flux de mesure indique un nouveau statut FIRING ou un nouvel événement admissible, le service Surveillance envoie un message d'alarme.
Le service Surveillance suit les flux de mesure par alarme pour les événements admissibles, mais les messages sont soumis aux limites du 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"
}Notes sur cet exemple d'alarme :
- Le centile est spécifié dans l'interrogation 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 l'interrogation comme intervalle (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 aller de null (absent) à 100.
- Évaluations des points de données :
- Pour toute valeur de point de données supérieure à 85, l'évaluation est vraie (
1). Une véritable évaluation signifie que la condition de la règle de déclenchement a été satisfaite. - 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 règle de déclenchement n'est pas satisfaite pendant trois minutes successives. Cette configuration correspond au délai de déclenchement de l'alarme (
pendingDuration), réglé àPT3M. - L'alarme met à jour son état à OK lorsque la condition de violation a été 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 dans 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éclenchement est remplie.
Comment les points de données sont comptés
Cette section décrit comment déterminer le nombre de points de données (ou datapoints) extraits par une alarme. Ce nombre peut vous aider à estimer les tarifs du service de surveillance.
Pour trouver le nombre de points de données extraits par une alarme, obtenez d'abord le nombre de flux d'interrogation et les minutes analysées.
- Le nombre de flux d'interrogation dépend des flux de mesure retournés par l'interrogation d'alarme.
- Les minutes analysées dépendent des attributs d'alarme
interval,resolutionetpendingDuration. Pour les interrogations d'alarme, la seule valeur valide pourresolutionest1m. Pour plus d'informations surinterval, voir Intervalle. Pour plus d'informations surresolutionetpendingDuration, voir API du service de surveillance.
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)
À propos de la période de réinitialisation interne
La période de réinitialisation interne détermine à quel moment 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 ultérieures ignorent le flux de mesure indiqué. Si aucun autre flux de mesure n'est à l'origine de 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 de marge par défaut de 3 minutes). Vous pouvez personnaliser la période de marge.
La durée de la période de réinitialisation interne est configurée globalement à 10 minutes, ce qui entraîne 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 de 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 l'achèvement de la période de détection d'absence (par défaut, 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 tient compte de tous les points de données de cette période.
Par exemple, considérons un flux 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 mesure A, des heures t5 à t15. Au moment t16, le flux de mesure A n'est plus évalué.
Le diagramme suivant présente deux périodes de réinitialisation internes pour le flux de mesure A, des heures t3 à t5 et de t6 à t16. A émet un point de données à t6, en démarrant une autre période de réinitialisation interne. Au moment t17, le flux de mesure A n'est plus évalué.
Exemple d'alarme de seuil
Une alarme de seuil signale les flux de mesure qui se produisent en dehors du seuil. Lorsqu'un flux de mesure précédemment problématique est absent, l'alarme démarre la période de réinitialisation interne du flux de mesure.
Dans cet exemple, quatre flux 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 d'autres événements significatifs dans cet exemple sont décrits dans le tableau suivant.
| Heure | État | Transition | Événements | Avis (voir Types de message) |
|---|---|---|---|---|
| 12:0 | OK |
OK |
Toutes les émissions sont à l'intérieur du seuil. | FIRING_TO_OK |
| 1:30 | FIRING |
FIRING |
Les émissions de resource1 dépassent 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. Toutefois, l'alarme est toujours déclenchée, 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 à l'intérieur du 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 mesure absents. Lorsqu'un flux de mesure est absent, l'alarme démarre la période de détection d'absence pour le flux de mesure (par défaut, deux heures peuvent être personnalisées). Une fois la période de détection des absences terminée, l'alarme démarre la période de réinitialisation interne pour le flux de mesure.
Dans cet exemple, un flux de mesure est évalué par une alarme d'absence qui utilise la période de détection d'absence de deux heures par défaut et la période d'absence 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 d'autres événements significatifs dans cet exemple sont décrits dans le tableau suivant.
| Heure | État | Transition | Événements | Avis (voir Types de message) |
|---|---|---|---|---|
| 1:00 | OK |
-- | Les é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 resource-z. | OK_TO_FIRING |
| 4:0 | FIRING |
-- |
La période de détection d'absence pour la ressource-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 mesure n'est plus surveillé par l'alarme, de sorte que l'alarme passe à l'état OK. | RESET (envoyé après la période de relâche de trois minutes, vers 4:13) |
Temps nécessaire à l'application des mises à jour des alarmes
L'application des mises à jour des alarmes peut prendre jusqu'à cinq minutes.
Par exemple, si vous mettez à jour une alarme pour fractionner les avis, l'affichage du état du flux de mesure dans la console peut prendre jusqu'à cinq minutes.
Recherche d'alarmes
Recherchez des alarmes à l'aide des attributs pris en charge.
Pour plus d'informations sur le service Recherche, voir Aperçu du service de recherche. Pour la description des attributs, voir Informations de référence sur les alarmes.
-
id -
displayName -
compartmentId -
metricCompartmentId -
namespace -
query -
severity -
destinations -
suppression -
isEnabled -
lifecycleState -
timeCreated -
timeUpdated -
tags
Le type de message indique le motif de l'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 de l'alarme pour chaque type de message.
| Type de message | État | 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 avis répétés. |
RESET |
OK |
de FIRING à OK |
Important : Lorsque le statut passe à Ce type de message est envoyé lorsque l'alarme passe à l'état Causes possibles d'un flux de mesure absent : La ressource qui émet la mesure a peut-être été déplacée ou interrompue, ou la mesure ne peut être émise qu'en cas d'échec. Pour plus d'informations sur la période de réinitialisation interne, voir À propos de la période de réinitialisation interne. |
Format de message et exemples
Concepts relatifs au service de surveillance
Les concepts suivants sont essentiels pour utiliser le service Surveillance.
- 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 24 dernières heures de points de données bruts pour la mesureCpuUtilization. Les données regroupées sont affichées dans les graphiques de mesure par défaut de la console. Vous pouvez également créer des interrogations de mesure pour des jeux spécifiques de données agrégées. Pour des instructions, voir Consultation des graphiques de mesure par défaut et Création d'interrogations de mesures. - alarme
- Interrogation d'alarme à évaluer et destination de l'avis à utiliser lorsque l'alarme est en état de déclenchement, avec d'autres propriétés d'alarme.
- INTERROGATION D'ALARME
- Expression MQL (Monitoring Query Language) à évaluer pour l'alarme. Une interrogation d'alarme doit spécifier une mesure, une statistique, un intervalle et une règle de déclenchement (seuil ou absence). La fonction d'alarme du service Surveillance interprète les résultats de chaque série chronologique retournée sous forme de valeur booléenne, où zéro représente Faux et une valeur différente de zéro représente Vrai. Une valeur Vrai signifie que la condition de règle de déclenchement a été satisfaite.
- POINT DE DONNÉES
- Paire horodatage-valeur pour la mesure spécifiée. Exemple :
2022-05-10T22:19:00Z, 10.4 - DIMENSION
- Qualificatif fourni dans une définition de mesure. Exemple : Identificateur de ressource (
resourceId), fourni dans les définitions de mesures oci_computeagent. Utilisez des dimensions pour filtrer ou regrouper les données de mesure. Exemple de paire nom-valeur de dimension pour filtrer 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 bruts sont publiés par l'espace de noms de mesure dans le service de surveillance.) Bien que la fréquence varie par mesure, les mesures de service par défaut ont généralement une fréquence de 60 secondes (un point de données publié par minute). Voir aussi résolution.
- INTERVALLE
- Période utilisée pour convertir le jeu de points de données bruts.
- message
- Contenu que la fonction d'alarmes du service Surveillance envoie aux sujets dans les destinations d'avis 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), fournie dans la définition de la mesure oci_computeagent
DiskBytesRead. Utilisez les métadonnées pour déterminer les informations supplémentaires relatives à une mesure. Pour la définition des mesures, voir Services pris en charge. - mesure
- Mesure de l'état, de la capacité ou de la performance d'une ressource. Exemple :
CpuUtilizationMesureoci_computeagent, qui mesure l'utilisation d'une instance de calcul. Pour la définition des mesures, voir Services pris en charge. - définition de mesure
- Jeu de références, de qualificatifs et d'autres informations fourni par un espace de noms de mesure pour une mesure. Par exemple, la mesure oci_computeagent
DiskBytesReadest définie par des dimensions (par exemple l'identificateur de la ressource) et des métadonnées (spécifiant les octets pour l'unité) ainsi que par l'identification de son espace de noms de mesure (oci_computeagent). Chaque jeu de points de données publié comporte ces informations. Utilisez l'opération d'API ListMetricData pour obtenir la définition des mesures. Pour la définition des mesures, voir 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 la mesure. Par exemple, la définition de mesure
CpuUtilizationémise par le logiciel Oracle Cloud Agent sur les instances de calcul liste l'espace de noms de mesureoci_computeagentcomme source de la mesureCpuUtilization. Pour la définition des mesures, voir Services pris en charge. - FLUX DE MESURE
- Jeu individuel de données agrégées pour une mesure et zéro ou plusieurs valeurs de dimension.
- L'image suivante présente les flux de mesure dans un graphique. Chaque ligne du graphique correspond à un flux de mesure.
- destination de l'avis
- Détails pour envoyer 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 sont notamment Avis et Diffusion en continu. - Logiciel Oracle Cloud Agent
- Logiciel utilisé par une instance de calcul pour publier des points de données bruts dans le service de surveillance. Il est installé automatiquement avec les dernières versions des images prises en charge. Voir Activation de la surveillance pour les instances de calcul.
- query
- Expression MQL (Monitoring Query Language) et informations associées (telles que l'espace de noms de mesure) à évaluer pour retourner des données agrégées. L'interrogation doit spécifier une mesure, une statistique et un intervalle.
- RÉSOLUTION
-
Période entre des fenêtres de temps ou régularité à laquelle les fenêtres de temps changent. Par exemple, utilisez une résolution de
1mpour extraire les agrégations toutes les minutes.Note
Pour les interrogations de mesure, l'intervalle sélectionné détermine la résolution par défaut de la demande, qui détermine l'intervalle de temps maximal des données retournées.Pour les interrogations d'alarme, l'intervalle indiqué n'a aucun effet sur la résolution de la demande. La seule valeur valide de la résolution d'une demande d'interrogation d'alarme est
1m. Pour plus d'informations sur le paramètre de résolution tel qu'utilisé dans les interrogations d'alarme, voir Alarme.Comme illustré ci-dessous, la résolution contrôle l'heure de début de chaque fenêtre d'agrégation relative à la fenêtre précédente alors que l'intervalle contrôle la longueur des fenêtres. Les deux demandes appliquent la statistique
maxaux données dans chaque fenêtre de 5 minutes (intervalle), ce qui entraîne un seul point de données agrégé représentant le compteurCPUutilizationle plus élevé pour cette fenêtre. Seule la valeur de la résolution diffère. Cette résolution modifie la régularité à laquelle les fenêtres d'agrégation changent ou les heures de début des fenêtres d'agrégation successives. La demande A ne spécifie pas de résolution et utilise donc la valeur par défaut égale à l'intervalle (5 minutes). Les fenêtres d'agrégation de 5 minutes de cette demande sont ainsi extraites des jeux de points de données émis entre 0:n et 5:00, 5:n et 10:00, etc. La demande B spécifie une résolution de 1 minute. Par conséquent, ses fenêtres d'agrégation de cinq minutes sont extraites du jeu de points de données émis toutes les minutes entre 0: n et 5:00, 1: n et 6:00, etc.
Pour spécifier une résolution non par défaut qui diffère de l'intervalle, voir Sélection d'une résolution non par défaut pour une interrogation et Création d'une alarme.
- GROUPES DE RESSOURCES
- Chaîne personnalisée fournie avec une mesure personnalisée pouvant être utilisée comme filtre ou pour agréger les 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 au jeu de points de données bruts.
- suppression
- Configuration permettant d'arrêter la publication de messages pendant l'intervalle de temps spécifié. Utile pour suspendre les avis d'alarme lors de la maintenance du système.
- Intervalle de temps
- Limites (horodatages) des données de mesure qui vous intéressent. Par exemple, la dernière heure.
- règle de déclenchement
- Condition à respecter pour que l'alarme soit en état de déclenchement. Une règle de déclenchement peut être basée sur un seuil ou une absence de mesure.
Disponibilité
Le service Surveillance est disponible dans toutes les régions commerciales d'Oracle Cloud Infrastructure. Voir À propos des régions et des domaines de disponibilité pour obtenir la liste des régions disponibles, ainsi que les emplacements, identificateurs de région, clés de région et domaines de disponibilité associés.
Services pris en charge
Les services suivants ont des ressources ou des composants pouvant émettre des mesures dans le service Surveillance :
- Analytics Cloud - voir Surveiller les mesures
- Passerelle d'API - Voir Mesures liées à la passerelle d'API
- Surveillance de la performance des applications - Voir Mesures de surveillance de la performance des applications
- Service de récupération autonome - Voir Mesures du service de récupération
- Hôte bastion - Voir Mesures du service d'hôte bastion
- Service de mégadonnées - voir Gestion des mesures de grappe
- Volume par blocs - Voir Mesures des volumes par blocs
- Blockchain Platform - voir Surveiller les mesures
-
Service de calcul - voir Mesures de calcul et surveillance
-
Compute Cloud@Customer - Voir Mesures de Compute Cloud@Customer
- Centre de connecteurs - Voir Mesures du centre de connecteurs
- Instances de conteneur - Voir Mesures liées aux instances de conteneur
- Catalogue de données - Voir mesures liées au catalogue de données
- Flux de données - Voir mesures liées au service de flux de données
- Intégration de données - Voir mesures liées au service d'intégration de données
- Service de science des données - voir Mesures
- Base de données - voir ces pages :
- Surveiller la performance avec des mesures Autonomous Database (Autonomous Database sans serveur)
- Observabilité de la base de données avec les mesures d'Autonomous Database (Autonomous Database sur une infrastructure Exadata dédiée)
- Metrics for Oracle Exadata Database Service on Dedicated Infrastructure in the Monitoring Service (from Reference Guides for Exadata Cloud Infrastructure)
- Mesures pour le service de base de données de base dans le service de gestion de bases de données : Surveiller une base de données à l'aide des mesures du service de gestion de bases de données
- Mesures pour une base de données externe
- Service de gestion de bases de données - Voir Mesures du service de gestion de bases de données pour les bases de données Oracle
- Migration de bases de données - Voir Mesures du service de migration de bases de données
- Base de données OCI avec PostgreSQL - Voir Base de données OCI avec mesures PostgreSQL
- DevOps - Voir Mesures DevOps
- Digital Assistant - Voir Mesures liées à Digital Assistant
- DNS - Voir Mesures DNS
- Transmission de messages - Voir Mesures de transmission de messages
- Événements - Voir Mesures liées aux événements
- Stockage de fichiers - Voir Mesures de système de fichiers
- Fonctions - Voir Mesures des fonctions
- Autonomous Database réparti dans le monde - Voir Surveiller la performance avec des mesures Autonomous Database
- Base de données Exadata répartie dans le monde sur une infrastructure exaflopique (voir Mesures pour Oracle Exadata Database Service on Dedicated Infrastructure dans le service de surveillance)
- GoldenGate - Voir Mesures du service GoldenGate pour Oracle Cloud Infrastructure
- Vérifications d'état - Voir Mesures liées aux vérifications d'état
- Integration Génération 2 : Voir les mesures liées aux messages
- Intégration 3 : Voir les mesures de message et les messages facturables
- Gestion Java - Voir Mesures de gestion Java
- Kubernetes Engine - Voir Mesures liées à Kubernetes Engine (OKE)
- Équilibreur de charge - Voir Mesures de l'équilibreur de charge
- Journalisation - Voir Mesures du service de journalisation
- Logging Analytics - Voir Surveiller Logging Analytics à l'aide de mesures de service
- Service de flux de médias en continu (Services de médias) - voir Mesures liées au service de flux de médias en continu
- Agent de gestion - Voir Mesures de l'agent de gestion
- HeatWave - Voir Mesures
-
Service de réseau - Voir Mesures du service de réseau
- NoSQL Database Cloud - Voir Mesures de service
- Avis - Voir Mesures du service d'avis
- Pare-feu de réseau - Voir Surveillance des pare-feu
- Stockage d'objets - - Voir Mesures du service de stockage d'objets
- Service de données clés sur l'exploitation - Voir Mesures du service de données clés sur l'exploitation
- Oracle APEX Application Development - Voir Surveiller la performance du service APEX
- Centre de gestion du système d'exploitation - voir Mesures du centre de gestion du système d'exploitation
- Automatisation des processus - voir Surveiller Oracle Cloud Infrastructure Process Automation
- File d'attente - Voir Mesures de file d'attente
- Maillage de services - Voir Mesures de maillage de services
- Surveillance de pile - Voir Informations de référence sur les mesures
- Diffusion en continu - Voir Mesures du service de diffusion en continu
- Chambre forte - Voir Surveillance des ressources du service de chambre forte
- Balayage de vulnérabilités - Voir mesures de balayage
- WAF - Voir Mesures des politiques de périphérie de réseau
Identificateurs de ressource
La plupart des types de ressource Oracle Cloud Infrastructure ont un identificateur unique affecté par Oracle, appelé identificateur Oracle Cloud (OCID). Pour plus d'informations sur le format des OCID et sur les autres moyens d'identifier vos ressources, voir Identificateurs de ressource, voir Identificateurs de ressource.
Les ressources de mesure n'ont pas d'OCID .
Méthodes d'accès au service Surveillance
Vous pouvez accéder à Oracle Cloud Infrastructure (OCI) à l'aide de la console (une interface basée sur le navigateur), de l'API REST ou de l'interface de ligne de commande OCI. Les instructions relatives à la console, à l'API et à l'interface de ligne de commande sont incluses dans les rubriques de cette documentation. Pour la liste des trousses SDK disponibles, voir Trousses SDK et interface de ligne de commande.
Console : Pour accéder au service Surveillance à l'aide de la console, vous devez utiliser un numéro de navigateur pris en charge. Pour accéder à la page de connexion de la console, ouvrez le menu de navigation en haut de cette page et sélectionnez Console Infrastructure. Vous êtes invité à entrer votre location Oracle Cloud, votre nom d'utilisateur et votre mot de passe. Ouvrez le menu de navigation et sélectionnez Observabilité et gestion. Sous Surveillance, sélectionnez Mesures de service.
API : Pour accéder au service Surveillance au moyen des API, utilisez l'API du service de surveillance pour les mesures et les alarmes et l'API du service d'avis pour les avis (utilisé avec les alarmes).
Interface de ligne de commande : Voir Informations de référence sur la ligne de commande pour le service de surveillance et Informations de référence sur la ligne de commande pour le service d'avis.
Authentification et autorisation
Chaque service d'Oracle Cloud Infrastructure est intégré avec le service de gestion des identités et des accès GIA aux fins d'authentification et d'autorisation, pour toutes les interfaces (console, trousse SDK ou interface de ligne de commande et API REST).
Un administrateur d'une organisation doit configurer les groupes , les compartiments et les politiques qui déterminent les utilisateurs pouvant accéder aux services et aux ressources, ainsi que le type d'accès. Par exemple, les politiques contrôlent qui peut créer des utilisateurs, créer et gérer le réseau en nuage, créer des instances, créer des seaux, télécharger des objets, etc. Pour plus d'informations, voir Gestion des domaines d'identité. Pour des détails précis sur l'écriture de politiques pour les différents services, voir Informations de référence sur les politiques.
Si vous êtes un utilisateur régulier (pas un administrateur) qui doit utiliser les ressources Oracle Cloud Infrastructure de la société, demandez à un administrateur de configurer un ID utilisateur pour vous. L'administrateur vous indiquera les compartiments que vous pouvez utiliser.
Pour plus d'informations sur les autorisations d'utilisateur pour la surveillance, voir Politiques IAM.
Administrateurs : Pour les politiques communes qui permettent aux groupes d'accéder aux mesures, voir Accès aux mesures pour les groupes. Pour les politiques communes sur les alarmes, voir Accès aux alarmes pour les groupes. Pour autoriser des ressources, par exemple des instances, à effectuer des appels d'API, ajoutez les ressources à un groupe dynamique. Utilisez les règles de correspondance du groupe dynamique pour ajouter les ressources, puis créez une politique qui permet à ce groupe dynamique d'accéder aux mesures. Voir Accès aux mesures pour les ressources.
Limites du service de surveillance
Voir Limites du service de surveillance pour la liste des limites applicables et les instructions pour demander une augmentation des limites.
Les autres limites sont les suivantes.
Limites de stockage
| Élément | Intervalle de temps de stockage |
|---|---|
| Définition des mesures | 90 jours |
| Entrées de l'historique des alarmes | 90 jours |
Limites des données retournées (mesures)
Lorsque vous interrogez des mesures et consultez des graphiques de mesure, les données retournées sont soumises à certaines limites. Les informations sur les limites pour les données retournées comprennent la valeur maximale de 100 000 points de données et les intervalles de temps maximum (déterminés par la résolution, qui se rapporte à l'intervalle). Consultez la page MetricData.
Limites de messages 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.
Le service Surveillance assure le suivi de 200 000 flux de mesure par alarme pour les événements admissibles. Pour plus d'informations sur les évaluations d'alarme, voir Évaluations d'alarme dans cette page.
| Destination de l'alarme | Transmission | Nombre maximal de messages d'alarme par évaluation |
|---|---|---|
| Sujet (Avis) | Au moins une fois | 60 |
| Flux (Diffusion en continu) | Au moins une fois | 100,000 |
Prenons l'exemple des évaluations suivantes pour une alarme qui fractionne les avis en 200 flux de mesure, en utilisant un sujet comme destination.
| Évaluation de l'alarme (temps) | Changement d'état des flux de mesure | Messages générés | Messages envoyés | Messages abandonnés |
|---|---|---|---|---|
| 00:01:00 | 110 flux de mesure passent de OK à FIRING. | 110 | 60 | 50 |
| 00:02:00 | 90 flux de mesure passent de OK à FIRING. | 90 | 60 | 30 |
Lorsqu'un sujet ou un flux est surutilisé, les avis d'alarme peuvent être retardés. Une surutilisation peut survenir lorsque plusieurs ressources utilisent ce sujet ou ce flux.
Meilleures pratiques pour rester dans les limites
Lorsque vous prévoyez un volume élevé d'avis d'alarme, suivez ces meilleures pratiques pour éviter de dépasser les limites de messages d'alarme et de générer les retards associés.
- Réservez un sujet ou un flux unique pour l'utiliser avec une alarme à volume élevé. N'utilisez pas un sujet ou un flux pour plusieurs alarmes à volume élevé.
- Si vous prévoyez plus de 60 messages par minute, spécifiez Diffusion en continu en tant que destination de l'alarme.
- Flux :
- Créez des partitions en fonction de la charge prévue. Voir Limites pour les ressources de diffusion en continu.
- Si les messages d'alarme dépassent l'espace de flux, mettez à jour l'alarme afin qu'elle utilise un autre flux comportant plus de partitions. Par exemple, si le flux initial contient cinq partitions, créez un flux avec dix partitions, puis mettez à jour l'alarme pour qu'elle utilise le nouveau flux.Note
Pour éviter les messages manquants, continuez à consommer le flux initial jusqu'à ce qu'il n'y ait plus de messages reçus.
- Augmenter les limites pour la location :
- Sujets : Voir Limites de publication des messages (opération PublishMessage).
- Flux : Voir Limites pour les ressources de diffusion en continu.
Dépannage des limites
Pour dépanner une erreur d'interrogation liée à un trop grand nombre de flux de mesure, voir Erreur : Nombre maximal de flux de mesure dépassé.
Pour des informations de dépannage, voir Dépannage du service de surveillance.
Sécurité
Cette rubrique décrit la sécurité relative au service Surveillance.
Pour plus d'informations sur la sécurisation du service Surveillance, notamment les informations et les recommandations de sécurité, voir Sécurisation du service de surveillance.