これは、このセクションの複数ページの印刷可能なビューです。印刷するには、ここをクリックしてください.

監視と利用状況

1: ユーザーのアクティビティを監査ログで追跡する
2: Prometheus モニタリングを使用する
3: Slack アラートの設定
4: 組織のダッシュボードを表示する

1 - ユーザーのアクティビティを監査ログで追跡する

W&B の監査ログを使用して、組織内のユーザー活動を追跡し、企業のガバナンス要件に準拠します。監査ログは JSON フォーマットで利用可能です。監査ログスキーマを参照してください。

監査ログへのアクセス方法は、W&B プラットフォームのデプロイメントタイプによって異なります:

W&B プラットフォームデプロイメントタイプ	監査ログアクセス機構
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	エンタープライズプランのみで利用可能です。API を使用してのみ利用可能です。

監査ログを取得した後、Pandas、Amazon Redshift、Google BigQuery、Microsoft Fabric などのツールを使用して分析できます。監査ログの分析ツールによっては JSON をサポートしていないものもあります。分析ツールのドキュメントを参照して、分析前に JSON 形式の監査ログを変換するためのガイドラインと要件をご確認ください。

監査ログの保存

特定の期間に渡って監査ログを保存する必要がある場合、W&B はログを長期保存場所に定期的に転送することを推奨しています。ストレージバケットや監査ログ API を使用できます。

Health Insurance Portability and Accountability Act of 1996 (HIPAA) に準拠する必要がある場合、監査ログは最低 6 年間保存され、保存期間が終了するまで内部または外部のいずれのアクターによっても削除または変更できない環境に保存されなければなりません。HIPAA に準拠した Dedicated Cloud インスタンスには、長期保存ストレージを含むマネージドストレージのためのガードレールを設定する必要があります。

監査ログスキーマ

この表は、監査ログエントリに現れる可能性のあるすべてのキーをアルファベット順に示しています。アクションと状況によって、特定のログエントリには、可能なフィールドのサブセットのみが含まれる場合があります。

キー	定義
`action`	イベントのアクション。
`actor_email`	アクションを開始したユーザーのメールアドレス（該当する場合）。
`actor_ip`	アクションを開始したユーザーの IP アドレス。
`actor_user_id`	アクションを実施したログインユーザーの ID（該当する場合）。
`artifact_asset`	アクションに関連するアーティファクト ID（該当する場合）。
`artifact_digest`	アクションに関連するアーティファクトダイジェスト（該当する場合）。
`artifact_qualified_name`	アクションに関連するアーティファクトの完全名（該当する場合）。
`artifact_sequence_asset`	アクションに関連するアーティファクトシーケンス ID（該当する場合）。
`cli_version`	アクションを開始した Python SDK のバージョン（該当する場合）。
`entity_asset`	アクションに関連するエンティティまたはチーム ID（該当する場合）。
`entity_name`	アクションに関連するエンティティまたはチーム名（該当する場合）。
`project_asset`	アクションに関連するプロジェクト（該当する場合）。
`project_name`	アクションに関連するプロジェクトの名前（該当する場合）。
`report_asset`	アクションに関連するレポート ID（該当する場合）。
`report_name`	アクションに関連するレポートの名前（該当する場合）。
`response_code`	アクションの HTTP レスポンスコード（該当する場合）。
`timestamp`	イベントの時間を RFC3339 形式で示します。例えば、`2023-01-23T12:34:56Z` は 2023 年 1 月 23 日 12 時 34 分 56 秒 UTC を示します。
`user_asset`	アクションが影響を与えるユーザーアセット（アクションを実行するユーザーではなく）（該当する場合）。
`user_email`	アクションが影響を与えるユーザーのメールアドレス（アクションを実行するユーザーのメールアドレスではなく）（該当する場合）。

個人を特定できる情報 (PII)

個人を特定できる情報 (PII) は API エンドポイントオプションを使用することによってのみ利用可能です。

Self-managed および Dedicated Cloud では、組織の管理者は監査ログを取得する際に PII を除外できます。
SaaS Cloud では、監査ログの関連フィールドを常に API エンドポイントが返します。PII を含むこれらのフィールドは設定変更できません。

監査ログの取得

W&B インスタンスの監査ログは、Audit Logging API を使用して、組織またはインスタンス管理者が取得できます。そのエンドポイントは audit_logs/ です。

管理者以外のユーザーが監査ログを取得しようとすると、HTTP 403 エラーが発生し、アクセスが拒否されたことが示されます。
複数のエンタープライズ SaaS Cloud 組織の管理者である場合、監査ログ API リクエストが送信される組織を設定する必要があります。プロフィール画像をクリックし、ユーザー設定 をクリックしてください。その設定は デフォルト API 組織 と呼ばれます。

インスタンスに対する正しい API エンドポイントを決定します：
- Self-managed: <wandb-platform-url>/admin/audit_logs
- Dedicated Cloud: <wandb-platform-url>/admin/audit_logs
- SaaS Cloud (エンタープライズ必須): https://api.wandb.ai/audit_logs
次のステップで、<API-endpoint> を実際の API エンドポイントで置き換えてください。
基本エンドポイントから完全な API エンドポイントを構築し、必要に応じて URL パラメータを含めます：
- anonymize: true に設定すると、PII を削除します。デフォルトは false です。監査ログ取得時の PII を除外を参照してください。SaaS Cloud ではサポートされていません。
- numDays: today - numdays から最新のログまで取得されます。デフォルトは 0 で、今日のログのみを返します。SaaS Cloud では過去最大 7 日分の監査ログを取得できます。
- startDate: オプションの日付、YYYY-MM-DD 形式で指定します。 SaaS Cloud でのみサポートされています。
  
  startDate と numDays の相互作用：
  - startDate と numDays の両方を設定すると、startDate から startDate + numDays の範囲でログが返されます。
  - startDate を省略して numDays を含めると、today から numDays までの範囲でログが返されます。
  - startDate と numDays のどちらも設定しないと、今日のログのみが返されます。
Web ブラウザーや Postman、HTTPie、cURL などのツールを使用して、構築した完全修飾 API エンドポイントに対して HTTP GET リクエストを実行します。

API レスポンスには、新しい行で区切られた JSON オブジェクトが含まれます。監査ログがインスタンスレベルのバケットに同期される場合と同じように、そのオブジェクトにはスキーマに記載されたフィールドが含まれます。その場合、監査ログはバケット内の /wandb-audit-logs ディレクトリー内に配置されます。

基本認証を使用する

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 を除外するには、URL パラメータ anonymize=true を渡します。例えば、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:delete`	アーティファクトが削除されます。
`artifact:read`	アーティファクトが読み取られます。
`project:delete`	プロジェクトが削除されます。
`project:read`	プロジェクトが読み取られます。
`report:read`	レポートが読み取られます。 ¹
`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:create`	チームが作成されます。
`team:delete`	チームが削除されます。
`team:invite_user`	ユーザーがチームに招待されます。
`team:uninvite`	ユーザーまたはサービスアカウントがチームから招待取り消されます。
`user:create_api_key`	ユーザーの API キーが作成されます。¹
`user:create`	ユーザーが作成されます。 ¹
`user:deactivate`	ユーザーが無効化されます。¹
`user:delete_api_key`	ユーザーの API キーが削除されます。¹
`user:initiate_login`	ユーザーがログインを開始します。¹
`user:login`	ユーザーがログインします。¹
`user:logout`	ユーザーがログアウトします。¹
`user:permanently_delete`	ユーザーが完全に削除されます。¹
`user:reactivate`	ユーザーが再活性化されます。¹
`user:read`	ユーザーのプロフィールが読み取られます。¹
`user:update`	ユーザーが更新されます。¹

1: SaaS Cloud では、監査ログは次の項目で収集されません:

オープンまたはパブリックプロジェクトの場合。
report:read のアクション。
特定の組織に関連付けられていない User のアクション。

2 - Prometheus モニタリングを使用する

Prometheus を W&B サーバーと一緒に使用します。Prometheus のインストールは Kubernetes ClusterIP サービスとして公開されます。

Prometheus モニタリングはセルフマネージドインスタンスでのみ利用可能です。

以下の手順に従って、Prometheus メトリクスエンドポイント (/metrics) にアクセスします：

Kubernetes CLI ツールキットの kubectl を使用してクラスターに接続します。詳細については、Kubernetes のクラスターへのアクセスドキュメントを参照してください。
クラスターの内部アドレスを見つけます：
```
kubectl describe svc prometheus
```
Kubernetes クラスターで実行中のコンテナ内でシェルセッションを開始し、kubectl exec を使用して、<internal address>/metrics エンドポイントにアクセスします。

以下のコマンドをコピーしてターミナルで実行し、<internal address> を内部アドレスに置き換えます：
```
kubectl exec <internal address>/metrics
```

テストポッドが開始され、ネットワーク内の何かにアクセスするためだけに exec することができます：

kubectl run -it testpod --image=alpine bin/ash --restart=Never --rm

そこから、ネットワークへのアクセスを内部に保つか、kubernetes nodeport サービスで自分で公開するかを選択できます。

3 - Slack アラートの設定

Integrate W&B Server with Slack.

W&B 専用クラウドデプロイメントでの Slack アラートの設定を示したビデオを見る (6 分)。

Slack アプリケーションを作成する

以下の手順に従って Slack アプリケーションを作成してください。

https://api.slack.com/apps にアクセスし、Create an App を選択します。
App Name フィールドにアプリの名前を入力します。
アプリを開発したい Slack ワークスペースを選択します。アラートに使用する予定のワークスペースと同じワークスペースを使用していることを確認してください。

Slack アプリケーションを設定する

左側のサイドバーで OAth & Permissions を選択します。
Scopes セクションで、ボットに incoming_webhook スコープを追加します。スコープは、アプリに開発ワークスペースでのアクションを実行する権限を与えます。

Bot の OAuth スコープについての詳細は、Slack API ドキュメントの「Understanding OAuth scopes for Bots」チュートリアルを参照してください。
W&B インストールを指すようにリダイレクト URL を設定します。ローカルシステム設定で指定されたホスト URL と同じ URL を使用してください。インスタンスへの異なる DNS マッピングを持つ場合は、複数の URL を指定できます。
Save URLs を選択します。
Restrict API Token Usage で、オプションとして W&B インスタンスの IP または IP 範囲を許可リストに指定できます。許可された IP アドレスの制限は、Slack アプリケーションのセキュリティをより強化します。

Slack アプリケーションを W&B に登録する

W&B インスタンスの System Settings または System Console ページに移動します。デプロイメントに応じて異なります。
使用している System ページに応じて、以下のオプションのいずれかを実行します：
- System Console にいる場合: Settings から Notifications に進みます。
- System Settings にいる場合: カスタム Slack アプリケーションを有効にするために Enable a custom Slack application to dispatch alerts をトグルします。
Slack client ID と Slack secret を入力し、Save をクリックします。設定の基本情報でアプリケーションのクライアント ID とシークレットを見つけることができます。
W&B アプリケーションで Slack インテグレーションを設定して、すべてが正常に動作していることを確認します。

4 - 組織のダッシュボードを表示する

組織のダッシュボードは、専用クラウドと自己管理インスタンスでのみ利用可能です。

組織の W&B 使用状況を確認する

組織のダッシュボードを使用して、組織の W&B 使用状況の全体像を把握できます。このダッシュボードはタブごとに整理されています。

Users: 各ユーザーの名前、メール、チーム、役割、最後の活動を含む詳細をリストします。
Service accounts: サービスアカウントに関する詳細をリストし、サービスアカウントを作成することができます。
Activity: 各ユーザーの活動に関する詳細をリストします。
Teams: 各チームのユーザー数や追跡時間を含む詳細をリストし、管理者がチームに参加できるようにします。
Billing: 組織の請求内容を要約し、請求レポートを実行およびエクスポートすることができ、ライセンスの期限などの詳細を示します。
Settings: カスタムロールとプライバシーや認証に関連する設定を構成できます。

ユーザーのステータスを確認する

Users タブには、すべてのユーザーと各ユーザーに関するデータが一覧表示されます。Last Active 列は、ユーザーが招待を受け入れたかどうか、およびユーザーの現在のステータスを示します。

Invite pending: 管理者が招待を送信しましたが、ユーザーが招待を受け入れていない状態。
Active: ユーザーが招待を受け入れ、アカウントを作成した状態。
-: ユーザーは以前にアクティブでしたが、過去6カ月間活動していない状態。
Deactivated: 管理者がユーザーのアクセスを取り消した状態。

アクティビティでユーザーのリストを並べ替えるには、Last Active 列の見出しをクリックします。

組織の W&B 利用方法を確認して共有する

Users タブから、組織の W&B 利用方法の詳細を CSV 形式で確認できます。

Invite new user ボタンの横にあるアクション ... メニューをクリックします。
Export as CSV をクリックします。ダウンロードされた CSV ファイルには、組織の各ユーザーに関する詳細（ユーザー名、メールアドレス、最後のアクティブ時刻、役割など）が記載されています。

ユーザーのアクティビティを確認する

Users タブ内の Last Active 列を使用して、個々のユーザーの Activity summary を取得します。

Last Active でユーザーのリストを並べ替えるには、列名をクリックします。
ユーザーの最後のアクティビティについての詳細を見るには、ユーザーの Last Active フィールドにマウスを重ねます。ツールチップが表示され、ユーザーが追加された日時と、ユーザーがアクティブであった総日数が示されます。

ユーザーが アクティブ であるとは以下の場合を指します:

W&B にログインする。
W&B アプリ内の任意のページを見る。
run をログする。
SDK を使用して実験を追跡する。
W&B サーバーと何らかの方法でやり取りする。

時間経過によるアクティブユーザーの確認

Activity タブのプロットを利用して、時間の経過とともに何人のユーザーがアクティブであったかの総合的なビューを取得できます。

Activity タブをクリックします。
Total active users プロットは、一定期間（デフォルトでは3カ月）におけるアクティブユーザー数を示します。
Users active over time プロットは、一定期間（デフォルトでは6カ月）におけるアクティブユーザー数の変動を示します。ポイントにマウスを重ねると、その日時のユーザー数が表示されます。

プロットの期間を変更するには、ドロップダウンを使用します。次のオプションから選択できます:

過去30日間
過去3カ月
過去6カ月
過去12カ月
すべての時間