Klicken Sie in der oberen rechten Ecke einer beliebigen Seite auf , um auf das Dashboard zuzugreifen.
Lizenzinformationen und Suche
In diesem Abschnitt des Websiteadministrator-Dashboards können Sie Ihre aktuelle GitHub Enterprise-Lizenz überprüfen, nach Benutzern und Repositorys suchen und das Auditprotokoll abfragen.
Managementkonsole
Hier können Sie die Managementkonsole starten, um die Einstellungen der virtuellen Appliance zu verwalten, also beispielsweise die Domain, die Authentifizierung und SSL.
Erkunden
Die Daten für die Seite mit Trends für GitHub wird für Repositorys und Entwickler in täglichen, wöchentlichen und monatlichen Zeiträumen berechnet. Im Abschnitt Erkunden können Sie sehen, wann diese Daten letztmals zwischengespeichert wurden. Zudem können Sie darin neue Aufträge zur Berechnung von Trends in die Warteschlange versetzen.
Auditprotokoll
GitHub Enterprise speichert ein Ablaufprotokoll der überwachten Aktionen, die Sie abfragen können.
Das Auditprotokoll zeigt standardmäßig eine Liste sämtlicher überwachter Aktionen in umgekehrt chronologischer Reihenfolge an. Sie können diese Liste filtern. Geben Sie dazu im Textfeld Query (Abfragen) Schlüsselwertpaare ein, und klicken Sie anschließend auf Search (Suchen), wie dies unter „Auditprotokoll durchsuchen“ erläutert ist.
For more information on audit logging in general, see "Audit logging." For a full list of audited actions, see "Audited actions."
Berichte
Zum Abrufen von Informationen zu Benutzern, Organisationen und Repositorys in Ihre GitHub Enterprise Server-Instanz würden Sie normalerweise über die GitHub-API JSON-Daten abrufen. Leider stellt die API nicht alle gewünschten Daten bereit und erfordert ein gewisses technisches Know-how. Das Websiteadministrator-Dashboard bietet alternativ den Abschnitt Reports (Berichte). In diesem können Sie ohne Weiteres CSV-Berichte mit den meisten Informationen herunterladen, die Sie wahrscheinlich für Benutzer, Organisationen und Repositorys benötigen.
Insbesondere können Sie CSV-Berichte herunterladen, die Folgendes auflisten:
- alle Benutzer
- alle Benutzer, die im letzten Monat aktiv waren
- alle Benutzer, die mindestens für einen Monat inaktiv waren
- alle Benutzer, die gesperrt wurden
- alle Organisationen
- alle Repositorys
Darüber hinaus können Sie mit einem Websiteadministratorkonto über die HTTP-Standardauthentifizierung programmatisch auf diese Berichte zugreifen. Du musst ein persönliches Zugangs-Token mit dem „scope“ (Anwendungsbereich) site_admin verwenden. For more information, see "Creating a personal access token."
So würden Sie beispielsweise den Bericht „all users“ (alle Benutzer) mit der cURL herunterladen:
curl -L -u username:token http(s)://hostname/stafftools/reports/all_users.csvErsetzen Sie für den programmatischen Zugriff auf die anderen Berichte all_users durch active_users, dormant_users, suspended_users, all_organizations oder all_repositories.
Hinweis: Die anfängliche curl-Anforderung gibt eine 202 HTTP-Antwort zurück, wenn keine zwischengespeicherten Berichte verfügbar sind. Im Hintergrund wird ein Bericht generiert. Sie können eine zweite Anforderung senden, um den Bericht herunterzuladen. Sie können ein Passwort oder ein OAuth-Token mit dem Umfang site_admin anstelle eines Passworts verwenden.
Benutzerberichte
| Schlüssel | Beschreibung |
|---|---|
created_at | Zeitpunkt der Benutzerkontoerstellung (als ein ISO 8601-Zeitstempel) |
id | Konto-ID für den Benutzer oder für die Organisation |
login | Anmeldename des Kontos |
E-Mail | Primäre E-Mail-Adresse des Kontos |
Rolle | Gibt an, ob es sich um ein Administrator- oder um ein normales Benutzerkonto handelt |
suspended? | Gibt an, ob das Konto gesperrt wurde |
last_logged_ip | Neueste IP-Adresse für Kontoanmeldung |
repos | Anzahl der dem Konto gehörenden Repositorys |
ssh_keys | Anzahl der für das Konto registrierten SSH-Schlüssel |
org_memberships | Anzahl der Organisationen, zu denen das Konto gehört |
dormant? | Gibt an, ob das Konto inaktiv ist |
last_active | Gibt den Zeitpunkt der letzten Kontoaktivität an (als ein ISO 8601-Zeitstempel) |
raw_login | Unformatierte Anmeldeinformationen (im JSON-Format) |
2fa_enabled? | Gibt an, ob der Benutzer die Zwei-Faktor-Authentifizierung aktiviert hat |
Organisationsberichte
| Schlüssel | Beschreibung |
|---|---|
id | Organisations-ID |
created_at | Zeitpunkt der Organisationserstellung |
login | Anmeldename der Organisation |
E-Mail | Primäre E-Mail-Adresse der Organisation |
owners | Anzahl der Organisationsinhaber |
members | Anzahl der Organisationsmitglieder |
teams | Anzahl der Organisationsteams |
repos | Anzahl der Organisations-Repositorys |
2fa_required? | Gibt an, ob für die Organisation die Zwei-Faktor-Authentifizierung erforderlich ist |
Repository-Berichte
| Schlüssel | Beschreibung |
|---|---|
created_at | Zeitpunkt der Repository-Erstellung |
owner_id | ID des Repository-Inhabers |
owner_type | Gibt an, ob das Repository einem Benutzer oder einer Organisation gehört |
owner_name | Name des Repository-Inhabers |
id | Repository-ID |
name | Repository-Name |
Transparenz/Sichtbarkeit | Gibt an, ob das Repository öffentlich oder privat ist |
readable_size | Größe des Repositorys in einem visuell lesbaren Format |
raw_size | Größe des Repositorys als eine Zahl |
collaborators | Anzahl der Repository-Mitarbeiter |
fork? | Gibt an, ob das Repository ein Fork ist |
deleted? | Gibt an, ob das Repository gelöscht wurde |
Indizierung
Die GitHub-Features zur Codesuche werden von ElasticSearch unterstützt. Dieser Abschnitt des Websiteadministrator-Dashboards zeigt den aktuellen Status Ihres ElasticSearch-Clusters und stellt Ihnen verschiedene Tools bereit, mit denen Sie das Verhalten der Suchvorgänge und Indizierung steuern können. Diese Tools sind in die folgenden drei Kategorien unterteilt.
Codesuche
Dadurch können Sie Such- und Indizierungsvorgänge im Quellcode aktivieren oder deaktivieren.
Reparatur des Codesuche-Index
Dadurch wird gesteuert, wie der Index für die Codesuche repariert wird. Sie können
- Indexreparaturaufträge aktivieren oder deaktivieren,
- einen neuen Indexreparaturauftrag starten,
- den gesamten Indexreparaturzustand zurücksetzen.
GitHub Enterprise verwendet Reparaturaufträge, um den Zustand des Suchindex mit den in einer Datenbank (Issues, Pull Requests, Repositorys und Benutzer) gespeicherten Daten und mit den in Git-Repositorys (Quellcode) gespeicherten Daten abzustimmen. Dies ist der Fall, wenn
- ein neuer Suchindex erstellt wird,
- fehlende Daten abgeglichen oder
- alte Suchdaten aktualisiert werden müssen.
Reparaturaufträge werden demnach nach Bedarf gestartet und im Hintergrund ausgeführt. Sie werden nicht von Websiteadministratoren geplant.
Zudem verwenden Reparaturaufträge einen „Reparaturversatz“ zur Parallelisierung. Dies ist ein Versatz in der Datenbanktabelle für den abzustimmenden Datensatz. Anhand dieses Versatzes können mehrere Hintergrundaufträge die Arbeit synchronisieren.
Eine Fortschrittsanzeige zeigt den aktuellen Status eines Reparaturauftrags auf den gesamten Hintergrund-Workern an. Hierbei handelt es sich um die prozentuale Abweichung des Reparaturversatzes mit der höchsten Datensatz-ID in der Datenbank. Machen Sie sich keine Sorgen hinsichtlich des nach Abschluss eines Reparaturauftrags in der Fortschrittsanzeige angezeigten Werts. Dieser zeigt nämlich den Unterschied zwischen dem Reparaturversatz und der höchsten Datensatz-ID in der Datenbank. Der Wert wird kleiner, wenn mehr Repositorys zu Ihre GitHub Enterprise Server-Instanz hinzugefügt werden, auch wenn diese Repositorys tatsächlich indiziert sind.
Reparaturaufträge des Codesuche-Index können jederzeit gestartet werden. Diese verwenden eine einzelne CPU und stimmen den Suchindex mit den Datenbank- und Git-Repository-Daten ab. Versuchen Sie, einen Reparaturauftrag zunächst außerhalb der Hauptauslastungszeiten durchzuführen, um die Auswirkungen auf die E/A-Leistung zu minimieren und die Wahrscheinlichkeit von Betriebsunterbrechungen zu verringern. Mit einem Dienstprogramm wie top können Sie die durchschnittliche Auslastung und CPU-Auslastung Ihres Systems überwachen. Wenn Sie keine erheblichen Änderungen feststellen, können Sie einen Indexreparaturauftrag auch in Spitzenzeiten ohne Weiteres ausführen.
Indexreparatur für Issues
Dadurch wird gesteuert, wie der Issues-Index repariert wird. Sie können
- Indexreparaturaufträge aktivieren oder deaktivieren,
- einen neuen Indexreparaturauftrag starten,
- den gesamten Indexreparaturzustand zurücksetzen.
Repositorys
Dies ist eine Liste der Repositorys auf Ihre GitHub Enterprise Server-Instanz. Sie können auf einen Repository-Namen klicken und auf Funktionen zum Verwalten des Repositorys zugreifen.
- Erzwungene Push-Vorgänge an ein Repository blockieren
- Git Large File Storage konfigurieren
- Repositorys archivieren und deren Archivierung aufheben
Alle Benutzer
Hier können Sie alle Benutzer auf Ihrer Ihre GitHub Enterprise Server-Instanz anzeigen und eine SSH-Schlüsselüberwachung initiieren.
Websiteadministratoren
Hier können Sie alle Administratoren auf Ihrer Ihre GitHub Enterprise Server-Instanz anzeigen und eine SSH-Schlüsselüberwachung initiieren.
Inaktive Benutzer
Hier können Sie alle inaktiven Benutzer auf Ihre GitHub Enterprise Server-Instanz anzeigen und sperren. In den folgenden Fällen wird ein Benutzerkonto als inaktiv angesehen:
- Es besteht schon länger als die für Ihre GitHub Enterprise Server-Instanz festgelegte Inaktivitätsschwelle.
- Es hat in diesem Zeitraum keine Aktivitäten generiert.
- Es ist kein Websiteadministrator.
Die Inaktivitätsschwelle ist die Zeitspanne welche ein Benutzer inaktiv sein muss um als ruhend betrachtet zu werden. Die Standard-Inaktivitätsschwelle beträgt 90 Tage, Du kannst sie aber für Ihre GitHub Enterprise Server-Instanz anpassen. Weitere Informationen finden Sie unter „Inaktive Benutzer verwalten“.
Gesperrte Benutzer
Hier können Sie alle Benutzer anzeigen, die auf Ihre GitHub Enterprise Server-Instanz gesperrt wurden, und eine SSH-Schlüsselüberwachung initiieren.