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

ダッシュボードへアクセスするには、ページ右上の隅にあるをクリックしてください。

検索

ユーザーとリポジトリの検索、および監査ログのクエリを実行するには、サイト管理者ダッシュボードのこのセクションを参照してください。

[Management Console]

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

探索

GitHub のトレンドページのデータは、リポジトリと開発者の両方において、日単位、週単位、月単位の期間で計算されます。 [探索] セクションで、このデータが最後にいつキャッシュされたのかの確認や、新しいトレンドの計算ジョブをキューに入れることができます。

監査ログ

GitHub Enterprise Server では、クエリで確認できる、監査されたアクションの実行ログが保持されます。

デフォルトでは、Audit log は、監査されたアクション全てを新しい順で表示します。このリストをフィルター処理するには、「エンタープライズの監査ログの検索」で説明されているように、 [クエリ] テキストボックスにキーと値のペアを入力し、 [検索] をクリックします。

一般的な監査ログについて詳しくは、「企業の監査ログについて」をご覧ください。監査されたアクションの完全な一覧については、「エンタープライズの監査ログイベント」をご覧ください。

Reports

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

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

全ユーザ
すべてのアクティブなユーザー
すべての休眠ユーザー
停止されている全ユーザ
全ての Organization
全てのリポジトリ

サイトアドミンのアカウントを用いて標準の HTTP 認証を使用すれば、これらのレポートにプログラムでアクセスすることもできます。 site_admin スコープとともに personal access token を使う必要があります。詳しくは、「個人用アクセストークンの作成」を参照してください。

たとえば、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 の差が示されます。その値は、たとえリポジトリが実際にインデックス付けされていても、お使いの GitHub Enterprise Server インスタンスにリポジトリが追加されるにつれて減少します。

I/O パフォーマンスに与える影響を最小限にするため、および、オペレーションがタイムアウトする可能性を低く抑えるために、混雑していない時間帯に修理ジョブを実行してください。ジョブによって検索インデックスをデータベースおよび Git リポジトリデータと照合して調整する場合、使用される CPU は 1 つです。 top のようなユーティリティを使用して、システムの負荷平均と CPU 使用率を監視します。リソース消費の大幅な増加が示されていない場合は、ピーク時間帯にインデックス修復ジョブを実行しても問題ありません。

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

Code Search

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

予約済みログイン

特定の単語は、お使いの GitHub Enterprise Server インスタンスの内部使用のために予約されています。つまり、これらの単語をユーザー名として使用することはできません。

たとえば、次の単語は予約されています。

admin
enterprise
login
staff
support

完全なリストまたは予約語について確認するには、サイト管理者ダッシュボードの [予約済みログイン] に移動します。

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 の支払いについて詳しくは、「GitHub Advanced Security の課金について」をご覧ください。

全ユーザ

組織、ユーザー、ポリシー、設定を管理するには、サイト管理者ダッシュボードのこのセクションを参照してください。

リポジトリ

これはお使いの GitHub Enterprise Server インスタンス上のリポジトリのリストです。リポジトリ名をクリックしてリポジトリを管理するための機能にアクセスできます。

すべてのユーザー

ここでは、お使いの GitHub Enterprise Server インスタンス上のすべてのユーザーを確認し、SSH キー監査を開始することができます。

サイトアドミン

ここでは、お使いの GitHub Enterprise Server インスタンス上のすべての管理者を確認し、SSH キー監査を開始することができます。

休眠ユーザ

ここでは、お使いの GitHub Enterprise Server インスタンス上のすべての非アクティブなユーザーを確認し、一時停止させることができます。ユーザーアカウントは、次の場合において、非アクティブ ("休眠") と見なされます。

お使いの GitHub Enterprise Server インスタンスで設定されている休眠しきい値よりも長く存在している。
その期間内にどのアクティビティも生成していない。
サイト管理人ではない

休眠の閾値は、休眠と見なされるまでにユーザがアクティブであってはならない期間です。休眠の既定のしきい値は 90 日ですが、お使いの GitHub Enterprise Server インスタンスの休眠しきい値はカスタマイズできます。詳しくは、「休眠ユーザの管理」をご覧ください。

停止されたユーザ

ここでは、お使いの GitHub Enterprise Server インスタンス上の一時停止されたすべてのユーザーを確認し、SSH キー監査を開始することができます。

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

この記事の内容