ダッシュボードへアクセスするには、ページ右上の隅にある をクリックしてください。
探索
GitHub のトレンド ページのデータは、リポジトリと開発者の両方において、日単位、週単位、月単位の期間で計算されます。 [探索] セクションで、このデータが最後にいつキャッシュされたのかの確認や、新しいトレンドの計算ジョブをキューに入れることができます。
監査ログ
GitHub Enterprise Server では、クエリで確認できる、監査されたアクションの実行ログが保持されます。
デフォルトでは、Audit log は、監査されたアクション全てを新しい順で表示します。 このリストをフィルター処理するには、「エンタープライズの監査ログの検索」で説明されているように、 [クエリ] テキスト ボックスにキーと値のペアを入力し、 [検索] をクリックします。
一般的な監査ログについて詳しくは、「企業の監査ログについて」をご覧ください。 監査されたアクションの完全な一覧については、「エンタープライズの監査ログ イベント」をご覧ください。
Reports
お使いの GitHub Enterprise Server インスタンス にある、ユーザー、Organization、リポジトリの情報が必要な場合、一般的には、GitHub API を使って、JSON データをフェッチします。 残念ながら、API は、必要なデータを提供しない可能性があり、使用するのには専門知識が必要です。 サイト管理者ダッシュボードには代替手段として [レポート] セクションが設けられ、ユーザー、Organization、リポジトリに必要と思われるほぼすべての情報を含んだ CSV レポートを簡単にダウンロードできます。
具体的には、次の情報を含む CSV 報告をダウンロードできます。
- 全ユーザ
- すべてのアクティブなユーザー
- すべての休眠ユーザー
- 停止されている全ユーザ
- 全ての Organization
- 全ての リポジトリ
サイトアドミンのアカウントを用いて標準の HTTP 認証を使用すれば、これらのレポートにプログラムでアクセスすることもできます。 site_admin スコープとともに personal access token を使う必要があります。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。
たとえば、curl コマンドで "all users" レポートをダウンロードする方法は次のとおりです。
curl --remote-name \
--location \
--user '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 | Organization 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 インスタンス の内部使用のために予約されています。つまり、これらの単語をユーザー名として使用することはできません。
たとえば、次の単語は予約されています。
adminenterpriseloginstaffsupport
完全なリストまたは予約語について確認するには、サイト管理者ダッシュボードの [予約済みログイン] に移動します。
休眠ユーザ
ここでは、お使いの GitHub Enterprise Server インスタンス 上のすべての非アクティブなユーザーを確認し、一時停止させることができます。 詳しくは、「ユーザーのサスペンドとサスペンドの解除」を参照してください。
ユーザー アカウントは、次の場合において、非アクティブ ("休眠") と見なされます。
- お使いの GitHub Enterprise Server インスタンス で設定されている休眠しきい値よりも長く存在している。
- その期間内にどのアクティビティも生成していない。
- サイト管理人ではない
休眠の閾値は、休眠と見なされるまでにユーザがアクティブであってはならない期間です。 休眠の既定のしきい値は 90 日ですが、お使いの GitHub Enterprise Server インスタンス の休眠しきい値はカスタマイズできます。 詳しくは、「休眠ユーザの管理」をご覧ください。
停止されたユーザ
ここでは、お使いの GitHub Enterprise Server インスタンス 上の一時停止されたすべてのユーザーを確認し、SSH キー監査を開始することができます。