PowerFlex : GET_INFO - Support Bundle Collection Utility

get_info.sh [OPTIONS]

DESCRIPTION

get_info.sh est un utilitaire de diagnostic qui collecte les informations de débogage à partir d’un hôte PowerFlex (ex-ScaleIO) et les archive dans un bundle compressé à des fins d’analyse par le personnel de support.

L’utilitaire collecte des données provenant de plusieurs sources, notamment :

• Fichiers journaux, de configuration et de suivi des composants PowerFlex
• Sorties de requête MDM/SCLI et vidage de débogage interne
• Diagnostics internes des composants PowerFlex
• Configuration du système d’exploitation, journaux et état d’exécution
• Inventaire du matériel (contrôleurs de stockage, périphériques réseau, NVMe, NVDIMM, etc.)
• Vidages mémoire (existants et générés à la demande en option)
• Contrôleur de données de diagnostic (diag_coll) statistiques

Le bundle résultant est une archive compressée unique (tar/gz par défaut) qui peut être transférée vers le support PowerFlex pour une analyse plus approfondie.

Une seule instance de get_info.sh peut s’exécuter sur un hôte à un moment donné. S’il n’y a pas suffisamment d’espace libre pour sa sortie, il refuse de s’exécuter (sauf si la vérification de l’espace est explicitement ignorée).

OPTIONS

Options générales

• -a, --all

  Collectez toutes les données. Cela équivaut à spécifier --mdm-repository, --collect-cores, --max-cores=2, --valgrind-coreset --analyse-diag-coll.

• -A, --analyse-diag-coll

  Analyser le collecteur de données de diagnostic (diag coll) données

• -b[COMPONENTS], --collect-cores[=COMPONENTS]

  Collecter les vidages mémoire existants pour la liste séparée par des espaces des User-Land COMPONENTS. Par défaut (quand COMPONENTS est omis) : Tous les composants de l’espace utilisateur
   

Exemple

-b'mdm sds'

--collect-cores='mdm sds'

• -d OUT_DIR, --output-dir=OUT_DIR

  Stockez le bundle résultant sous le répertoire OUT_DIR. Default: <WORK_DIR>/scaleio-getinfo (Voir --work-dir).

• -f, --skip-mdm-login

  Ignorez la requête pour les informations d’identification de connexion du MDM PowerFlex. Utile lorsque l’utilisateur s’est déjà connecté manuellement.

• -h, --help

  Affichez le message d’aide et quittez. Lorsqu’il est combiné avec --tech, affichent également les options du technicien.

• -J, --xz

  Utilisez tar/xz format du bundle collecté au lieu de la valeur par défaut tar/gz. Ignoré si le tar(1) Ne prend pas en charge --use-compress-program ou xz(1) est introuvable.

• -k NUM, --max-cores=NUM

  Collectez jusqu’à NUM fichiers mémoire de chaque composant. Default : Tous les fichiers mémoire, ce qui implique --collect-cores

• -l, --light

  Générez un bundle léger. Seule la dernière génération de fichiers log numérotés est collectée, et les fichiers exécutables ou bibliothèques de composants ne sont pas inclus lors de la collecte des cœurs. L’utilisation de cette option réduit la prise en charge et son utilisation est déconseillée.

• -m NUM, --max-traces=NUM

  Collectez jusqu’à NUM Fichiers de trace PowerFlex de chaque composant. Default : Tous les fichiers

• -N, --skip-space-check

  Ignorez la vérification de l’espace disque disponible avant la collecte des données.

• -P PATH, --collect-path=PATH

  Collecter le chemin supplémentaire PATH. Seuls les chemins absolus sont acceptés. Accepte les caractères génériques ; Les caractères génériques doivent être mis entre guillemets. Cette option peut être spécifiée plusieurs fois pour collecter plusieurs chemins.

• -q, --quiet, --silent

  Supprime les messages sur la sortie standard.

• -r, --mdm-repository

  Collectez les fichiers du référentiel MDM.

• -s, --skip-sdbg

  Ignorer la collecte de la sortie SDBG (débogueur de diagnostic).

• -S, --pause-core-generation

  Suspendez la génération de cœur des composants PowerFlex lors de la collecte des données. La configuration d’origine est restaurée à la fin de la collecte.

• -w WORK_DIR, --work-dir=WORK_DIR

  Utiliser le répertoire WORK_DIR pour les fichiers temporaires. Default : /tmp.

• -x FILE, --output-file=FILE

  Stockez le bundle collecté en tant que fichier nommé FILE. Le suffixe de nom de fichier approprié (.tgz, .zip, et ainsi de suite) est ajouté automatiquement. si FILE Est - (tiret), écrivez le bundle dans la sortie standard (ce qui implique --quiet). Lorsqu’un bundle est écrit sur la sortie standard, aucun fichier de bundle n’est créé sur le disque. Default : getInfoDump.

• -z, --zip

  Utilisez zip format du bundle collecté au lieu de la valeur par défaut tar/gz. Ignoré si zip(1) Introuvable sur le système.

• --mdm-port=PORT

  Connexion au MDM à l’aide du port PORT pour les commandes SCLI. Default : scli default behavior.

• --overwrite-output-file

  Remplacez le fichier de sortie s’il existe déjà. Lorsqu’un fichier de sortie ou un répertoire est explicitement spécifié (à l’aide de -x ou -d), le comportement par défaut est de refuser d’écraser ; Cette option remplace cela.

• --tech

  Incluez les options du technicien dans la sortie du message d’aide.

Options de connexion MDM

Les options suivantes sont transmises à la SCLI : --login . Leur comportement et les valeurs par défaut sont régis par SCLI.

• -n, --use-nonsecure-communication

  Connectez-vous au MDM en mode non sécurisé.

• -p PASSWORD, --password=PASSWORD

  Utilisez PASSWORD pour la connexion MDM PowerFlex. Default : Comportement par défaut de la SCLI

• -u USERNAME, --username=USERNAME

  Utilisez USERNAME pour la connexion MDM PowerFlex. Default : Comportement par défaut de la SCLI

• --ldap-authentication

  Connectez-vous à PowerFlex MDM à l’aide de l’authentification basée sur LDAP.

• --management-system-ip=ADDRESS

  Connectez-vous à SSO/M&O at ADDRESS pour la connexion à PowerFlex. Default : Comportement par défaut de la SCLI

• --p12-password=PASSWORD

  Chiffrer la connexion PowerFlex PKCS#12 fichier à l’aide de PASSWORD. Default : Comportement par défaut de la SCLI

• --p12-path=FILE

  Stockez les identifiants de connexion PowerFlex PKCS#12 Fichier en tant que FILE. Default : Comportement par défaut de la SCLI

Options pour les techniciens

Les options suivantes sont destinées aux techniciens de support et s’affichent dans le message d’aide uniquement lorsque : --tech est spécifié.

• -c[COMPONENTS], --generate-cores[=COMPONENTS]

Générer des fichiers mémoire (à l’aide de gcore(1)) pour les processus en cours d’exécution de la liste séparée par des espaces des utilisateurs-land COMPONENTS. Par défaut : tous les composants user-land, implique --collect-executables, et nécessite gdb et gcore.

Exemples :

-c'mdm sds'
--generate-cores='mdm sds'

• -C CORE_FILE, --reference-core-file=CORE_FILE

  Collectez les journaux et les cœurs du produit par rapport à l’heure de la dernière modification (mtime) de CORE_FILE, au lieu de l’heure de début d’exécution. Implique --collect-cores

• -E REF_TIME, --event-time=REF_TIME

  Collectez les journaux et les cœurs du produit relatifs à REF_TIME, au lieu de l’heure de début d’exécution. Accepte tout format compris par date(1). Implique --collect-cores.

• -g[COMPONENTS], --valgrind-cores[=COMPONENTS]

Recueillir valgrind Vidages mémoire pour l’utilisateur-land spécifié COMPONENTS. Par défaut : tous les composants user-land. Implique --collect-executables.

Exemples :

-g'mdm sds'
--valgrind-cores='mdm sds'

• -t MIN, --minutes-before-event=MIN

  Collectez les journaux de produits et les cœurs générés jusqu’à MIN minutes avant l’heure de référence. Default : 15

• -T MIN, --minutes-after-event=MIN

  Collectez les journaux de produits et les cœurs générés jusqu’à MIN minutes après l’heure de référence. Default : 5

• -X[COMPONENTS], --collect-executables[=COMPONENTS]

  Collecter les fichiers exécutables des composants et leurs bibliothèques partagées pour l’utilisateur spécifié COMPONENTS. Default : Tous les composants de l’espace utilisateur

Exemples :

-X'mdm sds'
--collect-executables='mdm sds'

• --keep-work-dir

  Conservez le répertoire de travail temporaire généré après la création du bundle (nettoyé automatiquement).

STRUCTURE DE L’OFFRE GROUPÉE

Le bundle de sortie est une archive compressée unique.

• Le répertoire de premier niveau du bundle correspond au nom d’hôte du système collecté.
• Les sorties de commande de l’hôte général vont dans un server/ Sous-répertoire.
  Le nom du fichier est <command> + <arguments> + suffixe (.txt par défaut). Espaces remplacés par _, caractères non alphanumériques supprimés
  Exemple : server/ip_-s_addr.txt – output of ip -s addr
• Les sorties de commande de produit sont placées dans le sous-répertoire du composant. mdm/ Pour scli, sdc/ Pour drv_cfg, et ainsi de suite.
  Nom de la commande (scli, drv_cfg, et ainsi de suite) est dépouillé. Le premier argument significatif devient le nom de fichier. Les fichiers sont attribués comme le suffixe approprié, .txt par défaut.

Exemples : 

• • mdm/query_cluster.txt - Sortie de scli --query_cluster
  • mdm/tgt_dump.txt - Sortie de scli --debug_action --tgt_dump
  • sdc/query_mdms.txt - Sortie de drv_cfg --query_mdms
  • sds/sdbg.txt - la sortie de SDBG dumpallscreens pour FDS
• Fichiers de composants de produits (par opposition aux sorties de commandes), <component>/cfg, <component>/logs, et ainsi de suite
  Copié à partir du répertoire du composant avec le préfixe supprimé.

Exemples : 

• • mdm/cfg/conf.txt - copie de /opt/emc/scaleio/mdm/cfg/conf.txt
  • sds/logs/trc.0 - copie de /opt/emc/scaleio/sds/logs/trc.0
• Les fichiers du système de fichiers hôte sont placés sur leur chemin d’accès au système de fichiers par rapport à la racine du bundle.

Exemples :

• • etc/os-release - copie de /etc/os-release
  • var/log/messages - copie de /var/log/messages
  • proc/cpuinfo - copie de /proc/cpuinfo
• Les fichiers du collecteur de diagnostics (diag_coll) sont copiés avec le /opt préfixe dépouillé, préservant la structure interne.
  Exemple : diag_coll/logs/sar.0 - copie de /opt/diag_coll/logs/sar.0
• Les fichiers masqués (précédés d’un point) sont « masqués » en supprimant le point de début.
• Journal d’exécution de l’utilitaire, get_info_run.log, placé directement sous le nom> d’hôte</racine

Structure arborescente des répertoires du bundle :

<hostname>/
|-- get_info_run.log                   Utility execution log
|-- server/                            General command output directory
|   |-- ip_-s_addr.txt
|   |-- uptime.txt
|   |-- uname_-a.txt
|   |-- ps_-elF.txt
|   |-- dmesg.txt
|   +-- ...                            (one file per collected command)
|
|-- mdm/                               PowerFlex component data (if installed)
|   |-- cfg/                           Configuration files (excl. PEM)
|   |-- logs/                          Trace and log files
|   |-- rep/                           Repository (if --mdm-repository)
|   |-- query_all.txt                  SCLI query outputs
|   |-- sdbg.txt                       SDBG screen dumps
|   +-- ...
|-- sds/
|-- pds/  
|-- dgwt/
|-- sdr/
|-- sdt/
|-- lia/
|-- sdc/
|-- gateway/
|
|-- diag_coll/                         Diagnostic data collector (if installed)
|   |-- logs/
|   |-- cfg/
|   +-- ...
|
|-- etc/                               Host files
|   |-- os-release
|   |-- sysconfig/
|   |-- network/
|   +-- ...
|-- var/
|   |-- log/
|   |   |-- messages
|   |   +-- ...
|   +-- ...
|-- proc/
|   |-- cpuinfo
|   |-- meminfo
|   +-- ...
|-- sys/
|-- ...
|
|-- scaleio-getinfo-extra/        Extra diagnostic data (if present)
+-- scaleio-getinfo-backup/       Backed-up configuration files (if any)

FILTRAGE DES JOURNAUX DE PRODUITS ET DES FICHIERS MÉMOIRE

Les options décrites dans cette section contrôlent la façon dont les fichiers journaux du produit (également appelés fichiers de suivi, par exemple trc.0, trc.1, exp.0) et les fichiers de vidage mémoire sont sélectionnés pour être inclus dans le bundle collecté. Pour ce faire, ils définissent une heure de référence, une fenêtre temporelle autour de celle-ci et des limites de comptage.

Lorsqu’aucune option de filtrage n’est spécifiée, tous les fichiers journaux du produit et (si la collecte mémoire est activée) tous les fichiers de vidage mémoire sont collectés. Les options de filtrage restreignent progressivement cette sélection, comme décrit ci-dessous.

Heure de référence

Une heure de référence peut être définie à l’aide de l’une des méthodes suivantes : -E/--event-time ou -C/--reference-core-file.

Si ni l’un ni l' --event-time Ni --reference-core-file est donné, aucun filtrage de la période n’est effectué : l’heure de référence est par défaut l’heure actuelle et n’est utilisée que pour l’ordre basé sur la proximité lorsqu’une limite de comptage (-m ou -k) est en vigueur (voir la section Limites de comptage ci-dessous).

Si les deux -E et -C apparaît, le dernier élément de la ligne de commande prend effet.

Fenêtre de temps

Lorsqu’une heure de référence est définie (à l’aide de --event-time ou --reference-core-file), une fenêtre temporelle s’établit autour d’elle. Le périmètre de la période peut être défini comme suit : -t/--minutes-before-event et/ou -T/--minutes-after-event, qui sont respectivement de 15 et 5 minutes par défaut. Seuls les fichiers dont le contenu chevauche cette fenêtre peuvent être collectés.

Par exemple : -E "2020-03-20 14:30" -t 10 -T 3 collecte des fichiers couvrant la période de 14:20:00 à 14:33:00.

--minutes-before-event et --minutes-after-event sont ignorés lorsque ni l’un ni l’autre --event-time Ni --reference-core-file est spécifié.

Count Limits

Une limite de nombre de fichiers peut être définie à l’aide de -m/--max-traces et -k/--max-cores, respectivement pour les fichiers journaux et les fichiers noyaux. La limite est mesurée par composant.

Lorsque plus de fichiers que NUM se trouvent dans la période (ou sont disponibles, si aucune fenêtre n’est active), les fichiers NUM les plus proches de l’heure de référence sont collectés.

Lorsqu’une limite de comptage est utilisée sans --event-time ou --reference-core-file, tous les fichiers sont candidats (pas de période) et les fichiers NUM les plus récents sont sélectionnés.

Logique de filtrage

Le filtrage de fichiers s’applique d’abord à la période, puis à la limite de nombre :

1. Établissez des candidats. Tous les fichiers journaux du produit et/ou les fichiers de vidage mémoire d’un composant sont énumérés.
2. Dériver la période de contenu. Le contenu des fichiers journaux du produit représente un point. La période de contenu commence à l’heure de la dernière modification de son prédécesseur (mtime), ou l’époque UNIX, lorsqu’il n’existe pas de prédécesseur ; il se termine à la fin du fichier mtime. Les fichiers de vidage mémoire représentent un point dans le temps, au niveau du fichier mtime.
3. Fenêtre de temps d’application (si -E ou -C spécifié). Les fichiers dont le contenu se trouve entièrement en dehors de la fenêtre sont ignorés de la sélection. Pour les fichiers journaux de produit, si aucun fichier ne se trouve dans la fenêtre, le fichier unique le plus proche de la fenêtre est conservé afin que le lot ne soit jamais vide pour un composant. Pour les fichiers de vidage mémoire, ce type de retour arrière ne s’applique pas.
4. Appliquer la limite de comptage (si -m et/ou -k spécifié). Parmi les autres fichiers, tout au plus NUM sont sélectionnés, en préférant ceux qui se rapprochent le plus de l’heure de référence. Les fichiers antérieurs et postérieurs à l’heure de référence sont en concurrence égale pour la sélection.

AUTHENTIFICATION

L’utilitaire tente de se connecter au MDM local si un processus MDM principal est détecté à l’écoute sur le port attendu (par défaut : 6611)

Les options de connexion MDM sont transmises à la SCLI --login et sont traitées par elle.

Si la connexion échoue, l’utilitaire se termine avec une erreur.

Lorsque la connexion est ignorée, les commandes SCLI sont toujours utilisées (pour prendre en charge les scénarios dans lesquels l’utilisateur s’est connecté manuellement au préalable). Après trois échecs SCLI, un avertissement s’affiche et toutes les autres commandes SCLI sont ignorées.

La connexion est ignorée dans les cas suivants :

• Aucun processus MDM principal n’a été trouvé sur l’hôte local.
• La commande --skip-mdm-login est spécifiée.

La connexion échoue dans les cas suivants :

• Le propriétaire du processus MDM ne figure pas dans la liste des utilisateurs autorisés (par défaut : root) et la connexion sécurisée est activée.
• Le SCLI --login renvoie une erreur (par exemple, des informations d’identification incorrectes).

ESPACE DISQUE

L’espace disque requis pour les fichiers temporaires et l’offre groupée qui en résulte peut varier considérablement.

L’utilitaire tente de minimiser l’utilisation temporaire de l’espace ; Elle se limite aux sorties de commande et aux copies du système de fichiers virtuel collecté (/proc et /sys) dans les fichiers.

L’offre groupée peut être diffusée en continu à partir d’un hôte distant avec --output-file=- pour réduire l’utilisation de l’espace disque sur l’hôte PowerFlex. Le fichier de bundle est écrit directement dans la sortie standard (stdout) lors de la diffusion en continu ; Il n’est pas créé sur le disque.

L’utilitaire estime l’espace disque requis pour le répertoire de travail temporaire et le bundle de sortie avant de collecter les données.

Si l’espace requis estimé dépasse l’espace disponible sur les systèmes de fichiers appropriés, l’utilitaire se termine avec une erreur. Cette vérification peut être contournée avec --skip-space-check.

Le répertoire de travail et le répertoire de sortie peuvent résider sur des systèmes de fichiers différents ; Chacune d’entre elles est vérifiée indépendamment.

L’espace estimé requis est écrit dans le fichier journal de l’utilitaire, get_info_run.log.

ÉTAT DE SORTIE

FICHIERS

ENVIRONNEMENT

Configuration requise

• L’utilitaire doit être exécuté en tant que root (ou un utilisateur disposant de privilèges suffisants pour lire les fichiers de composants, exécuter des commandes de diagnostic et accéder /proc, /sys, et ainsi de suite).
• Utilitaires standard : tar, gzip, stat, find, awk, sed, getopt(1) (amélioré), nice.
• Facultatif : zip (pour --zip), xz (pour --xz), gdb/gcore (pour --generate-cores)

Concurrence

Une seule instance de get_info.sh peut s’exécuter à la fois. L’utilitaire recherche une instance existante en cours d’exécution à l’aide de pidof(1) et s’arrête si une instance est trouvée.

Gestion des signaux

Les traps utilitaires INT, EXITet TERM lors de la collecte des données. À la réception d’un signal, il :

1. Restaure tous les fichiers de configuration sauvegardés (par exemple, les paramètres de génération de cœur).
2. Nettoie les répertoires temporaires
3. Sorties avec l’état 1

Le journal d’exécution est conservé et son chemin d’accès est imprimé sur l’erreur standard.

Exemples

Collecter un bundle de support standard :

get_info.sh

Diffusez un bundle via une connexion SSH, sans créer de fichier de bundle sur l’hôte PowerFlex distant :

ssh <host> 'get_info.sh --output-file=-' > getInfoDump-<host>.tgz

Utilisez un autre répertoire de travail pour éviter de le remplir /tmp:

get_info.sh --work-dir=/var/tmp

Incluez des chemins personnalisés dans l’offre groupée :

get_info.sh --collect-path=/opt/custom/app/logs --collect-path='/var/log/app*'

Collectez le dernier vidage mémoire uniquement pour les composants SDS et MDM :

get_info.sh --collect-cores='mdm sds' --max-cores=1

Collectez des données centrées sur l’heure de modification d’un fichier mémoire, avec une fenêtre de temps personnalisée :

get_info.sh --reference-core-file=/opt/emc/scaleio/sds/bin/core.1000 \
            --minutes-before-event=10 \  
            --minutes-after-event=2