.service-now.com`.
+4. ServiceNow 인스턴스에 대한 사용자 이름과 비밀번호를 추가합니다.
+
+**참고**: ServiceNow에서 Datadog만을 위한 제한된 사용자를 만들 수 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-configuration-new-instance-12-23.png" alt="ServiceNow 통합 새 인스턴스" >}}
+
+## CMDB 설정
+
+### Datadog용 서비스 그래프 연결기
+
+[관측 가능성을 위한 서비스 그래프 연결기 - Datadog][3]는 Datadog에서 발견한 새로운 리소스에 대해 자동으로 CMDB[4]에서 서버와 데이터베이스 설정 항목(CI)을 자동으로 입력할 수 있도록 해줍니다. 서비스 그래프 연결기는 ServiceNow [스토어][4]를 통해 사용할 수 있습니다[4].
+
+설정을 위해 서비스 그래프 연결기의 가이드 설정 지침을 따릅니다.
+
+지원되는 CI 유형:
+
+- 서버
+- Amazon RDS
+
+아래 알림은 ServiceNow ITOM/ITSM에 대한 통합을 이미 설정한 경우에만 적용됩니다.
+
+- 서비스 그래프 연결기는 설정 타일에서 `Target table` 및 `Custom table` 값을 사용하지 않습니다. 대상 테이블 기본 값을 통해 통합을 저장할 수 있습니다.
+- 서비스 그래프 연결기에 안내된 설정 지침에 따라 `cmdb_import_api_admin` 역할을 이 사용자에게 부여하여 동일한 ITOM/ITSM 사용자를 서비스 그래프 연결기를 위해 사용할 수 있습니다.
+
+### CI 필드 커스터마이즈
+
+[Datadog ServiceNow][2] 통합 타일에서 **서비스 그래프 연결기** 탭을 클릭한 다음 **CI 필드 커스터마이즈** 섹션을 확장합니다. 다음 옵션을 사용할 수 있습니다.
+
+CI 유형
+: 이 필드가 적용되는 CI 유형입니다.
+
+ServiceNow Field
+: 적용할 ServiceNow의 필드입니다.
+
+Datadogtag
+: Datadog 리소스에서 전송할 태그입니다(동일한 이름의 여러 태그가 존재하는 경우 쉼표로 구분됩니다.).
+
+예를 들어 `Host` CI 유형을 CI 필드와 ServiceNow 필드 `Host Name`를 추가하려면 모든 _호스트_ 태그 속성을 `Datadogtag` 필드를 추가합니다.
+
+**참고**: `Datadogtag` 필드는 Datadog 호스트에서 존재하는 _호스트_태그여야 하며 호스트 속성 태그가_아니어야_ 합니다.
+
+{{< img src="integrations/servicenow/servicenow_integration_tile.png" alt="서비스 그래프 연결기 탭을 표시하는 ServiceNow 통합 타일의 스크린샷" >}}
+
+### 호스트 태깅
+
+호스트 태깅을 통해 ServiceNow CMDB 메타데이터를 통해 Datadog 호스트를 강화합니다.
+
+호스트 태그 수집을 활성화하려면,
+
+1. Datadog에서 태깅하려는 모든 호스트를 반환하는 ServiceNow 인스턴스의 [쿼리 빌더][5] 쿼리를 설정합니다.
+1. 쿼리를 예약하여 원하는 새로고침 간격으로 실행합니다.
+1. 쿼리가 ServiceNow에 저장되면 Datadog의 ServiceNow 통합 타일로 이동합니다. **CMDB 강화** 탭에서 **호스트 태깅**을 선택합니다.
+1. **쿼리 설정**에서 **새 쿼리 추가** 버튼을 클릭합니다.
+1. 드롭다운 메뉴에서 **ServiceNow 인스턴스** 및 **쿼리**를 선택합니다.
+1. 쿼리 루트의 CI 호스트 이름 필드를 Datadog의 호스트 이름 필드에 매핑하는 **호스트 이름 열**의 값을 선택합니다.
+1. **열 이름 맵**을 사용하여 선택 필드 이름 리매핑을 선택합니다.
+1. **저장**을 클릭합니다.
+
+쿼리 예약 실행 직후 Datadog에 호스트 태그가 채워질 것으로 보입니다.
+
+{{< img src="integrations/servicenow/host-tags.jpg" alt="ServiceNow 호스트 태그를 보여주는 호스트 정보 탭의 스크린샷" >}}
+
+`source:servicenow`에서 검색 쿼리 범위를 지정하여 Datadog [이벤트 탐색기][6]에서 수집 프로세스를 모니터링합니다.
+
+{{< img src="integrations/servicenow/ingestion-progress.jpg" alt="수집을 실행하는 항목을 보여주는 스크린샷" >}}
+
+#### 호스트 태깅 트러블슈팅
+
+호스트 태깅이 올바르게 작동하려면 다음 항목이 시스템에서 참인지 확인하세요.
+
+- 쿼리 빌더 쿼리를 만들고 생성하는 사용자가 Datadog 설정의 사용자 이름과 일치합니다. ServiceNow의 사용자는 `cmdb_query_builder_read` 역할이어야 합니다.
+- 쿼리에서 반환되는 결과 수는 ServiceNow의 `glide.cmdb.query.max_results_limit` 설정보다 작거나 같아야 합니다. 기본적으로 최대 결과 수는 10000개입니다. 설정을 변경하려면 **설정** -> **CMDB 속성** -> **쿼리 빌더 속성**으로 이동하세요.
+- 쿼리 빌더 쿼리에 구성된 모든 CI에는 **1** 레이블이 있어야 합니다. 이렇게 하면 파서가 지원하지 않는 중복된 CI를 만들지 않았는지 확인할 수 있습니다.
+
+#### 한계
+
+- 수집은 실행별 10만 개 호스트로 제한됩니다.
+- 호스트에 대한 업데이트는 시간당 몇 천 건으로 제한됩니다. 일정 간격을 선택할 때 이 제한을 고려하세요.
+- 태깅은 Datadog 호스트 별칭은 대소문자를 구분하므로 소문자 호스트 이름을 가진 Linux 시스템에서는 작동하지 않습니다.
+
+### 서비스 태깅
+
+서비스 태깅을 통해 ServiceNow CMDB 메타데이터로 Datadog 서비스 카탈로그를 강화하세요.
+
+서비스 태깅을 사용하여 Datadog [서비스 카탈로그][7]를 ServiceNow CMDB의 서비스로 채울 수 있습니다.
+
+#### 설정
+
+서비스 데이터 수집을 활성화하려면,
+
+1. 서비스 카탈로그에서 보강하려는 모든 서비스를 반환하는 [쿼리 빌더][5] 쿼리를 ServiceNow 인스턴스에서 설정합니다.
+1. 원하는 새로 고침 간격에 실행되도록 쿼리 예약을 설정합니다.
+1. 쿼리가 ServiceNow에 저장되면 Datadog의 ServiceNow 통합 타일로 이동합니다. **CMDB 강화** 탭 에서 **서비스 태깅**을 선택합니다.
+1. **쿼리 설정**에서 **새 쿼리 추가** 버튼을 클릭합니다.
+1. 드롭다운 메뉴에서 **ServiceNow 인스턴스** 및 **쿼리**를 선택합니다.
+1. **서비스 이름 열** 드롭다운 메뉴에서 값을 선택합니다. 이 값은 쿼리의 루트 서비스 CI의 열 이름과 일치하며 서비스 카탈로그의 서비스 이름을 채웁니다.
+1. 스키마 매핑을 설정하여 서비스에 대한 추가 메타데이터를 서비스 카탈로그로 풀링할 수 있습니다. 자세한 내용은 [서비스 정의][8]를 참조하세요. Datadog에서 수집을 허용하려면 매핑의 각 필드가 서비스 카탈로그 서비스 정의 스키마에 매핑할 수 있는 올바른 유형이어야 합니다.
+1. **저장**을 클릭합니다.
+
+쿼리' 예약 실행 후 몇 분 후에 Datadog에 서비스 데이터가 채워질 것으로 예상됩니다. 수집 오류를 보려면 [이벤트 탐색기][6]로 이동하고 이벤트의 경우 검색에서 `source:servicenow`로 이동하세요.
+
+{{< img src="integrations/servicenow/service-metadata.jpg" alt="ServiceNow에서 채워진 메타데이터를 보여주는 서비스 설정 패널 스크린샷" >}}
+
+#### 설정 트러블슈팅
+
+서비스 수집이 올바르게 작동하려면 시스템에서 다음 항목이 참인지 확인하세요.
+
+- 쿼리 빌더 쿼리를 만들고 실행하는 사용자는 Datadog 설정의 사용자 이름과 일치해야 합니다. ServiceNow 사용자는 `cmdb_query_builder_read` 역할이 있어야 합니다.
+- 쿼리에서 반환되는 결과 수는 ServiceNow의 `glide.cmdb.query.max_results_limit` 설정보다 작거나 같아야 합니다. 기본적으로 최대 결과 수는 10000개입니다. 설정을 변경하려면 **설정** -> **CMDB 속성** -> **쿼리 빌더 속성**으로 이동하세요.
+- 쿼리 빌더 쿼리에 구성된 모든 CI에는 **1** 레이블이 있어야 합니다. 이렇게 하면 파서가 지원하지 않는 중복된 CI를 만들지 않았는지 확인할 수 있습니다.
+
+### 네트워크 장치 태깅
+
+ServiceNow CMDB의 데이터로 채워진 Datadog에서 네트워크 장치에 태그를 추가합니다.
+
+장치 태깅을 사용하면 ServiceNow CMDB의 장치 메타데이터로 Datadog [네트워크 장치 모니터링][9]에서 모니터링하는 네트워크 장치를 동적으로 보강할 수 있습니다.
+
+장치 태그 수집을 활성화하려면,
+
+1. ServiceNow 인스턴스에서 [쿼리 빌더][5] 쿼리를 설정합니다. 장치 IP 주소를 반환하는지 확인합니다.
+1. 원하는 새로 고침 간격에 실행되도록 쿼리 예약을 설정합니다.
+1. Datadog에서 커스텀 IP 네임스페이스를 사용하는 경우 ServiceNow에 추가해야 합니다. 네트워크 장치 CI에 **u_dd_device_namespace**라는 열을 만들고 각 장치에 해당하는 네임스페이스로 채웁니다. 이 열이 없는 경우 기본값 네임스페이스가 사용됩니다.
+1. 쿼리가 ServiceNow에 저장되면 Datadog의 ServiceNow 통합 타일로 이동합니다. **CMDB 강화** 탭에서 **장치 태깅**을 선택합니다.
+1. **쿼리 설정**에서 **새 쿼리 추가** 버튼을 클릭합니다.
+1. 드롭다운 메뉴에서 **ServiceNow 인스턴스** 및 **쿼리**를 선택합니다.
+1. 쿼리의 IP 주소 필드를 Datadog의 IP 주소 필드에 매핑하는 IP 주소 열을 선택합니다.
+1. 선택 필드 이름 리매핑을 선택합니다.
+1. **저장**을 클릭합니다.
+
+쿼리 예약 실행 후 몇 분 이내에 Datadog에 네트워크 장치 태그가 채워질 것으로 예상할 수 있습니다. 모든 수집 오류는 이벤트 탐색기에서 볼 수 있는 이벤트를 통해 보고됩니다.
+
+`source:servicenow`에서 검색 쿼리 범위를 지정하여 Datadog [이벤트 탐색기][6]에서 수집 프로세스를 모니터링합니다.
+
+{{< img src="integrations/servicenow/ingestion-progress.jpg" alt="수집을 실행하는 항목을 표시하는 스크린샷" >}}
+
+#### 네트워크 장치 태깅 트러블슈팅
+
+- 쿼리 빌더 쿼리를 만들었거나 실행 중인 사용자가 Datadog 설정에서 동일한 사용자이고 역할이 `cmdb_query_builder_read`인지 확인합니다.
+- 쿼리가 ServiceNow `glide.cmdb.query.max_results_limit` 설정에서 허용되는 것보다 더 많은 결과를 반환하지 않는지 확인합니다.
+ 쿼리 빌더 쿼리에 설정된 모든 CI에 '1' 레이블이 있는지 확인합니다. 파서가 중복된 CI를 지원하지 않으므로 중복된 CI를 만들지 않았는지 확인하세요.
+
+#### 한계
+
+- 수집은 실행당 10만 호스트로 제한됩니다.
+- 네트워크 장치 태깅은 [SNMP 장치][10]로 제한됩니다.
+- 장치에 대한 업데이트는 시간당 수천 건으로 제한됩니다. 일정 간격을 선택할 때 이 점을 고려하세요.
+
+### 참조표
+
+[참조 테이블][11]을 사용하여 ServiceNow CI의 추가 필드로 로그와 이벤트를 보강합니다. 참조 테이블을 사용하면 값 필드 집합을 호스트 이름과 같은 기본 키에 매핑하고 지정된 키가 포함된 모든 로그 또는 이벤트에 이러한 필드를 자동으로 추가할 수 있습니다.
+
+참조 테이블 수집을 활성화하려면,
+
+1. ServiceNow 인스턴스에서 [쿼리 빌더][12] 쿼리를 설정합니다.
+1. 쿼리를 원하는 새로 고침 간격으로 실행하도록 예약합니다.
+1. 쿼리를 저장합니다.
+1. **새 쿼리 추가**를 선택하고 드롭다운 메뉴에서 쿼리를 선택합니다.
+1. 기본 키 드롭다운에서 기본 키로 사용할 열 이름을 선택합니다.
+ 1. 선택적으로 이 기본 키로 [처리 파이프라인][13]을 생성하여 로그와 이벤트를 보강하고 연계합니다.
+1. 참조 테이블의 이름을 입력합니다.
+1. **저장**을 클릭합니다.
+
+[참조 테이블][11]은 저장 직후 쿼리 데이터로 채워집니다.
+
+#### 주의 사항 및 제한 사항
+
+- 참조 테이블 이름은 고유해야 합니다.
+- 기존 테이블의 삭제 및 스키마 업데이트는 지원되지 않습니다.
+
+## ITOM 및 ITSM 설정
+
+{{% site-region region="gov,ap1" %}}
+
+
+사례 관리 통합은 {{< region-param key=dd_datacenter code="true" >}} 사이트에서 지원되지 않습니다.
+
+{{% /site-region %}}
+
+{{% site-region region="gov" %}}
+
+인시던트 관리 통합은 {{< region-param key=dd_datacenter code="true" >}} 사이트에서 지원되지 않습니다.
+
+{{% /site-region %}}
+
+{{% site-region region="gov" %}}
+
+
+
+서식화된 모니터 알림은 {{< region-param key=dd_datacenter code="true" >}} 사이트에서 지원되지 않습니다.
+
+{{% /site-region %}}
+
+모니터, 사례 관리 및 인시던트 관리에 Datadog 통합을 사용하려면 다음 단계를 따르세요:
+
+1. [앱 설치하기](#install-the-app)
+2. [Datadog]에 대한 올바른 권한으로 ServiceNow 계정 만들기](#create-a-servicenow-account-with-correct-permissions-for-Datadog)
+3. [ ITOM 및 ITSM과 함께 사용하기 위한 Datadog 애플리케이션 설정](#configure-datadog-applications-for-use-with-itom-and-itsm-modules)
+
+### 앱 설치
+
+앱은 두 가지 방법으로 설치할 수 있습니다.
+
+1. ServiceNow 스토어에서 `ITOM/ITSM Integration for Datadog` 앱 최신 버전을 설치합니다.
+
+{{< img src="integrations/servicenow/servicenow-appstore-itxm-integration.png" alt="ServiceNow 앱 스토어 ITSM/ITOM 통합" >}}
+
+2. 최신 업데이트 세트를 다운로드합니다. [`Datadog-Snow_Update_Set_v2.6.1.xml`][14]를 다운로드하여 ServiceNow 인스턴스에 수동으로 업로드합니다.
+
+**변경 로그**
+
+- v2.4.0 >= 사례 관리를 통한 단방향 동기화를 제공합니다.
+- v2.5.0 >= 인시던스 관리와의 통합을 위한 사례 관리와 ITSM 테이블을 통한 양방향 동기화, 또한 케이스 관리를 통한 양방향 동기화는 ServiceNow ITSM에서만 지원됩니다.
+- v2.6.0 >= ITOM/ITSM을 통해 서식화된 모니터 알림을 제공합니다.
+
+ServiceNow에서 업데이트 세트 설치하기:
+
+1. 다운로드한 업데이트 세트 XML 파일을 ServiceNow 인스턴스로 수동으로 가져옵니다.
+2. XML 파일을 가져오면 업데이트 집합에 `Loaded` 상태가 표시되어야 합니다. 업데이트 집합의 이름을 클릭하여 변경 사항을 미리 봅니다.
+3. 업데이트 세트를 미리 보고 오류가 없는지 확인했으면 **업데이트 세트 커밋**을 선택하여 애플리케이션을 시스템에 병합합니다.
+
+앱을 설치한 후 ServiceNow 탐색 메뉴에서 검색 **Datadog**를 클릭하여 모든 테이블과 양방향 동기화 설정을 위한 설정 페이지에 액세스합니다.
+
+- `Configuration`
+- `Datadog Incidents ITSM`
+- `Cases ITOM`, 이전 `Datadog Cases ITOM`
+- `Cases ITSM`, 이전 `Datadog Cases ITSM`
+- `Legacy Monitors ITOM`, 이전 `Datadog Monitors ITOM`
+- `Legacy Monitors ITSM`, 이전 `Datadog Monitors ITSM`
+- `Templated Monitors ITOM`
+- `Templated Monitors ITSM`
+
+### Datadog에 대한 올바른 권한이 있는 ServiceNow 계정을 만듭니다.
+
+통합을 사용하려면 ServiceNow 사용자(예: 사용자 이름 "Datadog" 또는 "datadog_통합")를 만들고 다음 역할을 모두 할당하세요.
+
+- `x_datad_datadog.user` 및
+- `import_set_loader` 및
+- `import_transformer`
+
+#### 인시던트 해결 및 종결
+
+사례 관리와의 양방향 동기화는 ServiceNow ITSM에 대해서만 지원됩니다.
+
+해결을 위해 인시던트 상태를 동기화하려면 ServiceNow 사용자에게 다음 역할 중 하나가 필요합니다.
+
+- `ITIL` 또는
+- `list_updater` 또는
+- `sn_incident_write`
+
+종료 시 인시던트 상태를 동기화하려면 ServiceNow 사용자에게 다음과 같은 역할이 필요합니다.
+
+- `ITIL_admin`
+
+#### 인시던트 및 이벤트 테이블에 직접 모니터 알림 전송
+
+알림 을 ITOM 모듈 **이벤트** 테이블 또는 ITSM 모듈 **인시던트** 테이블로 직접 전송히려면 ServiceNow 사용자에게 다음 역할 중 하나가 필요합니다.
+
+- ITSM을 위한 `ITIL`
+- ITOM을 위한 `evt_mgmt_integration`
+
+**참고**: 이 ServiceNow 사용자("Datadog" 또는 "datadog_통합")가 ServiceNow에서 티켓에 수동으로 업데이트한 내용은 Datadog에 동기화되지 않습니다.
+
+### 서식화된 모니터 알림
+
+**참고**: 이 기능을 사용하려면 앱 버전 >= v2.6.0이 필요합니다. 또한 아래 단계를 완료하기 전에 Datadog에서 ServiceNow 타일의 설정 페이지에 인스턴스를 추가해야 합니다.
+
+##### 인스턴스 우선순위 매핑 설정
+
+{{< img src="integrations/servicenow/servicenow-priority-mapping.png" alt="통합 타일에서 ServiceNow 우선순위 매핑" >}}
+
+특정 인스턴스에 서식화된 모든 @-핸들에 대해 이제 이 매핑에 따라 Datadog가 ServiceNow의 영향과 긴급성에 따른 모니터 우선순위 모니터링 매핑을 실행합니다.
+
+`Use Instance Priority Mapping`을 끄면 ServiceNow 레코드에 대한 영향 및 긴급성 설정이 비활성화됩니다.
+
+#### 모니터 템플릿 설정
+
+{{< img src="integrations/servicenow/servicenow-integration-tile.png" alt="새 ServiceNow 통합 타일" >}}
+
+Datadog에서 `@servicenow-`을 사용하는 모니터 알림의 경우, ServiceNow 통합 타일 에서 Datadog의 ITOM/ITSM 탭에서 새 템플릿 생성 UI를 사용하여 ServiceNow 알림을 생성합니다.
+
+**참고**: 이 기능은 앱 버전이 2.6.0 이상인 경우에만 사용할 수 있습니다.
+
+##### 모니터 알림에 대한 커스텀 ServiceNow @핸들을 만듭니다.
+
+{{< img src="integrations/servicenow/servicenow-monitors.png" alt="새 ServiceNow 통합 타일의 모니터 알림 지침" >}}
+
+1. `+ New` 버튼을 클릭하여 새 템플릿을 만듭니다.
+2. 전달할 모니터 알림에 대해 `Name`, `Instance` 및 `Target Table` @핸들을 정의합니다. 그런 다음 `Assignment Group`, `Business Service`, `User` 또는 `Unassigned` 중 하나를 선택하여 레코드를 할당합니다. 2.6.0에 정의된 변환 맵은 여기서 선택한 값으로 인시던트 `INC` 레코드를 자동으로 채웁니다.
+
+새 템플릿을 사용하려면 모니터 설명에 `@servicenow-`을 추가하세요.
+
+`Customize notification payload` 섹션에서 `Add Field` 을 클릭하여 페이로드에 커스텀 필드를 추가할 수 있습니다.
+
+#### 사례 관리 설정
+
+{{< img src="integrations/servicenow/servicenow-case-management.png" alt="새 ServiceNow 통합 타일의 사례 관리 지침" >}}
+
+`Case Management` 탭에서,
+
+1. 사례 관리용 설정하려는 인스턴스를 선택합니다.
+2. `Datadog Cases ITOM` 또는 `Datadog Cases ITSM` 중 사례를 보낼 테이블을 선택합니다.
+ **참고**: 기본적으로 테이블이 선택되지 않습니다.
+3. Datadog에서 [사례 관리][15]로 이동합니다.
+4. ServiceNow 인시던트 만들기를 선택합니다.
+5. 인스턴스와 선택적 할당 그룹을 고른 다음 만들기를 클릭합니다.
+
+##### 사례 관리를 통해 양방향으로 상태 및 댓글 동기화
+
+ServiceNow에서 편집한 내용을 Datadog 에서 관련 사례를 업데이트하려면 `x_datad_datadog.user` 및 `admin` 역할이 있는 ServiceNow 사용자가 ServiceNow에서 **Datadog 앱에 대한 ITOM/ITSM 통합**의 설치 구성을 설정해야 합니다:
+
+1. 왼쪽 상단의 **모두**를 클릭하고 필터에 `ITOM/ITSM Integration for Datadog`를 입력한 다음 필터링된 목록에 표시되는 **설정** 링크를 클릭하여 **ITOM/ITSM 통합 for Datadog** 앱의 설정 구성 페이지로 이동합니다.
+1. Datadog 데이터 센터 사이트를 선택합니다.
+1. **조직 설정**에서 찾을 수 있는 Datadog API 키를 **API 키** 필드에 붙여넣습니다.
+1. **조직 설정**에서 찾을 수 있는 Datadog 서비스 계정 신청 키를 **신청 키** 필드에 붙여넣습니다.
+1. 활성화됨 확인란을 선택하고 설정 변경 사항을 저장합니다.
+
+ServiceNow에서 설치 구성을 설정한 후 Datadog 사례 관리로 돌아가 [통합 설정][16]으로 이동합니다.
+
+**참고**: 이 설정에서는 사용자의 애플리케이션 키가 아닌 서비스 계정 애플리케이션 키를 사용하는 것이 중요합니다. 사용자의 애플리케이션 키는 사용자의 계정 권한에 연결됩니다. 사용자의 권한이 줄어들거나 사용자가 비활성화되면 ServiceNow와 Datadog 간의 양방향 동기화가 중지됩니다. 서비스 계정 애플리케이션 키는 개별 사용자에게 연결되지 않으므로 양방향 동기화는 사용자 계정 변경의 영향을 받지 않습니다.
+
+{{< img src="integrations/servicenow/datadog-sync-configuration.png" alt="ServiceNow 설정 구성으로 Datadog에서 ServiceNow 변경 사항을 동기화합니다." >}}
+
+#### 인시던트 관리 설정
+
+앱을 설치한 후 인시던트 앱의 [통합 설정][17]으로 이동하여 설정을 완료합니다.
+
+#### 레거시 모니터 알림
+
+Datadog에서 `@servicenow-`을 사용하는 레거시 모니터 알림의 경우, 중간 테이블을 선택하여 "레거시 모니터 알림 관리"라는 ITOM/ITSM 타일 하단에 있는 알림을 전송합니다.
+
+1. 알림을 설정하려는 인스턴스를 선택한 다음 레거시 모니터 알림에 쓸 테이블을 선택합니다.
+2. 통합이 올바르게 설정되었는지 확인하려면 모니터 또는 이벤트 알림에 `@servicenow-`을 추가합니다. 원시 데이터가 중간 테이블의 행에 채워지고 앱에서 지정한 ServiceNow 테이블로 전달됩니다.
+3. ServiceNow에서 [변환 맵 사용](#customize-data-with-transform-maps)을 사용하여 중간 테이블로 전송되는 데이터의 변환을 커스터마이즈합니다.
+4. 사용 가능한 Datadog 변수 또는 커스텀 문자열을 사용하여 알림 페이로드를 커스터마이즈합니다.
+
+#### 변환 맵을 사용하여 모니터 알림에 대한 데이터 커스터마이즈
+
+**서식화된 모니터 ITSM**, **레거시 모니터 ITSM** 및 **Datadog 사례 ITSM** 테이블은 변환 맵을 사용하여 Datadog 레코드를 ServiceNow 인시던트로 변환합니다.
+마찬가지로 **Datadog 모니터 ITOM** 및 **Datadog 사례 ITOM** 테이블은 Datadog 레코드를 ServiceNow 이벤트로 변환합니다.
+
+**템플릿 모니터 ITOM** 및 **템플릿 모니터 ITSM** 테이블은 변환 맵을 사용하여 Datadog 레코드를 각각 ServiceNow 이벤트 및 인시던트로 변환합니다. `New Template` UI에서 알림 페이로드를 커스터마이즈하여 이러한 테이블의 ServiceNow 이벤트 및 인시던트 정보를 사용자 지정하고 ServiceNow에서 변환 맵을 확장할 수 있습니다.
+
+**참고**: Datadog 사례 ITOM** 및 **Datadog 사례 ITSM** 테이블은 변환 맵을 유사하게 사용하지만, Datadog 사례의 페이로드는 사용자 지정할 수 없으므로 사례 관리와 함께 사용하기 위해 변환 맵 커스터마이즈를 권장하지 않습니다.
+
+## 트러블슈팅
+
+ServiceNow 테이블에 이벤트가 표시되지 않고 대신 다음과 같은 메시지가 표시되는 경우
+
+- Datadog 통합 타일 또는 `Error while trying to post to your ServiceNow instance` 알림에 오류 메시지가 표시됩니다.
+
+ - 인스턴스 이름을 입력할 때 하위 도메인만 사용되었는지 확인합니다.
+ - 생성한 사용자에게 필요한 권한이 있는지 확인합니다.
+ - 사용자 이름과 비밀번호가 올바른지 확인합니다.
+
+- 통합이 설정되고 알림이 트리거되며 티켓이 만들어지지 않습니다.
+
+ - 중간 테이블이 채워졌는지 확인합니다. 그렇다면 매핑 및 변환에 문제가 있는 것입니다. ServiceNow에서 **변환 오류**로 이동하여 매핑 및 스크립트를 추가로 디버깅할 수 있습니다.
+ - 타일에서 지정한 임시 테이블로 작업하고 있는지 확인합니다.
+
+ ServiceNow 사용자가 가져오기 테이블에 액세스할 수 있도록 `rest_service` 및 `x_datad_datadog.user` 역할이 필요합니다. 알림을 인시던트 테이블 또는 이벤트 테이블로 직접 보내는 레거시 방법을 사용하는 경우에는 `itil` 및 `evt_mgmt_integration` 권한이 필요합니다.
+
+Datadog 사례 관리에서 ServiceNow로의 업데이트는 표시되지만 ServiceNow에서 Datadog로의 업데이트가 표시되지 않는 경우 이는 ServiceNow ITOM에 대해 예상되는 동작입니다. 사례 관리와의 양방향 동기화는 ServiceNow ITSM에서만 지원됩니다.
+
+추가 지원이 필요하세요? [Datadog 지원][18]에 문의하세요.
+
+## 지식 기반
+
+### 서식화된 모니터 ITXM 테이블 필드 및 매핑 변환
+
+`action`
+: **유형**: 문자열
+모니터에서 수행 중인 작업: `create`, `update`, `acknowledge` 또는 `resolve`
+
+`additional_information`
+: **유형**: 문자열
+**ITOM 변환**: `additional_info`
+모든 이벤트 세부 정보를 포함하는 형식화된 문자열
+
+`aggreg_key`
+: **유형**: 문자열
+경고 모니터의 ID 해시를 나타내는 집계 키입니다.
+
+`alert_cycle_key`
+: **유형**: 문자열
+단일 모니터의 경고 주기(경고 → 주의 → 해결)의 해시를 나타내는 키입니다.
+
+`alert_id`
+: **유형**: 문자열
+경고 모니터링 ID
+
+`alert_metric`
+: **유형**: 문자열
+**ITOM 변환**: `metric_name`
+경고를 트리거한 메트릭
+
+`alert_query`
+: **유형**: 문자열
+쿼리 경고를 트리거한 문자열
+
+`alert_scope`
+: **유형**: 문자열
+범위 경고를 트리거한 문자열
+
+`alert_status`
+: **유형**: 문자열
+알림의 현재 상태
+
+`alert_title`
+: **유형**: 문자열
+알림 이름
+
+`alert_transition`
+: **유형**: 문자열
+**ITSM 변환**: (스크립트) -> 상태
+경고 전환 상태: `Triggered`, `Warn`, 또는 `Recovered`
+
+`assignment_group_sys_id`
+: **유형**: 참조
+**ITSM 변환**: `assignment_group`
+**참조 테이블**: Group
+서식화된 핸들의 할당 그룹에 대한 ServiceNow sys_id
+
+`business_service_sys_id`
+: **유형**: 참조
+**ITSM 변환**: `business_service`
+**참조 테이블**: 서비스
+서식화된 핸들의 비즈니스에 대한 ServiceNow sys_id 서비스
+
+`custom_fields`
+: **유형**: 문자열
+JSON 변환 가능한 문자열로 포맷된 사용자 설정 키-값 필드
+
+`datadog_tags`
+: **유형**: 문자열
+경고 모니터의 Datadog 태그
+
+`description`
+: **유형**: 문자열
+**ITSM 변환**: `description`
+**ITOM 변환**: `description`
+모니터 알림에 대한 요약 설명
+
+`event_details`
+: **유형**: 문자열
+**ITSM 변환**: `work_notes`
+이벤트 형식이 지정된 클릭 가능한 링크가 포함된 세부 정보 Datadog
+
+`event_id`
+: **유형**: 문자열
+Datadog ID 이벤트
+
+`event_link`
+: **유형**: 문자열
+모니터 알림에서 생성된 이벤트 링크
+
+`event_msg`
+: **유형**: 문자열
+이벤트 메시지
+
+`event_title`
+: **유형**: 문자열
+**ITSM 변환**: `short_description`
+이벤트 제목
+
+`event_type`
+: **유형**: 문자열
+**ITOM 변환**: `type`
+유형 이벤트
+
+`hostname`
+: **유형**: 문자열
+**ITSM 변환**: `cmdb_ci`
+**ITOM 변환**: `node`
+영향을 받은 모니터의 호스트
+
+`impact`
+: **유형**: 정수
+**ITSM 변환**: `impact`
+모니터 우선순위의 사용자 정의 매핑에 기반한 영향 값
+
+`logs_sample`
+: **유형**: 문자열
+관련 샘플 로그
+
+`monitor_priority`
+: **유형**: 정수
+**ITOM 변환**: `severity`
+경고 모니터링하다 의 우선순위를 정수로 변환합니다.
+
+`org_name`
+: **유형**: 문자열
+경고 모니터의 조직 이름
+
+`sys_created_by`
+: **유형**: 문자열
+**ITSM 변환**: `caller_id`
+레코드 작성자(일반적으로 구성된 ServiceNow API 계정)
+
+`ticket_state`
+: **유형**: 문자열
+**ITSM 변환**: (스크립트) -> 상태, (스크립트) -> 닫기_코드, (스크립트) -> 해결_노트
+**ITOM 변환**: (스크립트) -> resolution_notes
+ServiceNow 레코드의 상태: `new` 또는 `resolved`
+
+`u_correlation_id`
+: **유형**: 문자열
+**ITSM 변환**: `correlation_id`
+**ITOM 변환**: `message_key`
+동일한 대상 인시던트에 레코드를 통합하는 데 사용되는 alert_cycle_key와 aggreg_key를 결합한 값입니다.
+
+`urgency`
+: **유형**: 정수
+**ITSM 변환**: `urgency`
+모니터에 정의된 우선순위에 따라 통합 타일의 사용자 정의 매핑에서 설정된 긴급도입니다.
+
+`user_sys_id`
+: **유형**: 참조
+**ITSM 변환**: `assigned_to`
+**참조 테이블**: 사용자
+사용자에 대해 전달된 템플릿 핸들의 sys_id.
+
+
+### Datadog 가져오기 호스트 자동 플러시 규칙
+
+가져오기 세트 테이블 `x_datad_datadog_import_host` 에 너무 많은 행이 누적되는 것을 방지하기 위해 최근 24시간의 데이터만 유지하도록 자동 플러시 규칙이 테이블 클리너 도구에 추가되었습니다. 이 설정을 구성하려면 필터 탐색기에서 `sys_auto_flush_list.do`로 이동하여 `x_datad_datadog_import_host` 테이블에 대한 규칙으로 이동하여 필요에 따라 변경할 수 있습니다. `Age in seconds` 필드는 그에 따라 업데이트할 수 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-cmdb-autoflush-rule.png" alt="통합 설정 구성" >}}
+
+### Datadog 알림에서 지원 티켓 자동 생성하기
+
+ServiceNow가 Datadog 계정에 연결되면 수신된 알림이 자동으로 지원 티켓을 만들어 ServiceNow 티켓팅 대기열로 보낼 수 있습니다. 거기서부터 지원팀은 ServiceNow 내에서 이미 설정한 커뮤니케이션 워크플로우를 사용하여 문제를 통보받게 됩니다. 알림 메시지에 `@servicenow`를 언급하거나 알림 목록에 `@servicenow`를 추가합니다.
+
+{{< img src="integrations/servicenow/servicenow-02-monitor-page.png" alt="ServiceNow" >}}
+
+### 중복 인시던트 모니터링
+
+모니터에서 동일한 인시던트가 다시 열리지 않도록 하려면, 각 경고에 대해 새 경고를 만드는 대신, 모니터가 단순 알림으로 설정되어 있지 않은지 확인하세요. 메트릭에서 태그를 사용하여 그룹화하여 모니터를 [다중 알림][19]으로 변환합니다. 이렇게 하면 각 알림이 별도의 인시던트를 트리거하게 됩니다.
+
+### 티켓 페이로드 및 필드 매핑에 변수 사용하기
+
+변수를 알림 본문이나 필드 매핑에 사용하여 이벤트의 세부 정보가 ServiceNow에 포함되도록 할 수 있습니다. 예를 들어 제목과 심각도를 적절한 ServiceNow 필드에 포함하거나 ServiceNow 티켓에서 바로 Datadog에 특정 인시던트로 돌아가는 링크를 포함할 수 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-variables-form.png" alt="ServiceNow 변수 입력 양식" >}}
+
+{{< img src="integrations/servicenow/servicenow-variables.png" alt="ServiceNow 변수" >}}
+
+### 인시던트 우선순위 필드 매핑
+
+ServiceNow 인시던트의 `priority` 필드는 _읽기 전용_이며 [우선 순위 조회 규칙][20]을 통해서만 업데이트할 수 있습니다.
+
+모니터에 `Impact` 및 `Urgency`를 정의하여 ServiceNow 인시던트 우선 순위를 계산합니다.
+
+{{< img src="integrations/servicenow/servicenow-priority-field-mapping.png" alt="ServiceNow 우선순위 필드 매핑" >}}
+
+### 지원 해결 워크플로 자동화
+
+모니터 상태가 정상으로 돌아오면 관련 지원 티켓이 자동으로 "종결됨"으로 표시됩니다.
+
+{{< img src="integrations/servicenow/servicenow-03-servicenow-resolved.png" alt="ServiceNow 종결됨" >}}
+
+### 커스텀 매핑 정의
+
+테이블 중 하나를 클릭하고(예: **Datadog ITSM 테이블 모니터링**) 레코드 하단으로 스크롤하여 연결된 변환 맵의 링크를 확인합니다.
+
+### 매핑 이해
+
+변환 맵의 이름을 클릭하면 레코드를 볼 수 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-click-transform-map.png" alt="ServiceNow 통합" >}}
+
+상단에는 변환 레코드의 두 가지 중요한 필드인 `Source table` 및 `Target table`이 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-source-target-fields.png" alt="ServiceNow 통합" >}}
+
+**참고**:
+
+- 소스는 선택한 가져오기 집합 테이블(Datadog ITSM 테이블 모니터링)이고 대상은 이벤트가 저장되어 있는 실제 인시던트 테이블(또는 이벤트 테이블)입니다.
+- 필드 매핑은 레코드 하단에 있습니다. 몇 가지 기본 매핑이 포함되어 있습니다. 여기에서 포함할 필드를 선택하고, 형식을 정의하고, ServiceNow 인스턴스에서 대상 필드를 선택합니다.
+
+### 새 필드 매핑 추가
+
+**새로 만들기**를 클릭합니다.
+
+{{< img src="integrations/servicenow/servicenow-click-new.png" alt="SeviceNow 통합" >}}
+
+일대일 매핑을 위해 소스 필드와 대상 필드를 선택합니다.
+
+{{< img src="integrations/servicenow/servicenow-select-source-target.png" alt="ServiceNow 통합" >}}
+
+또는 **소스 스크립트 사용** 상자를 점검하고 변환을 정의합니다.
+
+{{< img src="integrations/servicenow/servicenow-script-example.png" alt="ServiceNow 통합" >}}
+
+**참고: 통합 타일의 커스텀 필드를 매핑하려면 Datadog 모니터 ITOM 및 Datadog 모니터 ITSM 변환 맵에 대해 다음 매핑 스크립트를 사용할 수 있습니다. 이 예제에서는 `my_field` 필드가 통합 타일에서 커스텀 필드로 정의되었습니다.
+
+```
+answer = (function transformEntry(source)
+{
+ var additional_info = JSON.parse(source.additional_info);
+ return additional_info.custom_my_field;
+})(source);
+```
+
+### 여러 매핑 정의
+
+**매핑 지원**(관련 링크 아래)을 사용하여 여러 소스 필드와 대상 필드를 매핑할 수 있습니다.
+
+{{< img src="integrations/servicenow/servicenow-mapping-assist.png" alt="ServiceNow 통합" >}}
+
+### 검증
+
+통합이 올바르게 설정되었는지 확인하려면 모니터 또는 이벤트 알림에 `@servicenow`를 추가합니다. 원시 데이터는 중간 테이블의 행을 채운 뒤, 생성한 매핑 및 변환에 지정된 ServiceNow 테이블로 전달됩니다.
+
+## 참고 자료
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: https://www.servicenow.com/community/now-platform-articles/servicenow-versions-release/ta-p/2312014
+[2]: https://app.datadoghq.com/integrations/servicenow
+[3]: https://store.servicenow.com/sn_appstore_store.do#!/store/application/c877cb86687e0050f8774bfad236c950/1.2.1
+[4]: https://store.servicenow.com/
+[5]: https://docs.servicenow.com/bundle/xanadu-servicenow-platform/page/product/configuration-management/concept/cmdb-query-builder-landing-page.html
+[6]: https://app.datadoghq.com/event/explorer
+[7]: https://docs.datadoghq.com/ko/tracing/service_catalog/
+[8]: https://docs.datadoghq.com/ko/tracing/service_catalog/adding_metadata/
+[9]: https://docs.datadoghq.com/ko/network_monitoring/devices/
+[10]: https://docs.datadoghq.com/ko/network_monitoring/devices/snmp_metrics/
+[11]: https://app.datadoghq.com/reference-tables
+[12]: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/configuration-management/task/use-cmdb-query-builder.html
+[13]: https://app.datadoghq.com/event/pipelines
+[14]: https://docs.datadoghq.com/resources/xml/Datadog-Snow_Update_Set_v2.6.1.xml
+[15]: https://app.datadoghq.com/cases
+[16]: https://docs.datadoghq.com/ko/service_management/case_management/settings#servicenow
+[17]: https://app.datadoghq.com/incidents/settings#Integrations
+[18]: https://docs.datadoghq.com/ko/help/
+[19]: https://docs.datadoghq.com/ko/monitors/configuration/?tab=thresholdalert#multi-alert
+[20]: https://docs.servicenow.com/en-US/bundle/sandiego-it-service-management/page/product/incident-management/task/def-prio-lookup-rules.html
\ No newline at end of file
diff --git a/content/ko/logs/guide/sending-events-and-logs-to-datadog-with-amazon-eventbridge-api-destinations.md b/content/ko/logs/guide/sending-events-and-logs-to-datadog-with-amazon-eventbridge-api-destinations.md
new file mode 100644
index 00000000000..603d7555ed5
--- /dev/null
+++ b/content/ko/logs/guide/sending-events-and-logs-to-datadog-with-amazon-eventbridge-api-destinations.md
@@ -0,0 +1,65 @@
+---
+further_reading:
+- link: https://aws.amazon.com/blogs/compute/using-api-destinations-with-amazon-eventbridge/#sending-aws-events-to-datadog
+ tag: 블로그
+ text: API 목적지 사용 사례 예시가 포함된 AWS 블로그
+- link: /logs/guide/reduce_data_transfer_fees
+ tag: 가이드
+ text: 데이터 전송 수수료를 줄이면서 로그를 Datadog로 보내는 방법
+title: Amazon EventBridge API 목적지를 사용하여 이벤트 및 로그를 Datadog에 전송하기
+---
+
+{{< site-region region="gov" >}}
+정부 사이트용 Datadog는 Amazon EventBridge를 지원하지 않습니다.
+{{< /site-region >}}
+
+Amazon EventBridge는 이벤트 기반 애플리케이션을 구축할 수 있는 서버리스 이벤트 버스입니다. EventBridge는 AWS 서비스와 통합할 수 있지만 API 목적지 기능을 사용하면 AWS 외부에서 API를 사용하여 데이터를 푸시하고 가져올 수 있습니다. 이 가이드는 이벤트 및 로그를 EventBridge에서 Datadog로 전송하는 단계를 안내합니다. Datadog에서 EventBridge로 이벤트를 푸시하는 방법에 대한 자세한 내용은 [EventBridge 통합 문서][1]를 참조하세요.
+
+## 설정
+
+시작하기 전에 [Datadog 계정][2]과 [API 키][3]가 있어야 하며, [Amazon Eventbridge API 목적지][4]에 액세스할 수 있어야 합니다.
+
+### 설정
+
+1. [Amazon API 목적지 문서 만들기][5] 단계를 따라 Datadog를 API 목적지로 추가합니다.
+ - API 키 인증을 사용하고 키 이름은 `DD-API-KEY`, 값은 [Datadog API 키][3]로 지정합니다.
+ - 목적지 엔드포인트의 경우 로그에는 `https://{{< region-param key="http_endpoint" code="true" >}}/api/v2/logs`를, 이벤트에는 `https://api.{{< region-param key="dd_site" code="true" >}}/api/v1/events`를 사용하고 HTTP 메서드로 `POST`를 설정합니다. 로그와 이벤트 의 차이점에 대한 자세한 내용은 [데이터 관련 위험 줄이기][8]를 참조하세요.
+ - 이벤트 엔드포인트를 사용하는 경우 API 목적지 연결에 `title` 및 `text`를 `body.field` 파라미터로 포함해야 합니다. 이는 이벤트 엔드포인트에 대한 `POST`에 필요한 값입니다. 자세한 내용은 [이벤트 문서 게시하기][9]를 참조하세요.
+2. 목적지를 설정한 후에는 Amazon 설명서를 참조하여 [이벤트 브리지 규칙 만들기][10]에서 Datadog를 목적지로 설정합니다.
+3. Datadog를 목적지로 설정하는 규칙을 만든 후에는 이벤트를 EventBridge에 게시하여 이벤트를 트리거합니다. Datadog에서 이벤트 를 EventBridge로 푸시하는 방법에 대한 자세한 내용은 [EventBridge 통합 설명서][1]를 참조하세요. 예를 들어, 계정에서 [개체를 S3 버킷에 업로드][11]하여 이벤트 테스트를 트리거하려면 다음 AWS CloudShell 명령을 사용합니다:
+
+ ```bash
+ echo "test" > testfile.txt
+ aws s3 cp testfile.txt s3://YOUR_BUCKET_NAME
+ ```
+4. 이벤트 및 로그 전송이 완료되면, 약 5분 후에 데이터를 전송하는 엔드포인트에 따라 Datadog [로그 콘솔][12] 또는 [이벤트 탐색기][13]에서 데이터를 확인할 수 있습니다.
+
+## 트러블슈팅
+
+Datadog로 전송된 페이로드에 대한 자세한 내용을 확인하고 API 엔드포인트의 응답을 보려면 Amazon SQS 대기열을 설정하세요.
+1. [Amazon SQS][14]에서 대기열을 만듭니다.
+2. [설정](#configuration) 섹션에서 만든 [EventBridge 규칙][15]으로 이동합니다.
+3. **대상** 탭을 선택하고 **편집**을 클릭합니다.
+4. **추가 설정** 섹션을 확장합니다.
+4. **DLQ(Dead Letter Queue) 대기열** 섹션에서 **현재 AWS 계정에서 DLQ로 사용할 Amazon SQS 대기열을 선택합니다.**
+5. 방금 만든 SQS 대기열을 선택합니다.
+6. 규칙을 업데이트합니다.
+
+## 참고 자료
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+
+[1]: /ko/integrations/amazon_event_bridge/
+[2]: https://www.datadoghq.com/free-datadog-trial/
+[3]: /ko/account_management/api-app-keys/#api-keys
+[4]: https://aws.amazon.com/eventbridge/
+[5]: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destinations.html#eb-api-destination-create
+[8]: /ko/data_security/#other-sources-of-potentially-sensitive-data/
+[9]: https://docs.datadoghq.com/ko/api/latest/events/#post-an-event
+[10]: https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html
+[11]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html
+[12]: https://app.datadoghq.com/logs
+[13]: https://app.datadoghq.com/event/explorer
+[14]: https://console.aws.amazon.com/sqs/
+[15]: https://console.aws.amazon.com/events/
\ No newline at end of file
diff --git a/content/ko/real_user_monitoring/correlate_with_other_telemetry/logs/_index.md b/content/ko/real_user_monitoring/correlate_with_other_telemetry/logs/_index.md
new file mode 100644
index 00000000000..4bf3ed99427
--- /dev/null
+++ b/content/ko/real_user_monitoring/correlate_with_other_telemetry/logs/_index.md
@@ -0,0 +1,45 @@
+---
+algolia:
+ tags:
+ - rum logs
+further_reading:
+- link: https://www.datadoghq.com/blog/real-user-monitoring-with-datadog/
+ tag: 블로그
+ text: 실제 사용자 모니터링
+- link: /logs/guide/ease-troubleshooting-with-cross-product-correlation/
+ tag: 가이드
+ text: 교차 제품 연결을 통한 트러블슈팅
+title: RUM 및 로그 연결
+---
+
+{{< img src="real_user_monitoring/correlate_rum_and_logs/rum_browser_logs.png" alt="RUM 작업 내 브라우저 로그" style="width:100%;" >}}
+
+## 개요
+
+RUM과 로그 통합을 이용하면 애플리케이션 상태를 완전히 가시화할 수 있습니다.
+
+RUM, 백엔드, 인프라스트럭처, 로그 정보뿐만 아니라 프런트엔드 데이터를 사용해 스택 어디에서나 이슈를 파악하고 사용자가 어떤 경험을 하는지 이해할 수 있습니다.
+
+RUM 이벤트를 Datadog로 전송하려면 [Real User Monitoring][1]을 확인하세요.
+
+## RUM은 로그와 어떻게 연결되어 있나요?
+
+로그와 RUM 이벤트는 자동으로 상호 연결되어 있습니다. 로그와 RUM을 상호 연결하면 `session_id` 및 `view.id` 등의 속성을 사용하여 [엔티티 수준의 일관성을 유지하는 공격적인 샘플링 전략][2]을 쉽게 구사할 수 있습니다.
+
+더 자세한 정보는 [RUM 및 세션 재생 요금][3]을 참고하세요.
+**Browser Logs**에서 연결을 올바르게 설정하려면 [RUM Browser SDK와 Logs SDK 간에 구성을 일치][4]시켜야 합니다.
+
+## 설정 지침
+
+로그 설정 페이지에 액세스하려면 내가 사용하는 플랫폼에 따라 다음 링크를 이용하세요.
+
+{{< partial name="rum/rum-correlate-rum-and-logs.html" >}}
+
+## 참고 자료
+
+{{< partial name="whats-next/whats-next.html" >}}
+
+[1]: /ko/real_user_monitoring/
+[2]: /ko/logs/guide/ease-troubleshooting-with-cross-product-correlation/#correlate-frontend-products
+[3]: /ko/account_management/billing/rum/#how-do-you-view-logs-from-the-browser-collector-in-rum
+[4]: /ko/real_user_monitoring/browser/setup/#initialization-parameters
\ No newline at end of file
diff --git a/content/ko/security/code_security/iast/security_controls/_index.md b/content/ko/security/code_security/iast/security_controls/_index.md
new file mode 100644
index 00000000000..68d78cf08ed
--- /dev/null
+++ b/content/ko/security/code_security/iast/security_controls/_index.md
@@ -0,0 +1,304 @@
+---
+aliases:
+- /ko/security/application_security/code_security/iast
+disable_toc: false
+title: 보안 컨트롤
+---
+
+
+Security Controls는 이스케이프 및 삭제를 사용하여 취약성 탐지에서 오탐 보고를 방지합니다. 보안 함수는 데이터 처리 방식을 세분화하여 적절한 변경 사항이 불필요한 보안 경고를 트리거하지 않도록 합니다.
+
+## Input Validator 및 Sanitizer 비교
+
+Security Controls는 보안 유효성 검사에서 함수를 사용하는 방식에 따라 **Input Validator** 및 "Sanitizer**를 구분합니다.
+
+- **Input Validator**: 함수가 전달된 파라미터를 검증하는 경우 사용됩니다. Validator는 사용자 입력이 처리되기 전 해당 입력이 예상되는 형식을 준수하도록 합니다.
+- **Sanitizer**: 함수가 애플리케이션에서 반환 값이 사용되기 전 반환 값을 검증하거나 수정하는 경우 사용됩니다. Sanitizer는 데이터 삭제를 지원하여 잠재적으로 유해한 콘텐츠를 포함하지 않도록 보장합니다.
+
+## 보안 제어 설정하기
+
+Security Controls 정의는 설정 변수 `DD_IAST_SECURITY_CONTROLS_CONFIGURATION`에 배치해야 합니다.
+보안 제어 목록을 설정하려면 아래의 형식과 필드 사양을 따르세요.
+이 형식은 특정 구분 기호를 사용하여 각 보안 제어 항목을 구성합니다.
+
+### 형식
+
+`:::::`
+
+### 필드 사양
+| **필드** | **설명** |
+|---------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **유형** | 제어 유형을 정의합니다. **허용되는 값은 `INPUT_VALIDATOR` 또는 `SANITIZER`입니다.** |
+| **보안 마크** | 적용할 취약성 유형 목록입니다. 사용 가능한 값은 [보안 마크](#secure-marks)에 정의되어 있습니다. 부수적으로 `*`을 사용하여 모든 유형에 대한 적용 가능성을 표시할 수 있습니다. |
+| **클래스/파일** | 보안 제어를 구현하는 정규화된 클래스 또는 파일입니다. |
+| **메서드** | 보안 제어를 구현하는 메서드의 이름입니다. |
+| **파라미터(선택 사항)** | 완전한 적격 클래스 파라미터입니다. 오버로드 메서드를 구분하는 데 사용됩니다. 생략 또는 오버로드가 존재하는 경우 보안 제어가 모든 오버로드 메서드에 적용됩니다. |
+| **검증할 파라미터(선택 사항)** | 검증할 파라미터 포지션의 0 기반 목록입니다. 첫 번째 파라미터 는 **0** 위치입니다. 이 필드는 `INPUT_VALIDATOR` **유형에만** 적용됩니다. **일부 파라미터에 대해 유효성 검사가 필요하지 않은 경우** 사용됩니다. |
+
+
+### 구분 기호
+- `;` (세미콜론): 각 보안 제어를 구분합니다.
+- `:` (콜론): 보안 제어 내의 각 필드를 구분합니다.
+- `,` (쉼표): 목록을 허용하는 필드 내에서 항목을 구분합니다.
+
+### 보안 마크
+
+사용 가능한 보안 마크는 각 삽입 관련 취약성과 관련된 코드에 대응합니다. [지원되는 취약성][1]에서 해당 코드와 각 언어에 대해 사용 가능한지 여부를 확인할 수 있습니다.
+
+삽입 관련 취약점은 다음과 같습니다.
+
+* 코드 삽입
+* 명령 삽입
+* 이메일 HTML 삽입
+* 헤더 삽입
+* LDAP 삽입
+* NoSQL 삽입
+* 경로 탐색
+* 반사 삽입
+* 서버 측 요청 위조(SSRF)
+* SQL 삽입
+* 신뢰 경계 위반
+* 신뢰할 수 없는 역직렬화
+* 유효하지 않은 리디렉션
+* XPath 삽입
+* 사이트 간 스크립팅(XSS)
+
+## 호환성 요구 사항
+
+이 기능은 각 언어의 다음 추적 라이브러리 버전부터 사용할 수 있습니다.
+
+* **자바(Java)**: 1.45.0 이상
+* **.NET**: 지원되지 않음
+* **Node.js**: 5.37.0 이상
+* **파이썬(Python)**: 지원되지 않음
+
+
+## 예시
+
+{{% collapse-content title="Java" level="h4" %}}
+
+### Input Validator
+
+#### 모든 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar.foo.CustomInputValidator#validate(String input1, String input2)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar.foo.CustomInputValidator:validate`
+
+#### 단일 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomInputValidator#validate(String input1, String inputToValidate)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar.foo.CustomInputValidator:validate:1`
+
+#### 2개의 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomInputValidator#validate(String input1, String firstInputToValidate, String secondInputToValidate, Object anotherInput)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar.foo.CustomInputValidator:validate:1,2
+`
+#### 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성과 코드 삽입 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomInputValidator#validate(String input)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION,CODE_INJECTION:bar.foo.CustomInputValidator:validate
+`
+#### 입력 파라미터를 검증하는 메서드로 모든 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomInputValidator#validate(String input)`
+
+##### 설정
+`INPUT_VALIDATOR:*:bar.foo.CustomInputValidator:validate
+`
+#### 입력 파라미터를 검증하는 오버로드 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 메서드
+ `bar.foo.CustomInputValidator#validate(String input)`
+
+ `bar.foo.CustomInputValidator#validate(String input, String input2)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar.foo.CustomInputValidator:validate:java.lang.String
+`
+##### 참고
+첫 번째 메서드를 적용합니다.
+
+
+#### 입력 파라미터를 검증하는 오버로드 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 메서드
+ `bar.foo.CustomInputValidator#validate(String input)`
+
+ `bar.foo.CustomInputValidator#validate(String input, String input2)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar.foo.CustomInputValidator:validate
+`
+##### 참고
+두 가지 메서드 모두에 적용됩니다.
+
+### Sanitizer
+
+#### Sanitizer로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomSanitizer#sanitize(String input)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION:bar.foo.CustomSanitizer:sanitize
+`
+#### Sanitizer로 명령 삽입 및 코드 삽입 취약성을 방지합니다.
+
+##### 방법
+ `bar.foo.CustomSanitizer#sanitize(String input)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION,CODE_INJECTION:bar.foo.CustomSanitizer:sanitize
+`
+#### 모든 취약성을 방지하는 Sanitizer입니다.
+
+##### 방법
+ `bar.foo.CustomSanitizer#sanitize(String input)`
+
+##### 설정
+`SANITIZER:*:bar.foo.CustomSanitizer:sanitize
+`
+#### 오버로드 Sanitizer로 명령 삽입 취약성을 방지합니다.
+
+##### 메서드
+ `bar.foo.CustomSanitizer#sanitize(String input)`
+
+ `bar.foo.CustomSanitizer#sanitize(String input, String input2)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION:bar.foo.CustomSanitizer:sanitize:자바(Java).lang.String
+`
+##### 참고
+첫 번째 메서드를 적용합니다.
+
+#### 오버로드 Sanitizer로 명령 삽입 취약성을 방지합니다.
+
+##### 메서드
+` bar.foo.CustomSanitizer#sanitize(String input)`
+
+`bar.foo.CustomSanitizer#sanitize(String input, String input2)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION:bar.foo.CustomSanitizer:sanitize
+`
+##### 참고
+두 가지 메서드 모두에 적용됩니다.
+
+{{% /collapse-content %}}
+
+
+{{% collapse-content title="Node.js" level="h4" %}}
+
+### Input Validator
+
+#### 모든 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_validator.js#validate(input1, input2)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar/foo/custom_input_validator.js:validate`
+
+#### 단일 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_validator.js#validate(input1, inputToValidate)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar/foo/custom_input_validator.js:validate:1`
+
+#### 2개의 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_validator.js#validate(input1, firstInputToValidate, secondInputToValidate, anotherInput)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar/foo/custom_input_validator.js:validate:1,2`
+
+#### 입력 파라미터를 검증하는 메서드로 명령 삽입 취약성과 코드 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_validator.js#validate(input)`
+
+##### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION,CODE_INJECTION:bar/foo/custom_input_validator.js:validate`
+
+#### 입력 파라미터를 검증하는 메서드로 모든 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_validator.js#validate(input)`
+
+##### 설정
+`INPUT_VALIDATOR:*:bar/foo/custom_input_validator.js:validate`
+
+### Sanitizer
+
+#### Sanitizer로 명령 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_sanitizer.js#sanitize(input)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION:bar/foo/custom_input_sanitizer.js:sanitize`
+
+#### Sanitizer로 명령 삽입 및 코드 삽입 취약성을 방지합니다.
+
+##### 방법
+`bar/foo/custom_input_sanitizer.js#sanitize(input)`
+
+##### 설정
+`SANITIZER:COMMAND_INJECTION,CODE_INJECTION:bar/foo/custom_input_sanitizer.js:sanitize`
+
+#### 모든 취약성을 방지하는 Sanitizer입니다.
+
+##### 방법
+`bar/foo/custom_input_sanitizer.js#sanitize(input)`
+
+##### 설정
+`SANITIZER:*:bar/foo/custom_input_sanitizer.js:sanitize`
+
+### 특수 사례
+
+#### 내보내기한 개체 내의 보안 제어 메서드
+`validate` 메서드는 명령 삽입 취약성을 방지하기 위해 입력 파라미터를 검증하는 `validators` 개체 내부로 내보내기됩니다.
+
+```javascript
+// bar/foo/custom_input_validator.js
+module.exports = {
+ validators: {
+ validate: (input) => {
+ /* validation process */
+ }
+ }
+}
+```
+
+#### 설정
+`INPUT_VALIDATOR:COMMAND_INJECTION:bar/foo/custom_input_validator.js:validators.validate`
+
+#### 전이적 종속성을 통한 보안 제어 메서드
+`npm` 플랫 종속성 구조로 인해 직접 종속성과 전이적 종속성을 구분할 수 없습니다. 즉, 종속성 내에 보안 제어가 정의되어 있으면 해당 종속성의 모든 인스턴스(직접 또는 전이)가 영향을 받습니다.
+
+다음 보안 제어 정의는 종속성 트리에 있는 모든 `sql-sanitizer` 패키지에 영향을 줍니다.
+
+#### 설정
+`SANITIZER:SQL_INJECTION:node_modules/sql-sanitizer/index.js:sanitize`
+
+
+{{% /collapse-content %}}
+
+[1]: /ko/security/code_security/iast/#overview
\ No newline at end of file
diff --git a/content/ko/serverless/libraries_integrations/plugin.md b/content/ko/serverless/libraries_integrations/plugin.md
index 56a728ad470..d1be2283aa9 100644
--- a/content/ko/serverless/libraries_integrations/plugin.md
+++ b/content/ko/serverless/libraries_integrations/plugin.md
@@ -2,7 +2,7 @@
aliases:
- /ko/serverless/serverless_integrations/plugin
dependencies:
-- https://github.com/DataDog/serverless-plugin-datadog/blob/master/README.md
+- https://github.com/DataDog/serverless-plugin-datadog/blob/main/README.md
title: Datadog 서버리스 프레임워크 플러그인
---
@@ -32,45 +32,47 @@ Datadog는 서버리스 애플리케이션을 구축하기 위해 서버리스
플러그인을 추가로 구성하려면 `serverless.yml`에서 다음 사용자 지정 파라미터를 사용합니다.
-| 파라미터 | 설명 |
-| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `site` | `datadoghq.com`(기본값), `datadoghq.eu`, `us3.datadoghq.com`, `us5.datadoghq.com`, `ap1.datadoghq.com` 또는 `ddog-gov.com` 등 데이터를 전송할 Datadog 사이트를 설정합니다. 이 파라미터는 Datadog 람다 확장을 사용해 텔레메트리를 수집할 때 필요합니다. |
-| `apiKey` | [Datadog API 키][7]입니다. 이 파라미터는 Datadog 람다 확장을 사용해 텔레메트리를 수집할 때 필요합니다. 대신 배포 환경에서 `DATADOG_API_KEY` 환경 변수를 설정할 수도 있습니다. |
-| `appKey` | Datadog 앱 키입니다. `monitors` 필드가 정의된 경우에만 필요합니다. 대신 배포 환경에서 `DATADOG_APP_KEY` 환경 변수를 설정할 수 있습니다. |
-| `apiKeySecretArn` | `apiKey` 필드의 대안입니다. AWS 암호 관리자에 Datadog API 키를 저장하는 암호 ARN입니다. 람다 실행 역할에 `secretsmanager:GetSecretValue` 권한을 추가하는 것을 기억하세요. |
-| `apiKMSKey` | `apiKey` 필드의 대안입니다. KMS를 사용하여 암호화된 Datadog API 키입니다. 람다 확장 역할에 `kms:Decrypt` 권한을 추가하는 것을 잊지 마세요. |
-| `env` | `addExtension`을 설정할 때 `DD_ENV` 환경 변수가 제공된 값과 함께 모든 람다 함수에 추가됩니다. 그렇지 않으면 제공된 값과 함께 모든 람다 함수에 `env` 태그가 추가됩니다. 서버리스 배포 `stage` 값이 기본값으로 설정됩니다. |
+| 파라미터 | 설명 |
+| ----------------------------- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `site` | `datadoghq.com`(기본값), `datadoghq.eu`, `us3.datadoghq.com`, `us5.datadoghq.com`, `ap1.datadoghq.com` 또는 `ddog-gov.com` 등 데이터를 전송할 Datadog 사이트를 설정합니다. 이 파라미터는 Datadog 람다 확장을 사용해 텔레메트리를 수집할 때 필요합니다. |
+| `apiKey` | [Datadog API 키][7]입니다. 이 파라미터는 Datadog 람다 확장을 사용해 텔레메트리를 수집할 때 필요합니다. 대신 배포 환경에서 `DATADOG_API_KEY` 환경 변수를 설정할 수도 있습니다. |
+| `appKey` | Datadog 앱 키입니다. `monitors` 필드가 정의된 경우에만 필요합니다. 대신 배포 환경에서 `DATADOG_APP_KEY` 환경 변수를 설정할 수 있습니다. |
+| `apiKeySecretArn` | `apiKey` 필드의 대안입니다. AWS 암호 관리자에 Datadog API 키를 저장하는 암호 ARN입니다. 람다 실행 역할에 `secretsmanager:GetSecretValue` 권한을 추가하는 것을 기억하세요. |
+| `apiKMSKey` | `apiKey` 필드의 대안입니다. KMS를 사용하여 암호화된 Datadog API 키입니다. 람다 확장 역할에 `kms:Decrypt` 권한을 추가하는 것을 잊지 마세요. |
+| `env` | `addExtension`을 설정할 때 `DD_ENV` 환경 변수가 제공된 값과 함께 모든 람다 함수에 추가됩니다. 그렇지 않으면 제공된 값과 함께 모든 람다 함수에 `env` 태그가 추가됩니다. 서버리스 배포 `stage` 값이 기본값으로 설정됩니다. |
| `service` | `addExtension`와 함께 설정할 때 `DD_SERVICE` 환경 변수는 제공된 값과 함께 모든 람다 함수에 추가됩니다. 그렇지 않으면 제공된 값과 함께 모든 람다 함수에 `service` 태그가 추가됩니다. 서버리스 프로젝트의 `service` 값이 기본값으로 설정됩니다.
-| `version` | `addExtension`과 함께 설정하는 경우 `DD_VERSION` 환경 변수는 제공된 값과 함께 모든 람다 함수에 추가됩니다. `forwarderArn`과 함께 설정하는 경우 `version` 태그가 제공된 값과 함께 모든 람다 함수에 추가됩니다. |
-| `tags` | 단일 문자열인 `key`:`value` 쌍의 쉼표로 구분된 목록입니다. `extensionLayerVersion`과 함께 설정할 경우 `DD_TAGS` 환경 변수가 제공된 값과 함께 모든 람다 함수에 추가됩니다. `forwarderArn`과 함께 설정할 경우 플러그인이 문자열을 파싱하고 모든 람다 함수에 태그로 각 `key`:`value` 쌍이 태그로 설정됩니다. |
-| `enableXrayTracing` | `true`을 설정하여 람다 함수와 API 게이트웨이 통합에서 X-Ray 트레이싱을 활성화합니다. `false`이 기본값으로 설정됩니다. |
-| `enableDDTracing` | 람다 함수에서 Datadog 트레이싱을 활성화합니다. `true`가 기본값으로 설정됩니다. |
-| `enableDDLogs` | 람다 확장을 사용하여 Datadog 로그 수집을 활성화합니다. `true`가 기본값으로 설정됩니다. 참고: 이 설정은 Datadog 포워더에서 전송한 로그에는 영향을 미치지 않습니다. |
-| `monitors` | 정의된 경우 Datadog 플러그인은 배포된 함수에 대한 모니터링을 설정합니다. 환경에서 `DATADOG_API_KEY` 및 `DATADOG_APP_KEY` 설정이 필요합니다. 모니터를 정의하는 방법을 알아보려면 [권장되는 서버리스 모니터 활성화 및 설정 방법](#to-enable-and-configure-a-recommended-serverless-monitor)을 참조하세요. |
-| `captureLambdaPayload` | 람다 호출의 Datadog 애플리케이션 성능 모니터링(APM) 스팬에서 [수신 및 발신 AWS 람다 페이로드를 캡처합니다][17]. `false`가 기본값으로 설정됩니다. |
-| `enableSourceCodeIntegration` | 함수를 위해 [Datadog 소스 코드 통합]을 활성화합니다. `true`가 기본값으로 설정됩니다. |
-| `uploadGitMetadata` | 소스 코드 통합의 일환으로, 함수를 위해 Git 메타데이터 업로드를 활성화합니다. Datadog Github 통합이 불필요한 Git 메타데이터가 업로드를 제공하므로 Datadog Github 통합이 설치된 경우 거짓으로 설정합니다. |
-| `subscribeToAccessLogs` | Datadog 포워더(Forwarder)의 API 게이트웨이 액세스 로그인 그룹 자동 구독을 활성화합니다. `forwarderArn`를 설정해야 합니다. 기본값이 `true`로 설정됩니다. |
-| `subscribeToExecutionLogs` | Datadog 포워더의 HTTP API 및 Websocket 로그 그룹 자동 구독을 활성화합니다. `forwarderArn`를 설정해야 합니다. 기본값이 `true`로 설정됩니다. |
-| `subscribeToStepFunctionLogs` | Datadog 포워더의 Step 함수 로그 그룹 자동 구독을 활성화합니다. 설정된 Step 함수 로그 그룹이 없으면 자동으로 생성됩니다. `forwarderArn`을 설정해야 합니다. 기본값이 `false`로 설정됩니다. |
-| `forwarderArn` | Datadog 포워더 ARN은 람다 또는 API 게이트웨이 로그 그룹에 구독됩니다. |
-| `addLayers` | Datadog 람다 라이브러리를 레이어로 설치할지를 결정합니다. 기본값은 `true`로 설정됩니다. 특정 버전의 Datadog 람다 라이브러리([파이썬(Python)][8] or [Node.js][9])를 설치할 수 있도록 Datadog 람다 라이브러리를 함수의 배포 패키지로 자체적으로 패키징할 계획이 있다면 `false`로 설정합니다. |
-| `addExtension` | Datadog 람다 확장을 레이어로 설치할지를 결정합니다. 기본값은 `true`로 설정됩니다. 활성화되면 `apiKey` 및 `site`를 설정해야 합니다. |
-| `exclude` | 설정되면 이 플러그인은 지정된 모든 함수를 무시합니다. Datadog 기능에 포함되지 말아야 할 함수가 있는 경우 이 파라미터를 사용합니다. 기본값은 `[]`로 설정됩니다. |
+| `version` | `addExtension`과 함께 설정하는 경우 `DD_VERSION` 환경 변수는 제공된 값과 함께 모든 람다 함수에 추가됩니다. `forwarderArn`과 함께 설정하는 경우 `version` 태그가 제공된 값과 함께 모든 람다 함수에 추가됩니다. |
+| `tags` | 단일 문자열인 `key`:`value` 쌍의 쉼표로 구분된 목록입니다. `extensionLayerVersion`과 함께 설정할 경우 `DD_TAGS` 환경 변수가 제공된 값과 함께 모든 람다 함수에 추가됩니다. `forwarderArn`과 함께 설정할 경우 플러그인이 문자열을 파싱하고 모든 람다 함수에 태그로 각 `key`:`value` 쌍이 태그로 설정됩니다. |
+| `enableXrayTracing` | `true`을 설정하여 람다 함수와 API 게이트웨이 통합에서 X-Ray 트레이싱을 활성화합니다. `false`이 기본값으로 설정됩니다. |
+| `enableDDTracing` | 람다 함수에서 Datadog 트레이싱을 활성화합니다. `true`가 기본값으로 설정됩니다. |
+| `enableASM` | Lambda 함수에서 [Datadog 애플리케이션 보안 관리(ASM)][19]를 활성화합니다. Datadog 확장(`addExtension`을 사용하거나 수동으로 추가)과 `enableDDTracing`이 있어야 합니다. 기본값은 `false`입니다. |
+| `enableDDLogs` | 람다 확장을 사용하여 Datadog 로그 수집을 활성화합니다. `true`가 기본값으로 설정됩니다. 참고: 이 설정은 Datadog 포워더에서 전송한 로그에는 영향을 미치지 않습니다. |
+| `monitors` | 정의된 경우 Datadog 플러그인은 배포된 함수에 대한 모니터링을 설정합니다. 환경에서 `DATADOG_API_KEY` 및 `DATADOG_APP_KEY` 설정이 필요합니다. 모니터를 정의하는 방법을 알아보려면 [권장되는 서버리스 모니터 활성화 및 설정 방법](#to-enable-and-configure-a-recommended-serverless-monitor)을 참조하세요. |
+| `captureLambdaPayload` | 람다 호출의 Datadog 애플리케이션 성능 모니터링(APM) 스팬에서 [수신 및 발신 AWS 람다 페이로드를 캡처합니다][17]. `false`가 기본값으로 설정됩니다. |
+| `enableSourceCodeIntegration` | 함수를 위해 [Datadog 소스 코드 통합]을 활성화합니다. `true`가 기본값으로 설정됩니다. |
+| `uploadGitMetadata` | 소스 코드 통합의 일환으로, 함수를 위해 Git 메타데이터 업로드를 활성화합니다. Datadog Github 통합이 불필요한 Git 메타데이터가 업로드를 제공하므로 Datadog Github 통합이 설치된 경우 거짓으로 설정합니다. |
+| `subscribeToAccessLogs` | Datadog 포워더(Forwarder)의 API 게이트웨이 액세스 로그인 그룹 자동 구독을 활성화합니다. `forwarderArn`를 설정해야 합니다. 기본값이 `true`로 설정됩니다. |
+| `subscribeToExecutionLogs` | Datadog 포워더의 HTTP API 및 Websocket 로그 그룹 자동 구독을 활성화합니다. `forwarderArn`를 설정해야 합니다. 기본값이 `true`로 설정됩니다. |
+| `forwarderArn` | Datadog 포워더 ARN은 람다 또는 API 게이트웨이 로그 그룹에 구독됩니다. |
+| `addLayers` | Datadog 람다 라이브러리를 레이어로 설치할지를 결정합니다. 기본값은 `true`로 설정됩니다. 특정 버전의 Datadog 람다 라이브러리([파이썬(Python)][8] or [Node.js][9])를 설치할 수 있도록 Datadog 람다 라이브러리를 함수의 배포 패키지로 자체적으로 패키징할 계획이 있다면 `false`로 설정합니다. |
+| `addExtension` | Datadog 람다 확장을 레이어로 설치할지를 결정합니다. 기본값은 `true`로 설정됩니다. 활성화되면 `apiKey` 및 `site`를 설정해야 합니다. |
+| `exclude` | 설정되면 이 플러그인은 지정된 모든 함수를 무시합니다. Datadog 기능에 포함되지 말아야 할 함수가 있는 경우 이 파라미터를 사용합니다. 기본값은 `[]`로 설정됩니다. |
| `enabled` | `false`로 설정하면 Datadog 플러그인이 비활성 상태로 유지됩니다. 기본값은 `true`로 설정됩니다. 환경 변수를 사용해 이 옵션을 조정할 수 있습니다. 예를 들어 `enabled: ${strToBool(${env:DD_PLUGIN_ENABLED, true})}`를 사용해 배포 동안 플러그인을 활성화/비활성화할 수 있습니다. 대신 `--stage`를 통과한 값을 사용하여 이 옵션을 조정할 수 있습니다. [예시 참조](#disable-plugin-for-particular-environment) |
-| `customHandler` | 설정되면 지정된 핸들러가 모든 함수에 대한 핸들러로 설정됩니다. |
-| `failOnError` | 설정되면 Datadog 모니터가 생성이나 업데이트에 실패했을 때 오류를 트리거합니다. 배포 후에 발생할 수 있지만 0이 아닌 종료 코드를 반환하기 위해(사용자 CI 실패를 위해) `serverless deploy`를 발생시킬 수 있습니다. 기본값은 `false`로 설정됩니다. |
-| `logLevel` | 로그 수준으로, 확장된 로깅을 위해 `DEBUG`로 설정됩니다. |
-| `skipCloudformationOutputs` | 스택에 Datadog Cloudformation Outputs 추가하기를 건너뛰려면 `true`로 설정합니다. 200개 출력 제한은 스택 생성을 실패하게 할 수 있으므로 이 경우 유용합니다. |
-| `enableColdStartTracing` | 콜드 스타트 추적을 비활성화하려면 `false`로 설정합니다. Node.js 및 파이썬(Python)에서 사용됩니다. 기본값은 `true`입니다. |
-| `coldStartTraceMinDuration` | 콜드 스타트 추적을 통해 추적할 모듈 로드 이벤트의 최소 지속 시간(밀리초)을 설정합니다. 번호. 기본값은`3` 입니다. |
-| `coldStartTraceSkipLibs` | 선택적으로 쉼표로 구분된 라이브러리 목록에 대해 콜드 스타트 스팬(span) 만들기를 건너뜁니다. 깊이를 제한하거나 알려진 라이브러리를 건너뛸 때 유용합니다. 기본값은 런타임에 따라 다릅니다. |
-| `subdomain` | 부수적인 하위 도메인을 설정하여 출력 생성을 위해 프린트되는 앱 URL을 사용합니다. 기본값은 `app`으로 설정됩니다. |
-| `enableProfiling` | `true`와 함께 Datadog 계속적인 프로파일러를 사용하도록 설정합니다. Node.js 및 파이썬(Python)용 베타에서 지원됩니다. 기본값은 `false`입니다. |
-| `encodeAuthorizerContext` | 람다 승인자에 대해 `true`로 설정하면 추적 컨텍스트가 전파를 위해 응답으로 인코딩됩니다. Node.js 및 파이썬(Python)에서 지원됩니다. 기본값은 `true`입니다. |
-| `decodeAuthorizerContext` | 람다 인증자를 통해 인증된 람다에 대해 `true`로 설정하면 인코딩된 추적 컨텍스트를 구문 분석하고 사용합니다(찾은 경우). Node.js 및 파이썬(Python)에서 지원됩니다. 기본값은 `true`입니다. |
-| `apmFlushDeadline` | 밀리초에서 시간 초과하기 전에 기간을 제출할 시기를 결정하는 데 사용됩니다. AWS 람다 호출의 남은 시간이 설정된 값보다 작으면 추적기는 현재 활성 스팬(span)과 완료된 모든 스팬(span)을 제출하려고 시도합니다. Node.js 및 파이썬(Python)에서 지원됩니다. 기본값은 `100`밀리초입니다. |
-
+| `customHandler` | 설정되면 지정된 핸들러가 모든 함수에 대한 핸들러로 설정됩니다. |
+| `failOnError` | 설정되면 Datadog 모니터가 생성이나 업데이트에 실패했을 때 오류를 트리거합니다. 배포 후에 발생할 수 있지만 0이 아닌 종료 코드를 반환하기 위해(사용자 CI 실패를 위해) `serverless deploy`를 발생시킬 수 있습니다. 기본값은 `false`로 설정됩니다. |
+| `logLevel` | 로그 수준으로, 확장된 로깅을 위해 `DEBUG`로 설정됩니다. |
+| `skipCloudformationOutputs` | 스택에 Datadog Cloudformation Outputs 추가하기를 건너뛰려면 `true`로 설정합니다. 200개 출력 제한은 스택 생성을 실패하게 할 수 있으므로 이 경우 유용합니다. |
+| `enableColdStartTracing` | 콜드 스타트 추적을 비활성화하려면 `false`로 설정합니다. NodeJS 및 파이썬(Python)에서 사용됩니다. 기본값은 `true`입니다. |
+| `coldStartTraceMinDuration` | 콜드 스타트 추적을 통해 추적할 모듈 로드 이벤트의 최소 지속 시간 (밀리초)을 설정합니다. 번호. 기본값은`3` 입니다. |
+| `coldStartTraceSkipLibs` | (선택 사항) 쉼표로 구분된 라이브러리 목록에 대한 콜드 스타트 스팬 생성을 건너뛸 수 있습니다. 깊이를 제한하거나 알려진 라이브러리를 건너뛸 때 유용합니다. 기본값은 런타임에 따라 다릅니다. |
+| `subdomain` | 부수적인 하위 도메인을 설정하여 출력 생성을 위해 프린트되는 앱 URL을 사용합니다. 기본값은 `app`으로 설정됩니다. |
+| `enableProfiling` | `true`로 설정해 Datadog Continuous Profiler를 활성화합니다. NodeJS 및 파이썬(Python)용은 베타 버전에서 지원됩니다. 기본값은 `false`입니다. |
+| `encodeAuthorizerContext` | 람다 인증자에 대해 `true`로 설정하면 추적 컨텍스트가 전파를 위해 응답으로 인코딩됩니다. NodeJS 및 파이썬(Python)에서 지원됩니다. 기본값은 `true`입니다. |
+| `decodeAuthorizerContext` | 람다 인증자를 통해 인증된 람다에 대해 `true`로 설정하면 인코딩된 추적 컨텍스트를 구문 분석하여 사용합니다 (있는 경우). NodeJS 및 파이썬(Python)에서 지원됩니다. 기본값은 `true`입니다. |
+| `apmFlushDeadline` | 시간 초과가 발생하기 전에 스팬을 제출할 시점을 밀리초 단위로 결정하는 데 사용됩니다. AWS 람다 호출의 남은 시간이 설정된 값보다 작으면 추적기는 현재 활성 스팬과 완료된 모든 스팬을 제출하려고 시도합니다. NodeJS 및 파이썬(Python)에서 지원됩니다. 기본값은 `100`밀리초입니다. |
+| `enableStepFunctionsTracing` | Datadog 포워더에서 Step 함수 로그 그룹과 Step 함수 추적을 자동 구독하도록 활성화합니다. 설정된 Step 함수 로그 그룹이 없으면 자동으로 생성됩니다. `forwarderArn`을 설정해야 합니다. 기본값은 `false`입니다. |
+| `propagateUpstreamTrace` | `true`로 설정하면 다운스트림 Step 함수 호출 트레이스가 업스트림 Step 함수 호출과 병합됩니다. 기본값은 `false`입니다. |
+| `redirectHandlers` | (선택 사항)`false`로 설정된 경우 핸들러 리디렉션을 비활성화할 수 있습니다. APM이 완전 비활성화될 경우에만 `false`로 설정해야 합니다. 기본값은 `true`입니다. |
이 파라미터를 사용하려면 이 예시와 유사한 `serverless.yml`에 `custom` > `datadog` 섹션을 추가합니다.
```yaml
@@ -172,7 +174,6 @@ custom:
include_tags: true
notify_audit: true
thresholds:
- ok: 0.025
warning: 0.05
critical: 0.1
```
@@ -203,23 +204,32 @@ custom:
notify_audit: true
notify_no_data: false
thresholds:
- ok: 1
warning: 2
critical: 3
```
## 변경 사항 중단
-### [v5.0.0](https://github.com/DataDog/serverless-plugin-datadog/releases/tag/v5.0.0)
+[**v5.0.0**](https://github.com/DataDog/serverless-plugin-datadog/releases/tag/v5.0.0)
- Datadog 확장과 함께 사용하면 이 플러그인은 람다 리소스 태그 대신 환경 변수를 통해 `service` 및 `env` 태그를 설정합니다.
- `enableTags` 파라미터는 새로운 `service`, `env` 파라미터를 대체합니다.
-### [v4.0.0](https://github.com/DataDog/serverless-plugin-datadog/releases/tag/v4.0.0)
+[**v4.0.0**](https://github.com/DataDog/serverless-plugin-datadog/releases/tag/v4.0.0)
- Datadog 람다 확장은 이제 텔레메트리를 Datadog에 전송하기 위한 기본 메커니즘입니다.
-## 오프닝 이슈
+## serverless-plugin-warmup으로 작업
+이 라이브러리는 [serverless-plugin-warmup](https://github.com/juanjoDiaz/serverless-plugin-warmup)과 가장 호환이 잘 됩니다. Datadog에서 warmer 함수를 제외하고 싶은 경우, 이 라이브러리의 `exclude` 기능을 사용하세요.
+
+애플리케이션을 제대로 패키징하려면 `serverless.yml` 파일 `serverless-plugin-warmup` _뒤_에 플러그인 목록이 와야 *합니다*.
+```yaml
+plugins:
+ - serverless-plugin-warmup
+ - serverless-plugin-datadog
+```
+
+## 이슈 열기
이 패키지에서 버그를 발견한 경우 이슈를 작성하여 알려주세요! 새로운 이슈를 시작하기 전 기존 이슈를 검색하여 중복을 피해 주세요.
@@ -233,7 +243,7 @@ custom:
## 커뮤니티
-제품 피드백 및 질문은 [슬랙의 Datadog 커뮤니티](https://chat.datadoghq.com/)의 `#serverless`에 가입하세요.
+제품 피드백 및 질문이 있는 경우 [슬랙의 Datadog 커뮤니티](https://chat.datadoghq.com/)의 `#serverless` 채널에 가입하세요.
## 라이센스
@@ -258,4 +268,5 @@ custom:
[15]: https://github.com/DataDog/serverless-plugin-datadog/blob/master/src/layers.json
[16]: https://docs.datadoghq.com/ko/tracing/setup_overview/configure_data_security/?tab=mongodb#replace-rules-for-tag-filtering
[17]: https://www.datadoghq.com/blog/troubleshoot-lambda-function-request-response-payloads/
-[18]: https://docs.datadoghq.com/ko/integrations/guide/source-code-integration
\ No newline at end of file
+[18]: https://docs.datadoghq.com/ko/integrations/guide/source-code-integration
+[19]: https://docs.datadoghq.com/ko/security/application_security/
\ No newline at end of file
diff --git a/content/ko/synthetics/guide/reusing-browser-test-journeys.md b/content/ko/synthetics/guide/reusing-browser-test-journeys.md
index f024fc814bb..e71e5962b22 100644
--- a/content/ko/synthetics/guide/reusing-browser-test-journeys.md
+++ b/content/ko/synthetics/guide/reusing-browser-test-journeys.md
@@ -9,7 +9,7 @@ further_reading:
- link: https://www.datadoghq.com/blog/test-creation-best-practices/
tag: 블로그
text: 엔드 투 엔드 테스트 생성 모범 사례
-title: 브라우저 테스트 여정을 테스트 스위터 전체에 재사용하기
+title: 브라우저 테스트 여정을 테스트 스위트(suite) 전체에 재사용하기
---
## 개요
@@ -32,19 +32,19 @@ title: 브라우저 테스트 여정을 테스트 스위터 전체에 재사용
로그인 테스트를 만들고 테스트 스위트 전체에 하위 테스트로 사용하는 방법:
-1. 애플리케이션에 로그인만 하는 테스트 A를 만드세요. 테스트 A의 **Starting URL**을 로그인 전 URL로 설정하세요.
+1. 애플리케이션에 로그인만 하는 테스트를 만드세요. 테스트의 **시작 URL**을 로그인 전 URL로 설정하세요.
- {{< img src="synthetics/guide/reusing-browser-test-journeys/login_subtest_recording.mp4" alt="로그인 하위 테스트 레코딩" video="true" width="100%">}}
+ {{< img src="synthetics/guide/reusing-browser-test-journeys/login_subtest_recording_2.mp4" alt="로그인 하위 테스트 레코딩t" video="true" width="100%">}}
-2. 애플리케이션 로그인 후 기능을 모니터링하는 두 번째 테스트 테스트 B를 만드세요. 다음은 대시보드 생성을 모니터링하는 두 번째 테스트 예시입니다. 테스트 B의 **Starting URL**도 로그인 전 UR로 설정하세요.
+2. 애플리케이션 로그인 후 기능을 모니터링하는 두 번째 테스트를 만드세요. 다음은 대시보드 생성을 모니터링하는 두 번째 테스트 예시입니다. 테스트의 **시작 URL**도 로그인 전 UR로 설정하세요.
- {{< img src="synthetics/guide/reusing-browser-test-journeys/dashboard_test_configuration.png" alt="상위 테스트 구성" >}}
+ {{< img src="synthetics/guide/reusing-browser-test-journeys/dashboard_test_configuration_2.png" alt="상위 테스트 설정" >}}
-3. 테스트 B를 레코딩할 때 **Subset**을 클릭하고 로그인 테스트 A를 선택하세요.
+3. 두 번째 테스트를 레코딩할 때 **하위 테스트**를 클릭하고 1단계에서 생성한 로그인 테스트를 선택하세요.
- {{< img src="synthetics/guide/reusing-browser-test-journeys/dashboard_test_subtest.mp4" alt="상위 테스트에서 하위 테스트를 포함" video="true" width="100%">}}
+ {{< img src="synthetics/guide/reusing-browser-test-journeys/dashboard_subtest_2.mp4" alt="상위 테스트에 하위 테스트 포함" video="true" width="80%">}}
- 이렇게 하위 테스트 단계를 설정할 때 테스트 A에 포함된 모든 단계가 상위 테스트 B를 시작할 때 실행됩니다. 또 하위 테스트 A에 있는 변수를 상위 테스트 B에서 가져옵니다. 기본적으로 하위 테스트는 메인 탭에서 실행됩니다. 따라서 하위 테스트 단계가 이전 및 다음 단계가 실행되는 동일 탭에서 실행됩니다. 상위 테스트에 설정된 URL을 사용해 하위 테스트가 실행되고(이 경우 로그인 전 URL), 하위 테스트 단계가 모두 실행된 후 브라우저 테스트가 하위 테스트가 마지막으로 실행된 브라우저에 상위 테스트의 첫 단계를 실행합니다. 현재 상위 테스트는 생성하지 않은 상태입니다.
+ 이렇게 하위 테스트 단계를 설정할 때 로그인 테스트에 포함된 모든 단계가 상위 테스트를 시작할 때 실행됩니다. 또 하위 테스트에 있는 변수를 두 번째 테스트의 상위 테스트로 가져옵니다. 기본적으로 하위 테스트는 메인 탭에서 실행됩니다. 따라서 하위 테스트 단계가 이전 및 다음 단계가 실행되는 동일 탭에서 실행됩니다. 상위 테스트에 설정된 URL을 사용해 하위 테스트가 실행되고(이 경우 로그인 전 URL), 하위 테스트 단계가 모두 실행된 후 브라우저 테스트가 하위 테스트가 마지막으로 실행된 페이지에서 상위 테스트의 첫 비하위 테스트 단계를 실행합니다. 현재 상위 테스트는 생성하지 않은 상태입니다.
**참고:** [**Subtest Advanced Options**][1]을 사용해 하위 테스트가 있는 탭을 선택할 수 있습니다.
diff --git a/data/partials/platforms.es.yaml b/data/partials/platforms.es.yaml
index 05d8e369655..77bfb0b8754 100644
--- a/data/partials/platforms.es.yaml
+++ b/data/partials/platforms.es.yaml
@@ -24,130 +24,130 @@ gs:
link: https://app.datadoghq.com/account/settings/agent/latest?platform=centos
name: rockylinux
- image: platform_almalinux.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=centos
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=CentOS
name: almalinux
-- image: platform_fedora.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=fedora
+- image: plataforma_fedora.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=Fedora
name: fedora
-- image: platform_suse.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=suse
+- image: plataforma_suse.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=SUSE
name: suse
-- image: platform_aix.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=aix
+- image: plataforma_aix.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=aix
name: aix
-- image: platform_coreos.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=coreos
+- image: plataforma_coreos.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=coreos
name: coreos
-- image: platform_docker.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=docker
+- image: plataforma_docker.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=Docker
name: docker
-- image: platform_kubernetes.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=kubernetes
+- image: plataforma_kubernetes.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=Kubernetes
name: kubernetes
-- image: platform_openshift.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=openshift
+- image: plataforma_openshift.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=openshift
name: openshift
-- image: platform_chef.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=chef
+- image: plataforma_chef.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=chef
name: chef
-- image: platform_puppet.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=puppet
+- image: plataforma_marioneta.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=puppet
name: marioneta
-- image: platform_ansible.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=ansible
+- image: plataforma_ansible.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=ansible
name: ansible
-- image: platform_cloud_foundry.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=cloud_foundry
+- image: plataforma_nube_fundición.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=cloud_foundry
name: cloud_foundry
-- image: platform_saltstack.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=saltstack
+- image: plataforma_saltstack.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=saltstack
name: salt
-- image: platform_heroku.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=heroku
+- image: plataforma_heroku.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=Heroku
name: heroku
-- image: platform_fromsource.png
- link: https://app.datadoghq.com/account/settings/agent/latest?platform=source
+- image: plataforma_fromsource.png
+ link: https://app.datadoghq.com/account/settings/Agent/latest?platform=source
name: fuente
platforms:
- category: Linux
- image: platform_aix.png
- link: agent/basic_agent_usage/aix/
+ image: plataforma_aix.png
+ link: Agent/uso_agente_basico/aix/
name: aix
- category: Linux
- image: platform_almalinux.png
- link: agent/basic_agent_usage/centos/
+ image: plataforma_almalinux.png
+ link: Agent/uso_agente_basico/CentOS/
name: almalinux
- category: Linux
- image: platform_amazonlinux.png
- link: agent/basic_agent_usage/amazonlinux/
+ image: plataforma_amazonlinux.png
+ link: Agent/uso_agente_basico/amazonlinux/
name: amazonlinux
- category: configuration_management
- image: platform_ansible.png
- link: agent/basic_agent_usage/ansible/
+ image: plataforma_ansible.png
+ link: Agent/uso_agente_basico/ansible/
name: ansible
- category: Linux
- image: platform_centos.png
- link: agent/basic_agent_usage/centos/
+ image: plataforma_centos.png
+ link: Agent/uso_agente_basico/CentOS/
name: centos
- category: configuration_management
- image: platform_chef.png
- link: agent/basic_agent_usage/chef/
+ image: plataforma_chef.png
+ link: Agent/uso_agente_basico/chef/
name: chef
- category: Linux
- image: platform_debian.png
- link: agent/basic_agent_usage/deb/
+ image: plataforma_debian.png
+ link: Agent/uso_del_agente_basico/deb/
name: deb
- category: cloud_and_container
- image: platform_docker.png
- link: agent/docker/
+ image: plataforma_docker.png
+ link: Agent/Docker/
name: docker
- category: Linux
- image: platform_fedora.png
- link: agent/basic_agent_usage/fedora/
+ image: plataforma_fedora.png
+ link: Agent/uso_agente_basico/Fedora/
name: fedora
- category: cloud_and_container
- image: platform_heroku.png
- link: agent/basic_agent_usage/heroku/
+ image: plataforma_heroku.png
+ link: Agent/uso_agente_basico/Heroku/
name: heroku
- category: cloud_and_container
- image: platform_kubernetes.png
- link: agent/kubernetes/
+ image: plataforma_kubernetes.png
+ link: Agent/Kubernetes/
name: kubernetes
- category: macOS
- image: platform_macos.png
- link: agent/basic_agent_usage/osx/
+ image: plataforma_macos.png
+ link: Agent/uso_agente_basico/osx/
name: osx
- category: Linux
- image: platform_oracle.png
- link: agent/basic_agent_usage/oracle/
+ image: plataforma_oracle.png
+ link: Agent/uso_agente_basico/oracle/
name: Oracle
- category: configuration_management
- image: platform_puppet.png
- link: agent/basic_agent_usage/puppet/
+ image: plataforma_marioneta.png
+ link: Agent/uso_agente_basico/puppet/
name: puppet
- category: Linux
- image: platform_redhat.png
- link: agent/basic_agent_usage/redhat/
+ image: plataforma_redhat.png
+ link: Agent/uso_agente_basico/redhat/
name: redhat
- category: Linux
- image: platform_rockylinux.png
- link: agent/basic_agent_usage/centos/
+ image: plataforma_rockylinux.png
+ link: Agent/uso_agente_basico/CentOS/
name: rockylinux
- category: configuration_management
- image: platform_saltstack.png
- link: agent/basic_agent_usage/saltstack/
+ image: plataforma_saltstack.png
+ link: Agent/uso_agente_basico/saltstack/
name: salt
- category: Linux
- image: platform_suse.png
- link: agent/basic_agent_usage/suse/
+ image: plataforma_suse.png
+ link: Agent/uso_agente_basico/SUSE/
name: suse
- category: Linux
- image: platform_ubuntu.png
- link: agent/basic_agent_usage/ubuntu/
+ image: plataforma_ubuntu.png
+ link: Agent/uso_agente_basico/Ubuntu/
name: ubuntu
- category: Windows
- image: platform_windows.png
- link: agent/basic_agent_usage/windows/
+ image: plataforma_windows.png
+ link: Agent/uso_agente_basico/Windows/
name: windows
- category: Windows
image: platform_sccm.png
@@ -156,4 +156,4 @@ platforms:
- category: fuente
image: platform_fromsource.png
link: agent/basic_agent_usage/source/
- name: fuente
\ No newline at end of file
+ name: fuente