Analysieren des Git-Datenverkehrs auf Ihrer GitHub Enterprise Server Instanz

Über Gouverneur

Gouverneur ist ein integrierter Monitor für Git-Aktivitäten in Ihrer Instanz. Verwenden Sie den ghe-governor Befehl, um zu sehen, welche Repositorys, Benutzer, IP-Adressen und Git-Vorgänge Ladevorgänge erstellen.

Verwenden Sie diese Daten, wenn die CPU-, Arbeitsspeicher- oder Datenträgerauslastung zunimmt, und Sie müssen bestätigen, ob Git-Datenverkehr die Ursache ist. Informationen zu Befehlssyntax und Unterbefehlen finden Sie unter Befehlszeilenwerkzeuge.

Governor zeichnet nur Git-Vorgänge auf. Es enthält keine API oder Webdatenverkehr. Informationen zum Überprüfen der derzeit ausgeführten Vorgänge finden Sie ghe-btop im Hilfsprogramm in Befehlszeilenwerkzeuge.

Informationen zu Gouverneursdatendateien

Governor speichert seine Daten in Dateien unter /data/user/governor/. Jede Datei enthält eine Stunde Daten und wird für zwei Wochen aufbewahrt. Die Dateinamen enthalten Unix-Zeitstempel, die den Zeitraum der einzelnen Dateien angeben.

Um den Datenbereich zu bestätigen, der aktuell auf dem Datenträger gespeichert ist, konvertieren Sie die Zeitstempel in den frühesten und neuesten Dateinamen in lesbare Daten.

for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done

Die Ausgabe zeigt die Startzeit der frühesten und neuesten Datendateien an.

1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019

Bevor du anfängst

Bevor Sie Gouverneursabfragen ausführen, sammeln Sie diese Informationen:

• SSH-Zugriff auf die Appliance. Sie benötigen Zugriff auf die Verwaltungsshell, um sie auszuführen ghe-governor. Siehe Auf die Verwaltungsshell (SSH) zugreifen.
• Welcher Knoten abfragt werden soll. Starten Sie für eigenständige oder hochverfügbarkeitsbasierte Bereitstellungen auf dem primären Knoten. Führen Sie für Cluster Abfragen für jeden git-server Knoten aus, da kein einzelner Knoten den gesamten Git-Datenverkehr enthält.
• Das Auswirkungsfenster. Beachten Sie die Anfangs- und Endzeiten der gemeldeten Beeinträchtigung, damit Sie Abfragen mit -t und .-u
• Repository- oder Organisationsnamen, wenn Benutzer Probleme mit bestimmten Repositorys oder Organisationen gemeldet haben.

Ermitteln, ob Git zum Laden beiträgt

Beginnen Sie mit einer allgemeinen Zusammenfassung, und laden Sie dann attributen zu bestimmten Repositorys oder Programmen.

• Fassen Sie alle letzten Git-Aktivitäten in Ihrer Instanz zusammen:

  ghe-governor health
  

• Suchen Sie Repositorys mit der langsamsten durchschnittliche Antwortzeit:

  ghe-governor aggregate repo avg_rt
  

• Suchen sie Repositorys mit dem längsten einzelnen Vorgang:

  ghe-governor aggregate repo max_rt
  

• Ermitteln der langsamsten einzelnen Vorgänge (nicht gruppiert):

  ghe-governor top rt -n 50
  

• Suchen Sie die Repositorys, die die meiste CPU-Zeit verbrauchen:

  ghe-governor aggregate repo cpu
  

• Für ein Repository, das hervorsticht, finden Sie, welches Git-Unterprogramm für die CPU-Auslastung verantwortlich ist:

  ghe-governor aggregate program cpu -r OWNER/REPOSITORY
  

• Suchen Sie die Repositorys, in denen pack-objects die CPU-Zeit am meisten verbraucht wurde. Das pack-objects Programm fasst Daten zusammen, die während Klonen und Abrufen an Clients gesendet werden. Eine hohe Anzahl stellt einen erheblichen CPU- und Arbeitsspeicherdruck auf die Appliance fest:

  ghe-governor aggregate repo cpu -P pack-objects
  

• Suchen Sie die einzelnen Vorgänge, die die meiste CPU-Zeit verwendet haben (nicht gruppiert):

  ghe-governor top cpu -n 50
  

• Suchen Sie die Repositorys, die die meisten Datenträgerschreibvorgänge während eines bestimmten Zeitintervalls steuern:

  ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME
  

• Überprüfen Sie auf hohe Parallelität, was angibt, dass viele Git-Vorgänge gleichzeitig ausgeführt werden:

  ghe-governor aggregate repo max_parallelism
  

Wenn die Ergebnisse auf ein bestimmtes Repository oder Programm verweisen, fahren Sie mit dem entsprechenden Abschnitt unten fort.

Identifizieren des häufigsten Klons und Abrufen von Datenverkehr

Das upload-pack Programm verarbeitet Daten, die clients während Klonen und Abrufen bereitgestellt werden. Verwenden Sie diese Abfragen, um zu ermitteln, welche Repositorys, Benutzer und IP-Adressen die meisten Klon- und Abrufaktivitäten steuern.

• Zählen von Klon- und Abrufvorgängen nach Repository:

  ghe-governor aggregate repo count -P upload-pack
  

• Identifizieren Sie Benutzer, die Klonen ausführen, und rufen Sie ihre Vorgänge ab, und zählen Sie ihre Vorgänge:

  ghe-governor aggregate user_id count -P upload-pack
  

• Identifizieren Sie die IP-Adressen, die die meisten Klon- und Abrufanforderungen generieren. Eine kleine Gruppe von IP-Adressen mit hoher Anzahl weist häufig auf eine CI-Läuferflotte hin:

  ghe-governor aggregate ip count -P upload-pack
  

• Messen Sie das Gesamtvolumen der pro Repository bereitgestellten Daten:

  ghe-governor aggregate repo uploaded_kb -P upload-pack
  

• Messen Sie das durchschnittliche Datenvolumen, das pro Benutzer hochgeladen wurde:

  ghe-governor aggregate user_id avg_uploaded -P upload-pack
  

• Suchen Sie spitzen Klon und Abrufen der Parallelität pro Repository. In der MAXPL Spalte wird die höchste Anzahl gleichzeitiger Vorgänge angezeigt, die für jedes Repository aufgezeichnet werden. Ein hoher Wert für eine kleine Anzahl von Repositorys schlägt vor:

  ghe-governor aggregate repo max_parallelism -P upload-pack
  

• Suchen sie nach den größten einzelnen Klon- oder Abrufvorgängen (nicht gruppiert):

  ghe-governor top uploaded -P upload-pack -n 50
  

Identifizieren von pushlastigem Datenverkehr

Die receive-pack Programme spokes-receive-pack verarbeiten Daten, die von Clients während pushes empfangen werden. Verwenden Sie diese Abfragen, um zu ermitteln, welche Repositorys, Benutzer und IP-Adressen die meisten Pushaktivitäten generieren.

• Zählen von Pushvorgängen nach Repository:

  ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack
  

• Identifizieren Sie Benutzer, die an eine Organisation pushen, und zählen Sie ihre Pushvorgänge:

  ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack
  

• Messen Sie das Gesamtvolumen der empfangenen Daten pro Repository:

  ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack
  

• Identifizieren Sie IP-Adressen, die die meisten Pushdaten senden:

  ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack
  

• Suchen sie nach den größten einzelnen Pushvorgängen (nicht gruppiert):

  ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50
  

Einschränken der Analyse

Sie können einer oder ghe-governor aggregate einem ghe-governor top Befehl eine beliebige Kombination der folgenden Optionen hinzufügen, um die Abfrage auf ein bestimmtes Zeitfenster, Repository, Besitzer oder Programm zu konzentrieren.

Zeitfilter

Option	Description
-t <timespec>	Erwägen Sie nur Vorgänge seit einer bestimmten Startzeit. Der Standardwert ist vor 48 Stunden.
-u <timespec>	Erwägen Sie nur Vorgänge bis zu einer bestimmten Endzeit. Der Standardwert ist die aktuelle Uhrzeit.

Die folgenden Formate werden für <timespec>.

Format	Example	Bedeutung
Unix-Zeitstempel	-t 1371614483	Sekunden seit dem 1. Januar 1970
Java Zeitstempel	-t 1371614483637	Millisekunden seit dem 1. Januar 1970
Relative Tage	-t 1d	Der letzte Tag
Relative Stunden	-t 2h	Die letzten zwei Stunden
Relative Minuten	-t 20m	Die letzten zwanzig Minuten

Bereichsfilter

Option	Description
-r <owner>/<repository>	Erwägen Sie nur Vorgänge, die einem bestimmten Besitzer und Repository entsprechen. Geben Sie diese Option mehrmals an, um mehreren Repositorys zu entsprechen.
-o <owner>	Erwägen Sie nur Vorgänge, die einem bestimmten Besitzer entsprechen, z. B. einem Benutzer oder einer Organisation. Geben Sie diese Option mehrmals an, um mehreren Besitzern zu entsprechen.
-P <program>	Erwägen Sie nur Vorgänge, die ein bestimmtes Git-Unterprogramm ausgeführt haben, z upload-pack. B. , , receive-pack, rev-listoder pack-objects. Geben Sie diese Option mehrmals an, um mehreren Programmen zu entsprechen.
-I <address>	Erwägen Sie nur Vorgänge aus einer bestimmten IP-Adresse. Geben Sie diese Option mehrmals an, um mehrere Adressen abzugleichen.

Ausgabeoptionen

Option	Description
-j	Legen Sie das Ausgabeformat auf JSON anstelle einer ASCII-Tabelle fest.
-n <N>	Beschränken Sie die Ausgabe auf N-Datensätze. Der Standardwert ist 20 für aggregierte Abfragen und 200 für top-Abfragen.
--count-only	Nur die KEY Spalten anzeigen COUNT . Gilt nur für aggregierte Abfragen.

Interpretieren von Ergebnisspalten

Die folgenden Abkürzungen werden in ghe-governor Ergebnistabellen angezeigt.

Column	Bedeutung
AVG RT	Durchschnittliche Zeit in Sekunden, die Git-Aufrufe dauerten
MAX RT	Laufzeit in Sekunden des längsten Aufrufs pro Host
MAXPL / AVGPL	Maximale und durchschnittliche Parallelität: Wie viele Git-Aufrufe gleichzeitig ausstehen
CPU/SEC	Sekunden der CPU-Zeit, die von Git pro Sekunde der Wanduhrzeit verwendet wird. Dividieren Sie die Anzahl der CPU-Kerne, und multiplizieren Sie sie mit 100, um den gitspezifischen CPU-Prozentsatz zu erhalten. Dieser Wert darf die Anzahl der CPU-Kerne nicht überschreiten.
UPL	Daten, die der Server auf Clients hochgeladen hat, z. B. während der Abrufe und Klonen
RECV	Daten, die der Server von Clients empfangen hat, z. B. während pushes

Die READSpalten , WRITEund UPLdie RECV Spalten werden in Gigabyte (GB) gemeldet, und die entsprechende Rate wird in Megabyte pro Sekunde (MB/s) gemeldet.

Interpretieren allgemeiner Muster

Die folgende Tabelle ordnet allgemeine Ausgabemuster von Gouverneuren ihren wahrscheinlichen Ursachen zu.

Pattern	Wahrscheinliche Ursache
Hohe upload-pack Anzahl aus einer kleinen Gruppe von IP-Adressen	Eine CI-Runner-Flotte wird wiederholt ein oder mehrere Repositorys klonen, anstatt lokale Auscheckvorgänge wiederzuverwenden
Hoch max_parallelism für eine kleine Anzahl von Repositorys	Donnernde Herd: Viele Läufer lösen gleichzeitig gleichzeitig Klonen aus, oft weil geplante Aufträge gleichzeitig beginnen
Groß uploaded_kb pro Repository kombiniert mit hoher avg_uploaded Anzahl pro Benutzer	Wiederholte vollständige Klonen; Clients verwenden keine lokalen Auscheckvorgänge oder verwenden keine flachen oder teilweisen Klonen
Hoch received_kb für ein Repository oder eine Organisation	Pushintensive Arbeitsauslastung; kann große Binärdateien oder häufige Commits zu einem Monorepo umfassen
Hohe pack-objects CPU mit moderater Betriebsanzahl	Teure Objektverpackung; Das Repository kann von einer Wartungsausführung oder von der clientseitigen Verwendung teilweiser Klonen mit --filter
Hoch avg_rt oder max_rt für ein Repository	Langsame Vorgänge; häufig durch große pack-objects Läufe, hohe Parallelität oder Ressourcenkonflikt von einer anderen Workload verursacht

Empfohlene Aktionen für git load reduction

Wenn Gouverneursdaten zeigen, dass ein Repository, ein Benutzer oder eine Läuferflotte übermäßige Auslastung erzeugt, können die folgenden Aktionen die Auswirkungen verringern.

• Lokale Auscheckvorgänge wiederverwenden. Ersetzen Sie frische Klonen durch git fetch automatisierte Workflows. Dadurch wird die Übertragung des vollständigen Objektdiagramms bei jeder Ausführung vermieden.
• Verwenden Sie flache Klonen. Übergeben Sie --depth bei Workflows, die keinen vollständigen Commit-Verlauf erfordern, an den Klonbefehl, z git clone --depth 1. B. . Dies reduziert sowohl die übertragenen Daten als auch die Arbeit pack-objects .
• Verwenden Sie partielle Klonen. Verwenden Sie --filter für Repositorys mit großen binärobjekten oder vielen Dateien, die in einem bestimmten Workflow nicht benötigt werden, um nur die Objekte anzufordern, die der Workflow benötigt, z git clone --filter=blob:none. B. . .
• Fügen Sie einen lokalen Spiegel- oder Zwischenspeicherungsproxy hinzu. Bei großen Läuferflotten, die dieselben Repositorys wiederholt klonen, kann ein Pull-Through-Proxy oder ein lokaler Spiegel den Abrufdatenverkehr aufnehmen und die Auslastung Ihrer Instanz verringern.
• Gestaffelte geplante Aufträge. Offset CI/CD-Workflows werden nach einem Zeitplan ausgelöst, sodass nicht alle Läufer gleichzeitig beginnen, wodurch die Größe von gleichzeitigen Klon-Platzen reduziert wird.
• Reduzieren Sie die Workflow-Parallelität. Workflows, die mehrere Repositorys parallel klonen, können so konfiguriert werden, dass die Parallelität begrenzt und die Last im Laufe der Zeit verteilt wird.

Wann wenden Sie sich an GitHub den Support?

Wenden Sie sich an GitHub Enterprise-Support ein Supportpaket, wenn eine der folgenden Bedingungen zutrifft.

• Die Leistung bleibt nach dem Reduzieren des Klondrucks oder der gestaffelten geplanten Aufträge beeinträchtigt.
• Ihre Instanz bedient weit verbreitete Git-Fehler oder Verbindungsfehler, die nicht von der Clientauslastung erläutert werden.
• Gouverneur zeigt persistente max_parallelism Werte an, die darauf hindeuten, dass die Instanz in der Nähe der Kapazität liegt, und Arbeitsauslastungsänderungen allein sind unwahrscheinlich, dass das Problem behoben werden kann.
• Sie sehen ein klares Muster in der Ausgabe des Gouverneurs, sind aber unsicher, wie sie interpretiert werden oder welche Maßnahmen ergriffen werden sollen.

Weitere Informationen zum Generieren eines Supportpakets finden Sie unter Bereitstellen von Daten für GitHub Support.

Weiterführende Lektüre

Weitere Informationen zur Überwachung von Systemressourcen finden Sie unter Informationen zu den Monitordashboards.