サイトアドミンのダッシュボード

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2019-10-16. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise. For help with the upgrade, contact GitHub Enterprise support.

サイトアドミンのダッシュボード

サイトアドミンのダッシュボードには、GitHub Enterprise Server インスタンスインスタンスを管理するのに役立つ多数のツールが備わっています。

ダッシュボードへアクセスするには、ページ右上の隅にあるをクリックしてください。サイトアドミン設定にアクセスするための宇宙船のアイコン

ライセンスの情報と検索

現在の GitHub Enterprise のライセンスを確認する、ユーザとリポジトリを検索する、そして Audit log を照会するには、サイトアドミンのダッシュボードのこのセクションを参照してください。

Management Console

ここで、ドメインや認証、SSL などの仮想アプライアンスの設定を管理するための Management Consoleを起動することができます。

Explorer

GitHub の流行ページのためのデータは、リポジトリとデベロッパーの両方において、日ごと、週ごと、月ごとの期間で計算されます。 Explore のセクションで、このデータが最後にいつキャッシュされたのかの確認や、新規流行計算ジョブをキューに挿入することができます。

Audit log

GitHub Enterpriseは、クエリで確認できる、監査されたアクションのログを保持しています。

デフォルトでは、Audit log は、監査されたアクション全てを新しい順で表示します。 You can filter this list by entering key-value pairs in the Query text box and then clicking Search, as explained in "Searching the audit log."

監査ログ記録全般の詳しい情報については「監査ログ記録」を参照してください。監査済みアクションの全リストについては「監査済みアクション」を参照してください。

報告

GitHub Enterprise Server インスタンスにある、ユーザやOrganization、リポジトリについての情報が必要な場合、一般的には、GitHub API を使って、JSON のデータをフェッチします。残念ながら、API は、必要なデータを提供しない可能性があり、使用するのには専門知識が必要です。サイトアドミンのダッシュボードには代替手段として [Reports] セクションがあり、ユーザー、Organization、およびリポジトリに必要と思われるほぼすべての情報を掲載した CSV レポートを簡単にダウンロードできます。

具体的には、次の情報を含む CSV 報告をダウンロードできます。

全ユーザ
過去一ケ月の間、アクティブだった全ユーザ
過去一ケ月、アクティブでなかった全ユーザ
停止されている全ユーザ
全ての Organization
全てのリポジトリ

サイトアドミンのアカウントを用いて標準の HTTP 認証を使用すれば、これらのレポートにプログラムでアクセスすることもできます。たとえば、cURL を使用して "all users" レポートをダウンロードする方法は次のとおりです:

curl -L -u ユーザ名:password/token 
http(s)://ホスト名/stafftools/reports/all_users.csv

他の報告にプログラムでアクセスするには、 all_users を active_usersや、 dormant_users、suspended_users、all_organizations、all_repositories に置き換えてください。

注：キャッシュされた報告がない場合、最初の curl リクエストは、 202の HTTP レスポンスを返して、報告は背景で生成されます。もう一度リクエストを送れば、その報告をダウンロードすることができます。パスワードの代わりに、site_admin スコープでのパスワードまたはOAuthトークンを使うことができます。

ユーザ報告

キー	説明
`created_at`	ユーザアカウントの作成時間（ISO 8601 のタイムスタンプ）
`id`	ユーザまたはOrganization のアカウント ID
`login`	アカウントのログイン名
`email`	アカウントのプライマリメールアドレス
`ロール`	アカウントがアドミンか一般ユーザか
`suspended?`	アカウントが停止されているか
`last_logged_ip`	最後にアカウントにログインしたときの IP アドレス
`repos`	アカウントが所有しているリポジトリの数
`ssh_keys`	アカウントに登録されているSSHキーの数
`org_memberships`	アカウントが所属している Organization の数
`dormant?`	アカウントが休眠であるかどうか
`last_active`	アカウントが最後にアクティブだったとき（ISO 8601 のタイムスタンプ）
`raw_login`	（JSON フォーマットでの）未処理のログイン情報
`2fa_enabled?`	ユーザが二段階認証を有効にしているかどうか

Organization の報告

キー	説明
`id`	Organization の ID
`created_at`	Organization の作成時間
`login`	Organization のログイン名
`email`	Organization のプライマリメールアドレス
`owners`	Organizationのオーナーの数
`members`	Organization のメンバーの数
`teams`	Organization のチームの数
`repos`	Organization のリポジトリの数
`2fa_required?`	Organization が二段階認証を有効にしているかどうか

リポジトリの報告

キー	説明
`created_at`	リポジトリの作成時間
`owner_id`	リポジトリのコードオーナーの ID
`owner_type`	リポジトリの所有者がユーザか Organization か
`owner_name`	リポジトリの所有者の名前
`id`	リポジトリの ID
`name`	リポジトリの名前
`visibility`	リポジトリが公開かプライベートか
`readable_size`	人間が読める形式のリポジトリのサイズ
`raw_size`	数字でのリポジトリのサイズ
`collaborators`	リポジトリのコラボレータの数
`fork?`	リポジトリがフォークであるかどうか
`deleted?`	リポジトリが削除されているかどうか

インデックス化

GitHub のコード検索フィーチャは、Elasticsearch に駆動されています。サイトアドミンのダッシュボードのこのセクションには、ElasticSearch クラスターの現在のステータスが表示され、検索とインデックス作成の動作を制御するためのいくつかのツールが用意されています。このツールは、次の3つのカテゴリーに分類されています。

コード検索

これによって、ソースコードに対する検索とインデックスの作業を有効または無効にすることができます。

コード検索インデックスの修復

これはコード検索インデックスがどのように修復されるかを制御します。次のことができます:

インデックスの修理ジョブを有効または無効にする
新規インデックス修理ジョブを開始する
インデックス修理状態を全てリセットする

GitHub Enterpriseは、修理ジョブを使って、検索インデックスの状態をデータベースで保存されているデータ（Issueやプルリクエスト、リポジトリ、ユーザ）と Git リポジトリに保存されているデータ（ソースコード）を照合することができます。これは次の場合に使用されます。

新規検索インデックスが作成される
欠損データを埋め戻ししなければいけない場合
古い検索データを更新しなければいけない場合

すなわち、修理ジョブは、必要に応じて開始され、背景で作動しています。サイトアドミンが修理ジョブの開始時間を決めるわけではありません。

さらに、修理ジョブは、並列化のために"修理オフセット"を使っています。これは照合されているレコードのデータベーステーブルへのオフセットです。このオフセットによって、複数の背景ジョブの作業を同期化できます。

プログレスバーは、全ての背景ワーカープロセスによる、現在の修理ステータスを表示します。それは、データベースの中の最高レコード ID と修理オフセットでのパーセント差です。修復ジョブが完了した後にプログレスバーに表示される値については心配しないでください。それは修復オフセットとデータベース内の最大レコード ID の差を示すものであるため、たとえリポジトリが実際にインデックス付けされていても、GitHub Enterprise Server インスタンスにリポジトリが追加されるにつれて値は減少します。

いつでも新規コード検索インデックスの修理ジョブを開始できます。 1つの CPU を使って、検索インデックスをデータベース及びGitのリポジトリデータと照合します。 I/O パフォーマンスに与える影響を最小限にするため、および、オペレーションがタイムアウトする可能性を減少するために混雑していない時間帯に修理ジョブを実行してみてください。 top のようなユーティリティで、システム負荷と CPU 使用率の平均を監視しましょう。大差がない場合は、混雑している時間帯にもインデックスの修理ジョブを実行しても安全なはずです。