これは、このセクションの複数ページの印刷可能なビューです。 印刷するには、ここをクリックしてください.
Monitoring and usage
- 1: Track user activity with audit logs
- 2: Use Prometheus monitoring
- 3: Configure Slack alerts
- 4: View organization dashboard
1 - Track user activity with audit logs
W&B の監査ログを使用すると、組織内のユーザーアクティビティを追跡し、企業のガバナンス要件に準拠できます。監査ログは JSON 形式で利用できます。監査ログスキーマを参照してください。
監査ログへのアクセス方法は、W&B プラットフォームのデプロイメントタイプによって異なります。
| W&B Platform Deployment type | 監査ログアクセス方法 |
|---|---|
| Self-managed | インスタンスレベルのバケットに10分ごとに同期されます。また、APIを使用しても利用できます。 |
| Dedicated Cloud with secure storage connector (BYOB) | インスタンスレベルのバケット (BYOB) に10分ごとに同期されます。また、APIを使用しても利用できます。 |
| Dedicated Cloud with W&B managed storage (without BYOB) | APIを使用するとのみ利用できます。 |
| SaaS Cloud | Enterprise プランでのみ利用できます。APIを使用するとのみ利用できます。 |
監査ログを取得した後、Pandas、Amazon Redshift、Google BigQuery、または Microsoft Fabric などのツールを使用して分析できます。一部の監査ログ分析ツールは JSON をサポートしていません。分析ツールに関するドキュメントを参照して、分析の前に JSON 形式の監査ログを変換するためのガイドラインと要件を確認してください。
監査ログの保持
監査ログを特定の期間保持する必要がある場合、W&B は、ストレージバケットまたは Audit Logging API を使用して、ログを長期ストレージに定期的に転送することをお勧めします。
Health Insurance Portability and Accountability Act of 1996 (HIPAA) の対象となる場合、監査ログは、義務的な保持期間が終了する前に、内部または外部の行為者によって削除または変更できない環境で、最低 6 年間保持する必要があります。HIPAA 準拠の Dedicated Cloud インスタンス ( BYOB ) の場合、長期保持ストレージを含む、管理対象ストレージのガードレールを構成する必要があります。
監査ログスキーマ
この表は、監査ログエントリに表示される可能性のあるすべてのキーをアルファベット順に示しています。アクションと状況に応じて、特定ログエントリには、可能なフィールドのサブセットのみが含まれる場合があります。
| キー | 定義 |
|---|---|
action |
イベントの アクション。 |
actor_email |
アクションを開始したユーザーのメールアドレス (該当する場合)。 |
actor_ip |
アクションを開始したユーザーの IP アドレス。 |
actor_user_id |
アクションを実行したログインユーザーの ID (該当する場合)。 |
artifact_asset |
アクションに関連付けられた Artifact ID (該当する場合)。 |
artifact_digest |
アクションに関連付けられた Artifact ダイジェスト (該当する場合)。 |
artifact_qualified_name |
アクションに関連付けられた Artifact の完全名 (該当する場合)。 |
artifact_sequence_asset |
アクションに関連付けられた Artifact シーケンス ID (該当する場合)。 |
cli_version |
アクションを開始した Python SDK のバージョン (該当する場合)。 |
entity_asset |
アクションに関連付けられた Entity または Team ID (該当する場合)。 |
entity_name |
Entity または Team 名 (該当する場合)。 |
project_asset |
アクションに関連付けられた Project (該当する場合)。 |
project_name |
アクションに関連付けられた Project の名前 (該当する場合)。 |
report_asset |
アクションに関連付けられた Report ID (該当する場合)。 |
report_name |
アクションに関連付けられた Report の名前 (該当する場合)。 |
response_code |
アクションの HTTP レスポンスコード (該当する場合)。 |
timestamp |
RFC3339 形式でのイベントの時刻。たとえば、2023-01-23T12:34:56Z は、2023 年 1 月 23 日の 12:34:56 UTC を表します。 |
user_asset |
アクションが影響を与える User アセット (アクションを実行するユーザーではなく) (該当する場合)。 |
user_email |
アクションが影響を与える User のメールアドレス (アクションを実行するユーザーのメールアドレスではなく) (該当する場合)。 |
個人情報 (PII)
メールアドレスや Projects、Teams、Reports の名前などの個人情報 (PII) は、API エンドポイントオプションでのみ利用できます。
- Self-managed および Dedicated Cloud の場合、組織管理者は、監査ログの取得時に PII を除外 できます。
- SaaS Cloud の場合、API エンドポイントは常に、PII を含む監査ログの関連フィールドを返します。これは構成できません。
監査ログの取得
組織またはインスタンス管理者は、エンドポイント audit_logs/ で Audit Logging API を使用して、W&B インスタンスの監査ログを取得できます。
-
管理者以外のユーザーが監査ログを取得しようとすると、HTTP
403エラーが発生し、アクセスが拒否されたことを示します。 -
複数の Enterprise SaaS Cloud 組織の管理者である場合は、監査ログ API リクエストの送信先となる組織を構成する必要があります。プロファイル画像をクリックし、[User Settings] をクリックします。設定の名前は [Default API organization] です。
-
インスタンスの正しい API エンドポイントを決定します。
- Self-managed:
<wandb-platform-url>/admin/audit_logs - Dedicated Cloud:
<wandb-platform-url>/admin/audit_logs - SaaS Cloud (Enterprise required):
https://api.wandb.ai/audit_logs
以下の手順では、
<API-endpoint>を API エンドポイントに置き換えます。 - Self-managed:
-
ベースエンドポイントから完全な API エンドポイントを作成し、オプションで URL パラメータを含めます。
-
anonymize:trueに設定すると、PII が削除されます。デフォルトはfalseです。監査ログの取得時に PII を除外 を参照してください。SaaS Cloud ではサポートされていません。 -
numDays: ログはtoday - numdaysから最新のものまで取得されます。デフォルトは0で、todayのログのみが返されます。SaaS Cloud の場合、過去最大 7 日間の監査ログを取得できます。 -
startDate: オプションの日付で、形式はYYYY-MM-DDです。SaaS Cloud でのみサポートされています。startDateとnumDaysは相互に作用します。startDateとnumDaysの両方を設定した場合、ログはstartDateからstartDate+numDaysまで返されます。startDateを省略してnumDaysを含めた場合、ログはtodayからnumDaysまで返されます。startDateもnumDaysも設定しない場合、ログはtodayに対してのみ返されます。
-
-
Web ブラウザーまたは Postman、HTTPie、cURL などのツールを使用して、構築された完全修飾 API エンドポイントに対して HTTP
GETリクエストを実行します。
API レスポンスには、改行で区切られた JSON オブジェクトが含まれています。オブジェクトには、監査ログがインスタンスレベルのバケットに同期される場合と同様に、スキーマ で説明されているフィールドが含まれます。これらの場合、監査ログはバケットの /wandb-audit-logs ディレクトリーにあります。
基本認証の使用
API キーで基本認証を使用して監査ログ API にアクセスするには、HTTP リクエストの Authorization ヘッダーを文字列 Basic の後にスペース、次に username:API-KEY 形式の base-64 エンコードされた文字列に設定します。つまり、ユーザー名と API キーを : 文字で区切られた値に置き換え、その結果を base-64 エンコードします。たとえば、demo:p@55w0rd として認証する場合、ヘッダーは Authorization: Basic ZGVtbzpwQDU1dzByZA== にする必要があります。
監査ログの取得時に PII を除外
Self-managed および Dedicated Cloud の場合、W&B 組織またはインスタンス管理者は、監査ログの取得時に PII を除外できます。SaaS Cloud の場合、API エンドポイントは常に、PII を含む監査ログの関連フィールドを返します。これは構成できません。
PII を除外するには、anonymize=true URL パラメータを渡します。たとえば、W&B インスタンスの URL が https://mycompany.wandb.io で、過去 1 週間のユーザーアクティビティの監査ログを取得し、PII を除外する場合は、次のような API エンドポイントを使用します。
https://mycompany.wandb.io/admin/audit_logs?numDays=7&anonymize=true.
アクション
次の表は、W&B によって記録できるアクションをアルファベット順に説明しています。
| アクション | 定義 |
|---|---|
artifact:create |
Artifact が作成されました。 |
artifact:delete |
Artifact が削除されました。 |
artifact:read |
Artifact が読み取られました。 |
project:delete |
Project が削除されました。 |
project:read |
Project が読み取られました。 |
report:read |
Report が読み取られました。1 |
run:delete_many |
Run のバッチが削除されました。 |
run:delete |
Run が削除されました。 |
run:stop |
Run が停止されました。 |
run:undelete_many |
Run のバッチがゴミ箱から復元されました。 |
run:update_many |
Run のバッチが更新されました。 |
run:update |
Run が更新されました。 |
sweep:create_agent |
sweep agent が作成されました。 |
team:create_service_account |
サービスアカウントが Team に対して作成されました。 |
team:create |
Team が作成されました。 |
team:delete |
Team が削除されました。 |
team:invite_user |
User が Team に招待されました。 |
team:uninvite |
User またはサービスアカウントが Team から招待解除されました。 |
user:create_api_key |
User の APIキー が作成されました。1 |
user:create |
User が作成されました。1 |
user:deactivate |
User が非アクティブ化されました。1 |
user:delete_api_key |
User の APIキー が削除されました。1 |
user:initiate_login |
User がログインを開始しました。1 |
user:login |
User がログインしました。1 |
user:logout |
User がログアウトしました。1 |
user:permanently_delete |
User が完全に削除されました。1 |
user:reactivate |
User が再アクティブ化されました。1 |
user:read |
User プロファイルが読み取られました。1 |
user:update |
User が更新されました。1 |
1: SaaS Cloud では、次の監査ログは収集されません。
- オープンまたはパブリック Projects。
report:readアクション。- 特定の組織に関連付けられていない
Userアクション。
2 - Use Prometheus monitoring
W&B サーバー で Prometheus を使用します。Prometheus のインストールは、kubernetes ClusterIP サービス として公開されます。
Prometheus の メトリクス エンドポイント (/metrics) にアクセスするには、以下の手順に従ってください。
-
Kubernetes CLI ツールキット kubectl で クラスター に接続します。詳細については、Kubernetes の クラスターへのアクセス のドキュメントを参照してください。
-
次の コマンド で、 クラスター の内部 アドレス を見つけます。
kubectl describe svc prometheus -
Kubernetes クラスター で実行されているコンテナ内で、
kubectl execを使用してシェル セッションを開始します。<internal address>/metricsでエンドポイントにアクセスします。以下の コマンド をコピーして ターミナル で実行し、
<internal address>を内部 アドレス に置き換えます。kubectl exec <internal address>/metrics
テスト pod が起動します。これは、ネットワーク内のものにアクセスするためだけに exec できます。
kubectl run -it testpod --image=alpine bin/ash --restart=Never --rm
そこから、ネットワークへの内部 アクセス を維持するか、kubernetes nodeport サービスを使用して自分で公開するかを選択できます。
3 - Configure Slack alerts
W&B Server を Slack と連携させます。
Slack アプリケーションの作成
以下の手順に従って Slack アプリケーションを作成します。
-
https://api.slack.com/apps にアクセスし、Create an App を選択します。
-
App Name フィールドにアプリの名前を入力します。
-
アプリの開発に使用する Slack ワークスペースを選択します。使用する Slack ワークスペースが、アラートに使用するワークスペースと同じであることを確認してください。
Slack アプリケーションの設定
-
左側のサイドバーで、OAth & Permissions を選択します。
-
Scopes セクションで、ボットに incoming_webhook スコープを付与します。スコープは、開発ワークスペースでアクションを実行するための権限をアプリに付与します。
ボットの OAuth スコープの詳細については、Slack API ドキュメントのボットの OAuth スコープの理解に関するチュートリアルを参照してください。
-
リダイレクト URL が W&B インストールを指すように設定します。ホスト URL がローカル システム 設定で設定されている URL と同じ URL を使用します。インスタンスへの DNS マッピングが異なる場合は、複数の URL を指定できます。
-
Save URLs を選択します。
-
オプションで、Restrict API Token Usage で IP 範囲を指定し、W&B インスタンスの IP または IP 範囲を許可リストに登録できます。許可される IP アドレスを制限すると、Slack アプリケーションのセキュリティをさらに強化できます。
W&B への Slack アプリケーションの登録
-
デプロイメントに応じて、W&B インスタンスの System Settings または System Console ページに移動します。
-
表示されている System ページに応じて、以下のいずれかのオプションに従ってください。
-
System Console を使用している場合: Settings に移動し、次に Notifications に移動します。
-
System Settings を使用している場合: Enable a custom Slack application to dispatch alerts を切り替えて、カスタム Slack アプリケーションを有効にします。
-
-
Slack client ID と Slack secret を入力し、Save をクリックします。Settings の Basic Information に移動して、アプリケーションの client ID と secret を確認します。
-
W&B アプリで Slack インテグレーションを設定して、すべてが機能していることを確認します。
4 - View organization dashboard
W&B の組織利用状況の表示
Organization dashboard を使用して、組織の W&B の利用状況を全体的に把握できます。ダッシュボードはタブで構成されています。
- Users: 各 ユーザー の詳細（名前、メールアドレス、Teams、役割、最終アクティビティなど）をリスト表示します。
- Service accounts: サービスアカウントの詳細をリスト表示し、サービスアカウントを作成できます。
- Activity: 各 ユーザー のアクティビティの詳細をリスト表示します。
- Teams: 各 Team の詳細（ユーザー数、追跡時間など）をリスト表示し、管理者が Team に参加できるようにします。
- Billing: 組織の料金を要約し、請求 Reports の実行とエクスポートを可能にし、ライセンスの詳細（有効期限など）を表示します。
- Settings: プライバシーと認証に関連するカスタムロールと設定を構成できます。
ユーザー のステータスの表示
Users タブには、すべての ユーザー と、各 ユーザー に関する データ がリスト表示されます。「最終アクティブ」列には、 ユーザー が招待を承諾したかどうかと、 ユーザー の現在のステータスが表示されます。
- Invite pending: 管理者が招待を送信しましたが、 ユーザー が招待を承諾していません。
- Active: ユーザー が招待を承諾し、アカウントを作成しました。
- -: ユーザー は以前はアクティブでしたが、過去 6 か月間アクティブではありません。
- Deactivated: 管理者が ユーザー のアクセスを取り消しました。
アクティビティで ユーザー のリストを並べ替えるには、[最終アクティブ] 列の見出しをクリックします。
組織が W&B をどのように使用しているかの表示と共有
Users タブから、組織が W&B をどのように使用しているかの詳細を CSV 形式で表示します。
- [新しい ユーザー を招待] ボタンの横にあるアクション
...メニューをクリックします。 - [CSV としてエクスポート] をクリックします。ダウンロードされる CSV ファイルには、組織の各 ユーザー の詳細（ ユーザー 名、メール アドレス、最終アクティブ時間、役割など）がリスト表示されます。
ユーザー アクティビティの表示
Users タブの 最終アクティブ 列を使用して、個々の ユーザー の アクティビティの概要 を取得します。
- 最終アクティブ で ユーザー のリストを並べ替えるには、列名をクリックします。
- ユーザー の最終アクティビティの詳細を表示するには、 ユーザー の 最終アクティブ フィールドにマウスを合わせます。ユーザー が追加された時期と、 ユーザー がアクティブであった合計日数を示すツールチップが表示されます。
ユーザー は、次のいずれかに該当する場合に アクティブ になります。
- W&B にログインする。
- W&B App で任意のページを表示する。
- Runs を ログ する。
- SDK を使用して experiment を追跡する。
- 何らかの方法で W&B Server とやり取りする。
経時的なアクティブ ユーザー の表示
Activity タブのプロットを使用して、経時的にアクティブな ユーザー 数を集計して表示します。
- Activity タブをクリックします。
- アクティブ ユーザー の合計 プロットは、一定期間にアクティブであった ユーザー 数を示します（デフォルトは 3 か月）。
- 経時的なアクティブ ユーザー プロットは、一定期間のアクティブ ユーザー の変動を示します（デフォルトは 6 か月）。ポイントにマウスを合わせると、その日付の ユーザー 数が表示されます。
プロットの期間を変更するには、ドロップダウンを使用します。選択できるオプションは次のとおりです。
- 過去 30 日間
- 過去 3 か月
- 過去 6 か月
- 過去 12 か月
- 全期間