Oracle Cloud Infrastructure-Dokumentation

Verwenden des Support-Bundles-Tools

Das support-bundles-Tool sammelt verschiedene Arten von Bundles oder Modi von Private Cloud Appliance-Diagnosedaten wie den Health-Check-Status, die Befehlsausgaben und Logs.

Je nach den bereitgestellten Befehlsoptionen können diese Bundles Logs oder Status enthalten. Alle Modi sammeln Dateien in einem Bundle-Verzeichnis. Es ist nicht mehr als ein Support-Bundle-Prozess gleichzeitig zulässig. Eine Support-Bundle-Sperrdatei wird am Anfang der Bundle-Sammlung erstellt und entfernt, wenn die Bundle-Sammlung abgeschlossen ist.

Alle support-bundles-Befehle werden sofort zurückgegeben, und die Bundle-Sammlung wird im Hintergrund ausgeführt. Dies liegt daran, dass Bundle-Collections möglicherweise Stunden in Anspruch nehmen. Bundles werden zwei Tage lang gespeichert und dann automatisch gelöscht.

Die folgenden Bundles werden unterstützt:

  • Triagemodus. Erfasst Daten zum aktuellen Status der Private Cloud Appliance.

  • Zeitsegmentmodus. Sammelt Daten nach Zeitfenstern. Diese Ergebnisse können weiter eingegrenzt werden, indem Podname, Job und Label k8s_app angegeben werden.

  • Kombinationsmodus. Erfasst eine Kombination aus Triage- und Zeitsegmentdaten.

  • Nativer Modus. Erfasst Daten von Verwaltungs-, Rechen- und ZFS-Knoten sowie von ILOM- und Cisco-Hosts.

Eine gute Möglichkeit, ein Problem zu untersuchen, besteht darin, ein combo-Bundle zu erfassen. Suchen Sie in den Ergebnissen des triage-Modus nach NOT_HEALTHY, und vergleichen Sie diese mit den Ergebnissen des time_slice-Modus.

Für den Befehl support-bundles ist eine Modusoption erforderlich. Alle Modi akzeptieren die Option für die Serviceanfragenummer. Informationen hierzu finden Sie in der folgenden Tabelle. Für Zeitabschnitte und native Modi stehen zusätzliche Optionen zur Verfügung.

Option

Beschreibung

Erforderlich

-m mode

Der Bundle-Typ.

ja

-sr SR_number

--sr_number SR_number

Die Serviceanfrage-Nummer.

nein

Die Befehlsausgabe support-bundles wird im folgenden Verzeichnis auf dem Managementknoten gespeichert, wobei bundle-type der Modus ist: triage, time_slice, combo oder native:

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

Die SR_number wird verwendet, wenn Sie die Option -sr angegeben haben. Wenn Sie das Support-Bundle für eine Serviceanfrage erstellen, geben Sie die SR_number an.

Dieses Verzeichnis enthält eine Fortschrittsdatei für die Bundle-Sammlung und eine Archivdatei, die wie folgt benannt sind:

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

Die Archivdatei enthält eine Datei header.json mit den folgenden Standardkomponenten:

  • current-time - der Zeitstempel

  • create-support-bundle: Die verwendete Befehlszeile

  • sr-number: Die mit der Archivdatei verknüpfte SA-Nummer

Beim Managementknoten anmelden

Um den Befehl support-bundles zu verwenden, melden Sie sich als root beim Managementknoten an, auf dem Pacemaker-Ressourcen ausgeführt werden. Erfassen Sie Daten zuerst vom Verwaltungsknoten, auf dem Pacemaker-Ressourcen ausgeführt werden, und dann bei Bedarf von anderen Verwaltungsknoten.

Wenn Sie nicht wissen, welcher Managementknoten Pacemaker-Ressourcen ausführt, melden Sie sich bei einem beliebigen Managementknoten an, und prüfen Sie den Pacemaker-Clusterstatus. Der folgende Befehl zeigt die Pacemaker-Clusterressourcen, die auf pcamn01 ausgeführt werden.

[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

Triagemodus

Im Modus triage wird Prometheus platform_health_check sowohl für den Status HEALTHY als auch für den Status NOT_HEALTHY abgefragt. Wenn NOT_HEALTHY gefunden wird, verwenden Sie den Modus time_slice, um weitere Details abzurufen.

# support-bundles -m triage

Die folgenden Dateien befinden sich in der Ausgabearchivdatei.

Datei

Beschreibung

header.json

Zeitstempel und Befehlszeile zum Generieren dieses Bundles.

compute_node_info.json

Pods, die im Compute Node ausgeführt werden.

hardware_info.json

Die Hardwarekomponentenliste wurde aus hms abgerufen. Alle ipmitool fru, die auf allen verfügbaren Statusverwaltungs- und Compute Nodes ausgeführt werden, enthält alle zfssa-Informationen.

management_node_info.json

Pods, die im Managementknoten ausgeführt werden.

rack_info.json

Rackinstallation und Build-Version.

loki_search_results.log.n

Chunk-Dateien in json.

Zeitsegmentmodus

Im Zeitsegmentmodus werden Daten durch Angabe von Start- und Endzeitstempeln erfasst. Beide der folgenden Optionen sind erforderlich:

  • -s start_date

  • -e end_date

Der Zeitsegmentmodus hat neben den Optionen für den Modus und die Serviceanfragenummer die folgenden Optionen. Mit diesen Optionen können Sie die Datenerfassung eingrenzen. Wenn Sie weder die Option -j noch die Option --all angeben, werden Daten aus allen Health Checker-Jobs erfasst.

  • Es darf nur einer der folgenden Werte angegeben werden: --job_name, --all und --k8s_app.

  • Wenn keine der Optionen --job_name, --all oder --k8s_app angegeben ist, erfolgt die Podfilterung auf dem Standard (.+checker).

  • Die Option --all kann eine große Datenmenge erfassen. Möglicherweise möchten Sie Ihren Zeitabschnitt auf 48 Stunden beschränken.

Beispiel:

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

Siehe weitere Beispiele unten.

Option

Beschreibung

Erforderlich

-s timestamp

--start_date timestamp

Startdatum im Format yyyy-mmm-ddTHH:mm:ss

Das minimale Argument ist yyyy-mmm-dd

ja

-e timestamp

--end_date timestamp

Enddatum im Format yyyy-mmm-ddTHH:mm:ss

Das minimale Argument ist yyyy-mmm-dd

ja

-j job_name

--job_name job_name

Loki-Jobname. Standardwert: .+checker

Siehe Etikettenlistenabfrage unten.

nein
--k8s_app label

Der Labelwert k8s_app, der im Job k8s-stdout-logs abgefragt werden soll.

Siehe Etikettenlistenabfrage unten.

 nein
--all Fragt alle Jobnamen ab, mit Ausnahme von Jobs, die für zu viel Logging bekannt sind, wie audit, kubernetes-audit, und vault-audit und k8s_app Label pcacoredns. nein

-l level

--levelname level

Meldungsebene

nein

--pod_name pod_name

Der Podname (wie kube oder network-checker), um die Ausgabe basierend auf dem Pod zu filtern. Es sind nur die Anfangsbuchstaben notwendig.

nein

-t timeout

--timeout timeout

Timeout in Sekunden für eine einzelne Loki-Abfrage. Standardmäßig sind es 180 Sekunden.

nein
Labellistenabfrage

Verwenden Sie die Labellistenabfrage, um die verfügbaren Jobnamen und k8s_app-Labelwerte aufzulisten.

# 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']

Beispiele:

  • Kein Joblabel, kein k8s_app-Label, Log aus allen Health Checkern erfassen.

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

  • Ein Job Ceui.

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

  • Eine k8s_app-Netzwerkprüfung.

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

  • Alle Tätigkeiten und Datum.

    # 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"`

  • Alle Jobs.

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

Die folgenden Dateien befinden sich in der Ausgabearchivdatei.

Datei

Beschreibung

header.json

Zeitstempel und Befehlszeile zum Generieren dieses Bundles.

loki_search_results.log.n

Chunk-Dateien in json. Zeitsegment-Bundles sind von der Startzeit an auf 500.000 Logs pro Abfrage begrenzt.

rack_info.json

Rackinstallation und Build-Version.

Kombinationsmodus

Der Modus combo ist eine Kombination aus einem Triage-Bundle und einem Zeitsegment-Bundle. Die Ausgabe enthält eine Archivdatei und zwei Collection Log-Dateien: triage_collection.log und time_slice_collection.log.

Die folgenden Dateien befinden sich in der Ausgabearchivdatei.

Datei

Beschreibung

triage-bundle_timestamp.tar.gz

Die Triage Bundle-Archivdatei.

time_slice-bundle_timestamp.tar.gz

Die Archivdatei für das Zeitsegment-Bundle.

Die erfassten Zeitsegmentdaten gelten für --all-Jobs von einer Stunde vor der aktuellen Zeit bis zur aktuellen Zeit.

Nativer Modus

Die Datei native_collection.log im Bundle-Verzeichnis enthält Informationen zum Erfassungsfortschritt. Native Bundles können Stunden in Anspruch nehmen.

Der Modus native enthält zusätzlich zu Modus- und SA-Nummer die folgenden Parameter.

Parameter

Beschreibung

Erforderlich

-t nativetype

--type nativetype

  • zfs_bundle

  • sosreport

  • ilom_snapshot

  • cisco_bundle

Standardwert: zfs_bundle

nein

-c component

--component component

Komponentenname, wie der Name eines Verwaltungs-, Compute-, ZFS- oder ILOM- oder Cisco-Hosts.

nein

Die folgenden Dateien befinden sich in der Ausgabearchivdatei.

Datei

Beschreibung

header.json

Zeitstempel und Befehlszeile zum Generieren dieses Bundles.

Native Bundle-Dateien

Diese Dateien sind spezifisch für die angegebene nativetype.

rack_info.json

Rackinstallation und Build-Version.
ZFS-Bundle

Wenn nativetype ein ZFS-Support-Bundle ist, beginnt die Erfassung auf beiden ZFS-Knoten und lädt die neuen ZFS-Support-Bundles in das Bundle-Verzeichnis herunter. Wenn nativetype nicht angegeben wird, wird zfs_bundle standardmäßig erstellt.

# support-bundles -m native -t zfs_bundle
SOS-Berichtspaket

Wenn nativetype ein SOS-Berichts-Bundle ist, wird der Bericht vom Managementknoten oder Compute Node erfasst, der durch den Parameter --component angegeben wird. Wenn --component nicht angegeben ist, wird der Bericht von allen Management- und Compute Nodes erfasst.

# support-bundles -m native -t sosreport -c pcamn01
ILOM-Snapshot

Wenn nativeType=ilom_snapshot lautet, ist der Wert des Parameters --component der ILOM-Hostname eines Verwaltungsknotens oder Compute Nodes. Wenn der Parameter --component nicht angegeben ist, wird der Bericht von allen ILOM-Hosts erfasst.

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

Wenn nativetype cisco-bundle ist, ist der Wert des Parameters --component ein interner Cisco-Management-, Aggregations- oder Access Switch-Managementhostname.

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

Um einen Collection-Typ cisco-bundle zu erstellen, müssen die folgenden Bedingungen erfüllt sein:

  • Das Cisco OBFL-Modul muss auf allen Private Cloud Appliance Cisco Switches aktiviert sein. Das Cisco OBFL-Modul ist standardmäßig auf allen Private Cloud Appliance Cisco Switches aktiviert.

  • Das Cisco EEM-Modul muss auf allen Private Cloud Appliance Cisco Switches aktiviert sein. Das Cisco EEM-Modul ist standardmäßig auf allen Private Cloud Appliance Cisco Switches aktiviert.

  • EEM-Policy (Embedded Event Manager)