ダッシュボードにアクセスするには、任意のページの右上隅にある をクリックします。
検索
ユーザーとリポジトリの検索、および監査ログのクエリを実行するには、サイト管理者ダッシュボードのこのセクションを参照してく� さい。
[Management Console]
ここで、ドメインや認証、SSL などの仮想アプライアンスの設定を管理するための [Management Console]を起動することができます。
探索
GitHub のトレンド ページのデータは、リポジトリと開発者の両方において、日単位、週単位、月単位の期間で計算されます。 [探索] セクションで、このデータが最後にいつキャッシュされたのかの確認や、新しいトレンドの計算ジョブをキューに入れることができます。
監査ログ
GitHub Enterprise Server では、クエリで確認できる、監査されたアクションの実行ログが保持されます。
デフォルトでは、Audit log は、監査されたアクション全てを新しい� �で表示します。 このリストをフィルター処理するには、「エンタープライズの監査ログの検索」で説明されているように、 [クエリ] テキスト ボックスにキーと値のペアを入力し、[検索] をクリックします。
一般的な監査ログの詳細については、「エンタープライズの監査ログについて」を参照してく� さい。 監査されたアクションの完全なリストについては、「エンタープライズの監査ログ イベント」を参照してく� さい。
Reports
にある、ユーザー、組織、リポジトリの情� �が必要な� �合、一般的には、GitHub API を使って、JSON データをフェッチします。 残念ながら、API は、必要なデータを提供しない可能性があり、使用するのには専門知識が必要です。 サイト管理者ダッシュボードには代替手段として [レポート] セクションが設けられ、ユーザー、組織、リポジトリに必要と思われるほぼすべての情� �を含ん� CSV レポートを簡単にダウンロードできます。
具体的には、次の情� �を含む CSV � �告をダウンロードできます。
- 全ユーザ
- すべてのアクティブなユーザー
- すべての休� ユーザー
- 停止されている全ユーザ
- 全ての Organization
- 全ての リポジトリ
サイトアドミンのアカウントを用いて標準の HTTP 認証を使用すれば、これらのレポートにプログラ� でアクセスすることもできます。 site_admin スコープで個人用アクセス トークンを使用する必要があります。 詳細については、個人アクセス トークンの作成に関する記事を参照してく� さい。
たとえば、cURL を使用して "all users" レポートをダウンロードする方法は次のとおりです:
curl -L -u username:token http(s)://hostname/stafftools/reports/all_users.csvプログラ� で他のレポートにアクセスするには、all_users を active_users、dormant_users、suspended_users、all_organizations、または all_repositories に置き換えます。
注: キャッシュされたレポートがない� �合、最初の curl 要求では 202 HTTP 応答が返され、レポートはバックグラウンドで生成されます。 もう一度リクエストを送れば、その� �告をダウンロードすることができます。 パスワードを使用するか、パスワードの代わりに、site_admin スコープと併せて OAuth トークンを使用することができます。
ユーザ� �告
| Key | 説明 |
|---|---|
created_at | ユーザアカウントの作成時間（ISO 8601 のタイ� スタンプ） |
id | ユーザまたはOrganization のアカウント ID |
login | アカウントのログイン名 |
email | アカウントのプライマリメールアドレス |
role | アカウントがアドミンか一般ユーザか |
suspended? | アカウントが停止されているか |
last_logged_ip | 最後にアカウントにログインしたときの IP アドレス |
repos | アカウントが所有しているリポジトリの数 |
ssh_keys | アカウントに登録されているSSHキーの数 |
org_memberships | アカウントが所属している Organization の数 |
dormant? | アカウントが休� であるかどうか |
last_active | アカウントが最後にアクティブ� ったとき（ISO 8601 のタイ� スタンプ） |
raw_login | （JSON フォーマットでの）未処理のログイン情� � |
2fa_enabled? | ユーザが二段階認証を有効にしているかどうか |
Organization の� �告
| Key | 説明 |
|---|---|
id | 組織 ID |
created_at | Organization の作成時間 |
login | Organization のログイン名 |
email | Organization のプライマリメールアドレス |
owners | Organizationのオーナーの数 |
members | Organization のメンバーの数 |
teams | Organization のチー� の数 |
repos | Organization のリポジトリの数 |
2fa_required? | Organization が二段階認証を有効にしているかどうか |
リポジトリ の� �告
| Key | 説明 |
|---|---|
created_at | リポジトリの作成時間 |
owner_id | リポジトリのコードオーナーの ID |
owner_type | リポジトリの所有者がユーザか Organization か |
owner_name | リポジトリの所有者の名前 |
id | リポジトリの ID |
name | リポジトリ名です |
visibility | リポジトリが公開かプライベートか |
readable_size | 人間が読める形式のリポジトリのサイズ |
raw_size | 数字でのリポジトリのサイズ |
collaborators | リポジトリのコラボレータの数 |
fork? | リポジトリがフォークであるかどうか |
deleted? | リポジトリが削除されているかどうか |
インデックス作成
GitHub の検索機能には、Elasticsearch が搭載されています。 サイトアドミンのダッシュボードのこのセクションには、Elasticsearch クラスターの現在の状態が表示され、検索とインデックス作成の動作を制御するためにツールがいくつか用意されています。
コード検索の詳細については、「GitHub での情� �の検索」を参照してく� さい。 Elasticsearch の詳細については、Elasticsearch の Web サイトをご覧く� さい。
注: 通常の使用では、サイト管理者は新しいインデックスを作成したり、修復ジョブをスケジュールしたりする必要はありません。 トラブルシューティングやその他のサポート目的で、GitHub Support から修復ジョブの実行を指示される� �合があります。
インデックスの管理
GitHub Enterprise Server では、検索インデックスの状態をインスタンス上のデータと自動的かつ定期的に照合して調整します。
- データベース内の問題、プル要求、リポジトリ、およびユーザー
- ディスク上の Git リポジトリ (ソース コード)
ご利用のインスタンスでは修復ジョブを使用してデータを調整し、次のイベントが発生した� �合にバックグラウンドで修復ジョブをスケジュールします。
- 新規検索インデックスが作成される。
- � 損データを埋め戻ししなければいけない� �合。
- 古い検索データを更新しなければいけない� �合。
新しいインデックスを作成することも、リスト内の既存のインデックスをクリックしてインデックスを管理することもできます。 インデックスに対して次の操作を実行できます。
- インデックスを検索可能にする。
- インデックスを書き込み可能にする。
- インデックスを更新する。
- インデックスを削除する
- インデックスの修復状態をリセットする。
- 新規インデックス修理ジョブを開始する。
- インデックスの修理ジョブを有効または無効にする。
プログレス バーには、背景 worker にまたがる修理ジョブの現在の状態が表示されます。 このバーは、データベースの中の最高レコード ID と修理オフセットでのパーセント差を示します。 修復ジョブが完了したら、プログレス バーに表示される値は無視できます。 プログレス バーには、修復オフセットとデータベース内の最大レコード ID の差が示されます。その値は、たとえリポジトリが実際にインデックス付けされていても、 にリポジトリが追� されるにつれて減少します。
I/O パフォーマンスに与える影響を最小限にするため、および、オペレーションがタイ� アウトする可能性を低く抑えるために、混雑していない時間帯に修理ジョブを実行してく� さい。 ジョブによって検索インデックスをデータベースおよび Git リポジトリ データと照合して調整する� �合、使用される CPU は 1 つです。 top のようなユーティリティを使用して、システ� の� 荷平均と CPU 使用率を監視します。 リソース消費の大幅な増� が示されていない� �合は、ピーク時間帯にインデックス修復ジョブを実行しても問題ありません。
修理ジョブでは、並列化のために "修理オフセット" が使用されます。 これは照合されているレコードのデータベーステーブルへのオフセットです。 このオフセットによって、複数の背景ジョブの作業を同期化できます。
Code Search
これによって、ソースコードに対する検索とインデックスの作業を有効または無効にすることができます。
予約済みログイン
特定の単語は、 の内部使用のために予約されています。つまり、これらの単語をユーザー名として使用することはできません。
たとえば、次の単語は予約されています。
adminenterpriseloginstaffsupport
完全なリストまたは予約語について確認するには、サイト管理者ダッシュボードの [予約済みログイン] に移動します。
Advanced Security コミッター
GitHub Advanced Security のシートを現在使用しているアクティブなコミッターの数を確認できます。また、他の組織やリポジトリに対して GitHub Advanced Security を有効にした� �合に使用される追� のシート数を計算できます。
[現在のアクティブなコミッター数] では、GitHub Advanced Security が有効になっているリポジトリのアクティブなコミッターの数を確認できます。 これは、現在使用されているライセンス シートの数です。
[インスタンス全体の最大コミッター数] では、エンタープライズ内のすべてのリポジトリのアクティブなコミッターの数を確認できます。 これは、エンタープライズ内のすべてのリポジトリに対して GitHub Advanced Security を有効にした� �合に使用されるシートの数です。
[追� の高度なコミッターの計算] では、特定の組織とリポジトリに対して GitHub Advanced Security を有効にした� �合に使用される追� のシートの数を計算できます。 [組織とリポジトリ] で、1 行に 1 つの組織またはリポジトリを含む組織とリポジトリのリストを入力または貼り付けます。
example-org
octo-org/octo-repo
その結果、それらの組織とリポジトリに対して GitHub Advanced Security を有効にした� �合に使用される追� のシートの数が得られます。
Advanced Security の課金について詳しくは、「Advanced Security の課金について」を参照してく� さい。
全ユーザ
組織、ユーザー、ポリシー、設定を管理するには、サイト管理者ダッシュボードのこのセクションを参照してく� さい。
リポジトリ
これは 上のリポジトリのリストです。 リポジトリ名をクリックしてリポジトリを管理するための機能にアクセスできます。
すべてのユーザー
ここでは、 上のすべてのユーザーの確認と、SSH キー監査を開始することができます。
サイトアドミン
ここでは、 上のすべての管理者の確認と、SSH キー監査を開始することができます。
休� ユーザ
ここでは、 上のすべての非アクティブなユーザーを確認でき、一時停止させることができます。 ユーザー アカウントは、次の� �合において、非アクティブ ("休� ") と見なされます。
- で設定されている休� しきい値よりも長く存在している。
- その期間内にどのアクティビティも生成していない。
- サイト管理人ではない
休� の閾値は、休� と見なされるまでにユーザがアクティブであってはならない期間です。 既定の休� のしきい値は 90 日ですが、 の休止のしきい値をカスタマイズできます。 詳細については、「休� ユーザーの管理」を参照してく� さい。
停止されたユーザ
ここでは、 上の一時停止されたすべてのユーザーの確認と、SSH キー監査を開始することができます。