이 섹션의 다중 페이지 출력 화면임. 여기를 클릭하여 프린트.

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 배포 유형	감사 로그 엑세스 메커니즘
자체 관리	10분마다 인스턴스 수준 버킷에 동기화됩니다. API를 사용하여 사용할 수도 있습니다.
전용 클라우드 (보안 스토리지 커넥터 (BYOB))	10분마다 인스턴스 수준 버킷 (BYOB)에 동기화됩니다. API를 사용하여 사용할 수도 있습니다.
W&B 관리 스토리지 (BYOB 없음)가 있는 전용 클라우드	API를 통해서만 사용할 수 있습니다.
SaaS Cloud	Enterprise 요금제에서만 사용할 수 있습니다. API를 통해서만 사용할 수 있습니다.

감사 로그를 가져온 후에는 Pandas, Amazon Redshift, Google BigQuery 또는 Microsoft Fabric과 같은 툴을 사용하여 분석할 수 있습니다. 일부 감사 로그 분석 툴은 JSON을 지원하지 않습니다. 분석 전에 JSON 형식의 감사 로그를 변환하기 위한 지침 및 요구 사항은 분석 툴 설명서를 참조하십시오.

감사 로그 보존

특정 기간 동안 감사 로그를 보존해야 하는 경우 W&B는 스토리지 버킷 또는 감사 로깅 API를 사용하여 장기 스토리지로 로그를 주기적으로 전송하는 것이 좋습니다.

1996년 건강 보험 양도 및 책임에 관한 법률 (HIPAA)의 적용을 받는 경우 감사 로그는 의무 보존 기간이 끝나기 전에 내부 또는 외부 행위자가 삭제하거나 수정할 수 없는 환경에서 최소 6년 동안 보존해야 합니다. BYOB가 있는 HIPAA 규정 준수 전용 클라우드 인스턴스의 경우 장기 보존 스토리지를 포함하여 관리형 스토리지에 대한 가드레일을 구성해야 합니다.

감사 로그 스키마

이 표는 감사 로그 항목에 나타날 수 있는 모든 키를 알파벳순으로 보여줍니다. 작업 및 상황에 따라 특정 로그 항목에는 가능한 필드의 서브셋만 포함될 수 있습니다.

키	정의
`action`	이벤트의 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 또는 팀 ID.
`entity_name`	해당되는 경우, entity 또는 팀 이름.
`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가 아님).
`user_email`	해당되는 경우, 작업이 영향을 미치는 user의 이메일 어드레스 (작업을 수행하는 user의 이메일 어드레스가 아님).

개인 식별 정보 (PII)

이메일 어드레스, project 이름, 팀 및 report와 같은 개인 식별 정보 (PII)는 API 엔드포인트 옵션을 통해서만 사용할 수 있습니다.

자체 관리 및 전용 클라우드의 경우 조직 관리자는 감사 로그를 가져올 때 PII를 제외할 수 있습니다.
SaaS Cloud의 경우 API 엔드포인트는 항상 PII를 포함하여 감사 로그에 대한 관련 필드를 반환합니다. 이는 구성할 수 없습니다.

감사 로그 가져오기

조직 또는 인스턴스 관리자는 audit_logs/ 엔드포인트에서 감사 로깅 API를 사용하여 W&B 인스턴스에 대한 감사 로그를 가져올 수 있습니다.

관리자 이외의 사용자가 감사 로그를 가져오려고 하면 엑세스가 거부되었음을 나타내는 HTTP 403 오류가 발생합니다.
여러 Enterprise SaaS Cloud 조직의 관리자인 경우 감사 로깅 API 요청이 전송되는 조직을 구성해야 합니다. 프로필 이미지를 클릭한 다음 User Settings를 클릭합니다. 설정 이름은 Default API organization입니다.

인스턴스에 적합한 API 엔드포인트를 결정합니다.
- 자체 관리: <wandb-platform-url>/admin/audit_logs
- 전용 클라우드: <wandb-platform-url>/admin/audit_logs
- SaaS Cloud (Enterprise 필요): https://api.wandb.ai/audit_logs
다음 단계에서 <API-endpoint>를 API 엔드포인트로 바꿉니다.
기본 엔드포인트에서 전체 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에 대한 로그만 반환됩니다.
웹 브라우저 또는 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 제외

자체 관리 및 전용 클라우드의 경우 W&B 조직 또는 인스턴스 관리자는 감사 로그를 가져올 때 PII를 제외할 수 있습니다. SaaS Cloud의 경우 API 엔드포인트는 항상 PII를 포함하여 감사 로그에 대한 관련 필드를 반환합니다. 이는 구성할 수 없습니다.

PII를 제외하려면 anonymize=true URL 파라미터를 전달합니다. 예를 들어 W&B 인스턴스 URL이 https://mycompany.wandb.io이고 지난 주 동안의 사용자 활동에 대한 감사 로그를 가져오고 PII를 제외하려면 다음과 같은 API 엔드포인트를 사용합니다.

https://mycompany.wandb.io/admin/audit_logs?numDays=7&anonymize=true.

Actions

이 표는 W&B에서 기록할 수 있는 가능한 actions를 알파벳순으로 설명합니다.

Action	정의
`artifact:create`	Artifact가 생성되었습니다.
`artifact:delete`	Artifact가 삭제되었습니다.
`artifact:read`	Artifact가 읽혔습니다.
`project:delete`	Project가 삭제되었습니다.
`project:read`	Project가 읽혔습니다.
`report:read`	Report가 읽혔습니다. ¹
`run:delete_many`	Run 배치가 삭제되었습니다.
`run:delete`	Run이 삭제되었습니다.
`run:stop`	Run이 중지되었습니다.
`run:undelete_many`	휴지통에서 Run 배치가 복원되었습니다.
`run:update_many`	Run 배치가 업데이트되었습니다.
`run:update`	Run이 업데이트되었습니다.
`sweep:create_agent`	스윕 에이전트가 생성되었습니다.
`team:create_service_account`	팀에 대한 서비스 계정이 생성되었습니다.
`team:create`	팀이 생성되었습니다.
`team:delete`	팀이 삭제되었습니다.
`team:invite_user`	User가 팀에 초대되었습니다.
`team:uninvite`	User 또는 서비스 계정이 팀에서 초대 취소되었습니다.
`user:create_api_key`	User에 대한 API 키가 생성되었습니다. ¹
`user:create`	User가 생성되었습니다. ¹
`user:deactivate`	User가 비활성화되었습니다. ¹
`user:delete_api_key`	User에 대한 API 키가 삭제되었습니다. ¹
`user:initiate_login`	User가 로그인을 시작했습니다. ¹
`user:login`	User가 로그인했습니다. ¹
`user:logout`	User가 로그아웃했습니다. ¹
`user:permanently_delete`	User가 영구적으로 삭제되었습니다. ¹
`user:reactivate`	User가 다시 활성화되었습니다. ¹
`user:read`	User 프로필이 읽혔습니다. ¹
`user:update`	User가 업데이트되었습니다. ¹

1: SaaS Cloud에서 감사 로그는 다음에 대해 수집되지 않습니다.

공개 또는 퍼블릭 프로젝트.
report:read action.
특정 조직에 연결되지 않은 User actions.

2 - Use Prometheus monitoring

W&B Server 와 함께 Prometheus 를 사용하세요. Prometheus 설치는 kubernetes ClusterIP service 로 노출됩니다.

Prometheus 모니터링은 자체 관리 인스턴스 에서만 사용할 수 있습니다.

Prometheus 메트릭 엔드포인트 (/metrics) 에 엑세스하려면 아래 절차를 따르세요.

Kubernetes CLI 툴킷인 kubectl 를 사용하여 클러스터에 연결합니다. 자세한 내용은 Kubernetes 의 클러스터 엑세스 문서를 참조하세요.
다음 코맨드를 사용하여 클러스터의 내부 어드레스를 찾으세요:
```
kubectl describe svc prometheus
```
kubectl exec 를 사용하여 Kubernetes 클러스터에서 실행 중인 컨테이너 내부에서 쉘 세션을 시작합니다. <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 서버를 Slack 과 통합합니다.

W&B 전용 클라우드 배포에서 Slack 알림을 설정하는 방법을 보여주는 비디오 (6분)를 시청하세요.

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 Console 에 있는 경우 Settings 로 이동한 다음 Notifications 로 이동합니다.
- System Settings 에 있는 경우 Enable a custom Slack application to dispatch alerts 를 전환하여 사용자 지정 Slack 애플리케이션을 활성화합니다.
Slack client ID 와 Slack secret 을 제공한 다음 Save 를 클릭합니다. Settings 의 Basic Information 으로 이동하여 애플리케이션의 클라이언트 ID와 secret 을 찾습니다.
W&B 앱에서 Slack 인테그레이션을 설정하여 모든 것이 작동하는지 확인합니다.

4 - View organization dashboard

Organization dashboard는 전용 클라우드 및 자체 관리 인스턴스에서만 사용할 수 있습니다.

W&B의 조직 사용량 보기

조직 대시보드를 사용하여 조직의 W&B 사용량에 대한 전체적인 보기를 얻을 수 있습니다. 대시보드는 탭별로 구성되어 있습니다.

Users: 이름, 이메일, Teams, 역할 및 마지막 활동을 포함하여 각 user에 대한 세부 정보를 나열합니다.
Service accounts: 서비스 계정에 대한 세부 정보를 나열하고 서비스 계정을 만들 수 있습니다.
Activity: 각 user의 활동에 대한 세부 정보를 나열합니다.
Teams: user 수 및 추적 시간을 포함하여 각 team에 대한 세부 정보를 나열하고 관리자가 team에 참여할 수 있도록 합니다.
Billing: 조직의 요금을 요약하고, 결제 Reports를 실행 및 내보낼 수 있으며, 라이선스 만료 시기와 같은 세부 정보를 보여줍니다.
Settings: 개인 정보 보호 및 인증과 관련된 사용자 정의 역할 및 설정을 구성할 수 있습니다.

user 상태 보기

Users 탭에는 모든 user와 각 user에 대한 데이터가 나열되어 있습니다. Last Active 열은 user가 초대를 수락했는지 여부와 user의 현재 상태를 보여줍니다.

Invite pending: 관리자가 초대를 보냈지만 user가 초대를 수락하지 않았습니다.
Active: user가 초대를 수락하고 계정을 만들었습니다.
-: user가 이전에 활성 상태였지만 지난 6개월 동안 활성 상태가 아닙니다.
Deactivated: 관리자가 user의 엑세스를 취소했습니다.

활동별로 user 목록을 정렬하려면 Last Active 열 머리글을 클릭합니다.

조직에서 W&B를 사용하는 방법 보기 및 공유

Users 탭에서 조직에서 W&B를 사용하는 방법에 대한 세부 정보를 CSV 형식으로 볼 수 있습니다.

Invite new user 버튼 옆에 있는 작업 ... 메뉴를 클릭합니다.
Export as CSV를 클릭합니다. 다운로드되는 CSV 파일에는 user 이름 및 이메일 어드레스, 마지막 활동 시간, 역할 등과 같은 조직의 각 user에 대한 세부 정보가 나열됩니다.

user 활동 보기

Users 탭의 Last Active 열을 사용하여 개별 user의 Activity summary를 가져옵니다.

Last Active별로 user 목록을 정렬하려면 열 이름을 클릭합니다.
user의 마지막 활동에 대한 세부 정보를 보려면 user의 Last Active 필드 위에 마우스를 가져갑니다. user가 추가된 시기와 user가 총 며칠 동안 활성 상태였는지 보여주는 툴팁이 나타납니다.

다음과 같은 경우 user는 active 상태입니다.

W&B에 로그인합니다.
W&B App에서 페이지를 봅니다.
Runs를 로그합니다.
SDK를 사용하여 experiment를 추적합니다.
어떤 방식으로든 W&B Server와 상호 작용합니다.

시간 경과에 따른 활성 user 보기

Activity 탭의 플롯을 사용하여 시간 경과에 따라 얼마나 많은 user가 활성 상태였는지에 대한 집계 보기를 얻을 수 있습니다.

Activity 탭을 클릭합니다.
Total active users 플롯은 특정 기간 동안 얼마나 많은 user가 활성 상태였는지 보여줍니다 (기본값은 3개월).
Users active over time 플롯은 특정 기간 동안 활성 user의 변동을 보여줍니다 (기본값은 6개월). 해당 날짜의 user 수를 보려면 포인트 위에 마우스를 가져갑니다.

플롯의 기간을 변경하려면 드롭다운을 사용합니다. 다음을 선택할 수 있습니다.

Last 30 days
Last 3 months
Last 6 months
Last 12 months
All time