Surveillance de l'état

Surveillance

Indépendamment des contrôles d'intégrité intégrés, un administrateur peut consulter les données de surveillance à tout moment pour vérifier l'état global du système ou l'état d'un composant ou d'un service particulier. Pour ce faire, utilisez l'interface Grafana en interrogeant les données de mesure à l'échelle du système stockées dans Prometheus.

Grafana propose une approche visuelle de la surveillance : elle permet de créer des tableaux de bord composés de plusieurs panneaux de visualisation. Chaque panneau correspond à une requête de mesure unique ou à une combinaison de requêtes de mesure, affichée dans le format sélectionné. Les options disponibles sont les graphiques, les tableaux, les graphiques, les diagrammes, les jauges, etc. Pour chaque panneau de mesures, des seuils peuvent être définis. Lorsque le résultat de la requête dépasse ou descend en dessous d'un seuil donné, la couleur d'affichage change, fournissant une indication rapide des éléments en bon état, nécessitant des recherches ou présentant un dysfonctionnement.

Un ensemble de tableaux de bord prédéfinis permet aux administrateurs de commencer à surveiller le système dès qu'il est opérationnel. Les tableaux de bord de surveillance par défaut sont regroupés dans les catégories suivantes :

Les tableaux de bord par défaut contiennent des données de mesure pour les composants physiques du système (serveurs, commutateurs, fournisseurs de stockage, systèmes d'exploitation et microprogrammes), ainsi que pour ses composants logiques (logiciels de contrôleur, plate-forme, cluster et microservices Kubernetes, instances de calcul et ressources virtualisées). Cela permet à l'administrateur ou à l'ingénieur de support de vérifier l'état d'intégrité des deux catégories de composants indépendamment et de trouver des corrélations entre elles. Par exemple, un microservice particulier peut présenter de mauvaises performances en raison d'un manque de mémoire disponible. Les données de surveillance indiquent s'il s'agit d'un symptôme d'un problème de configuration système, d'un manque de ressources physiques ou d'une panne matérielle. Le système de surveillance dispose d'un service d'alerte capable de détecter et de signaler les pannes matérielles. L'administrateur peut éventuellement configurer un canal de notification pour recevoir des alertes en fonction des règles définies dans le système de surveillance.

Dans le cadre des opérations de service et de support, Oracle peut vous demander de générer des rapports sur des données de mesure spécifiques affichées dans les tableaux de bord par défaut. Pour cette raison, les configurations de tableau de bord par défaut doivent toujours être conservées. Toutefois, si une partie de la fonctionnalité de surveillance est modifiée ou interrompue par inadvertance, les valeurs par défaut peuvent être restaurées. De la même manière, il est possible pour Oracle de créer de nouveaux tableaux de bord ou de modifier des tableaux de bord existants pour une surveillance améliorée, et de les propager vers votre environnement opérationnel sans avoir besoin d'une procédure de mise à niveau formelle.

Tous les outils de surveillance et de journalisation open source décrits ici ont des API publiques qui permettent aux clients de s'intégrer à leurs systèmes de surveillance et d'alerte de l'état existants. Toutefois, Oracle ne prend pas en charge ces configurations personnalisées.

Observabilité du domaine de pannes

Lorsqu'il s'agit de maintenir l'infrastructure de l'appliance, les instances de calcul et leurs ressources associées en bon état, le domaine de pannes est un concept extrêmement important. Il regroupe un ensemble de composants d'infrastructure dans le but d'isoler les événements de temps d'arrêt dus aux pannes ou à la maintenance, en veillant à ce que les ressources des autres domaines de pannes ne soient pas affectées.

Conformément à Oracle Cloud Infrastructure, il existe toujours trois domaines de pannes dans une appliance de cloud privé. Chacun de ses domaines de pannes correspond à un ou plusieurs noeuds de calcul physiques. Outre l'utilisation de Grafana pour consulter les données de surveillance sur l'ensemble du système, un administrateur peut également accéder aux mesures de capacité clés pour les domaines de pannes directement à partir de l'enclave de service :

• Nombre de noeuds de calcul par domaine de pannes

• Quantité totale et disponible de RAM par domaine de pannes

• Nombre total et disponible de vCPUs par domaine de pannes

• Capacité de CPU et de RAM du système non affectée

Les mesures de domaine de pannes reflètent les ressources physiques réelles qui peuvent être consommées par les instances de calcul hébergées sur les noeuds de calcul. Les totaux n'incluent pas les ressources réservées au fonctionnement de l'hyperviseur : 40 Go de RAM et 4 coeurs de processeur (8 vCPUs).

Outre les trois domaines de pannes, la CLI de service affiche une catégorie "Unassigned". Il fait référence aux noeuds de calcul installés qui n'ont pas été provisionnés et qui ne font donc pas encore partie d'un domaine de pannes. Pour les noeuds de calcul non affectés, la capacité de mémoire ne peut pas être calculée, mais les mesures d'UC sont affichées.

Vérifications de l'état du système

Les contrôles de santé sont la forme de détection la plus élémentaire. Ils s'exécutent à intervalles réguliers en tant que services CronJob Kubernetes, qui sont très similaires aux travaux cron UNIX standard. Une entrée de statut est créée pour chaque résultat de vérification de l'état, ce qui est toujours l'une des deux possibilités suivantes : En bon état ou En mauvais état. Toutes les informations d'état sont stockées pour un traitement ultérieur dans Prométhée ; les résultats malsains génèrent également des entrées de journal dans Loki avec des détails pour aider à faire avancer le processus de dépannage.

Les vérifications de l'état sont destinées à vérifier l'état de composants système spécifiques et à détecter les changements d'état. Chaque processus de vérification de l'état suit le même principe de base : enregistrer la maladie en cours et la comparer au résultat attendu. Si elles correspondent, la vérification de l'état réussit ; si elles diffèrent, la vérification échoue. Le passage du statut En bon état à Non en bon état indique que le dépannage est requis.

Pour le dépannage, deux sources de données principales sont à votre disposition : les journaux et les mesures. Les deux catégories de données sont collectées à partir de l'ensemble du système et stockées dans un emplacement central : les journaux sont agrégés dans Loki et les métriques dans Prométhée. Les deux outils disposent d'une interface de requête qui vous permet de filtrer et de visualiser les données : ils s'intègrent tous deux à Grafana. Son interface basée sur un navigateur est accessible à partir de l'interface utilisateur Web de service.

Pour déterminer les causes de l'échec d'une vérification de l'état, il est utile de filtrer les journaux et les données de mesure en fonction du type d'échec. Loki catégorise les données avec un système d'étiquetage, affichant les messages de journal qui correspondent à l'étiquette de journal sélectionnée. Sélectionnez un libellé dans la liste pour afficher les journaux du service ou de l'application qui vous intéresse. Cette liste vous permet de sélectionner non seulement les vérifications de l'état, mais aussi les services de l'appareil interne et externe.

En outre, le dernier statut de chaque vérification de l'état s'affiche dans le tableau de bord de la vérification de l'état de la plate-forme, qui fait partie du tableau de bord de la fonction de conseil Service Advisor fourni par défaut dans Grafana.

Private Cloud Appliance exécute les vérifications de l'état répertoriées ci-dessous.

Journalisation centralisée

La plate-forme fournit une journalisation unifiée sur l'ensemble du système. Le collecteur de données Fluentd extrait les journaux des composants de l'ensemble du système et les stocke dans un emplacement central, ainsi que les données de télémétrie de l'appareil. Par conséquent, toutes les informations de dépannage et de débogage nécessaires sont conservées dans une seule banque de données et n'ont pas besoin d'être collectées auprès de différentes sources lorsqu'un problème doit être examiné. L'état général du système est capturé dans une vue, un tableau de bord Grafana, ce qui signifie qu'il n'est pas nécessaire qu'un administrateur vérifie des composants individuels.

Chaque fois qu'un problème nécessitant l'assistance d'Oracle est détecté, l'administrateur consigne une demande de service. Un lot d'informations pour le support est généralement demandé dans le cadre de ce processus. Grâce à la journalisation centralisée, le lot de support est facile à générer et reste possible même si le fonctionnement du système est gravement compromis. La génération du lot d'informations pour le support est une opération scriptée qui génère un fichier d'archive compressé unique. L'administrateur doit charger manuellement le fichier d'archive contenant les journaux consolidés et d'autres données de diagnostic.

Si l'appliance de cloud privé est enregistrée pour ASR, certaines pannes matérielles entraînent l'envoi automatique d'une demande de service et de données de diagnostic au support technique Oracle.