Surveillance de l'état et de l'état

Surveillance

Indépendamment des vérifications d'état intégrées, 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. Cela se fait via l'interface Grafana, en interrogeant les données de mesure à l'échelle du système stockées dans Prometheus.

Grafana fournit une approche visuelle de la surveillance : elle vous permet de créer des tableaux de bord composés d'un certain nombre de panneaux de visualisation. Chaque panneau correspond à une seule interrogation de mesure ou à une combinaison d'interrogations de mesure, affichées dans le format sélectionné. Les options incluent des graphiques, des tableaux, des graphiques, des diagrammes, des jauges, etc. Pour chaque panneau de mesure, des seuils peuvent être définis. Lorsque le résultat de l'interrogation dépasse ou descend en dessous d'un seuil donné, la couleur d'affichage change, fournissant une indication rapide des éléments qui sont sains, nécessitent une enquête ou sont défectueux.

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 et leurs systèmes d'exploitation et micrologiciels – ainsi que ses composants logiques – logiciel de contrôleur, plate-forme, grappe et microservices Kubernetes, instances de calcul et leurs ressources virtualisées. Cela permet à l'administrateur ou à l'ingénieur du soutien technique de vérifier l'état 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 du 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 du système, d'un manque de ressources physiques ou d'une défaillance matérielle. Le système de surveillance comporte 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 soutien, Oracle peut vous demander de déclarer 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 certaines fonctionnalités de surveillance sont modifiées ou endommagées par inadvertance, les valeurs par défaut peuvent être restaurées. De la même façon, Oracle peut créer de nouveaux tableaux de bord ou modifier ceux existants pour améliorer la surveillance et les pousser vers votre environnement opérationnel sans avoir besoin d'une procédure formelle de mise à niveau.

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

Observabilité du domaine d'erreur

Lorsqu'il s'agit de maintenir l'infrastructure du boîtier, les instances de calcul et leurs ressources connexes s'exécutent dans un état sain, le domaine d'erreur est un concept extrêmement important. Il regroupe un jeu de composants d'infrastructure dans le but d'isoler les événements de temps d'arrêt dus aux pannes ou à la maintenance, en s'assurant que les ressources des autres domaines d'erreur ne sont pas touchées.

Conformément à Oracle Cloud Infrastructure, il y a toujours trois domaines d'erreur dans un boîtier en nuage privé. Chacun de ses domaines d'erreur correspond à un ou plusieurs noeuds de calcul physiques. En plus d'utiliser Grafana pour consulter les données de surveillance dans l'ensemble du système, un administrateur peut également accéder aux mesures de capacité clés pour les domaines d'erreur directement à partir de l'Enclave de service :

• Nombre de noeuds de calcul par domaine d'erreur

• Quantité totale et disponible de mémoire vive par domaine d'erreur

• Nombre total et disponible de vCPUs par domaine d'erreur

• Capacité d'UC et de mémoire vive du système non affectée

Les mesures du domaine d'erreur reflètent les ressources physiques réelles pouvant ê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 mémoire vive et 4 coeurs d'UC (8 vCPUs).

En plus des trois domaines d'erreur, l'interface de ligne de commande du service affiche une catégorie "Non affecté". 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 d'erreur. 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 d'état du système

Les contrôles d'état sont la forme de détection la plus élémentaire. Ils s'exécutent à intervalles réguliers en tant que services Kubernetes CronJob, qui sont très similaires aux tâches 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 : Sain ou Non sain. Toutes les informations d'état sont stockées pour un traitement ultérieur dans Prometheus; 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 d'état sont destinées à vérifier le statut de composants système spécifiques et à détecter les modifications de statut. Chaque processus de vérification de l'état suit le même principe de base : enregistrer la condition courante 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 de l'état échoue. Un changement de statut de sain à non sain indique que le dépannage est nécessaire.

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

Pour examiner les causes de l'échec d'une vérification d'é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 une étiquette dans la liste pour voir les journaux du service ou de l'application qui vous intéresse. Cette liste vous permet de sélectionner non seulement les vérifications d'état, mais également les services internes et externes de l'appliance.

En outre, le dernier statut de chaque vérification d'état est affiché dans le tableau de bord de vérification d'état de la plate-forme, qui fait partie du jeu de tableaux de bord Service Advisor fourni par défaut dans Grafana.

Private Cloud Appliance exécute les vérifications d'état 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'appliance. Par conséquent, toutes les informations de dépannage et de débogage nécessaires sont conservées dans un seul magasin de données et n'ont pas besoin d'être collectées à partir de différentes sources lorsqu'un problème doit être étudié. 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.

Lorsqu'un problème nécessitant l'aide d'Oracle est détecté, l'administrateur enregistre une demande de service. Une offre groupée de soutien est généralement demandée dans le cadre de ce processus. Grâce à la journalisation centralisée, le faisceau 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 de l'ensemble de prise en charge est une opération par script qui produit un seul fichier d'archive compressé. L'administrateur doit charger manuellement le fichier d'archives contenant les journaux consolidés et d'autres données de diagnostic.

Si Private Cloud Appliance est enregistré pour ASR, certaines pannes matérielles entraînent l'envoi automatique d'une demande de service et de données de diagnostic au soutien technique d'Oracle.