Documentation sur Oracle Cloud Infrastructure

Utilisation de l'outil support-bundles

L'outil support-bundles collecte divers types d'ensemble ou modes de données de diagnostic du boîtier Private Cloud Appliance, tels que le statut de vérification de l'état, les sorties de commande et les journaux.

Selon les options de commande fournies, ces ensembles peuvent contenir des journaux ou un statut. Tous les modes collectent des fichiers dans un répertoire d'ensemble. Un seul processus d'offre groupée de soutien est autorisé à la fois. Un fichier de verrouillage d'offre groupée de soutien est créé au début de la collecte d'offre groupée et supprimé lorsque la collecte d'offre groupée est terminée.

Toutes les commandes support-bundles retournent immédiatement et la collection d'ensembles s'exécute en arrière-plan. En effet, les collectes d'offres groupées peuvent prendre des heures. Les offres groupées sont stockées pendant deux jours, puis supprimées automatiquement.

Les types d'offre groupée suivants sont pris en charge :

  • Mode de tri. Collecte des données sur le statut courant du boîtier Private Cloud Appliance.

  • Mode tranche de temps. Collecte les données par plage horaire. Ces résultats peuvent être affinés en spécifiant le nom du pod, la tâche et l'étiquette k8s_app.

  • Mode Combo. Collecte une combinaison de données de triage et de tranche de temps.

  • Mode natif. Collecte des données à partir des nœuds de gestion, de calcul et ZFS et des hôtes ILOM et Cisco.

Un bon moyen de commencer à enquêter sur un problème est de collecter un ensemble combo. Recherchez NOT_HEALTHY dans les résultats du mode triage et comparez-les à ce que vous voyez dans les résultats du mode time_slice.

La commande support-bundles nécessite une option de mode. Tous les modes acceptent l'option de numéro de demande de service. Voir le tableau suivant. La tranche de temps et les modes natifs comportent des options supplémentaires.

Option

Description

Obligatoire

-m mode

Type d'offre groupée.

oui

-sr SR_number

--sr_number SR_number

Numéro de la demande de service.

aucune

La sortie de la commande support-bundles est stockée dans le répertoire suivant sur le noeud de gestion, où bundle-type est le mode : triage, time_slice, combo ou native :

/nfs/shared_storage/support_bundles/SR_number_bundle-type-bundle_timestamp/

SR_number est utilisé si vous avez fourni l'option -sr. Si vous créez l'ensemble de soutien pour une demande de service, spécifiez SR_number.

Ce répertoire contient un fichier de progression de la collection d'ensembles et un fichier d'archives, nommés comme suit :

bundle-type_collection.log
SR_number_bundle-type-bundle_timestamp.tar.gz

Le fichier d'archives contient un fichier header.json avec les composants par défaut suivants :

  • current-time - Horodatage

  • create-support-bundle - Ligne de commande utilisée

  • sr-number - Numéro de demande de service associé au fichier d'archives

Connexion au noeud de gestion

Pour utiliser la commande support-bundles, connectez-vous en tant que root au noeud de gestion qui exécute les ressources Pacemaker. Collectez d'abord des données à partir du nœud de gestion qui exécute les ressources Pacemaker, puis à partir d'autres nœuds de gestion selon les besoins.

Si vous ne savez pas quel noeud de gestion exécute les ressources Pacemaker, connectez-vous à n'importe quel noeud de gestion et vérifiez le statut du cluster Pacemaker. La commande suivante montre que les ressources de grappe Pacemaker s'exécutent sur pcamn01.

[root@pcamn01 ~]# pcs status
Cluster name: mncluster
Stack: corosync
Current DC: pcamn01
...
Full list of resources:

scsi_fencing (stonith:fence_scsi): Stopped (disabled)
Resource Group: mgmt-rg
vip-mgmt-int (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-host (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ilom (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-lb (ocf::heartbeat:IPaddr2): Started pcamn01
vip-mgmt-ext (ocf::heartbeat:IPaddr2): Started pcamn01
l1api (systemd:l1api): Started pcamn01
haproxy (ocf::heartbeat:haproxy): Started pcamn01
pca-node-state (systemd:pca_node_state): Started pcamn01
dhcp (ocf::heartbeat:dhcpd): Started pcamn01
hw-monitor (systemd:hw_monitor): Started pcamn01

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Mode de triage

En mode triage, Prometheus platform_health_check est interrogé pour le statut HEALTHY et NOT_HEALTHY. Si NOT_HEALTHY est trouvé, utilisez le mode time_slice pour obtenir plus de détails.

# support-bundles -m triage

Les fichiers suivants se trouvent dans le fichier d'archive de sortie.

Fichier

Description

header.json

Horodatage et ligne de commande pour générer cet ensemble.

compute_node_info.json

Pods exécutés dans le noeud de calcul.

hardware_info.json

Liste des composants matériels extraite de hms, tous les ipmitool fru s'exécutant à tous les noeuds de gestion des états prêts et de calcul, toutes les informations sur les têtes zfssa.

management_node_info.json

Pods exécutés dans le noeud de gestion.

rack_info.json

Temps d'installation du bâti et version de compilation.

loki_search_results.log.n

Fichiers de tranche de mémoire dans json.

Mode de tranche de temps

En mode tranche de temps, les données sont collectées en spécifiant des horodatages de début et de fin. Les deux options suivantes sont requises :

  • -s start_date

  • -e end_date

Le mode de tranche de temps comporte les options suivantes en plus des options de mode et de numéro de demande de service. Ces options permettent de limiter la collecte de données. Si vous ne spécifiez pas l'option -j ou --all, les données sont collectées à partir de toutes les tâches du service de vérification de l'état.

  • Une seule des valeurs --job_name, --all et --k8s_app doit être spécifiée.

  • Si aucun des paramètres --job_name, --all ou --k8s_app n'est spécifié, le filtrage de pod se produit sur la valeur par défaut (.+checker).

  • L'option --all peut collecter une énorme quantité de données. Vous voudrez peut-être limiter votre tranche de temps à 48 heures.

Exemple :

# support-bundles -m time_slice -j flannel-checker -s 2021-05-29T22:40:00.000Z \
-e 2021-06-29T22:40:00.000Z -l INFO

Voir d'autres exemples ci-dessous.

Option

Description

Obligatoire

-s timestamp

--start_date timestamp

Date de début au format yyyy-mmm-ddTHH:mm:ss

L'argument minimal est yyyy-mmm-dd

oui

-e timestamp

--end_date timestamp

Date de fin au format yyyy-mmm-ddTHH:mm:ss

L'argument minimal est yyyy-mmm-dd

oui

-j job_name

--job_name job_name

Nom de l'emploi Loki. Valeur par défaut : .+checker

Voir Interrogation de liste d'étiquettes ci-dessous.

aucune
--k8s_app label

Valeur d'étiquette k8s_app à interroger dans la tâche k8s-stdout-logs.

Voir Interrogation de liste d'étiquettes ci-dessous.

 aucune
--all Interroge tous les noms de tâche, à l'exception des tâches dont la journalisation est trop importante, telles que audit, kubernetes-audit et vault-audit et l'étiquette k8s_app pcacoredns. aucune

-l level

--levelname level

Niveau du message

aucune

--pod_name pod_name

Nom du pod (par exemple kube ou network-checker) pour filtrer la sortie en fonction du pod. Seules les lettres de départ sont nécessaires.

aucune

-t timeout

--timeout timeout

Temporisation en secondes pour une seule interrogation Loki. Par défaut, elle est de 180 secondes.

aucune
Interrogation de liste d'étiquettes

Utilisez l'interrogation de liste d'étiquettes pour lister les noms de tâche disponibles et les valeurs d'étiquette k8s_app.

# support-bundles -m label_list
2021-10-14T23:19:18.265 - support_bundles - INFO - Starting Support Bundles
2021-10-14T23:19:18.317 - support_bundles - INFO - Locating filter-logs Pod
2021-10-14T23:19:18.344 - support_bundles - INFO - Executing command - ['python3', 
'/usr/lib/python3.6/site-packages/filter_logs/label_list.py']
2021-10-14T23:19:18.666 - support_bundles - INFO -
Label:  job
Values: ['admin', 'api-server', 'asr-client', 'asrclient-checker', 'audit', 'cert-checker', 'ceui', 
'compute', 'corosync', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 'flannel-checker', 
'his', 'hms', 'iam', 'k8s-stdout-logs', 'kubelet', 'kubernetes-audit', 'kubernetes-checker', 
'l0-cluster-services-checker', 'messages', 'mysql-cluster-checker', 'network-checker', 'ovm-agent', 
'ovn-controller', 'ovs-vswitchd', 'ovsdb-server', 'pca-healthchecker', 'pca-nwctl', 'pca-platform-l0', 
'pca-platform-l1api', 'pca-upgrader', 'pcsd', 'registry-checker', 'sauron-checker', 'secure', 
'storagectl', 'uws', 'vault', 'vault-audit', 'vault-checker', 'zfssa-checker', 'zfssa-log-exporter']
 
Label:  k8s_app
Values: ['admin', 'api', 'asr-client', 'asrclient-checker', 'brs', 'cert-checker', 'compute', 
'default-http-backend', 'dr-admin', 'etcd', 'etcd-checker', 'filesystem', 'filter-logs', 
'flannel-checker', 'fluentd', 'ha-cluster-exporter', 'has', 'his', 'hms', 'iam', 'ilom', 
'kube-apiserver', 'kube-controller-manager', 'kube-proxy', 'kubernetes-checker', '
l0-cluster-services-checker', 'loki', 'loki-bnr', 'mysql-cluster-checker', 'mysqld-exporter', 
'network-checker', 'pcacoredns', 'pcadnsmgr', 'pcanetwork', 'pcaswitchmgr', 'prometheus', 'rabbitmq', 
'registry-checker', 'sauron-api', 'sauron-checker', 'sauron-grafana', 'sauron-ingress-controller', 
'sauron-mandos', 'sauron-operator', 'sauron-prometheus', 'sauron-prometheus-gw', 
'sauron-sauron-exporter', 'sauron.oracledx.com', 'storagectl', 'switch-metric', 'uws', 'vault-checker', 
'vmconsole', 'zfssa-analytics-exporter', 'zfssa-csi-nodeplugin', 'zfssa-csi-provisioner', 'zfssa-log-exporter']

Exemples :

  • Aucune étiquette de tâche, aucune étiquette k8s_app, collectez le journal de tous les vérificateurs d'état.

    # support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

  • Un emploi ceui.

    # support-bundles -m time_slice -sr 3-xxxxxxxxxxx -j ceui -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

  • Un vérificateur de réseau k8s_app.

    # support-bundles -m time_slice -sr 3-xxxxxxxxxxx --k8s_app network-checker -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

  • Tous les emplois et la date.

    # support-bundles -m time_slice -sr 3-xxxxxxxxxxx -s `date -d "2 days ago" -u +"%Y-%m-%dT%H:%M:%S.000Z"` -e `date -d +u +"%Y-%m-%dT%H:%M:%S.000Z"`

  • Tous les travaux.

    # support-bundles -m time_slice -sr 3-xxxxxxxxxxx --all -s "2022-01-11T00:00:00" -e "2022-01-12T23:59:59"

Les fichiers suivants se trouvent dans le fichier d'archive de sortie.

Fichier

Description

header.json

Horodatage et ligne de commande pour générer cet ensemble.

loki_search_results.log.n

Fichiers de tranche de mémoire dans json. Les ensembles de tranches de temps ont une limite de 500 000 journaux par interrogation, à partir de l'heure de début.

rack_info.json

Temps d'installation du bâti et version de compilation.

Mode combinaison

Le mode combo est une combinaison d'un ensemble de triage et d'un ensemble de tranches de temps. La sortie inclut un fichier d'archives et deux fichiers journaux de collecte : triage_collection.log et time_slice_collection.log.

Les fichiers suivants se trouvent dans le fichier d'archive de sortie.

Fichier

Description

triage-bundle_timestamp.tar.gz

Fichier d'archives de l'ensemble de tri.

time_slice-bundle_timestamp.tar.gz

Fichier d'archives de l'ensemble de tranches de temps.

Les données de tranche d'heure collectées concernent les tâches --all d'une heure précédant l'heure courante à l'heure courante.

Mode natif

Le fichier native_collection.log du répertoire de l'ensemble fournit des informations sur la progression de la collecte. La collecte des ensembles natifs peut prendre des heures.

Le mode native comporte les paramètres suivants en plus du mode et du numéro de demande de service.

Paramètre

Description

Obligatoire

-t nativetype

--type nativetype

  • zfs_bundle

  • sosreport

  • ilom_snapshot

  • cisco_bundle

Valeur par défaut : zfs_bundle

aucune

-c component

--component component

Nom du composant, tel que le nom d'un noeud de gestion, de calcul ou ZFS, ou d'un hôte ILOM ou Cisco.

aucune

Les fichiers suivants se trouvent dans le fichier d'archive de sortie.

Fichier

Description

header.json

Horodatage et ligne de commande pour générer cette offre groupée.

Fichiers d'ensemble natifs

Ces fichiers sont propres à nativetype spécifié.

rack_info.json

Temps d'installation du bâti et version de compilation.
Offre groupée ZFS

Lorsque nativetype est un ensemble de prise en charge ZFS, la collecte démarre sur les deux noeuds ZFS et télécharge les nouveaux ensembles de prise en charge ZFS dans le répertoire de l'ensemble. Lorsque nativetype n'est pas spécifié, zfs_bundle est créé par défaut.

# support-bundles -m native -t zfs_bundle
Ensemble de rapports SOS

Lorsque nativetype est un ensemble de rapports SOS, le rapport est collecté à partir du noeud de gestion ou du noeud de calcul spécifié par le paramètre --component. Si --component n'est pas spécifié, le rapport est collecté à partir de tous les noeuds de gestion et de calcul.

# support-bundles -m native -t sosreport -c pcamn01
Instantané ILOM

Lorsque nativeType=ilom_snapshot, la valeur du paramètre --component est le nom d'hôte ILOM d'un noeud de gestion ou de calcul. Si le paramètre --component n'est pas spécifié, le rapport est collecté à partir de tous les hôtes ILOM.

# support-bundles -m native -t ilom_snapshot -c ilom-pcacn007
Ensemble Cisco

Lorsque nativetype est cisco-bundle, la valeur du paramètre --component est un nom d'hôte interne de gestion, d'agrégation ou de gestion des commutateurs d'accès Cisco.

# support-bundles -m native -t cisco-bundle -c accsn01

Pour créer un type de collection cisco-bundle, les conditions suivantes doivent être remplies :

  • Le module Cisco OBFL doit être activé sur tous les commutateurs Cisco Private Cloud Appliance. Le module Cisco OBFL est activé par défaut sur tous les commutateurs Cisco Private Cloud Appliance.

  • Le module Cisco EEM doit être activé sur tous les commutateurs Cisco Private Cloud Appliance. Le module Cisco EEM est activé par défaut sur tous les commutateurs Cisco Private Cloud Appliance.

  • Politique EEM (Embedded Event Manager)