Documentation Oracle Cloud Infrastructure

Utilisation de l'outil Support-bundles

L'outil support-bundles collecte différents types de bundles, ou modes, de données de diagnostic de Private Cloud Appliance telles que le statut de la vérification de l'état, les sorties de commande et les journaux.

Selon les options de commande fournies, ces bundles peuvent contenir des journaux ou un statut. Tous les modes collectent des fichiers dans un répertoire de groupe. Un seul processus de lot d'informations pour le support est autorisé à la fois. Un fichier de verrouillage de lot d'informations pour le support est créé au début de la collecte de lot d'informations et supprimé une fois la collecte de lot terminée.

Toutes les commandes support-bundles renvoient immédiatement et la collection de groupes s'exécute en arrière-plan. En effet, les collectes de lots peuvent prendre des heures. Les bundles sont stockés pendant deux jours, puis supprimés automatiquement.

Les types de bundles suivants sont pris en charge :

  • Mode de tri. Collecte des données sur le statut actuel de l'appliance de cloud privé.

  • Mode Tranche de temps. Collecte les données par tranches horaires. Vous pouvez affiner ces résultats en indiquant le nom du pod, le travail et le libellé k8s_app.

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

  • Mode natif. Collecte les données des noeuds de gestion, de calcul et ZFS et des hôtes ILOM et Cisco.

Un bon moyen de commencer à examiner un problème consiste à collecter un groupe 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 requiert une option de mode. Tous les modes acceptent l'option de numéro de demande de service. Reportez-vous au tableau suivant. La tranche de temps et les modes natifs disposent d'options supplémentaires.

Option

Description

Requis

-m mode

Type de bundle.

oui

-sr SR_number

--sr_number SR_number

Numéro demande d'assistance.

non

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 le lot d'informations pour le support d'une demande de service, indiquez SR_number.

Ce répertoire contient un fichier de progression de collecte de groupe et un fichier d'archive, nommés comme suit :

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

Le fichier d'archive 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 archive

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 les données à partir du nœud de gestion qui exécute les ressources Pacemaker, puis à partir d'autres nœuds de gestion si nécessaire.

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 indique que les ressources de cluster Pacemaker sont en cours d'exécution 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 triage

En mode triage, Prométhée platform_health_check est interrogé pour les statuts 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 ce groupe.

compute_node_info.json

Pods en cours d'exécution dans le noeud de calcul.

hardware_info.json

Liste des composants matériels extraite de hms, de tous les éléments ipmitool fru exécutés sur tous les noeuds de calcul et de gestion d'état prêts, de toutes les informations sur les têtes zfssa.

management_node_info.json

Pods en cours d'exécution dans le noeud de gestion.

rack_info.json

Durée d'installation du rack et version de compilation.

loki_search_results.log.n

Fichiers de blocs dans json.

Mode de tranche horaire

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

  • -s start_date

  • -e end_date

Le mode 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 n'indiquez pas l'option -j ou --all, les données sont collectées à partir de tous les travaux du vérificateur d'état.

  • Une seule valeur parmi --job_name, --all et --k8s_app doit être indiquée.

  • Si aucune valeur --job_name, --all ou --k8s_app n'est indiquée, le filtrage de pod se produit sur la valeur par défaut (.+checker).

  • L'option --all peut collecter une grande quantité de données. Vous pouvez 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 plus d'exemples ci-dessous.

Option

Description

Requis

-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 du travail Loki. Valeur par défaut : .+checker

Voir la requête de liste d'étiquettes ci-dessous.

non
--k8s_app label

Valeur de libellé k8s_app à interroger dans le travail k8s-stdout-logs.

Voir la requête de liste d'étiquettes ci-dessous.

 non
--all Interroge tous les noms de travail, à l'exception des travaux dont la journalisation est trop importante, tels que audit, kubernetes-audit, vault-audit et le libellé k8s_app pcacoredns. non

-l level

--levelname level

Niveau de message

non

--pod_name pod_name

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

non

-t timeout

--timeout timeout

Délai d'expiration en secondes pour une seule requête Loki. Par défaut, la valeur est de 180 secondes.

non
Requête de liste d'étiquettes

Utilisez la requête de liste de libellés pour répertorier les noms de travail et les valeurs de libellé k8s_app disponibles.

# 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 :

  • Aucun libellé de travail, aucun libellé 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 travail 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 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 ce groupe.

loki_search_results.log.n

Fichiers de blocs dans json. Les groupes de tranches horaires ont une limite de 500 000 journaux par requête, à partir de l'heure de début.

rack_info.json

Durée d'installation du rack et version de compilation.

Mode combinaison

Le mode combo est une combinaison d'un groupe de triage et d'un groupe de tranches horaires. La sortie inclut un fichier d'archive 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'archive du groupe de triages.

time_slice-bundle_timestamp.tar.gz

Fichier d'archive de groupe de tranches de temps.

Les données de tranche de temps collectées concernent les travaux --all d'une heure précédant l'heure actuelle à l'heure actuelle.

Mode natif

Le fichier native_collection.log du répertoire du groupe fournit des informations sur la progression de la collecte. La collecte des lots 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

Requis

-t nativetype

--type nativetype

  • zfs_bundle

  • sosreport

  • ilom_snapshot

  • cisco_bundle

Valeur par défaut : zfs_bundle

non

-c component

--component component

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

non

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 ce lot.

Fichiers de groupe natifs

Ces fichiers sont spécifiques au fichier nativetype indiqué.

rack_info.json

Durée d'installation du rack et version de compilation.
Groupe ZFS

Lorsque nativetype est un lot de support ZFS, la collecte démarre sur les deux noeuds ZFS et télécharge les nouveaux lots de support ZFS dans le répertoire du lot. Lorsque nativetype n'est pas indiqué, zfs_bundle est créé par défaut.

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

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

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

Lorsque nativeType=ilom_snapshot, la valeur du paramètre --component est le nom d'hôte ILOM d'un noeud de gestion ou d'un noeud 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
Bundle Cisco

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

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

Pour créer un ensemble de type 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.

  • Stratégie EEM (Embedded Event Manager)