From f7650dd01891afe8b6e637df453b032bd65b7445 Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 10:27:00 +0000 Subject: [PATCH 1/8] Translated file updates --- .../guide/hourly-usage-migration.md | 207 +------ .../create-your-first-cloudcraft-diagram.md | 94 +++ .../diagram-multiple-cloud-accounts.md | 39 ++ content/ko/integrations/abnormal_security.md | 108 ++++ content/ko/integrations/tomcat.md | 358 ++++++++++++ content/ko/integrations/twemproxy.md | 173 ++++++ content/ko/integrations/varnish.md | 218 +++++++ .../legacy/setup/datadog.md | 504 ++++++++++++++++ .../guide/otlp_delta_temporality.md | 288 +++++++++ .../advanced_configuration/reactnative.md | 545 ++++++++++++++++++ .../incident_management/describe.md | 41 ++ .../guide/send_traces_to_agent_by_api.md | 58 +- 12 files changed, 2439 insertions(+), 194 deletions(-) create mode 100644 content/ko/cloudcraft/getting-started/create-your-first-cloudcraft-diagram.md create mode 100644 content/ko/cloudcraft/getting-started/diagram-multiple-cloud-accounts.md create mode 100644 content/ko/integrations/abnormal_security.md create mode 100644 content/ko/integrations/tomcat.md create mode 100644 content/ko/integrations/twemproxy.md create mode 100644 content/ko/integrations/varnish.md create mode 100644 content/ko/observability_pipelines/legacy/setup/datadog.md create mode 100644 content/ko/opentelemetry/guide/otlp_delta_temporality.md create mode 100644 content/ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/reactnative.md create mode 100644 content/ko/service_management/incident_management/describe.md diff --git a/content/ko/account_management/guide/hourly-usage-migration.md b/content/ko/account_management/guide/hourly-usage-migration.md index 847e4ea777d15..fbab3620ae13c 100644 --- a/content/ko/account_management/guide/hourly-usage-migration.md +++ b/content/ko/account_management/guide/hourly-usage-migration.md @@ -1,4 +1,6 @@ --- +description: V1 시간별 사용량 엔드포인트에서 제품군, JSON:API 형식, 페이지 매김 및 다중 조직 지원을 통해 통합된 V2 API로 + 마이그레이션하는 방법에 대해 알아보세요. further_reading: - link: /account_management/plan_and_usage/ tag: 설명서 @@ -6,9 +8,11 @@ further_reading: title: V1 월간 사용량 API에서 V2로 마이그레이션 --- -## 소개 -v1 API 사용자는 미세하게 다른 형식으로 표시되는 -v2 시간별 사용량 API의 친숙한 개념을 인식해야 합니다. +## 요약 +2025년 2월 1일에 제품 엔드포인트별 개별 시간당 사용량은 v2 [제품군별 시간당 사용량 API][1]로 대체되어 더 이상 사용되지 않습니다. + +v1 API 사용자는 통합된 v2 시간별 사용량 API를 사용할 수 있습니다. 비슷한 방식이나 +약간 다른 형식으로 표현되어 있습니다. v1 API와 v2 API의 가장 눈에 띄는 차이점은 v2 API가 다음의 성질을 지닌다는 점입니다. * 모든 제품을 하나의 엔드포인트로 통합 @@ -19,164 +23,11 @@ v1 API와 v2 API의 가장 눈에 띄는 차이점은 v2 API가 다음의 성질 각 차이점은 다음 섹션에서 자세히 설명합니다. ## 통합 제품군 -v2 API는 제품군 및 사용량 유형의 개념을 도입합니다. 제품군은 -하나 이상의 사용량 유형을 그룹화합니다. 사용량 유형은 지정된 조직과 기간의 사용량 측정치에 해당합니다. -제품군의 초기 집합은 대부분 v1 API와 일치합니다. -전체 매핑은 아래에서 설명합니다. 다른 모든 제품군의 사용량을 -검색하는 특별한 `all` 제품군도 있습니다. - -제품군 및 사용량 유형: -- **all** - * _Contains all other product families_ -- **analyzed_logs** - * `analyzed_logs` -- **application_security** - * `app_sec_host_count` -- **audit_trail** - * `enabled` -- **serverless** - * `func_count` - * `invocations_sum` -- **ci_app** - * `ci_pipeline_indexed_spans` - * `ci_test_indexed_spans` - * `ci_visibility_pipeline_committers` - * `ci_visibility_test_committers` -- **cloud_cost_management** - * `host_count` -- **csm_container_enterprise** - * `cws_count` - * `compliance_count` - * `total_count` -- **csm_host_enterprise** - * `total_host_count` - * `compliance_hosts` - * `cws_hosts` - * `aas_host_count` - * `azure_host_count` - * `aws_host_count` - * `gcp_host_count` -- **cspm** - * `aas_host_count` - * `azure_host_count` - * `compliance_host_count` - * `container_count` - * `host_count` -- **cws** - * `cws_container_count` - * `cws_host_count` -- **dbm** - * `dbm_host_count` - * `dbm_queries_count` -- **fargate** - * `avg_profiled_fargate_tasks` - * `tasks_count` -- **infra_hosts** - * `agent_host_count` - * `alibaba_host_count` - * `apm_azure_app_service_host_count` - * `apm_host_count` - * `aws_host_count` - * `azure_host_count` - * `container_count` - * `gcp_host_count` - * `heroku_host_count` - * `host_count` - * `infra_azure_app_service` - * `opentelemetry_host_count` - * `vsphere_host_count` -- **incident_management** - * `monthly_active_users` -- **indexed_logs** - * `logs_indexed_events_3_day_count` - * `logs_live_indexed_events_3_day_count` - * `logs_rehydrated_indexed_events_3_day_count` - * `logs_indexed_events_7_day_count` - * `logs_live_indexed_events_7_day_count` - * `logs_rehydrated_indexed_events_7_day_count` - * `logs_indexed_events_15_day_count` - * `logs_live_indexed_events_15_day_count` - * `logs_rehydrated_indexed_events_15_day_count` - * `logs_indexed_events_30_day_count` - * `logs_live_indexed_events_30_day_count` - * `logs_rehydrated_indexed_events_30_day_count` - * `logs_indexed_events_45_day_count` - * `logs_live_indexed_events_45_day_count` - * `logs_rehydrated_indexed_events_45_day_count` - * `logs_indexed_events_60_day_count` - * `logs_live_indexed_events_60_day_count` - * `logs_rehydrated_indexed_events_60_day_count` - * `logs_indexed_events_90_day_count` - * `logs_live_indexed_events_90_day_count` - * `logs_rehydrated_indexed_events_90_day_count` - * `logs_indexed_events_180_day_count` - * `logs_live_indexed_events_180_day_count` - * `logs_rehydrated_indexed_events_180_day_count` - * `logs_indexed_events_360_day_count` - * `logs_live_indexed_events_360_day_count` - * `logs_rehydrated_indexed_events_360_day_count` - * `logs_indexed_events_custom_day_count` - * `logs_live_indexed_events_custom_day_count` - * `logs_rehydrated_indexed_events_custom_day_count` -- **indexed_spans** - * `indexed_events_count` - * `ingested_spans` - * `ingested_events_bytes` -- **iot** - * `iot_device_count` -- **lambda_traced_invocations** - * `lambda_traced_invocations_count` -- **logs** - * `billable_ingested_bytes` - * `indexed_events_count` - * `ingested_events_bytes` - * `logs_forwarding_events_bytes` - * `logs_live_indexed_count` - * `logs_live_ingested_bytes` - * `logs_rehydrated_indexed_count` - * `logs_rehydrated_ingested_bytes` -- **network_flows** - * `indexed_events_count` -- **network_hosts** - * `host_count` -- **observability_pipelines** - * `observability_pipelines_bytes_processed` -- **online_archive** - * `online_archive_events_count` -- **profiling** - * `avg_container_agent_count` - * `host_count` -- **rum** - * `browser_rum_units` - * `mobile_rum_units` - * `rum_units` -- **rum_browser_sessions** - * `replay_session_count` - * `session_count` -- **rum_mobile_sessions** - * `session_count` - * `session_count_android` - * `session_count_ios` - * `session_count_reactnative` - * `session_count_flutter` -- **sds** - * `logs_scanned_bytes` - * `total_scanned_bytes` -- **snmp** - * `snmp_devices` -- **synthetics_api** - * `check_calls_count` -- **synthetics_browser** - * `browser_check_calls_count` -- **synthetics_mobile** - * `test_runs` -- **timeseries** - * `num_custom_input_timeseries` - * `num_custom_output_timeseries` - * `num_custom_timeseries` - - -이 목록은 위의 제품군 및 사용량 유형이 v1 시간별 사용량 엔드포인트가 어떻게 매핑되는지 보여줍니다. 사용량 유형과 데이터 포인트는 달리 명시적으로 언급된 경우를 제외하고는 동일합니다. +v2 API에는 제품군 및 사용 유형 개념이 도입되었습니다. 제품군은 +하나 이상의 사용 유형으로 이루어진 그룹을 뜻합니다. 사용 유형은 특정 조직 및 +기간에 대한 사용량 측정값입니다. `all`을 선택하면 모든 제품군의 사용량을 검색할 수 있으며, 특정 제품군별로 필터링도 가능합니다. + +아래 목록은 제품군 및 사용 유형이 v1 시간별 사용량 엔드포인트에 어떻게 매핑되는지 보여줍니다. 사용 유형과 데이터 포인트는 명시적으로 언급된 경우를 제외하고는 동일합니다. 엔드포인트 | 제품군 `/api/v1/usage/hosts` | infra_hosts @@ -228,15 +79,8 @@ v2 API는 제품군 및 사용량 유형의 개념을 도입합니다. 제품군 : `func_count` : `invocations_sum` -`/api/v1/usage/rum_sessions?type=browser` | rum_browser_sessions -: `replay_session_count` -: `session_count` - -`/api/v1/usage/rum_sessions?type=mobile` | rum_mobile_sessions -: `session_count` -: `session_count_android` -: `session_count_ios` -: `session_count_reactnative` +`/api/v1/usage/rum_sessions` | rum +: 전체 매핑 지침은 [RUM 마이그레이션 가이드][2]를 참조하세요. `/api/v1/usage/network_hosts` | network_hosts : `host_count` @@ -276,9 +120,6 @@ v2 API는 제품군 및 사용량 유형의 개념을 도입합니다. 제품군 : `container_count` : `host_count` -`/api/v1/usage/audit_logs` | audit_logs -: `lines_indexed` - `/api/v1/usage/cws` | cws : `cws_container_count` : `cws_host_count` @@ -291,11 +132,6 @@ v2 API는 제품군 및 사용량 유형의 개념을 도입합니다. 제품군 : `logs_scanned_bytes` : `total_scanned_bytes` -`/api/v1/usage/rum` | rum -: `browser_rum_units` -: `mobile_rum_units` -: `rum_units` - `/api/v1/usage/ci-app` | ci_app : `ci_pipeline_indexed_spans` : `ci_test_indexed_spans` @@ -316,11 +152,11 @@ v2 API는 제품군 및 사용량 유형의 개념을 도입합니다. 제품군 ## JSON:API 준수 형식 -응답 본문 및 파라미터 이름은 [JSON:API 사양][1]을 준수합니다. v1 API에서 사용할 수 있는 모든 데이터는 -계속 사용할 수 있습니다. v1 호스트 API에서 -v2 시간별 사용량 API로의 매핑에 대한 예시는 아래를 참조하세요. +응답 본문과 파라미터 이름은 [JSON:API 사양][3]을 준수합니다. v1에서 사용할 수 있는 모든 데이터 +를 계속 사용할 수 있습니다. 아래에서 v1 호스트에서 v2 시간당 사용량 API로의 +매핑 예시를 참조하세요. -### V1 API: [호스트 및 컨테이너의 시간당 사용량 가져오기][2] +### V1 API: 호스트와 컨테이너의 시간당 사용량을 확인하세요. #### 요청 @@ -457,7 +293,7 @@ v2 시간별 사용량 API로의 매핑에 대한 예시는 아래를 참조하 * 사용량 측정 오브젝트에는 `usage_type` 및 `value` 필드가 있습니다. * `hour`, `org_name` 및 `public_id`도 `attributes` 오브젝트의 필드입니다. -## 페이지 지정 +## 페이지 매기기 v2 시간별 사용량 API에는 페이지가 지정됩니다. 응답은 500페이지로 제한되며 한 페이지에는 한 제품군, 한시간, 한 조적의 사용량 데이터가 포함되어 있습니다. 페이지 지정을 통해 API는 요청당 여러 제품, 요청당 여러 조직 및 무제한 시간 범위 등 다양한 @@ -487,5 +323,6 @@ v2 API는 한 번의 요청으로 모든 리전에 속하는 모든 하위 조 {{< partial name="whats-next/whats-next.html" >}} -[1]: https://jsonapi.org/format/ -[2]: /ko/api/latest/usage-metering/#get-hourly-usage-for-hosts-and-containers \ No newline at end of file +[1]: /ko/api/latest/usage-metering/#get-hourly-usage-by-product-family +[2]: /ko/account_management/guide/relevant-usage-migration/#rum +[3]: https://jsonapi.org/format/ \ No newline at end of file diff --git a/content/ko/cloudcraft/getting-started/create-your-first-cloudcraft-diagram.md b/content/ko/cloudcraft/getting-started/create-your-first-cloudcraft-diagram.md new file mode 100644 index 0000000000000..f4c205dbaae3a --- /dev/null +++ b/content/ko/cloudcraft/getting-started/create-your-first-cloudcraft-diagram.md @@ -0,0 +1,94 @@ +--- +title: 첫 번째 라이브 클라우드 다이어그램 만들기 +--- + +Cloudcraft를 사용하면 AWS 및 Azure 클라우드 환경을 *라이브 다이어그램*으로 가져올 수 있습니다. Cloudcraft 은 클라우드 계정의 아키텍처를 리버스 엔지니어링하여 새 다이어그램을 자동 생성하거나 기존 다이어그램을 개선하여 몇 시간 또는 며칠의 작업 시간을 절약할 수 있습니다. + +
Cloudcraft 새로운 라이브 환경을 사용하는 경우, 대신 더 나은 다이어그램 만들기: Cloudcraft 의 라이브 다이어그램 작성 및 필터링을 참조하세요.
+ +## 사전 필수 조건 + +시작하기 전에 클라우드 계정을 Cloudcraft에 연결하세요. + +- AWS 계정의 경우 [AWS 계정과 Cloudcraft 계정 연결하기][1]를 참조하세요. +- Azure 계정의 경우 [Cloudcraft][2]로 Azure 계정 연결]을 참조하세요. + +## 최초의 라이브 다이어그램 + +클라우드 아키텍처를 스캔하고 시각화하려면 청사진을 새로 만듭니다. 청사진에는 다이어그램, 예산, 개별 구성 요소에 첨부하는 모든 문서가 포함됩니다. + +1. Cloudcraft에서 **AWS** 또는 **Azure** 탭을 선택한 다음 **라이브** 탭을 선택합니다. 이 가이드에서는 주로 AWS 계정에 중점을 둡니다. Azure 계정이 있는 경우 프로세스는 비슷합니다. + +**Live** 탭에서는 계정을 선택하고, 지역을 스캔하고, 레이아웃을 생성하고, 계정의 모든 리소스를 볼 수 있습니다. + +{{< img src="cloudcraft/getting-started/create-your-first-cloudcraft-diagram/live-tab.png" alt="Cloudcraft에서 AWS 및 Live 탭이 강조된 실시간 인프라 다이어그램" responsive="true" style="width:100%;">}} + +Cloudcraft에 AWS 계정을 하나만 추가한 경우 해당 계정이 자동으로 선택됩니다. 그렇지 않은 경우 드롭다운에서 계정을 선택합니다. + +2. 스캔할 지역을 선택합니다. 여러 지역을 스캔하여 하나의 다이어그램에 통합할 수도 있지만, 하나의 지역부터 시작하는 것이 좋습니다. + +**Scan now** 버튼 아래에는 **Live** 또는 **Snapshot**이라는 토글이 있어 어떤 종류의 다이어그램을 만들 것인지 애플리케이션에 알려줍니다. **Live**를 선택하면 다이어그램이 내 계정의 정보로 계속 업데이트됩니다. **Snapshot**을 선택하면 특정 시점 이미지가 생성되며, 이는 다이어그램이 자동으로 업데이트되지 않음을 의미합니다. + +이 예에서는 **Live* 옵션을 사용합니다. **Live** 토글을 활성화합니다. 옵션 오른쪽에 있는 톱니바퀴 아이콘은 다이어그램 업데이트를 위한 추가 사용자 지정 설정을 제공합니다. 이 가이드의 목적상 기본 상태로 두는 것이 좋습니다. + +{{< img src="cloudcraft/getting-started/create-your-first-cloudcraft-diagram/live-diagram-options.png" alt="ICloudcraft 인터페이스에서 토글을 Live로 설정하여 실시간 리소스 다이어그램을 표시한 화면." responsive="true" style="width:100%;">}} + +3. **Scan now**을 클릭하여 계정에서 [지원되는 AWS 구성요소][3]를 스캔합니다. 스캔이 완료되면* *Scan complete** 메시지가 표시됩니다. + +스캔이 완료되면 **자동 레이아웃** 버튼과 AWS 계정에서 지원되는 모든 구성 요소가 나타납니다. 즉시 수동으로 추가할 수도 있지만, 애플리케이션이 자동으로 레이아웃을 설정하도록 하는 것이 좋습니다. + +두 가지 방법으로 이를 달성할 수 있습니다. + +- **Auto layout** 기능 사용 +- **Filtered layout** 기능 사용 + +**Auto layout** 기능은 모든 구성 요소를 다이어그램에 추가하고 그 연결과 관계를 보여주기 때문에 가장 간단합니다. 예를 들어, **Auto layout**을 구성하여 다른 모든 구성 요소는 제외하고 EC2 인스턴스만 표시하도록 할 수 있습니다. + +이 설명서의 다이어그램 유형은 **Live*로, AWS 계정에서 EC2 인스턴스를 제거하면 변경 사항이 다이어그램에 반영된다는 의미입니다. + +**Filtered Layout** 기능은 패턴과 일치하는 다이어그램을 만들 수 있으므로 클라우드 아키텍처를 다이어그램화하는 보다 고급적이고 강력한 방법입니다. 예를 들어 `environment=production` 및 `environment=staging`으로 태그된 리소스가 많지만 프로덕션에 있는 구성 요소만 다이어그램에 추가하려는 경우 `environment=production`으로 필터링하면 이 값과 키의 정확한 조합으로 태그된 구성 요소만 포함될 수 있습니다. + +클라우드 제공업체에서 리소스에 태그를 지정하지 않아도 필터 기능을 사용할 수 있습니다. 예를 들어 전원이 꺼진 EC2 인스턴스만 있는 다이어그램을 만들려면 `ec2 !running` 필터를 사용할 수 있습니다. + +다음 동영상은 **Filtered layout**의 힘을 보여줍니다. AWS에서 영업팀은 Cloudcraft 데모와 관련된 여러 리소스에 키 `Environment`와 값 `Demo`를 태그합니다. 데모하려는 내용과 각 구성 요소가 서로 어떻게 연결되는지 보려면 **Live** 탭 바로 아래의 검색창에서 `Environment=demo` 필터를 사용하면 됩니다. + +{{< img src="cloudcraft/getting-started/create-your-first-cloudcraft-diagram/filtered-layout-example-video.mp4" alt="Cloudcraft에서 사용자가 필터링된 다이어그램을 생성하는 과정을 보여주는 11초 분량의 영상" video="true">}} + +`Environment=demo`로 레이블이 지정된 구성 요소는 AWS에 해당 리소스에 태그가 지정되어 있지 않더라도 해당 VPC, 서브넷, 보안 그룹 내에 표시됩니다. WAF는 동일한 태그를 가지고 있음에도 불구하고 AWS API가 WAF와 나머지 구성 요소 간의 연결을 나타내지 않기 때문에 VPC 외부에 배치됩니다. + +구성 요소가 서로 연결되는 방식은 서비스에 따라 다릅니다. Cloudcraft에서는 사용 가능한 모든 클라우드 API를 사용하여 가능한 한 관계를 검색합니다. + +4. **Auto Layout** 기능을 계속 구성하려면 **Live/Snapshot** 토글 아래에서 **Auto Layout**을 선택합니다. + +새 대화 상자에서 다이어그램에 포함할 AWS 구성 요소를 결정할 수 있습니다. 대화 상자에는 세 가지 옵션 중 하나를 선택할 수 있는 **Options** 드롭다운 메뉴도 포함되어 있습니다: + +- 기존 구성 요소를 교체합니다. +- 기존 구성 요소를 포함합니다. +- 기존 구성 요소를 그대로 둡니다. + +이 옵션은 이미 구성 요소가 있는 다이어그램에서 **Auto layout**을 사용하는 경우 애플리케이션에 실행할 작업을 알려줍니다. + +- **Replace existing components**를 선택하면 다이어그램에 이미 있는 모든 구성 요소가 새 구성 요소로 바뀝니다. +- **Include existing components**을 선택하면 애플리케이션이 다이어그램의 모든 구성 요소만 아니라 인벤토리의 모든 구성 요소에 대해 자동 레이아웃을 실행합니다. +- **Leave existing components**를 선택하면 다이어그램의 구성 요소는 변경되지 않지만 애플리케이션에서 새 구성 요소에 대한 자동 레이아웃을 실행합니다. + +새 다이어그램을 만들고 있으므로 메뉴에서 *Replace existing components**를 선택합니다. **Layout**을 선택하면 인벤토리에 있는 모든 구성 요소가 연결되어 다이어그램에 자동으로 추가됩니다. + +{{< img src="cloudcraft/getting-started/create-your-first-cloudcraft-diagram/auto-layout-diagram.png" alt="Cloudcraft에서 생성된 대화형 AWS 인프라 다이어그램으로, 구성 요소가 자동 레이아웃으로 배치되고 연결선이 보이는 격자 배경 위에 표시됨." responsive="true" style="width:100%;">}} + +다이어그램은 사용자 정의가 가능하므로 각 구성 요소와 관련된 실시간 데이터를 관찰하면서 **Design** 탭의 요소를 사용하여 모양을 개선할 수 있습니다. + +구성 요소를 선택하면 화면 왼쪽 하단에 **Live feed** 대화 상자가 나타나고 선택한 구성 요소에 대한 실시간 정보가 표시됩니다. + +{{< img src="cloudcraft/getting-started/create-your-first-cloudcraft-diagram/live-feed.png" alt="대화형 클라우드 인프라 다이어그램에서 EC2 인스턴스가 강조 표시되어 있으며, 라이브 피드 정보 대화 상자가 인스턴스 세부 정보와 상태를 표시" responsive="true" style="width:100%;">}} + +## 새로운 라이브 경험 + +Cloudcraft는 사용자 경험을 개선하고 클라우드 인프라 다이어그램 작성 프로세스를 간소화하기 위한 지속적인 노력의 일환으로 개선된 라이브 환경을 도입했습니다. 이 업데이트된 환경은 모든 사용자가 액세스할 수 있으며 신규 사용자를 위한 표준 환경으로 설정되었습니다. + +자세한 내용은 [더 나은 다이어그램 만들기: Cloudcraft 라이브 다이어그램 작성 및 필터링][4]을 참조하세요. + +[1]: /ko/cloudcraft/getting-started/connect-aws-account-with-cloudcraft/ +[2]: /ko/cloudcraft/getting-started/connect-azure-account-with-cloudcraft/ +[3]: /ko/cloudcraft/faq/supported-aws-components/ +[4]: /ko/cloudcraft/getting-started/crafting-better-diagrams/ \ No newline at end of file diff --git a/content/ko/cloudcraft/getting-started/diagram-multiple-cloud-accounts.md b/content/ko/cloudcraft/getting-started/diagram-multiple-cloud-accounts.md new file mode 100644 index 0000000000000..abb94eaaa7b40 --- /dev/null +++ b/content/ko/cloudcraft/getting-started/diagram-multiple-cloud-accounts.md @@ -0,0 +1,39 @@ +--- +title: 여러 클라우드 계정 다이어그램 +--- + +Cloudcraft는 원활하고 효율적인 방식으로 클라우드 아키텍처를 시각화하고 계획할 수 있도록 설계된 도구입니다. 이 가이드에서는 Cloudcraft 내의 레거시 환경을 사용하여 여러 클라우드 계정을 다이어그램화하는 방법을 설명합니다. 다음 단계에 따라 여러 클라우드 계정을 하나의 일관된 다이어그램으로 통합하세요. + + + +## 1. 레거시 환경 사용 + +여러 클라우드 계정으로 작업하려면 레거시 다이어그램 환경을 사용하도록 설정해야 합니다. + +1. Cloudcraft를 열고 **Live** 탭으로 이동합니다. +2. **New Live Experience** 토글을 찾아서 **off**로 설정되어 있는지 확인합니다. + +{{< img src="cloudcraft/getting-started/diagram-multiple-cloud-accounts/new-live-experience-toggle.png" alt="여러 클라우드 계정에 대한 새로운 라이브 경험 토글을 보여주는 Cloudcraft 인터페이스" responsive="true" style="width:100%;">}} + +## 2. 첫 번째 계정 배열 + +레거시 환경을 사용하도록 설정한 후 첫 번째 계정을 배치합니다. + +1. 시각화하려는 초기 클라우드 계정을 선택합니다. +2. 이 계정 검사를 시작하여 현재 아키텍처 세부 정보를 수집합니다. +3. **Auto Layout** 버튼을 선택하면 다이어그램 내에서 이 계정의 구성 요소를 자동으로 배열할 수 있습니다. + +## 3. 두 번째 계정 배열 + +첫 번째 계정을 성공적으로 배열한 후에는 다이어그램에 더 많은 계정을 추가할 수 있습니다. + +1. 추가하려는 두 번째 클라우드 계정을 선택합니다. +2. 두 번째 계정에 대한 검사를 실행하여 아키텍처를 캡처합니다. +3. **Auto Layout**을 선택합니다. +4. **Options* 드롭다운에 액세스하여 **Include existing components**를 선택합니다. 이 작업은 첫 번째 계정의 구성 요소가 계속 표시되도록 하므로, 두 계정이 하나의 다이어그램에 통합됩니다. + +{{< img src="cloudcraft/getting-started/diagram-multiple-cloud-accounts/auto-layout-options.png" alt="AWS 인벤토리와 라이브 구성 요소 옵션을 보여주는 Cloudcraft 인터페이스" responsive="true" style="width:100%;">}} + +
이 과정을 반복하여 다이어그램에 더 많은 계정을 포함할 수 있습니다.
+ +위의 단계에 따라 하나의 Cloudcraft 다이어그램에서 여러 클라우드 계정을 통합하여 볼 수 있습니다. 레이아웃을 검토하여 필요한 모든 구성 요소가 포함되어 있고 원하는 대로 배열되었는지 확인합니다. 명확성이나 표현을 개선하기 위해 필요한 경우 수동으로 배열를 조정하세요. \ No newline at end of file diff --git a/content/ko/integrations/abnormal_security.md b/content/ko/integrations/abnormal_security.md new file mode 100644 index 0000000000000..26f482fc8ab86 --- /dev/null +++ b/content/ko/integrations/abnormal_security.md @@ -0,0 +1,108 @@ +--- +app_id: abnormal-security +app_uuid: 15f718fe-3819-4305-9681-ce80974c1b4b +assets: + dashboards: + abnormal-security-overview: assets/dashboards/abnormal_security_overview.json + integration: + auto_install: true + events: + creates_events: false + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 21175237 + source_type_name: Abnormal Security +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- security +- 로그 수집 +custom_kind: 통합 +dependencies: [] +display_on_public_website: true +draft: false +git_integration_title: abnormal_security +integration_id: abnormal-security +integration_title: Abnormal Security +integration_version: '' +is_public: true +manifest_version: 2.0.0 +name: abnormal_security +public_title: Abnormal Security +short_description: Abnormal Security를 통합하여 위협, 사례, 감사 로그를 확보하세요. +supported_os: +- linux +- 윈도우즈(Windows) +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Category::Security + - Category::Log Collection + - Offering::Integration + configuration: README.md#Setup + description: Abnormal Security를 통합하여 위협, 사례, 감사 로그를 확보하세요. + media: + - caption: Abnormal 개요 대시보드 + image_url: images/overview-dashboard.png + media_type: 이미지 + overview: README.md#Overview + support: README.md#Support + title: Abnormal Security +--- + + +## 개요 + +Abnormal Security는 사람의 행동을 이해하는 플랫폼을 사용하여 포괄적인 이메일 보호 기능을 제공합니다. 피싱, 소셜 엔지니어링, 계정 탈취 등 사람의 행동을 악용하는 공격으로부터 보호합니다. + +Datadog와 Abnormal Security를 통합하면 [Abnormal Security의 API][1]를 사용하여 로그를 수집하므로 세 가지 유형의 로그를 생성할 수 있습니다. +- **Threat Logs**: 위협 로그에는 조직, 데이터 또는 직원에게 해를 끼칠 수 있는 모든 악의적인 활동이나 공격이 포함됩니다. +- **Case Logs**: 사례 로그에는 Abnormal Security에서 식별한 이상 사례가 포함됩니다. 이러한 사례에는 일반적으로 관련 위협이 포함됩니다. +- **Audit Logs**: 이 로그에는 Abnormal Portal에서 실행한 작업이 포함됩니다. + + +## 설정 + +### 구성 + +1. [Abnormal Security Account][2]에 로그인합니다. +2. **Abnormal REST API**를 클릭합니다. +3. Abnormal Portal에서 인증 토큰을 검색합니다. + +이 토큰은 Abnormal에서 탐지된 위협, 사례, 감사 로그를 확인하는 데 사용됩니다. + +### 검증 + + +## 수집한 데이터 + +### 메트릭 + +Abnormal Security 통합은 메트릭을 포함하지 않습니다. + +### 로그 수집 + +Abnormal Security 인시던트, 사례, 감사 로그는 `abnormal-security` 소스 아래에 표시됩니다. + +### 이벤트 + +Abnormal Security 통합은 이벤트를 포함하지 않습니다. + +### 서비스 점검 + +Abnormal Security 통합은 서비스 점검을 포함하지 않습니다. + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][3]에 문의하세요. + +[1]: https://app.swaggerhub.com/apis/abnormal-security/abx/1.4.3#/info +[2]: https://portal.abnormalsecurity.com/home/settings/integrations +[3]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/tomcat.md b/content/ko/integrations/tomcat.md new file mode 100644 index 0000000000000..966ea61b5e8bc --- /dev/null +++ b/content/ko/integrations/tomcat.md @@ -0,0 +1,358 @@ +--- +app_id: tomcat +app_uuid: 9497c2d8-63cb-4d90-b73c-f32065349fe1 +assets: + dashboards: + tomcat: assets/dashboards/metrics.json + tomcat--overview: assets/dashboards/overview.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: tomcat.threads.count + metadata_path: metadata.csv + prefix: tomcat. + process_signatures: + - java tomcat + - java org.apache.catalina.startup.Bootstrap + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 43 + source_type_name: Tomcat + monitors: + All threads are busy: assets/monitors/thread_count_max.json + Busy threads number is high: assets/monitors/thread_busy.json + Error rate is high: assets/monitors/error_count.json + Processing time has a spike: assets/monitors/max_proc_time.json + Processing time is anomalous: assets/monitors/processing_time.json + Request rate is anomalous: assets/monitors/req_count.json + saved_views: + tomcat_4xx: assets/saved_views/tomcat_4xx.json + tomcat_5xx: assets/saved_views/tomcat_5xx.json + tomcat_overview: assets/saved_views/tomcat_overview.json + tomcat_processes: assets/saved_views/tomcat_processes.json + tomcat_status_code_overview: assets/saved_views/tomcat_status_code_overview.json +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- caching +- log collection +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/tomcat/README.md +display_on_public_website: true +draft: false +git_integration_title: tomcat +integration_id: tomcat +integration_title: Tomcat +integration_version: 4.0.0 +is_public: true +manifest_version: 2.0.0 +name: tomcat +public_title: Tomcat +short_description: 초당 요청, 제공된 바이트, 캐시 히트, servlet 메트릭 등을 추적하세요. +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Caching + - Category::Log Collection + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Offering::Integration + configuration: README.md#Setup + description: 초당 요청, 제공된 바이트, 캐시 히트, servlet 메트릭 등을 추적하세요. + media: [] + overview: README.md#Overview + resources: + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/monitor-tomcat-metrics + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/tomcat-architecture-and-performance + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/analyzing-tomcat-logs-and-metrics-with-datadog + support: README.md#Support + title: Tomcat +--- + + + + +![Tomcat 대시보드][1] + +## 개요 + +이 점검은 Tomcat 메트릭을 수집합니다. 예: + +- 전체 활동 메트릭: 오류 수, 요청 수, 처리 시간 등 +- 스레드 풀 메트릭: 스레드 수, 사용 중인 스레드 수 등 +- Sevlet 처리 시간 + +## 설정 + +### 설치 + +Tomcat 점검은 [Datadog Agent[2]] 패키지에 포함되어 있으므로 Tomcat 서버에 아무 것도 설치할 필요가 없습니다. + +이 점검은 JMX 기반이므로, Tomcat 서버에서 JMX Remote를 활성화해야 합니다. [Tomcat 모니터링 및 관리][3]의 지침을 따릅니다. + +### 구성 + +{{< tabs >}} +{{% tab "Host" %}} + +#### 호스트 + +호스트에서 실행 중인 에이전트에 대해 이 점검을 구성하려면: + +1. `tomcat.d/conf.yaml` 파일을 [Agent 설정 디렉터리][1] 루트에 있는 `conf.d/` 폴더에서 수정하여 Tomcat 메트릭과 [로그](#log-collection)를 수집하세요. 사용 가능한 모든 설정 옵션은 [샘플 tomcat.d/conf.yaml][2]에서 확인할 수 있습니다. + +2. [에이전트를 재시작][3]하세요. + +모든 JMX 기반 점검에서 사용할 수 있는 구성 옵션 목록은 [JMX 점검 설명서][4]를 참조하세요. + +#### 메트릭 목록 + +`conf` 파라미터는 연동에서 수집할 지표의 목록입니다. 두 개의 키만 허용됩니다. + +- `include` (**필수**): 필터 사전입니다. 이 필터와 일치하는 모든 속성은 `exclude` 필터와도 일치하지 않는 한 수집됩니다(아래 참조). +- `exclude` (**옵션**): 필터 사전입니다. 이 필터와 일치하는 속성은 수집되지 않습니다. + +주어진 bean에 메트릭은 다음과 같은 방식으로 태그가 지정됩니다. + +```text +mydomain:attr0=val0,attr1=val1 +``` + +이 예제에서 메트릭은 `mydomain` (또는 bean 내부의 속성에 따라 일부 변형)이며 `attr0:val0`, `attr1:val1`, `domain:mydomain` 태그가 있습니다. + +`include` 키에 _카멜(camel) 케이스_ 형식의 별칭을 지정하면 _스네이크(snake) 케이스_로 변환됩니다. 예를 들어 `MyMetricName`는 Datadog에서 `my_metric_name`로 표시됩니다. + +##### 속성 필터 + +`attribute` 필터는 다음 두 가지 유형의 값을 허용합니다. + +- 키가 속성 이름인 사전입니다(아래 참조). 이 경우 Datadog에서 메트릭의 별칭을 지정해 메트릭 이름으로 사용할 수 있습니다. 메트릭 유형을 게이지 또는 카운터로 지정할 수도 있습니다. 카운터를 선택하면 해당 메트릭의 초당 비율이 계산됩니다. + + ```yaml + conf: + - include: + attribute: + maxThreads: + alias: tomcat.threads.max + metric_type: gauge + currentThreadCount: + alias: tomcat.threads.count + metric_type: gauge + bytesReceived: + alias: tomcat.bytes_rcvd + metric_type: counter + ``` + +- 속성 이름 목록입니다(아래 참조). 이 경우 메트릭 유형은 게이지이고 메트릭 이름은 `jmx.\[DOMAIN_NAME].\[ATTRIBUTE_NAME]`입니다. + + ```yaml + conf: + - include: + domain: org.apache.cassandra.db + attribute: + - BloomFilterDiskSpaceUsed + - BloomFilterFalsePositives + - BloomFilterFalseRatio + - Capacity + - CompressionRatio + - CompletedTasks + - ExceptionCount + - Hits + - RecentHitRate + ``` + +#### 로그 수집 + + +1. Datadog에 로그를 제출하려면 Tomcat은 `log4j` 로거를 사용합니다. 8.0 이전 버전의 Tomcat의 경우 `log4j`가 기본적으로 구성됩니다. Tomcat 8.0 이상의 경우 `log4j`를 사용하도록 Tomcat을 구성해야 합니다([Log4j 사용하기][5] 참조). 해당 지침의 첫 번째 단계에서 `$CATALINA_BASE/lib` 디렉터리에 있는 `log4j.properties` 파일을 다음과 같이 편집합니다. + + ```conf + log4j.rootLogger = INFO, CATALINA + + # Define all the appenders + log4j.appender.CATALINA = org.apache.log4j.DailyRollingFileAppender + log4j.appender.CATALINA.File = /var/log/tomcat/catalina.log + log4j.appender.CATALINA.Append = true + + # Roll-over the log once per day + log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout + log4j.appender.CATALINA.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n + + log4j.appender.LOCALHOST = org.apache.log4j.DailyRollingFileAppender + log4j.appender.LOCALHOST.File = /var/log/tomcat/localhost.log + log4j.appender.LOCALHOST.Append = true + log4j.appender.LOCALHOST.layout = org.apache.log4j.PatternLayout + log4j.appender.LOCALHOST.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n + + log4j.appender.MANAGER = org.apache.log4j.DailyRollingFileAppender + log4j.appender.MANAGER.File = /var/log/tomcat/manager.log + log4j.appender.MANAGER.Append = true + log4j.appender.MANAGER.layout = org.apache.log4j.PatternLayout + log4j.appender.MANAGER.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n + + log4j.appender.HOST-MANAGER = org.apache.log4j.DailyRollingFileAppender + log4j.appender.HOST-MANAGER.File = /var/log/tomcat/host-manager.log + log4j.appender.HOST-MANAGER.Append = true + log4j.appender.HOST-MANAGER.layout = org.apache.log4j.PatternLayout + log4j.appender.HOST-MANAGER.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n + + log4j.appender.CONSOLE = org.apache.log4j.ConsoleAppender + log4j.appender.CONSOLE.layout = org.apache.log4j.PatternLayout + log4j.appender.CONSOLE.layout.ConversionPattern = %d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n + + # Configure which loggers log to which appenders + log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost] = INFO, LOCALHOST + log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager] =\ + INFO, MANAGER + log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager] =\ + INFO, HOST-MANAGER + ``` + 그런 다음 [Tomcat 설명서][5]의 나머지 단계에 따라 `log4j`를 구성합니다. + +2. 기본적으로 Datadog 통합 파이프라인은 다음과 같은 전환 패턴을 지원합니다. + + ```text + %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n + %d [%t] %-5p %c - %m%n + ``` + + 다른 형식이 있는 경우 [통합 파이프라인][6]을 복제하여 편집하세요. Tomcat 로깅 기능에 대한 자세한 내용은 [Tomcat에서 로깅하기][7]를 참조하세요. + +3. Datadog 에이전트에서 로그 수집은 기본적으로 사용하지 않도록 설정되어 있습니다. `datadog.yaml`파일에서 로그 수집을 사용하도록 설정합니다. + + ```yaml + logs_enabled: true + ``` + +4. 이 구성 블록을 `tomcat.d/conf.yaml` 파일에 추가하여 Tomcat 로그 수집을 시작하세요. + + ```yaml + logs: + - type: file + path: /var/log/tomcat/*.log + source: tomcat + service: "" + #To handle multi line that starts with yyyy-mm-dd use the following pattern + #log_processing_rules: + # - type: multi_line + # name: log_start_with_date + # pattern: \d{4}\-(0?[1-9]|1[012])\-(0?[1-9]|[12][0-9]|3[01]) + ``` + + `path` 및 `service` 파라미터 값을 변경하고 사용자 환경에 맞게 구성합니다. 사용 가능한 모든 구성 옵션은 [샘플 tomcat.yaml][2]을 참조하세요. + +5. [에이전트를 재시작][3]하세요. + +[1]: https://docs.datadoghq.com/ko/agent/guide/agent-configuration-files/#agent-configuration-directory +[2]: https://github.com/DataDog/integrations-core/blob/master/tomcat/datadog_checks/tomcat/data/conf.yaml.example +[3]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[4]: https://docs.datadoghq.com/ko/integrations/java/ +[5]: https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j +[6]: https://docs.datadoghq.com/ko/logs/processing/#integration-pipelines +[7]: https://tomcat.apache.org/tomcat-7.0-doc/logging.html +{{% /tab %}} +{{% tab "컨테이너화" %}} + +#### 컨테이너화 + +컨테이너화된 환경의 경우 [JMX를 사용한 자동탐지][1] 가이드를 참조하세요. + +[1]: https://docs.datadoghq.com/ko/agent/guide/autodiscovery-with-jmx/?tab=containerizedagent +{{% /tab %}} +{{< /tabs >}} + +### 검증 + +[Agent 상태 하위 명령][4]을 실행하고 **Checks** 섹션에서 `tomcat`을 찾습니다. + +## 수집한 데이터 + +### 메트릭 +{{< get-metrics-from-git "tomcat" >}} + + +### 이벤트 + +Tomcat 점검에는 이벤트가 포함되지 않습니다. + +### 서비스 점검 +{{< get-service-checks-from-git "tomcat" >}} + + +## 트러블슈팅 + +### 누락된 `tomcat.*` 메트릭 + +Datadog Agent는 Datadog Agent 버전 **7.49.0** 이상에서 `Catalina` 또는 `Tomcat`을 빈 도메인 이름으로 사용하여 JMX 메트릭을 수집합니다. 이전 버전에서는 `Catalina`를 빈 도메인 이름으로 사용하는 메트릭만 수집했습니다. +독립 실행형 Tomcat 배포에는 `Catalina` 도메인에 메트릭이 포함되지만, 임베디드 Tomcat 배포(예: Spring Boot)에는 `Tomcat` 도메인에 메트릭이 포함됩니다. + +버전이 **7.49.0**보다 오래된 경우 및 Datadog Agent 버전이 **7.49.0**보다 이전 버전이고 노출된 Tomcat 메트릭에 `Tomcat`가 같은 다른 빈 도메인 이름이 접두사로 붙은 경우, `metrics.yaml` 파일의 기본 메트릭을 `tomcat.d/conf.yaml` 파일의 `conf` 섹션으로 복사하고 해당 빈 도메인 이름을 사용하도록 `domain` 필터를 수정합니다. + +```yaml +- include: + domain: Tomcat + type: ThreadPool + attribute: + maxThreads: + alias: tomcat.threads.max + metric_type: gauge + currentThreadCount: + alias: tomcat.threads.count + metric_type: gauge + currentThreadsBusy: + alias: tomcat.threads.busy + metric_type: gauge +``` + +자세한 내용은 [JMX 점검 설명서][5]를 참조하세요. + +### 사용 가능한 메트릭을 보기 위한 명령 + +`datadog-agent jmx` 명령을 사용하면 JMXFetch 통합에서 트러블슈팅 명령을 실행할 수 있습니다. Linux 시스템에서는 명령 앞에 `sudo -u dd-agent`를 추가해 Datadog Agent가 올바른 사용자로 실행되도록 해야 합니다. + +#### datadog-agent jmx collect +`datadog-agent jmx collect`를 실행하면 현재 구성에 따라 메트릭 수집이 시작되고 콘솔에 표시됩니다. + +#### datadog-agent jmx list +`datadog-agent jmx list`에는 사용 가능한 여러 하위 명령이 있습니다. +- `collected` - 현재 인스턴스의 구성으로 실제로 수집되는 속성을 나열합니다. +- `everything` - JMXFetch에서 지원하는 유형이 있는 사용 가능한 모든 속성을 나열합니다. +- `limited` - 인스턴스의 구성 중 하나와 일치하지만 수집할 수 있는 메트릭 수를 초과하여 수집되지 않는 속성을 나열합니다. +- `matching` - 인스턴스의 구성 중 하나 이상과 일치하는 속성을 나열합니다. +- `not-matching` - 인스턴스의 구성과 일치하지 않는 속성을 나열합니다. +- `with-metrics` - 인스턴스의 구성 중 하나 이상과 일치하는 속성 및 메트릭 데이터를 나열합니다. +- `with-rate-metrics` - 요금 및 카운터를 포함하여 인스턴스의 구성 중 하나 이상과 일치하는 속성 및 메트릭 데이터를 나열합니다. + +## 참고 자료 + +기타 유용한 문서, 링크 및 기사: + +- [Datadog를 사용해 Tomcat 메트릭 모니터링][6] +- [Tomcat 모니터링을 위한 주요 메트릭][7] +- [Datadog를 사용해 Tomcat 로그 및 메트릭 분석하기][8] + + +[1]: https://raw.githubusercontent.com/DataDog/integrations-core/master/tomcat/images/tomcat_dashboard_2.png +[2]: https://app.datadoghq.com/account/settings/agent/latest +[3]: https://tomcat.apache.org/tomcat-10.1-doc/monitoring.html +[4]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#agent-status-and-information +[5]: https://docs.datadoghq.com/ko/integrations/java/ +[6]: https://www.datadoghq.com/blog/monitor-tomcat-metrics +[7]: https://www.datadoghq.com/blog/tomcat-architecture-and-performance +[8]: https://www.datadoghq.com/blog/analyzing-tomcat-logs-and-metrics-with-datadog \ No newline at end of file diff --git a/content/ko/integrations/twemproxy.md b/content/ko/integrations/twemproxy.md new file mode 100644 index 0000000000000..37d3b872f4a70 --- /dev/null +++ b/content/ko/integrations/twemproxy.md @@ -0,0 +1,173 @@ +--- +app_id: twemproxy +app_uuid: 34f4e81a-6fd2-48fd-a10c-5bffb75bbd0e +assets: + dashboards: + Twemproxy - Overview: assets/dashboards/twemproxy_overview.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: twemproxy.total_connections + metadata_path: metadata.csv + prefix: twemproxy. + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 10070 + source_type_name: Twemproxy +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- log collection +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/twemproxy/README.md +display_on_public_website: true +draft: false +git_integration_title: twemproxy +integration_id: twemproxy +integration_title: Twemproxy +integration_version: 3.0.0 +is_public: true +manifest_version: 2.0.0 +name: twemproxy +public_title: Twemproxy +short_description: twemproxy 성능을 시각화하고 나머지 애플리케이션과 연계하세요. +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Log Collection + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Offering::Integration + configuration: README.md#Setup + description: twemproxy 성능을 시각화하고 나머지 애플리케이션과 연계하세요. + media: [] + overview: README.md#Overview + support: README.md#Support + title: Twemproxy +--- + + + + +## 개요 + +각 Twemproxy 서버의 전체 및 풀별 통계를 추적하세요. 이 Agent 검사는 클라이언트 및 서버 연결 및 오류, 요청 및 응답 속도, 프록시 입출력 바이트 등에 대한 메트릭을 수집합니다. + +## 설정 + +### 설치 + +Agent의 Twemproxy 검사는 [Datadog Agent][1] 패키지에 포함되어 있으므로 Twemproxy 서버에 아무것도 설치할 필요가 없습니다. + +### 구성 + +{{< tabs >}} +{{% tab "Host" %}} + +#### 호스트 + +호스트에서 실행 중인 에이전트에 대해 이 점검을 구성하려면: + +1. [Agent 구성 디렉터리][1] 루트의 `conf.d/` 폴더에 있는 `twemproxy.d/conf.yaml` 파일을 편집합니다. 사용 가능한 모든 구성 옵션은 [샘플 twemproxy.d/conf.yaml][2]을 참조하세요. + + ```yaml + init_config: + + instances: + - host: localhost + port: 2222 + ``` + +2. [Agent를 다시 시작][3]하여 Datadog로 Twemproxy 메트릭 전송을 시작합니다. + +##### 로그 수집 + +1. Datadog Agent에서는 로그 수집이 기본적으로 비활성화되어 있습니다. `datadog.yaml` 파일에서 활성화해야 합니다. + + ```yaml + logs_enabled: true + ``` + +2. Apache 로그 수집을 시작하려면 이 구성 블록을 `twemproxy.d/conf.yaml` 파일에 추가하세요. + + ```yaml + logs: + - type: file + path: "" + source: twemproxy + service: "" + ``` + + `path` 및 `service` 파라미터 값을 변경하고 사용자 환경에 맞게 구성합니다. 사용 가능한 모든 구성 옵션은 [샘플 twemproxy.d/conf.yaml][2]을 참조하세요. + +3. [에이전트를 재시작][3]하세요. + +[1]: https://docs.datadoghq.com/ko/agent/guide/agent-configuration-files/#agent-configuration-directory +[2]: https://github.com/DataDog/integrations-core/blob/master/twemproxy/datadog_checks/twemproxy/data/conf.yaml.example +[3]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#start-stop-and-restart-the-agent +{{% /tab %}} +{{% tab "컨테이너화" %}} + +#### 컨테이너화 + +컨테이너화된 환경의 경우 [자동탐지 통합 템플릿][1]에 다음 파라미터를 적용하는 방법이 안내되어 있습니다. + +| 파라미터 | 값 | +| -------------------- | -------------------------------------- | +| `` | `twemproxy` | +| `` | 비어 있음 또는 `{}` | +| `` | `{"host": "%%host%%", "port":"22222"}` | + +##### 로그 수집 + +로그 수집은 기본적으로 Datadog Agent에서 비활성화 상태입니다. 활성화하려면 [Kubernetes 로그 수집 설명서][2]를 참조하세요. + +| 파라미터 | 값 | +| -------------- | ------------------------------------------------ | +| `` | `{"source": "twemproxy", "service": ""}` | + +[1]: https://docs.datadoghq.com/ko/agent/kubernetes/integrations/ +[2]: https://docs.datadoghq.com/ko/agent/kubernetes/log/ +{{% /tab %}} +{{< /tabs >}} + +### 검증 + +[Agent 상태 하위 명령][2]을 실행하고 확인 섹션에서 `twemproxy`를 찾습니다. + +## 수집한 데이터 + +### 메트릭 +{{< get-metrics-from-git "twemproxy" >}} + + +### 이벤트 + +Twemproxy 점검은 이벤트를 포함하지 않습니다. + +### 서비스 점검 +{{< get-service-checks-from-git "twemproxy" >}} + + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][3]에 문의하세요. + + + +[1]: https://app.datadoghq.com/account/settings/agent/latest +[2]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#agent-status-and-information +[3]: https://docs.datadoghq.com/ko/help/ \ No newline at end of file diff --git a/content/ko/integrations/varnish.md b/content/ko/integrations/varnish.md new file mode 100644 index 0000000000000..f662f8e0d0cd8 --- /dev/null +++ b/content/ko/integrations/varnish.md @@ -0,0 +1,218 @@ +--- +app_id: varnish +app_uuid: e342e5eb-71ce-4c5b-a9c9-2c33691e858f +assets: + dashboards: + varnish: assets/dashboards/varnish_dashboard.json + integration: + auto_install: true + configuration: + spec: assets/configuration/spec.yaml + events: + creates_events: false + metrics: + check: varnish.n_backend + metadata_path: metadata.csv + prefix: varnish. + process_signatures: + - service varnish start + - varnishd + service_checks: + metadata_path: assets/service_checks.json + source_type_id: 29 + source_type_name: Varnish + saved_views: + 4xx_errors: assets/saved_views/4xx_errors.json + 5xx_errors: assets/saved_views/5xx_errors.json + bot_errors: assets/saved_views/bot_errors.json + status_code_overview: assets/saved_views/status_code_overview.json + varnish_processes: assets/saved_views/varnish_processes.json +author: + homepage: https://www.datadoghq.com + name: Datadog + sales_email: info@datadoghq.com + support_email: help@datadoghq.com +categories: +- caching +- log collection +- network +custom_kind: 통합 +dependencies: +- https://github.com/DataDog/integrations-core/blob/master/varnish/README.md +display_on_public_website: true +draft: false +git_integration_title: varnish +integration_id: varnish +integration_title: Varnish +integration_version: 4.0.0 +is_public: true +manifest_version: 2.0.0 +name: varnish +public_title: Varnish +short_description: 클라이언트 및 백엔드 연결, 캐시 누락, 퇴거 등을 추적하세요. +supported_os: +- linux +- windows +- macos +tile: + changelog: CHANGELOG.md + classifier_tags: + - Category::Caching + - Category::Log Collection + - Category::Network + - Supported OS::Linux + - Supported OS::Windows + - Supported OS::macOS + - Offering::Integration + configuration: README.md#Setup + description: 클라이언트 및 백엔드 연결, 캐시 누락, 퇴거 등을 추적하세요. + media: [] + overview: README.md#Overview + resources: + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/top-varnish-performance-metrics + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/how-to-collect-varnish-metrics + - resource_type: 블로그 + url: https://www.datadoghq.com/blog/monitor-varnish-using-datadog + support: README.md#Support + title: Varnish +--- + + + + +![Varnish 기본 대시보드][1] + +## 개요 + +이 점검에서는 다음과 관련된 Varnish 메트릭을 수집합니다. + +- 클라이언트: 연결 및 요청 +- 캐시 성능: 조회수, 퇴장 등 +- 스레드: 생성, 실패, 대기 중인 스레드 +- 백엔드: 성공, 실패, 재시도 연결 + +또한 각 백엔드의 상태에 대한 서비스 점검도 제출합니다. + +## 설정 + +### 설치 + +Varnish 점검은 [Datadog Agent][2] 패키지에 포함되어 있습니다. 서버에 추가 설치가 필요하지 않습니다. + +### 구성 + +##### Varnish 준비 + +Varnish 4.1+를 실행하는 경우 `dd-agent` 시스템 사용자를 Varnish 그룹에 추가합니다. + +```text +sudo usermod -G varnish -a dd-agent +``` + +`secretfile`을 사용하는 경우 `dd-agent` 사용자가 읽을 수 있는지 확인해야 합니다. + +##### 메트릭 수집 + +1. [Agent 구성 디렉터리][3]의 루트에 있는 `conf.d/` 폴더에서 `varnish.d/conf.yaml` 파일을 편집합니다. 사용 가능한 모든 구성 옵션은 [샘플 varnish.d/conf.yaml][4]을 참조하세요. + + ```yaml + init_config: + + instances: + - varnishstat: /usr/bin/varnishstat + varnishadm: + ``` + + **참고**: `varnishadm`을 설정하지 않으면 Agent에서 백엔드 상태를 확인하지 않습니다. 설정하면 Agent에서 루트 권한으로 바이너리를 실행할 수 있는 권한이 필요합니다. `/etc/sudoers` 파일에 다음을 추가합니다. + + ```shell + dd-agent ALL=(ALL) NOPASSWD:/usr/bin/varnishadm + ``` + +2. [Agent를 재시작합니다][5]. + +##### 로그 수집 + +_Agent 버전 6.0 이상에서 사용 가능_ + +1. Varnish 로깅을 활성화하려면 `/etc/default/varnishncsa`에서 다음을 취소하세요. + + ```text + VARNISHNCSA_ENABLED=1 + ``` + +2. 동일 파일 끝에 다음을 추가합니다. + + ```text + LOG_FORMAT="{\"date_access\": \"%{%Y-%m-%dT%H:%M:%S%z}t\", \"network.client.ip\":\"%h\", \"http.auth\" : \"%u\", \"varnish.x_forwarded_for\" : \"%{X-Forwarded-For}i\", \"varnish.hit_miss\": \"%{Varnish:hitmiss}x\", \"network.bytes_written\": %b, \"http.response_time\": %D, \"http.status_code\": \"%s\", \"http.url\": \"%r\", \"http.ident\": \"%{host}i\", \"http.method\": \"%m\", \"varnish.time_first_byte\" : %{Varnish:time_firstbyte}x, \"varnish.handling\" : \"%{Varnish:handling}x\", \"http.referer\": \"%{Referer}i\", \"http.useragent\": \"%{User-agent}i\" }" + + DAEMON_OPTS="$DAEMON_OPTS -c -a -F '${LOG_FORMAT}'" + ``` + +3. `varnishncsa` 유틸리티를 다시 시작하여 변경 사항을 적용합니다. + +4. Datadog 에이전트에서 로그 수집은 기본적으로 사용하지 않도록 설정되어 있습니다. `datadog.yaml`파일에서 로그 수집을 사용하도록 설정합니다. + + ```yaml + logs_enabled: true + ``` + +5. 이 구성 블록을 `varnish.d/conf.yaml` 파일에 추가하여 Varnish 로그 수집을 시작하세요. + + ```yaml + logs: + - type: file + path: /var/log/varnish/varnishncsa.log + source: varnish + service: varnish + ``` + + `path` 및 `service` 파라미터 값을 변경하고 사용자 환경에 맞게 구성합니다. 사용 가능한 모든 구성 옵션은 [샘플 varnish.yaml][4]을 참조하세요. + +6. [Agent를 재시작합니다][5]. + + +### 검증 + +[Agent 상태 하위 명령][6]을 실행하고 Checks 섹션에서 `varnish`을 찾습니다. + +## 수집한 데이터 + +### 메트릭 +{{< get-metrics-from-git "varnish" >}} + + +### 이벤트 + +Varnish 점검에는 이벤트가 포함되지 않습니다. + +### 서비스 점검 +{{< get-service-checks-from-git "varnish" >}} + + +## 트러블슈팅 + +도움이 필요하신가요? [Datadog 지원팀][9]에 문의하세요. + +## 참고 자료 + +기타 유용한 문서, 링크 및 기사: + +- [상위 Varnish 성능 메트릭][10] +- [Varnish 메트릭 수집 방법][11] +- [Datadog를 통해 Varnish 모니터링][12] + +[1]: https://raw.githubusercontent.com/DataDog/integrations-core/master/varnish/images/varnish.png +[2]: https://app.datadoghq.com/account/settings/agent/latest +[3]: https://docs.datadoghq.com/ko/agent/guide/agent-configuration-files/#agent-configuration-directory +[4]: https://github.com/DataDog/integrations-core/blob/master/varnish/datadog_checks/varnish/data/conf.yaml.example +[5]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#start-stop-and-restart-the-agent +[6]: https://docs.datadoghq.com/ko/agent/guide/agent-commands/#agent-status-and-information +[7]: https://github.com/DataDog/integrations-core/blob/master/varnish/metadata.csv +[8]: https://github.com/DataDog/integrations-core/blob/master/varnish/assets/service_checks.json +[9]: https://docs.datadoghq.com/ko/help/ +[10]: https://www.datadoghq.com/blog/top-varnish-performance-metrics +[11]: https://www.datadoghq.com/blog/how-to-collect-varnish-metrics +[12]: https://www.datadoghq.com/blog/monitor-varnish-using-datadog \ No newline at end of file diff --git a/content/ko/observability_pipelines/legacy/setup/datadog.md b/content/ko/observability_pipelines/legacy/setup/datadog.md new file mode 100644 index 0000000000000..bdd79a2cb2c18 --- /dev/null +++ b/content/ko/observability_pipelines/legacy/setup/datadog.md @@ -0,0 +1,504 @@ +--- +aliases: +- /ko/agent/vector_aggregation/ +- /ko/integrations/observability_pipelines/integrate_vector_with_datadog/ +- /ko/observability_pipelines/integrate_vector_with_datadog/ +- /ko/observability_pipelines/integrations/integrate_vector_with_datadog/ +- /ko/observability_pipelines/production_deployment_overview/integrate_datadog_and_the_observability_pipelines_worker/ +- /ko/observability_pipelines/setup/datadog/ +further_reading: +- link: /observability_pipelines/legacy/production_deployment_overview/ + tag: 설명서 + text: 옵저버빌리티 파이프라인 작업자의 프로덕션 배포 설계 및 원칙 +- link: https://dtdg.co/d22op + tag: 학습 센터 + text: Observability Pipelines를 통한 안전한 로컬 프로세싱 +title: (레거시) Datadog에서 Observability Pipelines 설정 +--- + +{{< site-region region="gov" >}} +
Observability Pipelines은 US1-FED Datadog 사이트에서 사용할 수 없습니다.
+{{< /site-region >}} + +{{% observability_pipelines/legacy_warning %}} + +## 개요 + +[Observability Pipelines Worker][1]는 모든 소스에서 로그를 수집, 처리, 라우팅하여 원하는 대상에 전달할 수 있습니다. Datadog을 사용하면 모든 Observability Pipelines Worker 배포를 대규모로 구축하고 관리할 수 있습니다. + +이 가이드는 공통 툴 클러스터(common tools cluster)에 Worker를 배포하고 Datadog Agent를 구성하여 로그와 메트릭을 Worker로 전송하는 과정을 설명합니다. + +{{< img src="observability_pipelines/setup/opw-dd-pipeline.png" alt="여러 워크로드 클러스터에서 Observability Pipelines 집계기를 통해 데이터를 전송하는 다이어그램" >}} + +## 배포 모드 + +{{% op-deployment-modes %}} + +## 전제 조건 +* 이미 Datadog을 사용 중이며 Observability Pipelines를 사용하려는 경우 +* Observability Pipelines Worker가 배포될 클러스터와 집계될 워크로드에 대한 관리자 권한을 가진 경우 +* 모든 클러스터가 연결된 공통 툴 또는 보안 클러스터를 보유한 경우 + +## 설치 전 준비 사항 +설치 전에 다음을 확인해야 합니다. + +* 유효한 [Datadog API 키][2] +* 파이프라인 ID + +이 두 가지는 [Observability Pipelines][3]에서 생성할 수 있습니다. + +### 공급자별 요구 사항 +{{< tabs >}} +{{% tab "Docker" %}} +Docker를 실행하도록 머신이 구성되어 있는지 확인합니다. +{{% /tab %}} +{{% tab "AWS EKS" %}} +Kubernetes 노드에서 Worker를 실행하려면 최소 두 개의 노드와 각 노드에 1 CPU, 512MB RAM이 필요합니다. Datadog은 Worker 전용 노드 풀을 생성하는 것을 권장하며, 이는 프로덕션 배포 시에도 권장되는 구성입니다. + +* [EBS CSI 드라이버][1]가 필요합니다. 설치 여부는 아래 명령어로 확인할 수 있으며, 목록에 `ebs-csi-controller`가 있는지 확인하세요. + + ```shell + kubectl get pods -n kube-system + ``` + +* 올바른 EBS 디스크를 프로비저닝하려면 `StorageClass`가 필요합니다. 설치 여부는 아래 명령어로 확인할 수 있으며, 목록에 `io2`가 있는지 확인하세요. + + ```shell + kubectl get storageclass + ``` + + `io2`가 없으면 [StorageClass YAML][2]를 다운로드한 뒤 `kubectl apply`하세요. + +* [AWS Load Balancer controller][3]가 필요합니다. 설치 여부는 아래 명령어로 확인할 수 있으며 목록에서 `aws-load-balancer-controller`를 찾습니다. + + ```shell + helm list -A + ``` +* Datadog는 Amazon EKS 1.16 이상을 사용할 것을 권장합니다. + +프로덕션 수준 요건은 [OPW Aggregator 아키텍처 모범 사례][4]를 참조하세요. + +[1]: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html +[2]: /resources/yaml/observability_pipelines/helm/storageclass.yaml +[3]: https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html +[4]: /ko/observability_pipelines/legacy/architecture/ + +{{% /tab %}} +{{% tab "Azure AKS" %}} +Kubernetes 노드에서 Worker를 실행하려면 최소 두 개의 노드와 각 노드에 1 CPU, 512MB RAM이 필요합니다. Datadog은 Worker 전용 노드 풀을 생성하는 것을 권장하며, 이는 프로덕션 배포 시에도 권장되는 구성입니다. + +프로덕션 수준 요건은 [OPW Aggregator 아키텍처 모범 사례][4]를 참조하세요. + +[1]: /ko/observability_pipelines/legacy/architecture/ +{{% /tab %}} +{{% tab "Google GKE" %}} +Kubernetes 노드에서 Worker를 실행하려면 최소 두 개의 노드와 각 노드에 1 CPU, 512MB RAM이 필요합니다. Datadog은 Worker 전용 노드 풀 생성을 권장하며, 이는 프로덕션 배포 시에도 권장되는 구성입니다. + +프로덕션 수준 요건은 [OPW Aggregator 아키텍처 모범 사례][4]를 참조하세요. + +[1]: /ko/observability_pipelines/legacy/architecture/ +{{% /tab %}} +{{% tab "APT-based Linux" %}} +APT 기반 Linux 환경에는 별도의 요구 사항이 없습니다. +{{% /tab %}} +{{% tab "RPM-based Linux" %}} +RPM 기반 Linux 환경에는 별도의 요구 사항이 없습니다. +{{% /tab %}} +{{% tab "Terraform (AWS)" %}} +AWS 계정에서 Worker를 실행하려면 해당 계정의 관리자 권한이 필요합니다. Worker 인스턴스를 실행하기 위해 다음 정보를 수집해야 합니다. +* 인스턴스가 실행될 VPC ID +* 인스턴스가 실행될 서브넷 ID +* VPC가 위치한 AWS 리전 +{{% /tab %}} +{{% tab "CloudFormation" %}} + +
CloudFormation 설치는 원격 구성(Remote Configuration)만 지원합니다.
+
CloudFormation 설치는 프로덕션급 워크로드가 아닌 환경에서만 사용하세요.
+ +AWS 계정에서 Worker를 실행하려면 계정의 관리자 액세스 권한이 있어야 합니다. Worker 인스턴스를 실행하려면 다음 정보를 수집합니다. +* 인스턴스가 실행될 VPC ID +* 인스턴스가 실행될 서브넷 ID +* VPC가 위치한 AWS 지역 +{{% /tab %}} +{{< /tabs >}} + +## Observability Pipelines Worker 설치하기 + +{{< tabs >}} +{{% tab "Docker" %}} + +Observability Pipelines Worker 도커 이미지는 도커 허브 [여기][1]에 게시되어 있습니다. + +1. [샘플 파이프라인 설정 파일][2]을 다운로드합니다. + +2. 다음 명령을 실행하여 도커(Docker)를 통해 Observability Pipelines Worker를 시작합니다. + ``` + docker run -i -e DD_API_KEY= \ + -e DD_OP_PIPELINE_ID= \ + -e DD_SITE= \ + -p 8282:8282 \ + -v ./pipeline.yaml:/etc/observability-pipelines-worker/pipeline.yaml:ro \ + datadog/observability-pipelines-worker run + ``` + ``는 Datadog API 키로, ``는 Observability Pipelines 구성 ID로, `` 는 {{< region-param key="dd_site" code="true" >}}로 바꾸세요. `./pipeline.yaml`는 사용하려는 구성 파일의 상대 경로나 절대 경로여야 합니다. + +[1]: https://hub.docker.com/r/datadog/observability-pipelines-worker +[2]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml +{{% /tab %}} +{{% tab "AWS EKS" %}} +1. AWS EKS를 위해 [Helm 차트 값 파일][1]을 다운로드합니다. + +2. Helm 차트에서 `datadog.apiKey` 및 `datadog.pipelineId` 값을 파이프라인과 일치하도록 교체하고 `site` 값으로 {{< region-param key="dd_site" code="true" >}}를 사용합니다. 그 후 다음 명령을 사용하여 클러스터에 설치합니다. + + ```shell + helm repo add datadog https://helm.datadoghq.com + ``` + ```shell + helm repo update + ``` + ```shell + helm upgrade --install \ + opw datadog/observability-pipelines-worker \ + -f aws_eks.yaml + ``` + +[1]: /resources/yaml/observability_pipelines/datadog/aws_eks.yaml +{{% /tab %}} +{{% tab "Azure AKS" %}} +1. Azure AKS용 [Helm 차트 값 파일][1]을 다운로드합니다. + +2. Helm 차트에서 `datadog.apiKey` 및 `datadog.pipelineId` 값을 파이프라인과 일치하도록 교체하고 `site` 값으로 {{< region-param key="dd_site" code="true" >}}를 사용합니다. 그 후 다음 명령을 사용하여 클러스터에 설치합니다. + + ```shell + helm repo add datadog https://helm.datadoghq.com + ``` + ```shell + helm repo update + ``` + ```shell + helm upgrade --install \ + opw datadog/observability-pipelines-worker \ + -f azure_aks.yaml + ``` + +[1]: /resources/yaml/observability_pipelines/datadog/azure_aks.yaml +{{% /tab %}} +{{% tab "Google GKE" %}} +1. Google GKE용 [Helm 차트 값 파일][1]을 다운로로드합니다. + +2. Helm 차트에서 `datadog.apiKey` 및 `datadog.pipelineId` 값을 파이프라인과 일치하도록 교체하고 `site` 값으로 {{< region-param key="dd_site" code="true" >}}를 사용합니다. 그 후 다음 명령을 사용하여 클러스터에 설치합니다. + + ```shell + helm repo add datadog https://helm.datadoghq.com + ``` + ```shell + helm repo update + ``` + ```shell + helm upgrade --install \ + opw datadog/observability-pipelines-worker \ + -f google_gke.yaml + ``` + +[1]: /resources/yaml/observability_pipelines/datadog/google_gke.yaml +{{% /tab %}} +{{% tab "APT-based Linux" %}} +1. 다음 명령을 실행하여 APT를 설정하여 HTTPS를 통해 다운로드합니다. + + ``` + sudo apt-get update + sudo apt-get install apt-transport-https curl gnupg + ``` + +2. 다음 명령을 실행하여 시스템에 Datadog `deb` 리포지토리를 설정하고 Datadog 아카이브 키링을 생성합니다: + + ``` + sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://apt.datadoghq.com/ stable observability-pipelines-worker-1' > /etc/apt/sources.list.d/datadog-observability-pipelines-worker.list" + sudo touch /usr/share/keyrings/datadog-archive-keyring.gpg + sudo chmod a+r /usr/share/keyrings/datadog-archive-keyring.gpg + curl https://keys.datadoghq.com/DATADOG_APT_KEY_CURRENT.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch + curl https://keys.datadoghq.com/DATADOG_APT_KEY_06462314.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch + curl https://keys.datadoghq.com/DATADOG_APT_KEY_F14F620E.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch + curl https://keys.datadoghq.com/DATADOG_APT_KEY_C0962C7D.public | sudo gpg --no-default-keyring --keyring /usr/share/keyrings/datadog-archive-keyring.gpg --import --batch + ``` + +3. 다음 명령을 실행하여 로컬 `apt` 리포지토리를 업데이트하고 Worker를 설치합니다: + + ``` + sudo apt-get update + sudo apt-get install observability-pipelines-worker datadog-signing-keys + ``` + +4. 작업자의 환경 변수에 다음과 같이 키와 사이트({{< region-param key="dd_site" code="true" >}})를 추가합니다. + + ``` + sudo cat <<-EOF > /etc/default/observability-pipelines-worker + DD_API_KEY= + DD_OP_PIPELINE_ID= + DD_SITE= + EOF + ``` + +5. [샘플 설정 파일][1]을 호스트의 `/etc/observability-pipelines-worker/pipeline.yaml`에 다운로드합니다. + +6. Worker를 시작합니다. + ``` + sudo systemctl restart observability-pipelines-worker + ``` + +[1]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml +{{% /tab %}} +{{% tab "RPM-based Linux" %}} +1. 다음 명령을 실행하여 시스템에서 Datadog `rpm` 르포를 설정합니다. + + ``` + cat < /etc/yum.repos.d/datadog-observability-pipelines-worker.repo + [observability-pipelines-worker] + name = Observability Pipelines Worker + baseurl = https://yum.datadoghq.com/stable/observability-pipelines-worker-1/\$basearch/ + enabled=1 + gpgcheck=1 + repo_gpgcheck=1 + gpgkey=https://keys.datadoghq.com/DATADOG_RPM_KEY_CURRENT.public + https://keys.datadoghq.com/DATADOG_RPM_KEY_4F09D16B.public + https://keys.datadoghq.com/DATADOG_RPM_KEY_B01082D3.public + https://keys.datadoghq.com/DATADOG_RPM_KEY_FD4BF915.public + https://keys.datadoghq.com/DATADOG_RPM_KEY_E09422B3.public + EOF + ``` + + **참고:** RHEL 8.1 또는 CentOS 8.1을 실행하는 경우 위 설정에서 `repo_gpgcheck=1` 대신 `repo_gpgcheck=0`를 사용합니다. + +2. 패키지를 업데이트하고 Worker를 설치합니다. + + ``` + sudo yum makecache + sudo yum install observability-pipelines-worker + ``` + +3. 작업자의 환경 변수에 다음과 같이 키와 사이트({{< region-param key="dd_site" code="true" >}})를 추가합니다. + + ``` + sudo cat <<-EOF > /etc/default/observability-pipelines-worker + DD_API_KEY= + DD_OP_PIPELINE_ID= + DD_SITE= + EOF + ``` + +4. [샘플 설정 파일][1]을 호스트의 `/etc/observability-pipelines-worker/pipeline.yaml`에 다운로드합니다. + +5. Worker를 시작합니다. + ``` + sudo systemctl restart observability-pipelines-worker + ``` + +[1]: /resources/yaml/observability_pipelines/datadog/pipeline.yaml +{{% /tab %}} +{{% tab "Terraform (AWS)" %}} + +1. [샘플 설정][1]을 다운로드합니다. +1. 샘플 설정을 사용해 기존 Terraform에서 Worker 모듈을 설정합니다. `vpc-id`, `subnet-ids` 및 `region` 값을 업데이트하여 설정에서 AWS 배포를 매칭합니다. 또한, `datadog-api-key` 및 `pipeline-id`의 값을 업데이트하여 파이프라인을 매칭합니다. + +[1]: /resources/yaml/observability_pipelines/datadog/terraform_opw_datadog.tf + +{{% /tab %}} +{{% tab "CloudFormation" %}} + +
프로덕션 수준이 아닌 워크로드에만 CloudFormation 설치를 사용합니다.
+ +AWS 계정에 Worker를 설치하려면 다음과 같이 CloudFormation 템플릿으로 스택을 생성합니다. + + 1. Worker용 [CloudFormation 템플릿][1]을 다운로드합니다. + + 2. **CloudFormation console**에서 **Create stack**를 클릭하고 **With new resources (standard)** 옵션을 선택합니다. + + 3. **Template is ready** 옵션이 선택되어 있는지 확인하고 **Upload a template file**을 선택합니다. **Choose file**을 클릭하고 앞서 다운로드한 CloudFormation 템플릿 파일을 추가합니다. **Next**를 클릭합니다. + + 4. **Specify stack details**에서 스택 이름을 입력합니다. + + 5. CloudFormation 템플릿의 파라미터를 입력합니다. 다음 사항을 특별히 주의해 주세요. + + * `APIKey` 및 `PipelineID`의 경우 앞서 필수 요건 섹션에서 수집한 키와 ID를 입력합니다. + + * `VPCID` 및 `SubnetIDs`의 경우 앞서 선택한 서브넷과 VPC를 입력합니다. + + * 다른 파라미터는 Worker 배포에 적절한 기본값으로 설정되어 있습니다. 그러나 필요에 따라 내 사용 사례에 맞게 값을 조정할 수 있습니다. + + 6. **Next**를 클릭합니다. + + 7. 파라미터를 검토하고 예상값과 일치하는지 확인합니다. IAM에 필요한 권한 확인란을 클릭하고 **Submit**을 클릭하여 스택을 생성합니다. + +이 시점에서 CloudFormation이 설치를 시작합니다. Worker 인스턴스가 시작되어 필요한 소프트웨어를 다운로드한 후 자동으로 실행합니다. + +[1]: /resources/yaml/observability_pipelines/cloudformation/datadog.yaml +{{% /tab %}} +{{< /tabs >}} + +샘플 구성에 사용된 소스, 변환, 싱크에 대한 자세한 내용은 [구성][4]을 참조하세요. 데이터 변환에 관한 자세한 내용은 [데이터로 작업하기][5]를 참조하세요. + +### 로드 밸런싱 + +{{< tabs >}} +{{% tab "Docker" %}} +프로덕션 설정은 Docker 지침에 포함되어 있지 않습니다. 대신, 컨테이너 환경에서 로드 밸런싱을 설정할 때는 기업 표준을 참조합니다. 로컬 머신에서 테스트하는 경우에는 로드 밸런서를 설정할 필요가 없습니다. +{{% /tab %}} +{{% tab "AWS EKS" %}} +클라우드 공급자가 제공하는 로드 밸런서를 사용하세요. +로드 밸런서는 기본 Helm 설정에 지정된 오토스케일링 이벤트에 따라 자동으로 조정됩니다. 또한 로드 밸런서는 내부 네트워크 전용으로 설정되어, +고객님의 네트워크 내부에서만 접근할 수 있습니다. + +Datadog 에이전트를 설정할 때 Helm에서 제공한 로드 밸런서 URL을 사용합니다. + +[AWS 로드 밸런서 컨트롤러][1]가 프로비저닝된 NLB를 사용합니다. + +Worker 스케일링 시 로드 밸런서 권장 사항을 위한 [용량 계획 및 스케일링][2]을 참조하세요. +#### 교차 사용 가능성 존 로드 밸런싱 +제공된 Helm 설정은 로드 밸런싱 단순화를 시도합니다. 하지만 교차 AZ 트래픽에 대한 잠재적 가격을 고려애햐 합니다. 가능한 경우 샘플으 여러 교차 AZ 홉이 발생할 수 있는 상황을 만드는 것을 피하려 합니다. + +샘플 설정은 이 컨트롤러에서 사용 가능한 교차 존 로드 밸런싱 기능을 활성화할 수 없습니다. 활성화하려면 `service` 블록에서 다음 주석을 추가합니다. + +``` +service.beta.kubernetes.io/aws-load-balancer-attributes: load_balancing.cross_zone.enabled=true +``` + +자세한 정보는 [AWS 로드 밸런서 컨트롤러][3]를 참조하세요. + +[1]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/ +[2]: /ko/observability_pipelines/legacy/architecture/capacity_planning_scaling/ +[3]: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#load-balancer-attributes +{{% /tab %}} +{{% tab "Azure AKS" %}} +클라우드 공급자가 제공하는 로드 밸런서를 사용하세요. +로드 밸런서는 기본 Helm 설정에 지정된 오토스케일링 이벤트에 따라 자동으로 조정됩니다. 또한 로드 밸런서는 내부 네트워크 전용으로 설정되어, +고객님의 네트워크 내부에서만 접근할 수 있습니다. + +Datadog 에이전트를 설정할 때 Helm에서 제공한 로드 밸런서 URL을 사용합니다. + +Worker 스케일링 시 로드 밸런서 권장 사항에 대해서는 [용량 계획 및 스케일링][1]을 참조하세요. + +#### 교차 사용 가능성 존 로드 밸런싱 +제공된 Helm 설정은 로드 밸런싱 단순화를 시도합니다. 하지만 교차 AZ 트래픽에 대한 잠재적 가격을 고려애햐 합니다. 가능한 경우 샘플으 여러 교차 AZ 홉이 발생할 수 있는 상황을 만드는 것을 피하려 합니다. + +[1]: /ko/observability_pipelines/legacy/architecture/capacity_planning_scaling/ +{{% /tab %}} +{{% tab "Google GKE" %}} +클라우드 공급자가 제공하는 로드 밸런서를 사용하세요. +로드 밸런서는 기본 Helm 설정에 지정된 오토스케일링 이벤트에 따라 자동으로 조정됩니다. 또한 로드 밸런서는 내부 네트워크 전용으로 설정되어, +고객님의 네트워크 내부에서만 접근할 수 있습니다. + +Datadog 에이전트를 설정할 때 Helm에서 제공한 로드 밸런서 URL을 사용합니다. + +Worker 스케일링 시 로드 밸런서 권장 사항에 대해서는 [용량 계획 및 스케일링][1]을 참조하세요. + +#### 교차 사용 가능성 존 로드 밸런싱 +제공된 Helm 설정은 로드 밸런싱 단순화를 시도합니다. 하지만 교차 AZ 트래픽에 대한 잠재적 가격을 고려애햐 합니다. 가능한 경우 샘플으 여러 교차 AZ 홉이 발생할 수 있는 상황을 만드는 것을 피하려 합니다. + +글로벌 액세스는 공유 도구 클러스터에서 사용하는 경우가 많기 때문에 기본값으로 활성화되어 있습니다. + +[1]: /ko/observability_pipelines/legacy/architecture/capacity_planning_scaling/ +{{% /tab %}} +{{% tab "APT-based Linux" %}} +설치가 단일 머신에 한정되므로 로드 밸런싱에 대한 기본 제공 지원이 없습니다. 회사에서 정한 표준 방식에 따라 별도의 로드 밸런서를 구성해야 합니다. +{{% /tab %}} +{{% tab "RPM-based Linux" %}} +설치가 단일 머신에 한정되므로 로드 밸런싱에 대한 기본 제공 지원이 없습니다. 회사에서 정한 표준 방식에 따라 별도의 로드 밸런서를 구성해야 합니다. +{{% /tab %}} +{{% tab "Terraform (AWS)" %}} +Terraform 모듈이 NLB(Network Load Balancer)를 자동으로 프로비저닝하며, 인스턴스를 대상으로 설정합니다. NLB의 DNS 주소는 Terraform 출력값으로 반환됩니다. +{{% /tab %}} +{{% tab "CloudFormation" %}} + +
프로덕션 수준이 아닌 워크로드에만 CloudFormation 설치를 사용합니다.
+ +NLB는 CloudFormation 템플릿이 프로비저닝하며 오토스케일링 그룹을 포인팅하도록 설정됩니다. 해당 DNS 주소는 `LoadBalancerDNS` CloudFormation 출력에 반환됩니다. +{{% /tab %}} +{{< /tabs >}} + +### 버퍼링 +Observability Pipeline는 다수의 버퍼링 전략을 포함하여 다운스트림 오류에 대한 클러스터의 복원력을 향상합니다. 제공된 샘플 설정은 디스크 버퍼를 사용합니다. 해당 용량은 Observability Pipeline 배포에 대해 10Mbps/코어당 약 10분 분량의 데이터로 계산됩니다. 이는 자체적으로 일시적인 문제를 해결하거나 인시던트 반응자가 관측 가능성 데이터로 할 수 있는데 필요한 결정을 내리는 데 충분한 시간입니다. + +{{< tabs >}} +{{% tab "Docker" %}}} +기본적으로 Observability Pipelines Worker의 데이터 디렉터리는 `/var/lib/observability-pipelines-worker`로 설정되어 있습니다. 호스트 머신의 컨테이너 마운트 지점에 충분한 양의 저장 용량이 할당되어 있는지 확인하세요. +{{% /tab %}} +{{% tab "AWS EKS" %}} +AWS의 경우 Datadog에서는 `io2` EBS 드라이브 제품군을 사용할 것을 권장합니다. 또는 `gp3` 드라이브를 사용할 수도 있습니다. +{{% /tab %}} +{{% tab "Azure AKS" %}} +Azure AKS의 경우 Datadog은 `default`(`managed-csi`라고도 함) 디스크를 사용하기를 권장합니다. +{{% /tab %}} +{{% tab "Google GKE" %}} +Google GKE의 경우 Datadog은 SSD 기반이기 때문에 `premium-rwo` 드라이브 클래스 사용을 권장합니다. HDD 기반 클래스 `standard-rwo`는 버퍼에 필요한 충분한 쓰기 성능을 내지 못할 수도 있습니다. +{{% /tab %}} +{{% tab "APT-based Linux" %}} +기본적으로 Observability Pipelines Worker의 데이터 디렉터리는 `/var/lib/observability-pipelines-worker`로 설정되어 있습니다. 설정 샘플을 사용하는 경우 버퍼링에 사용할 수 있는 공간이 최소 288GB 이상 확보되어 있는지 확인해야 합니다. + +가능한 경우 해당 위치에 별도의 SSD를 장착하는 것을 권장합니다. +{{% /tab %}} +{{% tab "RPM-based Linux" %}} +기본적으로 Observability Pipelines Worker의 데이터 디렉터리는 `/var/lib/observability-pipelines-worker`로 설정되어 있습니다. 설정 샘플을 사용하는 경우 버퍼링에 사용할 수 있는 공간이 최소 288GB 이상 확보되어 있는지 확인해야 합니다. + +가능한 해당 위치에 별도의 SSD를 장착하는 것을 권장합니다. +{{% /tab %}} +{{% tab "Terraform (AWS)" %}} +기본적으로 각 인스턴스에는 288GB EBS 드라이브가 할당되며, 위의 샘플 설정에서는 버퍼링에 이를 사용하도록 설정되어 있습니다. +{{% /tab %}} +{{% tab "CloudFormation" %}} + +
이 CloudFormation 템플릿으로 생성된 EBS 드라이브의 수명 주기는 해당 탬플릿이 생성한 인스턴스와 관련되어어 있습니다. 그러므로 인스턴스가 오토스케일링 그룹 등에 의해 종료되면 데이터가 손실될 수 있습니다. 그러므로 프로덕션 수준이 아닌 워크로드에만 CloudFormation 설치를 사용합니다.
+ +각 인스턴스에는 288GB EBS 드라이브가 기본값으로 할당되며, 인스턴스 부팅 시 자동으로 마운트 및 포맷됩니다. +{{% /tab %}} +{{< /tabs >}} + +## Datadog 에이전트를 Observability Pipelines Worker에 연결하기 +Datadog 에이전트 로그를 Observability Pipelines Worker에 전송하려면 다음을 통해 에이전트 설정을 업데이트합니다. + +```yaml +observability_pipelines_worker: + logs: + enabled: true + url: "http://:8282" +``` + +`OPW_HOST`는 이전에 설정한 로드 밸런서 또는 컴퓨터의 IP입니다. 단일 호스트 도커(Docker) 기반 설치의 경우, 기본 호스트의 IP 주소입니다. 쿠버네티스(Kubernetes) 기반 설치의 경우, 다음 명령을 실행하고 `EXTERNAL-IP`를 복사하여 검색할 수 있습니다. + +```shell +kubectl get svc opw-observability-pipelines-worker +``` + +Terraform 설치의 경우 `lb-dns` 출력은 필요한 값을 제공합니다. CloudFormation 설치의 경우 `LoadBalancerDNS` CloudFormation 출력에는 사용할 수 있는 적절한 URL이 있습니다. + +이 시점에서 통합 가시성 데이터는 Worker로 이동되어 데이터 프로세싱에 사용할 수 있습니다. + +## 배포 모드 업데이트하기 + +{{% op-updating-deployment-modes %}} + +## 데이터로 작업하기 +제공된 샘플 구성에는 Observability Pipelines 도구를 시연하고 Datadog으로 전송되는 데이터가 올바른 형식인지 확인하는 프로세싱 단계의 예시가 포함되어 있습니다. + +### 로그 프로세싱하기 +예시 Observability Pipelines 설정은 다음 작업을 수행합니다. +- Datadog Agent에서 Observability Pipelines Worker로 전송된 로그를 수집합니다. +- Observability Pipelines Worker를 통해 들어오는 로그를 태깅합니다. 이렇게 하면 클러스터를 업데이트할 때 어떤 트래픽을 Worker로 전환해야 하는지 파악할 수 있습니다. 이 태그는 또한 불균형이 있을 때 부하 분산 장치를 통해 로그가 어떻게 라우팅되는지 보여줍니다. +- Worker를 통해 들어오는 로그의 상태를 수정합니다. Datadog Agent가 컨테이너에서 로그를 수집하는 방법으로 인해 제공된 `.status` 속성이 메시지의 실제 수준을 제대로 반영하지 못합니다. 이는 Worker에서 로그를 수신하는 백엔드에서 파싱 규칙과 관련된 문제를 방지하기 위해 제거되었습니다. + +다음은 예제 구성에서 중요한 두 가지 구성 요소입니다. +- `logs_parse_ddtags`: 문자열에 저장된 태그를 구조화된 데이터로 파싱합니다. +- `logs_finish_ddtags` Datadog Agent에서 전송하는 형식으로 태그를 다시 인코딩합니다. + +내부적으로 Datadog Agent는 로그 태그를 단일 문자열의 CSV로 나타냅니다. 이러한 태그를 효과적으로 조작하려면 수집 엔드포인트로 전송하기 전에 태그를 파싱하고 수정한 다음 다시 인코딩해야 합니다. 이 단계는 이 작업을 자동으로 실행하기 위해 작성되었습니다. 특히 태그 조작을 위해 파이프라인 수정은 이 두 단계 사이에 완료되어야 합니다. + +이 시점에서 환경은 데이터가 통과하는 Observability Pipelines에 맞게 구성되었습니다. 특정 사용 사례에 따라 추가 구성이 필요할 수 있지만 제공된 도구로 시작할 수 있습니다. + +## 참고 자료 +{{< partial name="whats-next/whats-next.html" >}} + + +[1]: /ko/observability_pipelines/legacy/ +[2]: /ko/account_management/api-app-keys/#api-keys +[3]: https://app.datadoghq.com/observability-pipelines/create +[4]: /ko/observability_pipelines/legacy/configurations/ +[5]: /ko/observability_pipelines/legacy/working_with_data/ \ No newline at end of file diff --git a/content/ko/opentelemetry/guide/otlp_delta_temporality.md b/content/ko/opentelemetry/guide/otlp_delta_temporality.md new file mode 100644 index 0000000000000..aa6326f31d40d --- /dev/null +++ b/content/ko/opentelemetry/guide/otlp_delta_temporality.md @@ -0,0 +1,288 @@ +--- +further_reading: +- link: /metrics/open_telemetry/otlp_metric_types + tag: 설명서 + text: OTLP 메트릭 유형 +- link: /opentelemetry/ + tag: 설명서 + text: Datadog의 OpenTelemetry 지원 +title: OpenTelemetry를 사용하여 델타 시간성 메트릭 생성하기 +--- + +## 개요 + +OpenTelemetry Protocol(OTLP)는 [여러 메트릭 유형][1]을 전송하며, 그중 일부는 *델타* 또는 *누적* [집계 시간성][2]을 가질 수 있습니다. Datadog는 단조 합계, 히스토그램 및 지수 히스토그램에 대한 델타 집계 시간성 사용 시 가장 잘 작동합니다. + +이 가이드에서는 누적 집계 시간성을 대신 사용하는 것의 의미와 OpenTelemetry 소프트웨어 SDK 또는 [OpenTelemetry 수집기 `cumulativetodelta` 프로세서][3]를 사용하여 메트릭을 사용하여 집계 시간성을 선택하는 방법에 관해 자세히 설명합니다. + +## 누적 집계 시간성 사용의 의미 + +OpenTelemetry Protocol 단조 합계, 히스토그램 또는 누적 집계 시간성을 가진 지수 히스토그램을 보내도록 선택하면 Datadog 시계열에서 연속된 지점 간의 차이를 수집합니다. 즉, 다음을 의미합니다. + +- 배포는 스테이트풀 방식이므로 시계열의 모든 포인트를 동일한 Datadog Agent 또는 Datadog 내보내기로 보내야 합니다. 이는 OpenTelemetry 수집기 배포 환경을 확장하는 방법에 영향을 줍니다. +- Datadog는 주어진 시계열에서 받은 첫 번째 포인트가 시계열의 실제 시작점인지 확인할 수 없는 경우 이 포인트를 보내지 않을 수 있습니다. 이로 인해 다시 시작할 때 포인트가 누락될 수 있습니다. +- 누적 OpenTelemetry Protocol 히스토그램의 경우 최소값과 최대값을 복구할 수 없으며, 히스토그램 내보내기 모드에 따라 누락되거나 근사치가 나올 수 있습니다. + +## OpenTelemetry SDK 구성하기 + +OpenTelemetry SDK에서 OTLP 메트릭을 생성하는 경우 OTLP 내보내기를 구성하여 델타 집계 시간성을 포함하는 메트릭 유형을 생성할 수 있습니다. 일부 언어에서는 `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE` 환경 변수를 `Delta`(대소문자 구분)로 설정하여 권장 구성을 사용할 수 있습니다. 이 환경 변수를 지원하는 언어 목록은 [사양 준수 매트릭스][4]를 참조하세요. + +SDK에서 이 환경 변수를 지원하지 않는 경우 코드에서 델타 시간성을 구성할 수 있습니다. 다음 예는 OpenTelemetry Protocol HTTP 내보내기를 구성하고 총 5분 동안 2초마다 `1`을 카운터에 추가하는 예제입니다. + +**참고**: 이 예제는 시작하는 데 도움을 주려는 목적으로 제공됩니다. 프로덕션 시나리오에서는 콘솔 또는 stdout 내보내기를 사용하는 등 패턴을 적용해선 안 됩니다. + +{{< programming-lang-wrapper langs="python,go,java,.net" >}} + +{{< programming-lang lang="python" >}} +```python +import time + +from opentelemetry.exporter.otlp.proto.http.metric_exporter import ( + OTLPMetricExporter, ) +from opentelemetry.sdk.metrics import ( + Counter, + Histogram, + MeterProvider, + ObservableCounter, + ObservableGauge, + ObservableUpDownCounter, + UpDownCounter, +) +from opentelemetry.sdk.metrics.export import ( + AggregationTemporality, + ConsoleMetricExporter, + PeriodicExportingMetricReader, +) + +deltaTemporality = { + Counter: AggregationTemporality.DELTA, + UpDownCounter: AggregationTemporality.CUMULATIVE, + Histogram: AggregationTemporality.DELTA, + ObservableCounter: AggregationTemporality.DELTA, + ObservableUpDownCounter: AggregationTemporality.CUMULATIVE, + ObservableGauge: AggregationTemporality.CUMULATIVE, +} + +exporter = OTLPMetricExporter(preferred_temporality=deltaTemporality) +reader = PeriodicExportingMetricReader(exporter, export_interval_millis=5_000) +provider = MeterProvider(metric_readers=[reader]) + +consoleReader = PeriodicExportingMetricReader( + ConsoleMetricExporter(preferred_temporality=deltaTemporality), export_interval_millis=5_000) +consoleProvider = MeterProvider(metric_readers=[consoleReader]) + +meter = provider.get_meter("my-meter") +counter = meter.create_counter("example.counter") + +consoleMeter = consoleProvider.get_meter("my-meter-console") +consoleCounter = consoleMeter.create_counter("example.counter.console") + +for i in range(150): + counter.add(1) + consoleCounter.add(1) + time.sleep(2) +``` +{{< /programming-lang >}} + + +{{< programming-lang lang="go" >}} +```go +package main + +import ( + "context" + "time" + + "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp" + "go.opentelemetry.io/otel/exporters/stdout/stdoutmetric" + "go.opentelemetry.io/otel/sdk/metric" + "go.opentelemetry.io/otel/sdk/metric/metricdata" +) + +func deltaSelector(kind metric.InstrumentKind) metricdata.Temporality { + switch kind { + case metric.InstrumentKindCounter, + metric.InstrumentKindGauge, + metric.InstrumentKindHistogram, + metric.InstrumentKindObservableGauge, + metric.InstrumentKindObservableCounter: + return metricdata.DeltaTemporality + case metric.InstrumentKindUpDownCounter, + metric.InstrumentKindObservableUpDownCounter: + return metricdata.CumulativeTemporality + } + panic("unknown instrument kind") +} + +func main() { + ctx := context.Background() + exporter, err := otlpmetrichttp.New(ctx, + otlpmetrichttp.WithTemporalitySelector(deltaSelector), + ) + consoleExporter, consoleErr := stdoutmetric.New( + stdoutmetric.WithTemporalitySelector(deltaSelector), + ) + if err != nil || consoleErr != nil { + panic(err) + } + + reader := metric.NewPeriodicReader(exporter, + metric.WithInterval(5*time.Second), + ) + provider := metric.NewMeterProvider(metric.WithReader(reader)) + + consoleReader := metric.NewPeriodicReader(consoleExporter, + metric.WithInterval(5*time.Second), + ) + consoleProvider := metric.NewMeterProvider(metric.WithReader(consoleReader)) + + defer func() { + err := provider.Shutdown(ctx) + consoleErr := consoleProvider.Shutdown(ctx) + if err != nil || consoleErr != nil { + panic(err) + } + }() + + meter := provider.Meter("my-meter") + counter, err := meter.Int64Counter("example.counter") + + consoleMeter := consoleProvider.Meter("my-meter-console") + consoleCounter, consoleErr := consoleMeter.Int64Counter("example.counter.console") + + if err != nil || consoleErr != nil { + panic(err) + } + + for i := 0; i < 150; i++ { + counter.Add(ctx, 1) + consoleCounter.Add(ctx, 1) + time.Sleep(2 * time.Second) + } +} +``` +{{< /programming-lang >}} + + +{{< programming-lang lang="java" >}} +```java +package io.opentelemetry.example.delta; + +import io.opentelemetry.api.metrics.LongCounter; +import io.opentelemetry.api.metrics.Meter; +import io.opentelemetry.api.metrics.MeterProvider; +import io.opentelemetry.exporter.otlp.http.metrics.OtlpHttpMetricExporter; +import io.opentelemetry.sdk.metrics.export.AggregationTemporalitySelector; +import io.opentelemetry.sdk.metrics.export.MetricReader; +import io.opentelemetry.sdk.metrics.SdkMeterProvider; +import io.opentelemetry.sdk.metrics.export.PeriodicMetricReader; + +public final class Main { + public static void main(String[] args) throws InterruptedException { + OtlpHttpMetricExporter exporter = + OtlpHttpMetricExporter.builder() + .setAggregationTemporalitySelector( + AggregationTemporalitySelector.deltaPreferred()) + .build(); + + MetricReader reader = + PeriodicMetricReader.builder(exporter).build(); + + MeterProvider provider = SdkMeterProvider.builder() + .registerMetricReader(reader) + .build(); + + Meter meter = provider.get("my-meter"); + + LongCounter counter = + meter.counterBuilder("example.counter").build(); + + for (int i = 0; i < 150; i++) { + counter.add(1); + Thread.sleep(2000); + } + } +} +``` +{{< /programming-lang >}} + +{{< programming-lang lang=".net" >}} +```c# +// 필수: $ dotnet 추가 패키지 OpenTelemetry.Exporter.OpenTelemetryProtocol + +using System.Diagnostics; +using System.Diagnostics.Metrics; +using OpenTelemetry; +using OpenTelemetry.Exporter; +using OpenTelemetry.Metrics; +using OpenTelemetry.Resources; +using System.Threading; +using System; +using System.Threading.Tasks; + +namespace GettingStarted; + +public class Program +{ + public static void Main() + { + using var meter = new Meter("my-meter"); + var providerBuilder = Sdk.CreateMeterProviderBuilder().AddMeter(meter.Name); + providerBuilder + .AddConsoleExporter((exporterOptions, metricReaderOptions) => + { + metricReaderOptions.PeriodicExportingMetricReaderOptions = new PeriodicExportingMetricReaderOptions + { + ExportIntervalMilliseconds = Convert.ToInt32("5000"), + }; + metricReaderOptions.TemporalityPreference = MetricReaderTemporalityPreference.Delta; + }) + .AddOtlpExporter((exporterOptions, metricReaderOptions) => + { + metricReaderOptions.PeriodicExportingMetricReaderOptions = new PeriodicExportingMetricReaderOptions + { + ExportIntervalMilliseconds = Convert.ToInt32("5000"), + }; + exporterOptions.Protocol = OtlpExportProtocol.HttpProtobuf; + metricReaderOptions.TemporalityPreference = MetricReaderTemporalityPreference.Delta; + }); + using var provider = providerBuilder.Build(); + + Counter counter = meter.CreateCounter("example.counter", "1", "Example counter"); + for (int i = 0; i < 150; i++) { + counter?.Add(1); + Task.Delay(2000).Wait(); + } + } +} + +``` +{{< /programming-lang >}} + +{{< /programming-lang-wrapper >}} + +비슷한 방식으로 OpenTelemetry Protocol gRPC 내보내기를 구성할 수 있습니다. + +## 수집기에서 델타 시간성으로 변환하기 + +메트릭이 OpenTelemetry 언어 라이브러리에서 제공되지 않는 경우 델타 집계 시간성을 사용하도록 구성하는 것이 불가능할 수 있습니다. 예를 들어 Prometheus와 같은 다른 오픈 소스 라이브러리로 메트릭을 생성하는 경우가 있습니다. 이때, [cumulative to delta 프로세서][3]를 사용하여 메트릭을 델타 집계 시간성에 매핑할 수 있습니다. 배포 환경이 스테이트풀인 경우, 즉 배포 환경에 여러 수집기가 있는 경우, 첫 번째 계층에서 프로세서를 사용하여 메트릭의 모든 포인트가 동일한 수집기 인스턴스로 전송되도록 해야 합니다. + +cumulative-to-delta 프로세서를 활성화하여 모든 지표에 적용하려면 `processors` 섹션에서 빈 구성으로 정의합니다. + +```yaml +processors: + cumulativetodelta: +``` + +마지막으로 메트릭 파이프라인의 `processors` 목록에 추가합니다. + +**참고**: cumulative-to-delta 프로세서는 지수 히스토그램을 지원하지 않습니다. 또한 최솟값 및 최댓값과 같은 일부 필드는 이 접근 방식으로는 복구할 수 없습니다. 대신 가능하면 OpenTelemetry SDK 접근 방식을 사용하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/metrics/open_telemetry/otlp_metric_types +[2]: https://opentelemetry.io/docs/reference/specification/metrics/data-model/#sums +[3]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/cumulativetodeltaprocessor +[4]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md#environment-variables \ No newline at end of file diff --git a/content/ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/reactnative.md b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/reactnative.md new file mode 100644 index 0000000000000..a22d5f59ac150 --- /dev/null +++ b/content/ko/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/reactnative.md @@ -0,0 +1,545 @@ +--- +aliases: +- /ko/real_user_monitoring/react-native/advanced_configuration/ +- /ko/real_user_monitoring/reactnative/advanced_configuration/ +code_lang: 리액티브 +code_lang_weight: 40 +description: React Native 설정을 위한 고급 설정 옵션에 대해 알아보세요. +further_reading: +- link: https://github.com/DataDog/dd-sdk-reactnative + tag: 소스 코드 + text: dd-sdk-reactnative를 위한 소스 코드 +- link: real_user_monitoring/reactnative/ + tag: 설명서 + text: React Native 모니터링에 대해 알아보기 +- link: real_user_monitoring/guide/monitor-hybrid-react-native-applications + tag: 설명서 + text: 하이브리드 React Native 애플리케이션 모니터링 +title: RUM React Native 고급 설정 +type: multi-code-lang +--- + +## 개요 + +SDK를 아직 설정하지 않은 경우 [앱 내 설정 지침서][1]를 따르거나 [React Native RUM 설정 설명서][2]를 참조하세요. + +## Jest로 테스트하기 + +네이티브 모듈은 테스트 환경에서 존재하지 않기 때문에 `'@datadog/mobile-react-native'`를 사용하여 앱을 테스트하려면 추가 단계를 완료해야 할 수 있습니다. + +Datadog은 `'@datadog/mobile-react-native'` 패키지에 대한 가짜 객체를 제공합니다. [Jest][4]와 함께 사용하려면 Jest 설정 파일에 다음을 추가합니다: + +```javascript +jest.mock('@datadog/mobile-react-native', () => { + return require('@datadog/mobile-react-native/jest/mock'); +}); +``` + +`DatadogProvider` 구성 요소로 SDK를 초기화하면 테스트에서 상호 작용, 오류 및 리소스 자동 추적이 비활성화됩니다. + +`jest.fn()`에 의해 모든 SDK 방식이 모킹되므로 Datadog SDK 방식이 호출되었다고 주장할 수 있습니다: + +```javascript +import { DdLogs } from '@datadog/mobile-react-native'; + +describe('App', () => { + it('calls DdLogs.debug on mount', () => { + renderer.create(); + expect(DdLogs.debug).toHaveBeenCalledWith('app started'); + }); +}); +``` + +Jest 이외의 테스트 러너를 사용하는 경우 테스트 러너에 대한 가짜 객체를 생성해야 합니다. + +## 초기화 파라미터 + +SDK를 초기화할 때 설정에서 다음 파라미터를 지정할 수 있습니다: + +`clientToken` +: 필수
+**유형**: 문자열
+[Datadog 클라이언트 토큰][8]. + +`env` +: 필수
+**유형**: 문자열
+애플리케이션의 환경(예: prod, pre-prod, staging). [태그 구문 요건][15]을 따릅니다. + +`applicationId` +: 필수
+**유형**: 문자열
+RUM 애플리케이션 ID. + +`trackInteractions` +: 선택 사항
+**유형**: 부울
+**기본값**: `false`
+사용자 액션 자동 수집 활성화 + +`trackResources` +: 선택 사항
+**유형**: 부울
+**기본값**: `false`
+리소스 이벤트 수집 활성화. + +`trackErrors` +: 선택 사항
+**유형**: 부울
+**기본값**: `false`
+React Native 충돌 수집 활성화 + +`site` +: 선택 사항
+**유형**: 문자열
+**기본값**: `US1`
+[조직의 Datadog 사이트 파라미터][9]. + +`serviceName` +: 선택 사항
+**유형**: 문자열
+애플리케이션 서비스 이름. [태그 구문 요건][15]을 따릅니다. + +`version` +: 선택 사항
+**유형**: 문자열
+애플리케이션 버전(예: 1.2.3, 6c44da20, 2020.02.13). [태그 구문 요건][15]을 따릅니다. + +`versionSuffix` +: 선택 사항
+**유형**: 문자열
+보고된 버전의 앱에 접미사를 추가합니다. 허용되는 문자는 영숫자이며, 버전과 접미사 사이에 자동으로 `_`,`-`, `:`, `.`, `/`. Other special characters are converted to underscores. A dash (`-`) 가 추가됩니다. [태그 구문 요건][15]을 따릅니다. + +`trackFrustrations` +: 선택 사항
+**유형**: 부울
+**기본값**: `true`
+[사용자 좌절 자동 수집][11]을 활성화합니다. 오류 탭만 지원되며,`trackInteractions: true`를 포함합니다. + +`nativeCrashReportEnabled` +: 선택 사항
+**Type**: 부울
+**Default**: `false`
+기본 플랫폼(iOS, Android)에 관한 크래시 보고를 활성화합니다. + +`sampleRate` +: 선택 사항 - **더 이상 사용되지 않음**
+**유형**: 숫자
+**기본값**: `100`
+`sessionSampleRate`를 확인하세요. + +`sessionSampleRate` +: 선택사 항
+**유형**: 숫자
+**기본값**:`100`
+추적하는 세션의 비율: 모두는 `100`이고 없음은 `0`입니다. 추적하는 세션만 RUM 이벤트를 보냅니다. + +`resourceTracingSamplingRate` +: 선택 사항
+**유형**: 숫자
+**기본값**: `20`
+추적 요청의 백분율: 모두 `100`이고 없음은 `0`입니다. 자세한 내용은 [RUM과 트레이스 연결][12]을 참조하세요. + +`verbosity` +: 선택 사항
+**유형**: SdkVerbosity
+**기본값**: `undefined`
+내부 SDK 로깅에 대한 상세도입니다. SDK 구현을 디버깅하도록 `SdkVerbosity.DEBUG`로 설정합니다. + +`nativeViewTracking` +: 선택 사항
+**유형**: 부울
+**기본값**: `false`
+기본 보기 추적을 활성화합니다. 기본 보기에 의존하는 커스텀 네비게이션 시스템을 사용하는 경우 `true`로 설정합니다. + +`nativeInteractionTracking` +: 선택사 항
+**유형**: 부울
+**기본값**: `false`
+기본 상호작용 추적을 활성화합니다. 기본 화면에서 상호작용을 추적하려면 `true`로 설정합니다. + +`firstPartyHosts` +: 선택 사항
+**Type**: 목록
+**Default**: `[]`
+추적을 활성화할 백엔드 호스트 목록입니다. 자세한 내용은 [RUM과 추적 연결하기][12]를 참조하세요. + +`telemetrySampleRate` +: 선택 사항
+**유형**: 숫자
+**기본값**: `20`
+잠재적인 문제를 감지하고 해결하기 위해 SDK 실행에 대한 텔레메트리 데이터(예: 오류 및 디버그 로그)가 Datadog으로 전송됩니다. 텔레메트리 수집을 거부하려면 이 옵션을 `0`으로 설정하세요. + +`longTaskThresholdMs` +: 선택 사항
+**유형**: 숫자 | 거짓
+**기본값**: `0`
+밀리초 단위로 보고되는 JavaScript 긴 작업의 임계값입니다. `0` 또는 `false`로 설정하면 JavaScript 긴 작업 보고가 비활성화됩니다. `100` 미만 값은 `100`으로 오르고 `5000` 이상 값은 `5000`으로 낮아집니다. + +`nativeLongTaskThresholdMs` +: 선택 사항
+**유형**: 숫자 | 거짓
+**기본값**: `200`
+밀리초 단위로 보고되는 기본 긴 작업의 임계값입니다. `0` 또는 `false`로 설정하면 JavaScript 의 긴 작업 보고를 비활성화합니다. `100`미만 값은 `100`으로 오르고 `5000`이상 값은 `5000`으로 낮아집니다. + +`vitalsUpdateFrequency` +: 선택 사항
+**유형**: VitalsUpdateFrequency
+**기본값**: `VitalsUpdateFrequency.AVERAGE`
+모바일 바이탈을 수집할 때 선호하는 빈도를 설정합니다. + +`uploadFrequency` +: 선택 사항
+**유형**: UploadFrequency
+**기본값**: `UploadFrequency.AVERAGE`
+데이터 배치를 업로드할 때 선호하는 빈도를 설정합니다. + +`batchSize` +: 선택 사항
+**유형**: BatchSize
+**기본값**: `BatchSize.MEDIUM`
+데이터를 Datadog 서버에 업로드하기 전에 데이터를 일괄 처리할 때 Datadog SDK 정책을 정의합니다. 작은 배치는 더 작지만 더 많은 네트워크 요청을 의미하고 큰 배치는 더 적지만 더 큰 네트워크 요청을 의미합니다. + +`trackBackgroundEvents` +: 선택 사항
+**유형**: 부울
+**기본값**: `false`
+RUM 보기가 활성화되지 않은 경우 RUM 이벤트 추적을 활성화합니다. 기본적으로 백그라운드 이벤트는 추적되지 않습니다. 이 기능을 활성화하면 추적되는 세션 수가 증가하고 빌링에 영향을 미칠 수 있습니다. + +`proxyConfig` +: 선택 사항
+**Type**: 프록시 구성
+선택적 [프록시 구성][13]. + +`useAccessibilityLabel` +: 선택 사항
+**Type**: 부울
+**Default**: `true`
+접근성 레이블을 사용하여 RUM 작업의 이름을 지정할지 여부를 결정합니다(기본값은 참). + +`bundleLogsWithRum` +: 선택 사항
+**Type**: 부울
+**Default**: `true`
+로그와의 RUM 상관관계를 활성화합니다(기본값은 참). + +`bundleLogsWithTraces` +: 선택 사항
+**Type**:: 부울
+**Default**: `true`
+로그와 트레이스 상관관계를 활성화합니다(기본값은 참). + +## 수동 계측 + +자동 계측이 필요에 맞지 않을 경우, RUM 이벤트 및 로그를 수동으로 생성할 수 있습니다: + +### 로그 전송 +코드를 계측하여 로그를 전송하는 경우 디버그, 정보, 경고, 또는 오류 세부 정보를 포함할 수 있습니다. + +```javascript +DdLogs.debug('Lorem ipsum dolor sit amet...', {}); +DdLogs.info('Lorem ipsum dolor sit amet...', {}); +DdLogs.warn('Lorem ipsum dolor sit amet...', {}); +DdLogs.error('Lorem ipsum dolor sit amet...', {}); +``` + +### RUM Views 수동 추적 +RUM Views를 수동으로 추적하려면 초기화 시 `view key`, `view name`, `action name`을 제공합니다. 필요에 따라 다음 전략 중 하나를 선택할 수 있습니다. + +```javascript +DdRum.startView('', 'View Name', {}, Date.now()); +//... +DdRum.stopView('', { custom: 42 }, Date.now()); +``` + +### RUM Actions 수동 추적 +RUM 작업을 수동으로 추적할 수 있습니다. + +```javascript +DdRum.addAction(RumActionType.TAP, 'action name', {}, Date.now()); +``` + +지속적 작업을 추적하려면, + +```javascript +DdRum.startAction(RumActionType.TAP, 'action name', {}, Date.now()); +//... +DdRum.stopAction({}, Date.now()); +``` + +### RUM Errors 수동 추적 +RUM 오류를 수동으로 추적할 수 있습니다. + +```javascript +DdRum.addError('', ErrorSource.SOURCE, '', {}, Date.now()); +``` + +### RUM Resources 수동 추적 +RUM 리소스를 수동으로 추적할 수 있습니다. + +```javascript +DdRum.startResource('', 'GET', 'http://www.example.com/api/v1/test', {}, Date.now()); +//... +DdRum.stopResource('', 200, 'xhr', (size = 1337), {}, Date.now()); +``` + +### 사용자 지정 타이밍 추가 +사용자 지정 타이밍을 추가할 수 있습니다. + +```javascript +DdRum.addTiming(''); +``` + +### 수동 스팬 전송 +수동으로 스팬을 전송할 수 있습니다. + +```javascript +const spanId = await DdTrace.startSpan('foo', { custom: 42 }, Date.now()); +//... +DdTrace.finishSpan(spanId, { custom: 21 }, Date.now()); +``` + +## 커스텀 글로벌 속성 추적 + +모든 RUM 이벤트에 사용자 정보를 첨부하여 RUM 세션에서 보다 자세한 정보를 얻을 수 있습니다. + +### 사용자 정보 + +사용자별 정보는 (SDK 초기화 후) 앱에서 원하는 곳에 다음 코드를 사용하세요. `id`, `name` 및 `email` 속성은 Datadog에 내장되어 있으며, 앱에 적합한 다른 속성을 추가할 수 있습니다. + +```js +DdSdkReactNative.setUser({ + id: '1337', + name: 'John Smith', + email: 'john@example.com', + type: 'premium' +}); +``` + +사용자 정보를 추가하거나 업데이트하려는 경우 다음 코드를 사용하여 기존 사용자의 세부 정보를 수정할 수 있습니다. + +```js +DdSdkReactNative.addUserExtraInfo({ + hasPaid: 'true' +}); +``` + +사용자 정보를 지우려면(예: 사용자가 로그아웃할 때) 다음과 같이 빈 개체를 전달하면 됩니다: + +```js +DdSdkReactNative.setUser({}); +``` + +### 전역 속성 + +A/B 테스트 설정, 광고 캠페인 출처, 카트 상태 등 특정 세션에 대한 정보를 추적하기 위해 글로벌 속성을 유지할 수도 있습니다. + +```js +DdSdkReactNative.setAttributes({ + profile_mode: 'wall', + chat_enabled: true, + campaign_origin: 'example_ad_network' +}); +``` + +## 모든 데이터 삭제 + +Datadog로 전송되지 않은 모든 데이터를 지우려면 `clearAllData`를 사용합니다. + +```js +DdSdkReactNative.clearAllData(); +``` + +## RUM 이벤트 수정 또는 삭제 + +RUM 이벤트가 Datadog으로 전송되기 전에 해당 특성을 수정하거나 이벤트를 완전히 삭제하려면 RUM React Native SDK를 설정할 때 Event Mappers API를 사용합니다: + +```javascript +const config = new DdSdkReactNativeConfiguration( + '', + '', + '', + true, // 사용자 상호 작용(예: 버튼 탭 등) 추적 + true, // XHR 리소스 추적 + true // 오류 추적 +); +config.logEventMapper = (event) => event; +config.errorEventMapper = (event) => event; +config.resourceEventMapper = (event) => event; +config.actionEventMapper = (event) => event; +``` + +각 맵퍼는 시그니처가 `(T) -> T?`인 함수이며, 여기서 `T`는 구체적인 RUM 이벤트 유형입니다. 이렇게 하면 이벤트가 전송되기 전에 이벤트의 일부를 변경하거나 이벤트를 완전히 삭제할 수 있습니다. + +예를 들어, RUM 오류 `message`에서 민감한 정보를 삭제하려면 커스텀 `redacted` 함수를 실행하고`errorEventMapper`에서 사용합니다: + +```javascript +config.errorEventMapper = (event) => { + event.message = redacted(event.message); + return event; +}; +``` + +오류, 리소스 또는 액션 맵퍼에서 `null`을 반환하면 이벤트가 완전히 삭제됩니다. 이벤트는 Datadog으로 전송되지 않습니다. + +이벤트 유형에 따라 일부 특정 프로퍼티만 수정할 수 있습니다: + +| 이벤트 유형 | 속성 키 | 설명 | +| ------------- | ------------------------ | ---------------------------------- | +| LogEvent | `logEvent.message` | 로그 메시지. | +| | `logEvent.context` | 로그의 커스텀 속성. | +| ActionEvent | `actionEvent.context` | 액션의 커스텀 속성. | +| ErrorEvent | `errorEvent.message` | 오류 메시지. | +| | `errorEvent.source` | 오류 소스. | +| | `errorEvent.stacktrace` | 오류의 스택 트레이스. | +| | `errorEvent.context` | 오류의 커스텀 속성. | +| | `errorEvent.timestampMs` | 오류의 타임스탬프. | +| ResourceEvent | `resourceEvent.context` | 리소스의 커스텀 속성. | + +이벤트는 추가 컨텍스트를 포함합니다: + +| 이벤트 유형 | 컨텍스트 속성 키 | 설명 | +| ------------- | ------------------------------------------------ | ----------------------------------------------------------------------- | +| LogEvent | `logEvent.additionalInformation.userInfo` | `DdSdkReactNative.setUser`가 설정한 글로벌 사용자 정보를 포함합니다. | +| | `logEvent.additionalInformation.attributes` | `DdSdkReactNative.setAttributes`가 설정한 글로벌 속성을 포함합니다. | +| ActionEvent | `actionEvent.actionContext` | 액션 또는 `undefined`에 해당하는 [GestureResponderEvent][5] 입니다. | +| | `actionEvent.additionalInformation.userInfo` | `DdSdkReactNative.setUser`가 설정한 글로벌 사용자 정보를 포함합니다. | +| | `actionEvent.additionalInformation.attributes` | `DdSdkReactNative.setAttributes`가 설정한 글로벌 속성을 포함합니다. | +| ErrorEvent | `errorEvent.additionalInformation.userInfo` | `DdSdkReactNative.setUser`가 설정한 글로벌 사용자 정보를 포함합니다. | +| | `errorEvent.additionalInformation.attributes` | `DdSdkReactNative.setAttributes`가 설정한 글로벌 속성을 포함합니다. | +| ResourceEvent | `resourceEvent.resourceContext` | 리소스 또는 `undefined`에 해당하는 [XMLHttpRequest][6] 입니다. | +| | `resourceEvent.additionalInformation.userInfo` | `DdSdkReactNative.setUser`가 설정한 글로벌 사용자 정보를 포함합니다. | +| | `resourceEvent.additionalInformation.attributes` | `DdSdkReactNative.setAttributes`가 설정한 글로벌 속성을 포함합니다. | + +## RUM 세션 ID 검색 + +RUM 세션 ID를 검색하면 문제 해결에 도움이 될 수 있습니다. 예를 들어 지원 요청, 이메일 또는 버그 보고서에 세션 ID를 첨부하면 나중에 지원 팀이 Datadog에서 사용자 세션을 찾을 수 있습니다. + +`sessionStarted` 이벤트를 기다리지 않고 런타임 중에 RUM 세션 ID에 액세스할 수 있습니다. + +```kotlin + fun getCurrentSessionId(promise: Promise) { + datadog.getRumMonitor().getCurrentSessionId { + promise.resolve(it) + } + } +``` + +## 리소스 타이밍 + +리소스 추적은 다음과 같은 타이밍을 제공합니다: + +- `First Byte`: 예약된 요청과 응답의 첫 번째 바이트 사이의 시간입니다. 이 시간에는 네이티브 수준의 요청 준비 시간, 네트워크 지연 시간, 서버가 응답을 준비하는 데 걸린 시간이 포함됩니다. +- `Download`: 응답을 받는 데 걸린 시간입니다. + +## 비동기적으로 초기화하기 + +앱이 시작될 때 많은 애니메이션이 포함되어 있는 경우, 이러한 애니메이션 중에 코드를 실행하면 일부 기기에서 애니메이션이 실행되는 것이 지연될 수 있습니다. 현재 모든 애니메이션이 시작된 후에 RUM용 Datadog React Native SDK 가 실행되도록 지연하려면 설정에서 `initializationMode`를 `InitializationMode.ASYNC`로 설정합니다: + +```js +import { DatadogProvider, DatadogProviderConfiguration, InitializationMode } from '@datadog/mobile-react-native'; + +const datadogConfiguration = new DatadogProviderConfiguration( + '', + '', + '', + true, + true, + true +); +datadogConfiguration.initializationMode = InitializationMode.ASYNC; + +export default function App() { + return ( + + + + ); +} +``` + +React Native의 [InteractionManager.runAfterInteractions][3]를 사용하여 애니메이션을 지연시킵니다. + +RUM SDK와의 모든 상호 작용(보기 추적, 액션, 리소스 추적 등)은 기록되고 100개의 이벤트 제한이 있는 대기열에 보관됩니다. + +로그는 기록되지 않으며 실제 초기화 전에 `DdLogs` 메서드를 호출하면 로깅이 중단될 수 있습니다. + +Datadog의 비동기 초기화를 설정하는 데 문제가 발생할 경우, [예제 애플리케이션][7]을 확인하세요. + +## 초기화 지연 + +SDK를 초기화하기 전에 기다려야 하는 상황이 있을 수 있습니다. 예를 들어 사용자 역할에 따라 다른 구성을 사용하거나 서버 중 하나에서 구성을 가져오고자 하는 경우입니다. + +이 경우 처음부터 앱을 자동 계측하고(사용자 상호작용, XHR 리소스 및 오류를 자동으로 수집) SDK를 초기화하기 전에 최대 100개의 RUM 및 스팬 이벤트를 기록할 수 있습니다. + +```js +import { DatadogProvider, DatadogProviderConfiguration } from '@datadog/mobile-react-native'; + +const datadogAutoInstrumentation = { + trackErrors: true, + trackInteractions: true, + trackResources: true, + firstPartyHosts: [''], + resourceTracingSamplingRate: 100 +}; + +const initializeApp = async () => { + const configuration = await fetchDatadogConfiguration(); // 서버 중 하나에서 구성을 가져옵니다. + await DatadogProvider.initialize(configuration); +}; + +export default function App() { + useEffect(() => initializeApp(), []); + + return ( + + + + ); +} +``` + +설정에 다음과 같은 키가 있는 경우: + +```js +import { ProxyConfig, SdkVerbosity, TrackingConsent } from '@datadog/mobile-react-native'; + +const configuration = { + clientToken: '', + env: '', + applicationId: '', + sessionSamplingRate: 80, // 선택 사항: RUM 세션 샘플링(여기서는 세션의 80%가 Datadog으로 전송됩니다). Default = 100% + site: 'US1', // 선택 사항: Datadog 사이트를 지정합니다. Default = 'US1' + verbosity: SdkVerbosity.WARN, // 선택 사항: SDK가 내부 로그를 출력하도록 설정할 수 있습니다 (제공된 수준 이상). Default = undefined (no logs) + serviceName: 'com.myapp', // Optional: set the reported service name. Default = package name / bundleIdentifier of your Android / iOS app respectively + nativeCrashReportEnabled: true, // 선택 사항: 네이티브 충돌 리포트를 활성화합니다. Default = false + version: '1.0.0', // 선택 사항: 보고되는 버전 재정의 방법은 문서를 참조하세요. Default = VersionName / Version of your Android / iOS app respectively + versionSuffix: 'codepush.v3', // 선택 사항: 보고되는 버전 재정의 방법은 문서를 참조하세요. Default = undefined + trackingConsent: TrackingConsent.GRANTED, // Optional: disable collection if user has not granted consent for tracking. Default = TrackingConsent.GRANTED + nativeViewTracking: true, // 선택 사항: 네이티브 뷰 추적을 활성화합니다. Default = false + proxyConfig: new ProxyConfig() // 선택 사항: 프록시를 통해 요청을 전송합니다. Default = undefined +}; +``` + +## 하이브리드 React Native 애플리케이션 모니터링 + +[하이브리드 리액트 네이티브 애플리케이션 모니터링][16]을 참조하세요. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: https://app.datadoghq.com/rum/application/create +[2]: /ko/real_user_monitoring/reactnative +[3]: https://reactnative.dev/docs/interactionmanager#runafterinteractions +[4]: https://jestjs.io/ +[5]: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react-native/v0.70/index.d.ts#L548 +[6]: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest +[7]: https://github.com/DataDog/dd-sdk-reactnative-examples/tree/main/rum-react-navigation-async +[8]: /ko/account_management/api-app-keys/#client-tokens +[9]: /ko/getting_started/site/ +[11]: /ko/real_user_monitoring/browser/frustration_signals/ +[12]: /ko/real_user_monitoring/platform/connect_rum_and_traces?tab=reactnativerum +[13]: /ko/real_user_monitoring/guide/proxy-mobile-rum-data/ +[15]: /ko/getting_started/tagging/#define-tags +[16]: /ko/real_user_monitoring/guide/monitor-hybrid-react-native-applications \ No newline at end of file diff --git a/content/ko/service_management/incident_management/describe.md b/content/ko/service_management/incident_management/describe.md new file mode 100644 index 0000000000000..79b29f7292eff --- /dev/null +++ b/content/ko/service_management/incident_management/describe.md @@ -0,0 +1,41 @@ +--- +further_reading: +- link: /service_management/incident_management/incident_settings + tag: 문서 + text: 인시던트 설정에서 인시던트 사용자 지정 +- link: /service_management/incident_management/notification + tag: 문서 + text: 인시던트 알림 구성 +title: 인시던트 설명 +--- + +## 개요 + +어디에서 [인시던트를 선언][1]하든, 조직의 인시던트 관리 프로세스에 참여하는 다른 사람들과 정보를 공유할 수 있도록 가능한 한 자세히 설명하는 것이 중요합니다. 인시던트 세부 사항에는 다음과 같은 정보가 포함되어야 합니다. +- 발생한 일 +- 발생한 이유 +- 인시던트와 관련 있는 속성 + +## 인시던트 상세 정보 + +인시던트의 상태 및 세부 정보는 인시던트의 개요 탭에서 업데이트할 수 있습니다. 인시던트에서 개요 탭에 인시던트 요약, 고객 영향, 영향을 받은 서비스, 인시던트 대응자, 근본 원인, 탐지 방법, 심각도 등 관련 세부 정보를 입력하여 팀에 인시던트를 조사하고 해결하는 데 필요한 모든 정보를 제공하세요. + +영향 섹션을 업데이트하여 시작 및 종료 시간을 포함하여 고객에게 미치는 영향을 기록하세요. 이러한 영향은 인시던트 분석에 도움을 주므로 조직은 비즈니스에서 인시던트의 영향을 분석할 수 있습니다. + +[인시던트 설정 속성 필드][2] 페이지에서 사용자 지정 인시던트 필드를 정의할 수 있습니다. + +### 상태 수준 + +기본 상태는 **Active**, **Stable** 및 **Resolved**입니다. 인시던트 설정 페이지에서 **Completed** 상태를 추가하고 각 상태 수준에 관한 설명을 사용자 지정할 수 있습니다. + +* 활성: 인시던트가 다른 요소에 영향을 미칩니다. +* 안정: 인시던트가 더 이상 다른 사람들에게 영향을 미치지 않지만, 조사가 완료되지 않았습니다. +* 해결됨: 인시던트가 더 이상 다른 요소에 영향을 미치지 않으며 조사가 완료되었습니다. +* 완료됨: 모든 교정이 완료되었습니다. + +## 참고 자료 + +{{< partial name="whats-next/whats-next.html" >}} + +[1]: /ko/service_management/incident_management/declare +[2]: https://app.datadoghq.com/incidents/settings#Property-Fields \ No newline at end of file diff --git a/content/ko/tracing/guide/send_traces_to_agent_by_api.md b/content/ko/tracing/guide/send_traces_to_agent_by_api.md index ee4fa9806653a..a3aa498ce6ea6 100644 --- a/content/ko/tracing/guide/send_traces_to_agent_by_api.md +++ b/content/ko/tracing/guide/send_traces_to_agent_by_api.md @@ -3,11 +3,13 @@ aliases: - /ko/api/latest/tracing/ - /ko/api/v1/tracing/ - /ko/api/v2/tracing/ +description: 사용자 지정 통합을 위해 추적 API를 사용하여 Datadog Agent 사용자 지정 통합 및 지원되지 않는 프레임워크에 직접 + 추적을 보내는 방법을 알아보세요. further_reading: - link: /tracing/ tag: 설명서 text: Datadog APM 트레이싱 알아보기 -- link: /tracing/visualization/ +- link: /tracing/glossary/ tag: 설명서 text: APM 용어 및 소개 title: API로 Agend에 트레이스 전송하기 @@ -15,7 +17,7 @@ title: API로 Agend에 트레이스 전송하기 Datadog 애플리케이션 성능 모니터링(APM)을 사용하면 코드를 트레이싱하여 성능 메트릭을 수집하고, 애플리케이션에서 느리거나 비효율적인 부분이 있는지 확인할 수 있습니다. -트레이싱 데이터는 HTTP API를 통해 계측된 코드에서 Datadog Agent로 전송됩니다. Datadog 트레이싱 라이브러리를 사용하여 Datadog Agent로의 메트릭 전송을 간단하게 처리할 수 있습니다. 단, 해당 라이브러리를 사용할 수 없는 애플리케이션이나 공식 Datadog 트레이싱 라이브러리가 아직 제공되지 않은 언어로 작성된 애플리케이션을 계측하기 위해 API를 직접 사용할 수도 있습니다. +추적 데이터는 계측된 코드에서 HTTP API를 통해 Datadog Agent로 전송됩니다. Datadog 추적 라이브러리를 사용하면 Datadog Agent로 메트릭을 간편하게 전송할 수 있습니다. 그러나 라이브러리를 사용할 수 없거나 아직 공식 Datadog 추적 라이브러리가 없는 언어로 작성된 애플리케이션을 계측하기 위해 API와 직접 상호 작용하고 싶을 수도 있습니다. 트레이싱 API는 서비스 측의 API가 아니라 Agent의 API입니다. 트레이스를 로컬 엔드포인트 `http://localhost:8126/v0.3/traces`로 전송하여, Agent가 트레이스를 Datadog로 전송할 수 있도록 하세요. @@ -41,21 +43,23 @@ trace1 = [ span, span2, span3 ] ### 모델 -| 항목 | 유형 | 설명 | +
Datadog 추적 라이브러리는 64비트 및 128비트 트레이스 ID를 모두 지원합니다. 자세한 내용은 스팬 및 트레이스 ID 형식을 참조하세요 .
+ +| 필드 | 유형 | 설명 | |------------|---------|---------------------------------------| | `duration` | int64 | 나노초 기준의 요청 처리 시간. | | `error` | int32 | 에러가 발생했음을 나타내려면 이 값을 1로 설정하세요. 오류가 발생하면 오류 메시지, 유형, 스택 등 추가 정보를 meta 속성으로 넘겨야 합니다. | | `meta` | 오브젝트 | 키값 메타데이터 세트. 키와 값은 스트링이어야 합니다. | -| - `` | 스트링 | 키값 메타데이터의 추가 속성. | +| - `` | 문자열 | 키값 메타데이터의 추가 속성. | | 메트릭 | 오브젝트 | 키값 메타데이터 세트. 키는 반드시 스트링이어야 하며, 값은 64bit 부동소수여야 합니다. | | - `` | double | 키값 메트릭의 추가 속성. | -| name | 스트링 | 스팬의 이름. 스팬 이름은 100자 이하여야 합니다. | +| name | 문자열 | 스팬의 이름. 스팬 이름은 100자 이하여야 합니다. | | `parent_id` | int64 | 부모 스팬의 스팬 정수 ID. | -| `resource` | 스트링 | 트레이싱하는 리소스. 리소스 이름은 5000자 이하여야 합니다. | -| `service` | 스트링 | 트레이싱하는 서비스. 서비스 이름은 100자 이하여야 합니다. | +| `resource` | 문자열 | 트레이싱하는 리소스. 리소스 이름은 5000자 이하여야 합니다. | +| `service` | 문자열 | 트레이싱하는 서비스. 서비스 이름은 100자 이하여야 합니다. | | `span_id` | int64 | 스팬 정수(64bit의 서명 없는) ID. | | `start` | int64 | UNIX Epoch로부터 나노초로 지정한 요청 시작 시간. | -| `trace_id` | int64 | 스팬을 포함하는 트레이스의 고유 정수(64bit의 서명 없는) ID. | +| `trace_id` | int64 | 트레이스에 대한 고유 정수 ID의 하단 64비트(스팬 포함)입니다. 128비트 트레이스 ID의 경우 `meta` 필드에 16진법으로 인코딩된 소문자 형식의 `_dd.p.tid` 태그를 사용하여 상위 64비트를 설정합니다. | | `type` | enum | 요청 유형. 사용할 수 있는 enum 값은 `web`, `db`, `cache`, `custom`입니다. | @@ -94,6 +98,10 @@ trace1 = [ span, span2, span3 ] ### 예시 +{{< tabs >}} + +{{% tab "Shell" %}} + {{< code-block lang="curl" >}} # Curl 명령어 curl -X PUT "http://localhost:8126/v0.3/traces" \ @@ -115,6 +123,38 @@ curl -X PUT "http://localhost:8126/v0.3/traces" \ EOF {{< /code-block >}} +{{% /tab %}} + +{{% tab "Powershell" %}} +{{< code-block lang="curl" >}} + +# Invoke-RestMethod 명령 + +$uri = "http://localhost:8126/v0.3/traces" +$headers = @{ + "Content-Type" = "application/json" +} +$body = @" +[ + [ + { + "duration": 12345, + "name": "span_name", + "resource": "/home", + "service": "service_name", + "span_id": 987654321, + "start": 0, + "trace_id": 123456789 + } + ] +] +"@ + +Invoke-RestMethod -Uri $uri -Method Put -Body $body -Headers $headers +{{< /code-block >}} +{{% /tab %}} +{{< /tabs >}} + ## 참고 자료 -{{< partial name="whats-next/whats-next.html" >}} +{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file From 1e33c00b04c266355eeb7b1fc9c86822c281b1da Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 17:54:42 +0000 Subject: [PATCH 2/8] Deleting translations of content/es/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/_index.md --- .../kotlin_multiplatform/_index.md | 44 ------------------- 1 file changed, 44 deletions(-) delete mode 100644 content/es/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/_index.md diff --git a/content/es/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/_index.md b/content/es/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/_index.md deleted file mode 100644 index d0fada3f6d0e1..0000000000000 --- a/content/es/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/_index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -description: Recopila datos de RUM y Error Tracking de tus proyectos de Kotlin Multiplatform. -further_reading: -- link: /real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/advanced_configuration - tag: Documentación - text: Configuración avanzada de RUM Kotlin Multiplatform -- link: https://github.com/DataDog/dd-sdk-kotlin-multiplatform - tag: Código fuente - text: Código fuente de dd-sdk-kotlin-multiplatform -- link: /real_user_monitoring - tag: Documentación - text: Explorar RUM de Datadog -- link: https://www.datadoghq.com/blog/kotlin-multiplatform-sdk/ - tag: Blog - text: Optimizar las aplicaciones móviles multiplataforma con Datadog RUM y el soporte - de Kotlin Multiplatform -title: Monitorización de Kotlin Multiplatform ---- -## Información general - -Datadog Real User Monitoring (RUM) te permite visualizar y analizar el rendimiento en tiempo real y los recorridos de cada usuario de tu aplicación. - -El SDK de Datadog Kotlin Multiplatform es compatible con Android 5.0+ (nivel de API 21) e iOS v12+. - -## Iniciar monitorización de aplicaciones de Kotlin Multiplatform - -Para empezar con RUM para Kotlin Multiplatform, crea una aplicación y configura el SDK de Kotlin Multiplatform. - -{{< whatsnext desc="Esta sección incluye los siguientes temas:">}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/setup">}}Configuración: conoce cómo configurar el SDK de Kotlin Multiplatform, rastrear eventos en segundo plano y enviar datos cuando los dispositivos están desconectados.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/error_tracking">}}Informes de fallos: añade la detección ANR y los eventos de fallos, obtén stack traces desenmascarados y, luego, prueba tu implementación.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/advanced_configuration">}}Configuración avanzada: mejora las sesiones de usuarios, administra los eventos y datos, rastrea los atributos globales personalizados y widgets, revisa parámetros de inicialización, modifica o deja eventos de RUM y más.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/mobile_vitals">}}Datos recopilados: revisa los datos que recopila el SDK de RUM Kotlin Multiplatform.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/mobile_vitals">}}Mobile Vitals: ve los signos de estado móviles, que ayudan a registrar la información sobre tu aplicación móvil.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/web_view_tracking">}}Web View Tracking: monitoriza las vistas web y elimina los puntos ciegos en tus aplicaciones móviles.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/integrated_libraries">}} - Bibliotecas integradas: importa las bibliotecas integradas para tus aplicaciones de Kotlin Multiplatform.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/kotlin_multiplatform/troubleshooting">}} - Solucionar problemas: soluciona problemas comunes del SDK de Kotlin Multiplatform.{{< /nextlink >}} -{{< /whatsnext >}} - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} \ No newline at end of file From 7fc82699d571b3b14f03b47c2a3090aaf4a02027 Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 17:55:20 +0000 Subject: [PATCH 3/8] Deleting translations of content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md --- .../react_native/troubleshooting.md | 294 ------------------ 1 file changed, 294 deletions(-) delete mode 100644 content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md deleted file mode 100644 index 1ba73ff0f5ffe..0000000000000 --- a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/react_native/troubleshooting.md +++ /dev/null @@ -1,294 +0,0 @@ ---- -aliases: -- /ja/real_user_monitoring/mobile_and_tv_monitoring/troubleshooting/reactnative -description: React Native Monitoring で発生する問題の対処方法を学びましょう。 -further_reading: -- link: https://github.com/DataDog/dd-sdk-reactnative - tag: ソースコード - text: dd-sdk-reactnative のソースコード -- link: /real_user_monitoring - tag: ドキュメント - text: Datadog Real User Monitoring -title: React Native SDK のトラブルシューティング ---- - -## 概要 - -Datadog React Native RUM で予期せぬ動作が発生した場合、このガイドを使用して問題を迅速に解決してください。問題が解決しない場合は、[Datadog サポート][1]にお問い合わせください。 - -## Datadog にデータが送信されていない - -SDK をインストールし、アプリをコンパイルしたが、Datadog からデータが受信されない場合、以下の手順で順番に説明します。 - -### 構成を確認する - -構成のちょっとした手違いによって、データが送信されない場合があります。 - -ここでは、よくあるチェックポイントをご紹介します。 - -- `clientToken` と `applicationId` が正しいことを確認します。 -- `sessionSamplingRate` を 100 (デフォルト値) 以外に設定していないか確認してください。それ以外の値に設定するとセッションが送信されない可能性があります。 -- Datadog の構成で `Proxy` を設定している場合、それが正しく構成されているか確認します。 -- ビューの追跡 (すべてのイベントはビューにアタッチされている必要があります) とイベントの送信を行っていることを確認してください。 - -### React Native で SDK のログを確認する - -- `config.verbosity = SdkVerbosity.DEBUG` を設定します。これは `@datadog/mobile-react-native` から `SdkVerbosity` をインポートしています。 -- 以下の出力のように、JavaScript コンソールにログが表示されるようになります。 - - ``` - INFO DATADOG: Datadog SDK was initialized - INFO DATADOG: Datadog SDK is tracking interactions - INFO DATADOG: Datadog SDK is tracking XHR resources - INFO DATADOG: Datadog SDK is tracking errors - DEBUG DATADOG: Starting RUM View "Products" #Products-oaZlP_FVwGM5vtPoup_rT - DEBUG DATADOG: Adding RUM Action "RCTView" (TAP) - ``` - - **注**: この例では、最初の 4 つのログは SDK が正しく構成されていることを示し、最後の 2 行は送信されたイベントです。 - -#### 考えられる原因 - -iOS で、ログや RUM イベントが初期化ログの**前**に送信されたことを示す DEBUG ログがある場合、これが SDK がイベントを送信しない理由かもしれません。 - -初期化前にイベントを送ることはできませんし、送ろうとすると SDK がデータを送れない状態になります。 - -#### ソリューション - -{{< tabs >}} -{{% tab "DdSdkReactNative.initialize" %}} - -Datadog SDK を起動するために `DdSdkReactNative.initialize` を使用する場合、トップレベルの `index.js` ファイルでこの関数を呼び出し、他のイベントが送信される前に SDK が初期化されるようにします。 - -{{% /tab %}} -{{% tab "DatadogProvider" %}} - -SDK バージョン `1.2.0` からは、`DatadogProvider` コンポーネントを使用して SDK を初期化することができます。このコンポーネントには RUM イベントバッファが含まれており、Datadog にデータを送信する前に SDK が初期化されていることを確認することで、この問題の発生を防ぐことができます。 - -利用するには、[Datadog Provider への移行ガイド][1]をご覧ください。 - -[1]: https://github.com/DataDog/dd-sdk-reactnative/blob/develop/docs/migrating_to_datadog_provider.md - -{{% /tab %}} -{{< /tabs >}} - -### ネイティブログを確認する - -ネイティブのログを確認することで、何が問題になっているのか、より多くの情報を得ることができます。 - -#### iOS の場合 - -- Xcode で `xed ios` を実行し、プロジェクトを開きます。 -- シミュレーターやデバイス向けにプロジェクトを構築します。 -- 右下にネイティブログが表示され始めます。 - - {{< img src="real_user_monitoring/react_native/troubleshooting-xcode-logs.png" alt="ネイティブログを確認することで、データが送信されない原因を突き止めることができます" >}} - -"DATADOG" でログをフィルターして、任意のエラーを探すことができます。 - -確かにイベントを送信していれば、以下のようなログが表示されるはずです。 - -``` -[DATADOG SDK] 🐶 → 10:02:47.398 [DEBUG] ⏳ (rum) Uploading batch... -[DATADOG SDK] 🐶 → 10:02:47.538 [DEBUG] → (rum) accepted, won't be retransmitted: [response code: 202 (accepted), request ID: AAAABBBB-1111-2222-3333-777788883333] -``` - -第 1 ログは、何らかのデータを送信中であることを示し、第 2 ログは、データを受信したことを示します。 - -##### 考えられる原因 - -以下のようなログが表示された場合、SDK を初期化する前に RUM メソッドを呼び出したことを意味します。 - -``` -[DATADOG SDK] 🐶 → 10:09:13.621 [WARN] The `Global.rum` was called but no `RUMMonitor` is registered. Configure and register the RUM Monitor globally before invoking the feature: -``` - -##### ソリューション - -{{< tabs >}} -{{% tab "DdSdkReactNative.initialize" %}} - -Datadog SDK を起動するために `DdSdkReactNative.initialize` を使用する場合、トップレベルの `index.js` ファイルでこの関数を呼び出し、他のイベントが送信される前に SDK が初期化されるようにします。 - -{{% /tab %}} -{{% tab "DatadogProvider" %}} - -SDK バージョン `1.2.0` からは、`DatadogProvider` コンポーネントを使用して SDK を初期化することができます。このコンポーネントには RUM イベントバッファが含まれており、Datadog にデータを送信する前に SDK が初期化されていることを確認することで、この問題の発生を防ぐことができます。 - -利用するには、[Datadog Provider への移行ガイド][1]をご覧ください。 - - -[1]: https://github.com/DataDog/dd-sdk-reactnative/blob/develop/docs/migrating_to_datadog_provider.md - -{{% /tab %}} -{{< /tabs >}} - -#### Android の場合 - -- より快適にデバッグするために、Datadog では [pidcat][2] のインストールを推奨しています。 - - pidcat は、デバイスログ (`adb logcat` で取得) をフィルターして、アプリケーションからのものだけを表示します。 - - Python 2 を持っていない M1 ユーザーは [この Issue][3] をご参照ください。 -- ネイティブ SDK から冗長ログを有効にするため、`node_modules/@datadog/mobile-react-native/android/src/main/kotlin/com/datadog/reactnative/DdSdk.kt` を修正します。 - - ```java - fun initialize(configuration: ReadableMap, promise: Promise) { - // ... - - datadog.initialize(appContext, credentials, nativeConfiguration, trackingConsent) - datadog.setVerbosity(Log.VERBOSE) // Add this line - - // ... - } - ``` - -- ラップトップにデバッグモードで接続されたスマートフォン (`adb devices` を実行すると表示されるはずです)、またはエミュレーターからアプリを実行してください。 -- ラップトップから pidcat `my.app.package.name` または `adb logcat` を実行します。 -- Datadog に言及したエラーがないか確認します。 - -Pidcat の出力は次のようになります。 - -{{< img src="real_user_monitoring/react_native/troubleshooting-pidcat-logs.png" alt="これは、pidcat の出力例です" >}} - -この例では、最後のログは、RUM データのバッチが正常に送信されたことを示します。 - -## 未定義のシンボル: Swift - -以下のエラーメッセージが表示された場合 - -``` -Undefined symbols for architecture x86_64: - "static Foundation.JSONEncoder.OutputFormatting.withoutEscapingSlashes.getter : Foundation.JSONEncoder.OutputFormatting", referenced from: - static (extension in Datadog):Foundation.JSONEncoder.default() -> Foundation.JSONEncoder in libDatadogSDK.a(JSONEncoder.o) -... -``` - -Xcode を開き、プロジェクト (アプリのターゲットではない) の `Build Settings` を開き、Library Search Paths が以下の設定になっていることを確認してください。 - -```shell -LIBRARY_SEARCH_PATHS = ( - "\"$(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME)\"", - "\"/usr/lib/swift\"", - "\"$(inherited)\"", -); -``` - -## 未定義のシンボル: _RCTModule - -_RCTModule が未定義である旨のエラーが表示される場合は、[react-native v0.63 のチェンジログ][4]にある変更が原因かもしれません。 - -以下のように変更することで解決します。 - -```objectivec -// DdSdk.m -// 以下の代わりに -#import -// おそらく: -@import React // または @import React-Core -``` - -## 無限ループのようなエラーメッセージ - -[React Native プロジェクトがエラーメッセージを次々と表示し、CPU 使用率が著しく上昇する問題][5]に遭遇した場合は、React Native プロジェクトを新規に作成してみてください。 - -## SDK バージョン 2.* での Android ビルドエラー - -### Unable to make field private final java.lang.String java.io.File.path accessible - -もし Android ビルドが以下のようなエラーで失敗する場合: - -``` -FAILURE: Build failed with an exception. - -* What went wrong: -Execution failed for task ':app:processReleaseMainManifest'. -> Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module @1bbf7f0e -``` - -現在使用している Java 17 は、お使いの React Native バージョンと互換性がありません。Java 11 に切り替えると問題を解決できます。 - -### java.lang.UnsupportedClassVersionError - -もし Android ビルドが以下のようなエラーで失敗する場合: - -``` -java.lang.UnsupportedClassVersionError: com/datadog/android/lint/DatadogIssueRegistry has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 -``` - -Java のバージョンが古すぎます。Java 17 に切り替えてください。 - -### Unsupported class file major version 61 - -もし Android ビルドが以下のようなエラーで失敗する場合: - -``` -FAILURE: Build failed with an exception. - -* What went wrong: -Could not determine the dependencies of task ':app:lintVitalRelease'. -> Could not resolve all artifacts for configuration ':app:debugRuntimeClasspath'. - > Failed to transform dd-sdk-android-core-2.0.0.aar (com.datadoghq:dd-sdk-android-core:2.0.0) to match attributes {artifactType=android-manifest, org.gradle.category=library, org.gradle.dependency.bundling=external, org.gradle.libraryelements=aar, org.gradle.status=release, org.gradle.usage=java-runtime}. - > Execution failed for JetifyTransform: /Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar. - > Failed to transform '/Users/me/.gradle/caches/modules-2/files-2.1/com.datadoghq/dd-sdk-android-core/2.0.0/a97f8a1537da1de99a86adf32c307198b477971f/dd-sdk-android-core-2.0.0.aar' using Jetifier. Reason: IllegalArgumentException, message: Unsupported class file major version 61. (Run with --stacktrace for more details.) -``` - -Android Gradle Plugin のバージョンが `5.0` 未満です。問題を修正するには、`android/gradle.properties` ファイルに以下を追加してください: - -```properties -android.jetifier.ignorelist=dd-sdk-android-core -``` - -### Duplicate class kotlin.collections.jdk8.* - -もし Android ビルドが以下のようなエラーで失敗する場合: - -``` -FAILURE: Build failed with an exception. - -* What went wrong: -Execution failed for task ':app:checkReleaseDuplicateClasses'. -> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckDuplicatesRunnable - > Duplicate class kotlin.collections.jdk8.CollectionsJDK8Kt found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk8-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.7.20) - Duplicate class kotlin.internal.jdk7.JDK7PlatformImplementations found in modules jetified-kotlin-stdlib-1.8.10 (org.jetbrains.kotlin:kotlin-stdlib:1.8.10) and jetified-kotlin-stdlib-jdk7-1.7.20 (org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.7.20) -``` - -Kotlin の依存関係が競合しないよう、プロジェクトで使用する Kotlin バージョンを指定する必要があります。`android/build.gradle` ファイルで `kotlinVersion` を指定してください: - -```groovy -buildscript { - ext { - // targetSdkVersion = ... - kotlinVersion = "1.8.21" - } -} -``` - -あるいは、`android/app/build.gradle` ファイルのビルドスクリプトに以下のルールを追加できます: - -```groovy -dependencies { - constraints { - implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.8.21") { - because("kotlin-stdlib-jdk7 is now a part of kotlin-stdlib") - } - implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.21") { - because("kotlin-stdlib-jdk8 is now a part of kotlin-stdlib") - } - } -} -``` - -## "Deobfuscation failed" warning - -スタックトレースのデオブフスケーションに失敗したときに警告が表示されることがあります。スタックトレースがもともと難読化されていない場合は、この警告は無視してかまいません。そうでない場合は、[RUM Debug Symbols ページ][6]でアップロードしたソースマップや dSYM、mapping ファイルを確認してください。[RUM Debug Symbols を用いた難読化スタックトレースの調査][7]も併せてご覧ください。 - -## その他の参考資料 - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: /ja/help -[2]: https://github.com/JakeWharton/pidcat -[3]: https://github.com/JakeWharton/pidcat/issues/180#issuecomment-1124019329 -[4]: https://github.com/facebook/react-native/commit/6e08f84719c47985e80123c72686d7a1c89b72ed -[5]: https://github.com/facebook/react-native/issues/28801 -[6]: https://app.datadoghq.com/source-code/setup/rum -[7]: /ja/real_user_monitoring/guide/debug-symbols \ No newline at end of file From 3a26c78fd2dbd655e91518ea0fea4fd9b1162451 Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 17:57:38 +0000 Subject: [PATCH 4/8] Deleting translations of content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md --- .../flutter/error_tracking.md | 95 ------------------- 1 file changed, 95 deletions(-) delete mode 100644 content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md deleted file mode 100644 index 1711472ce9fd8..0000000000000 --- a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Flutter のクラッシュレポートとエラー追跡 ---- - -## 概要 - -クラッシュレポートとエラー追跡を有効にすると、リアルユーザーモニタリングで包括的なクラッシュレポートとエラートレンドを取得できます。 - -クラッシュレポートは [**Error Tracking**][1] に表示されます。 - -## セットアップ - -Datadog Flutter SDK for RUM をまだセットアップしていない場合は、[アプリ内セットアップ手順][2]に従うか、[Flutter セットアップドキュメント][3]を参照してください。 - -### ネイティブクラッシュレポートの追加 - -初期化スニペットを更新し、`nativeCrashReportEnabled` を `true` に設定することで iOS と Android のネイティブクラッシュレポートを有効化します。 - -例: - -```dart -final configuration = DdSdkConfiguration( - clientToken: 'DD_CLIENT_TOKEN' - env: 'DD_ENV' - site: DatadogSite.us1, - trackingConsent: TrackingConsent.granted, - nativeCrashReportEnabled: true, // このフラグを設定します - loggingConfiguration: LoggingConfiguration(), - rumConfiguration: 'DD_APP_ID', -); -DatadogSdk.instance.initialize(configuration); -``` - -アプリケーションが致命的なクラッシュに見舞われた場合、アプリケーションが再起動すると、Datadog Flutter SDK は Datadog にクラッシュレポートをアップロードします。致命的でないエラーの場合、Datadog Flutter SDK はこれらのエラーを他の RUM データと共にアップロードします。 - - -## Datadog へのシンボルファイルのアップロード - -ネイティブ iOS クラッシュレポートは生のフォーマットで収集され、そのほとんどがメモリアドレスを含んでいます。これらのアドレスを読みやすいシンボル情報にマッピングするために、Datadog は .dSYM ファイルのアップロードを必要とし、これはアプリケーションのビルドプロセスで生成されます。 - -`--split-debug-info` オプションセットと `--obfuscate` オプションセットでビルドされたすべてのクラッシュレポートについて、その Android Proguard マッピングファイルと Flutter ビルドプロセスによって生成された Dart シンボルファイルをアップロードする必要があります。 - - -コマンドラインツール [@datadog/datadog-ci][4] は、必要なファイル (dSYMs、Android Proguard Mapping、Dart Symbol Files) を 1 つのコマンドでアップロードすることに対応しています。 - -まず、上記の手順で `datadog-ci` ツールをインストールし、プロジェクトのルートに `datadog-ci.json` ファイルを作成し、API キーと (オプションで) Datadog サイトを記述します。 -```json -{ - "apiKey": "", - "datadogSite": "datadoghq.eu" // datadoghq.com を使用している場合はオプション -} -``` - -このファイルには API キーが含まれているため、バージョン管理にはチェックインしないでください。 - -代わりに、環境変数 `DATADOG_API_KEY` と `DATADOG_SITE` を設定することも可能です。 - -次に、以下のコマンドを使用して、クラッシュレポートのシンボル化および難読化解除に必要なすべてのファイルをアップロードすることができます。 -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms -``` - -オプションの完全なリストは、`datadog-ci` [Flutter Symbols のドキュメント][6]を参照してください。 - -## 高度な設定: フレーバーとビルド番号 - -Datadog は、`service-name`、`version`、`flavor` の組み合わせで難読化のための正しいシンボルを探すので、`datadog-ci` コマンドに送るパラメーターと [DdSdkConfiguration][7] で設定するパラメーター - -Flutter でアプリの[フレーバー][8]を使用している場合、フレーバーを自動検出できないため、[DdSdkConfiguration.flavor][9] でフレーバーの名前を設定する必要があります。そして、これを `datadog-ci` コマンドの `--flavor` パラメーターに渡すことができます。 - -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --flavor my_flavor -``` - -Datadog SDK は、 `pubspec.yaml` に指定されたアプリケーションのバージョン番号を、ビルド番号を含まない範囲まで自動的に検出します。アプリケーションでバージョンにビルド番号を含めており、ビルドごとにシンボルをアップロードする必要がある場合は、 [DdSdkConfiguration.version][10] にそのバージョンを追加してください。その後、`datadog-ci` コマンドの `--version` パラメーターにこれを渡します: - -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --version 1.2.3+22 -``` - -Datadog は `+` を許さないバージョンのタグを使用することに注意してください。すべてのツールは、バージョンタグが Datadog で検索できるように、自動的に `+` を `-` に置き換えます。 - -## 参考資料 - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: https://app.datadoghq.com/rum/error-tracking -[2]: https://app.datadoghq.com/rum/application/create -[3]: https://docs.datadoghq.com/ja/real_user_monitoring/flutter/#setup -[4]: https://www.npmjs.com/package/@datadog/datadog-ci -[6]: https://github.com/DataDog/datadog-ci/tree/master/src/commands/flutter-symbols -[7]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration-class.html -[8]: https://docs.flutter.dev/deployment/flavors -[9]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/flavor.html -[10]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/version.html \ No newline at end of file From 6e87e2a2d50da8b44013af0640eca3c191cda8ad Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 17:58:11 +0000 Subject: [PATCH 5/8] Deleting translations of content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md --- .../flutter/error_tracking.md | 95 ------------------- 1 file changed, 95 deletions(-) delete mode 100644 content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md diff --git a/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md b/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md deleted file mode 100644 index c4cad0b268b60..0000000000000 --- a/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Notificación de fallos y seguimiento de errores de Flutter ---- - -## Información general - -Habilita ell informe de fallos y Error Tracking para obtener informes completos de fallos y tendencias de errores con Real User Monitoring. - -Tus informes de fallos aparecen en [**Seguimiento de errores**][1]. - -## Configuración - -Si aún no has configurado el SDK de Datadog Flutter para RUM, sigue las [instrucciones de configuración en la aplicación][2] o consulta la [documentación de configuración de Flutter][3]. - -### Añadir la notificación de fallos nativa - -Actualiza tu fragmento de inicialización para habilitar la la notificación de fallos nativa para iOS y Android configurando `nativeCrashReportEnabled` como `true`. - -Por ejemplo: - -```dart -final configuration = DdSdkConfiguration( - clientToken: 'DD_CLIENT_TOKEN' - env: 'DD_ENV' - site: DatadogSite.us1, - trackingConsent: TrackingConsent.granted, - nativeCrashReportEnabled: true, // Set this flag - loggingConfiguration: LoggingConfiguration(), - rumConfiguration: 'DD_APP_ID', -); -DatadogSdk.instance.initialize(configuration); -``` - -Si tu aplicación sufre un fallo fatal, una vez que se reinicia, el SDK de Datadog Flutter carga un informe de fallo en Datadog. Para errores no fatales, el SDK de Datadog Flutter carga estos errores con otros datos de RUM. - - -## Carga de archivos de símbolos en Datadog - -Los informes de fallos iOS se recopilan en un formato no procesado y contienen principalmente direcciones de memoria. Para convertir estas direcciones en información de símbolos legible, Datadog necesita que cargues archivos .dSYM, que se generan durante el proceso de compilación de tu aplicación. - -Para todos los informes de fallos que se compilan con el conjunto de opciones `--split-debug-info` o con el conjunto de opciones `--obfuscate`, es necesario cargar tu archivo de asignación de Android Proguard y archivos de símbolos Dart generados por el proceso de compilación de Flutter. - - -La herramienta de línea de comandos [@Datadog/Datadog-ci][4] permite cargar todos los archivos necesarios (archivos dSYM, de asignación Proguard Android y de símbolos de Dart) en un solo comando. - -En primer lugar, instala la herramienta `datadog-ci` siguiendo las instrucciones anteriores y crea un archivo `datadog-ci.json` en la raíz de tu proyecto, que contenga tu clave de API y (opcionalmente) tu sitio Datadog: -```json -{ - "apiKey": "", - "datadogSite": "datadoghq.eu" // Optional if you are using datadoghq.com -} -``` - -Dado que este archivo contiene tu clave de API, no debe registrarse en el control de versiones. - -Alternativamente, puedes establecer las variables de entorno `DATADOG_API_KEY` y `DATADOG_SITE`. - -A continuación, puedes utilizar el siguiente comando para cargar todos los archivos necesarios para la simbolización y desofuscación de tus informes de fallos: -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms -``` - -Si deseas consultar la lista completa de opciones, consulta la [documentación de símbolos de Flutter][6] `datadog-ci`. - -## Configuración avanzada: tipos y números de compilación - -Datadog utiliza la combinación de los comandos `service-name`, `version` y `flavor` para localizar los símbolos correctos para desenmascarar, es decir, los parámetros enviados al comando `datadog-ci` y los parámetros establecidos en [DdSdkConfiguration][7] - -Si estás usando [tipos][8] (flavors) de aplicación en Flutter, necesitarás establecer el nombre del tipo en [DdSdkConfiguration.flavor][9], ya que no podemos detectar el tipo automáticamente. A continuación, puedes pasar esto al parámetro `--flavor` del comando `datadog-ci`: - -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --flavor my_flavor -``` - -El SDK de Datadog detecta automáticamente el número de versión de tu aplicación especificado en `pubspec.yaml` hasta el número de compilación, pero sin incluirlo. Si utilizas números de compilación como parte de la versión de tu aplicación y necesitas cargar símbolos para cada compilación, deberás añadir la versión a [DdSdkConfiguration.version][10]. A continuación, puedes pasar esto al parámetro `--version` del comando `datadog-ci`: - -```sh -datadog-ci flutter-symbols upload --service-name --dart-symbols-location --android-mapping --ios-dsyms --version 1.2.3+22 -``` - -Ten en cuenta que Datadog utiliza etiquetas para las versiones que no permiten `+`. Todas las herramientas sustituyen automáticamente `+` por `-` para que las etiquetas de versiones puedan buscarse en Datadog. - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: https://app.datadoghq.com/rum/error-tracking -[2]: https://app.datadoghq.com/rum/application/create -[3]: https://docs.datadoghq.com/es/real_user_monitoring/flutter/#setup -[4]: https://www.npmjs.com/package/@datadog/datadog-ci -[6]: https://github.com/DataDog/datadog-ci/tree/master/src/commands/flutter-symbols -[7]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration-class.html -[8]: https://docs.flutter.dev/deployment/flavors -[9]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/flavor.html -[10]: https://pub.dev/documentation/datadog_flutter_plugin/latest/datadog_flutter_plugin/DatadogConfiguration/version.html \ No newline at end of file From 0a72ffbc589b7be93bc77ae44dcaedf7f9a1e25f Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 18:01:22 +0000 Subject: [PATCH 6/8] Deleting translations of content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md --- .../flutter/_index.md | 34 ------------------- 1 file changed, 34 deletions(-) delete mode 100644 content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md diff --git a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md b/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md deleted file mode 100644 index cef2227436a48..0000000000000 --- a/content/ja/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -further_reading: -- link: /real_user_monitoring/mobile_and_tv_monitoring/flutter/advanced_configuration - tag: ドキュメント - text: RUM Flutter の高度なコンフィギュレーション -- link: https://github.com/DataDog/dd-sdk-flutter - tag: ソースコード - text: dd-sdk-flutter のソースコード -- link: /real_user_monitoring - tag: ドキュメント - text: Datadog RUM を探索する -title: Flutter モニタリング ---- -## 概要 - -Datadog Real User Monitoring (RUM) を使用すると、アプリケーションの個々のユーザーのリアルタイムパフォーマンスとユーザージャーニーを視覚化して分析できます。 - -## Flutter アプリケーションのモニタリングを開始する - -Flutter 向け RUM を使い始めるには、アプリケーションを作成し、Flutter SDK を構成します。 - -{{< whatsnext desc="このセクションでは、以下のトピックについて説明します。">}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/setup">}}セットアップ: Flutter SDK のセットアップ方法、バックグラウンドイベントのトラッキング方法、およびデバイスがオフラインの場合のデータ送信方法について学びます。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking">}}クラッシュレポーティング: ANR 検知とクラッシュレポートを追加し、難読化解除後のスタックトレースを取得して、実装をテストします。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/advanced_configuration">}}高度な構成: ユーザーセッションの拡充、イベントとデータの管理、カスタムグローバル属性やウィジェットの追跡、初期化パラメータの確認、RUM イベントの変更または破棄などについて説明します。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/mobile_vitals">}}収集されるデータ: RUM Flutter SDK が収集するデータを確認します。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/mobile_vitals">}}モバイルバイタル: モバイルアプリケーションの分析に役立つモバイルバイタルを確認します。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/web_view_tracking/?tab=flutter">}} -Web View トラッキング: モバイルアプリケーション内の Web View をモニタリングし、見落としを防ぎます。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/integrated_libraries">}} -組み込みライブラリ: Flutter アプリケーション向けの組み込みライブラリをインポートします。{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/troubleshooting">}} -トラブルシューティング: Flutter SDK でよくある問題を解決する方法を紹介します。{{< /nextlink >}} -{{< /whatsnext >}} \ No newline at end of file From aeee5eabe0a9e69a3731d1d0fd58322e3cae8b90 Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 18:01:57 +0000 Subject: [PATCH 7/8] Deleting translations of content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md --- .../flutter/_index.md | 34 ------------------- 1 file changed, 34 deletions(-) delete mode 100644 content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md diff --git a/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md b/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md deleted file mode 100644 index 200c525378574..0000000000000 --- a/content/es/real_user_monitoring/mobile_and_tv_monitoring/flutter/_index.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -further_reading: -- link: /real_user_monitoring/mobile_and_tv_monitoring/flutter/advanced_configuration - tag: Documentación - text: Configuración avanzada de RUM Flutter -- link: https://github.com/DataDog/dd-sdk-flutter - tag: Código fuente - text: Código fuente de dd-sdk-flutter -- link: /real_user_monitoring - tag: Documentación - text: Explorar RUM de Datadog -title: Monitorización Flutter ---- -## Información general - -Datadog Real User Monitoring (RUM) te permite visualizar y analizar el rendimiento en tiempo real y los recorridos de cada usuario de tu aplicación. - -## Empezar a monitorizar aplicaciones Flutter - -Para empezar a utilizar RUM para Flutter, crea una aplicación y configura el SDK Flutter. - -{{< whatsnext desc="Esta sección incluye los siguientes temas:">}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/setup">}}Configuración: Aprende a configurar el SDK Flutter, rastrear eventos en segundo plano y enviar eventos cuando los dispositivos no están conectados.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/error_tracking">}}Notificación de fallos: Añade la detección y la notificación de fallos de ANR, obtén trazas (traces) de stack tecnológico desofuscadas y luego prueba tu implementación.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/advanced_configuration">}}Configuración avanzada: Enriquece sesiones de usuario, gestiona eventos y datos, realiza un seguimiento de atributos globales y widgets personalizados, revisa parámetros de inicialización, modifica o descarta eventos RUM y mucho más.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/mobile_vitals">}}Datos recopilados: Revisa los datos que recopila el SDK RUM Flutter.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/mobile_vitals">}}Vitals de móviles: Visualiza vitals de móviles para ayudarte a computar datos de tu aplicación móvil.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/web_view_tracking/?tab=flutter">}} - Seguimiento de vistas web: Monitoriza vistas web y elimina puntos ciegos en tus aplicaciones móviles.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/integrated_libraries">}} - Bibliotecas integradas: Importa bibliotecas integradas para tus aplicaciones Flutter.{{< /nextlink >}} - {{< nextlink href="/real_user_monitoring/mobile_and_tv_monitoring/flutter/troubleshooting">}} - Solucionar problemas: Soluciona problemas frecuentes del SDK Flutter.{{< /nextlink >}} -{{< /whatsnext >}} \ No newline at end of file From 43183eeaffba6357665990bf35fa9d44bf4b56ce Mon Sep 17 00:00:00 2001 From: "webops-guacbot[bot]" <214537265+webops-guacbot[bot]@users.noreply.github.com> Date: Mon, 6 Oct 2025 18:03:11 +0000 Subject: [PATCH 8/8] Deleting translations of content/es/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration.md --- .../ios/advanced_configuration.md | 831 ------------------ 1 file changed, 831 deletions(-) delete mode 100644 content/es/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration.md diff --git a/content/es/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration.md b/content/es/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration.md deleted file mode 100644 index 023ca897083cd..0000000000000 --- a/content/es/real_user_monitoring/mobile_and_tv_monitoring/ios/advanced_configuration.md +++ /dev/null @@ -1,831 +0,0 @@ ---- -aliases: -- /es/real_user_monitoring/ios/advanced_configuration -- /es/real_user_monitoring/mobile_and_tv_monitoring/advanced_configuration/ios -further_reading: -- link: https://github.com/DataDog/dd-sdk-ios - tag: Código fuente - text: Código fuente de dd-sdk-ios -- link: /real_user_monitoring - tag: Documentación - text: RUM y Session Replay -- link: /real_user_monitoring/mobile_and_tv_monitoring/ios/supported_versions/ - tag: Documentación - text: Versiones compatibles de la monitorización de RUM iOS y tvOS -title: Configuración avanzada de iOS ---- - -Si aún no has configurado el SDK de RUM iOS, sigue las [instrucciones de configuración dentro de la aplicación][1] o consulta la [documentación de configuración de RUM iOS][2]. - -## Mejorar las sesiones de usuario - -iOS RUM rastrea automáticamente atributos como la actividad de usuario, las pantallas, los errores y las solicitudes de red. Consulta la [documentación de recopilación de datos de RUM][3] para obtener información sobre los eventos de RUM y los atributos predeterminados. Para mejorar aún más la información de sesión de usuario y obtener un control más preciso sobre los atributos recopilados, puedes rastrear eventos personalizados. - -### Vistas personalizadas - -Además de [rastrear vistas automáticamente](#automatically-track-views), también puedes rastrear vistas específicas como `viewControllers` cuando se vuelven visibles e interactivas. Detén el rastreo cuando la vista deje de ser visible con los siguientes métodos en `RUMMonitor.shared()`: - -- `.startView(viewController:)` -- `.stopView(viewController:)` - -Por ejemplo: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogRUM - -// in your `UIViewController`: -let rum = RUMMonitor.shared() - -override func viewDidAppear(_ animated: Bool) { - super.viewDidAppear(animated) - rum.startView(viewController: self) -} - -override func viewDidDisappear(_ animated: Bool) { - super.viewDidDisappear(animated) - rum.stopView(viewController: self) -} -``` - -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -@import DatadogObjc; -// in your `UIViewController`: - -DDRUMMonitor *rum = [DDRUMMonitor shared]; - -- (void)viewDidAppear:(BOOL)animated { - [super viewDidAppear:animated]; - - [rum startViewWithViewController:self name:nil attributes:nil]; -} - -- (void)viewDidDisappear:(BOOL)animated { - [super viewDidDisappear:animated]; - - [rum stopViewWithViewController:self attributes:nil]; -} -``` -{{% /tab %}} -{{< /tabs >}} - -Para más detalles y opciones disponibles, consulta [`RUMMonitorProtocol` en GitHub][4]. - -### Acciones personalizadas - -Además de [rastrear acciones automáticamente](#automatically-track-user-actions), puedes rastrear acciones específicas del usuario (toques, clics y desplazamientos) con la API `addAction(type:name:)`. - -Para registrar manualmente acciones de RUM instantáneas como `.tap` en `RUMMonitor.shared()`, utiliza `.addAction(type:name:)`. Para acciones de RUM continuas como `.scroll`, utiliza `.startAction(type:name:)` o `.stopAction(type:)`. - -Por ejemplo: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogRUM - -// in your `UIViewController`: - -let rum = RUMMonitor.shared() - -@IBAction func didTapDownloadResourceButton(_ sender: UIButton) { - rum.addAction( - type: .tap, - name: sender.currentTitle ?? "" - ) -} -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -- (IBAction)didTapDownloadResourceButton:(UIButton *)sender { - NSString *name = sender.currentTitle ? sender.currentTitle : @""; - [[DDRUMMonitor shared] addActionWithType:DDRUMActionTypeTap name:name attributes:@{}]; -} -``` -{{% /tab %}} -{{< /tabs >}} - -**Nota**: Cuando se utiliza `.startAction(type:name:)` y `.stopAction(type:)`, la acción `type` debe ser la misma. Esto es necesario para que el SDK de RUM iOS haga coincidir el inicio de una acción con su finalización. - -Para más detalles y opciones disponibles, consulta [`RUMMonitorProtocol` en GitHub][4]. - -### Recursos personalizados - -Además de [rastrear recursos automáticamente](#automatically-track-red-requests), también puedes rastrear recursos personalizados específicos, como solicitudes de red o API de proveedores de terceros. Utiliza los siguientes métodos en `RUMMonitor.shared()` para recopilar manualmente recursos de RUM: - -- `.startResource(resourceKey:request:)` -- `.stopResource(resourceKey:response:)` -- `.stopResourceWithError(resourceKey:error:)` -- `.stopResourceWithError(resourceKey:message:)` - -Por ejemplo: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogRUM - -// in your network client: - -let rum = RUMMonitor.shared() - -rum.startResource( - resourceKey: "resource-key", - request: request -) - -rum.stopResource( - resourceKey: "resource-key", - response: response -) -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -// in your network client: - -[[DDRUMMonitor shared] startResourceWithResourceKey:@"resource-key" - request:request - attributes:@{}]; - -[[DDRUMMonitor shared] stopResourceWithResourceKey:@"resource-key" - response:response - attributes:@{}]; -``` -{{% /tab %}} -{{< /tabs >}} - -**Nota**: La `String` utilizada para `resourceKey` en ambas llamadas debe ser única para el recurso que estás llamando. Esto es necesario para que el SDK de RUM iOS haga coincidir el inicio de un recurso con su finalización. - -Para más detalles y opciones disponibles, consulta [`RUMMonitorProtocol` en GitHub][4]. - -### Errores personalizados - -Para realizar un rastreo de errores específicos, notifica `RUMMonitor.shared()` cuando se produzca un error utilizando uno de los siguientes métodos: - -- `.addError(message:)` -- `.addError(error:)` - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -let rum = RUMMonitor.shared() -rum.addError(message: "error message.") -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -[[DDRUMMonitor shared] addErrorWithMessage:@"error message." stack:nil source:DDRUMErrorSourceCustom attributes:@{}]; -``` -{{% /tab %}} -{{< /tabs >}} - -Para más detalles y opciones disponibles, consulta [`RUMMonitorProtocol` en GitHub][4] y la [documentación de Atributos de error][5]. - -## Rastrear atributos globales personalizados - -Además de los [atributos RUM predeterminados][6] capturados por el SDK de RUM iOS automáticamente, puedes optar por añadir información contextual adicional (como atributos personalizados) a tus eventos de RUM para mejorar tu observabilidad dentro de Datadog. - -Los atributos personalizados te permiten filtrar y agrupar información sobre el comportamiento observado del usuario (como el valor del carrito, el nivel de comerciante o la campaña publicitaria) con información a nivel de código (como los servicios de backend, la cronología de la sesión, los logs de error y el estado de la red). - -
Los atributos personalizados están pensados para pequeños fragmentos de información específicos (por ejemplo, ID, marcadores o etiquetas (labels) cortas). Evita adjuntar objetos grandes, como cargas útiles de respuesta HTTP completas. Esto puede aumentar significativamente el tamaño de los eventos y afectar al rendimiento.
- -### Establecer un atributo global personalizado - -Para establecer un atributo global personalizado, utiliza `RUMMonitor.shared().addAttribute(forKey:value:)`. - -* Para añadir un atributo, utiliza `RUMMonitor.shared().addAttribute(forKey: "", value: "")`. -* Para actualizar el valor, utiliza `RUMMonitor.shared().addAttribute(forKey: "", value: "")`. -* Para extraer la clave, utiliza `RUMMonitor.shared().removeAttribute(forKey: "")`. - -Para un mejor rendimiento en operaciones en bloque (modificar varios atributos a la vez), utiliza `.addAttributes(_:)` y `.removeAttributes(forKeys:)`. - -**Nota**: No se pueden crear facetas sobre atributos personalizados si se utilizan espacios o caracteres especiales en los nombres de las claves. Por ejemplo, utiliza `forKey: "store_id"` en lugar de `forKey: "Store ID"`. - -### Rastreo de las sesiones de usuario - -Al añadir información de usuario a tus sesiones de RUM, simplificas lo siguiente: - -* Seguir el recorrido de un usuario concreto -* Conocer qué usuarios se han visto más afectados por los errores -* Monitorizar el rendimiento de tus usuarios más importantes - -{{< img src="real_user_monitoring/browser/advanced_configuration/user-api.png" alt="API de usuario en la interfaz de usuario de RUM" >}} - -| Atributo | Tipo | Descripción | -| ----------- | ------ | ------------------------------------------------------------------------------- | -| `usr.id` | Cadena | (Obligatorio) Identificador único de usuario. | -| `usr.name` | Cadena | (Opcional) Nombre de usuario sencillo, mostrado por defecto en la interfaz de usuario RUM. | -| `usr.email` | Cadena | (Opcional) Correo electrónico del usuario, mostrado en la interfaz de usuario RUM, si el nombre de usuario no está presente. | - -Para identificar las sesiones de usuario, utiliza la API `Datadog.setUserInfo(id:name:email:)`. - -Por ejemplo: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogCore - -Datadog.setUserInfo(id: "1234", name: "John Doe", email: "john@doe.com") -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -[DDDatadog setUserInfoWithId:@"1234" name:@"John Doe" email:@"john@doe.com" extraInfo:@{}]; -``` -{{% /tab %}} -{{< /tabs >}} - -## Rastrear eventos en segundo plano - -

El rastreo de eventos en segundo plano puede dar lugar a sesiones adicionales, lo que puede afectar a la facturación. Si tienes dudas, contacta con el equipo de soporte de Datadog.

-
- -Puedes realizar un rastreo de eventos, como fallos y solicitudes de red, cuando tu aplicación está en segundo plano (por ejemplo, no hay ninguna vista activa). - -Para realizar un rastreo de eventos en segundo plano, añade el siguiente fragmento durante la inicialización en tu configuración de Datadog: - -```swift -import DatadogRUM - -RUM.enable( - with: RUM.Configuration( - ... - trackBackgroundEvents: true - ) -) -``` - -## Parámetros de inicialización - -Puedes utilizar las siguientes propiedades en `Datadog.Configuration` al crear la configuración de Datadog para inicializar el biblioteca: - -`backgroundTasksEnabled` -: este indicador determina si los métodos de `UIApplication` `beginBackgroundTask(expirationHandler:)` y `endBackgroundTask:` se utilizan para realizar cargas en segundo plano. Activar esta opción puede aumentar en 30 segundos el tiempo que la aplicación funciona en segundo plano. Normalmente, las tareas se detienen cuando no hay nada que subir o cuando se encuentra un bloqueo a la subida, como no tener conexión a Internet o tener poca batería. Por defecto, este indicador está configurado en `false`. - -`batchSize` -: establece el tamaño preferido de los datos por lotes cargados en Datadog. Este valor influye en el tamaño y el número de solicitudes realizadas por el SDK de RUM iOS (lotes pequeños significan más solicitudes, pero cada solicitud se hace más pequeña en tamaño). Los valores disponibles son: `.small`, `.medium` y `.large`. - -`bundle` -: el objeto bundle que contiene el ejecutable actual. - -`clientToken` -: el token de cliente de RUM (que admite RUM, rastreo y APM) o el token de cliente normal (que admite registro y APM). - -`encryption` -: cifrado de datos a utilizar para la persistencia de datos en disco proporcionando un objeto que cumpla con el protocolo `DataEncryption`. - -`env` -: el nombre de entorno que se envía a Datadog. Esto puede utilizarse para filtrar eventos por diferentes entornos (como `staging` o `production`). - -`proxyConfiguration` -: un atributo de configuración de proxy que puede utilizarse para habilitar un proxy personalizado para cargar los datos rastreados en la admisión de Datadog. - -`serverDateProvider` -: una interfaz de sincronización NTP personalizada. Por defecto, el SDK de Datadog sincroniza con grupos de NTP dedicados proporcionados por el [Proyecto de grupos de NTP][7]. El uso de diferentes grupos o la configuración de una implementación de no operación `ServerDateProvider` resulta en una desincronización de la instancia del SDK y los servidores de Datadog. Esto puede llevar a cambios de tiempo significativos en las sesiones de RUM o trazas distribuidas. - -`service` -: el nombre de servicio asociado a los datos enviados a Datadog. El valor por defecto es el identificador del paquete de aplicaciones. - -`site` -: el endpoint del servidor de Datadog al que se envían los datos. El valor por defecto es `.us1`. - -`uploadFrequency` -: la frecuencia preferida de carga de datos en Datadog. Los valores disponibles son: `.frequent`, `.average` y `.rare`. - -### Configuración de RUM - -Puedes utilizar las siguientes propiedades en `RUM.Configuration` al activar RUM: - -`actionEventMapper` -: establece la devolución de llamadas de limpieza de acciones. Puede utilizarse para modificar o soltar los eventos antes de que se envíen a Datadog. Para más información, consulta [Modificar o soltar eventos de RUM](#modify-or-drop-rum-events). - -`appHangThreshold` -: establece el umbral para informar cuando una aplicación se cuelga. El valor mínimo permitido para esta opción es `0.1` segundos. Para desactivar los informes, establece este valor en `nil`. Para obtener más información, consulta [Añadir informes de aplicaciones colgadas][8]. - -`applicationID` -: el identificador de la aplicación RUM. - -`customEndpoint` -: una URL de servidor personalizada para enviar datos de RUM. - -`errorEventMapper` -: la devolución de llamadas de limpieza de errores. Puede utilizarse para modificar o soltar los eventos de error antes de que se envíen a Datadog. Para más información, consulta [Modificar o soltar eventos de RUM](#modify-or-drop-rum-events). - -`longTaskEventMapper` -: la devolución de llamadas de limpieza de tareas largas. Puede utilizarse para modificar o soltar tareas largas antes de que se envíen a Datadog. Para más información, consulta [Modificar o soltar eventos de RUM](#modify-or-drop-rum-events). - -`longTaskThreshold` -: el umbral para el rastreo de tareas largas en RUM (en segundos). Por defecto, se envía a `0.1` segundos. - -`networkSettledResourcePredicate` -: la predicción utilizada para clasificar los recursos "iniciales" para el cálculo de tiempo de la vista Time-to-Network-Settled (TNS). - -`nextViewActionPredicate` -: la predicción utilizada para clasificar la "última" acción para el cálculo del tiempo de Interaction-to-Next-View (INV). - -`onSessionStart` -: (opcional) el método que se llama cuando RUM inicia la sesión. - -`resourceEventMapper` -: la devolución de llamadas de limpieza de recursos. Puede utilizarse para modificar o soltar los eventos de recursos antes de que se envíen a Datadog. Para más información, consulta [Modificar o soltar eventos de RUM](#modify-or-drop-rum-events). - -`sessionSampleRate` -: la frecuencia de muestreo para las sesiones de RUM. El valor `sessionSampleRate` debe estar entre `0.0` y `100.0`. Un valor de `0.0` significa que no se envía ninguna sesión, mientras que `100.0` significa que todas las sesiones se envían a Datadog. El valor por defecto es `100.0`. - -`telemetrySampleRate` -: la frecuencia de muestreo para la telemetría interna del SDK utilizada por Datadog. Esta frecuencia controla el número de solicitudes reportadas al sistema de rastreo. Debe ser un valor comprendido entre `0` y `100`. Por defecto, se establece en `20`. - -`trackAnonymousUser` -: Cuando se habilita, el SDK genera un ID de usuario anónimo, único y no personal que se conserva durante el lanzamiento de la aplicación. Este ID se adjuntará a cada sesión RUM, lo que te permitirá vincular sesiones originadas por el mismo usuario/dispositivo sin recopilar datos personales. Por defecto, se configura como `true`. - -`trackFrustrations` -: determina si se activa el rastreo automático de las frustraciones de los usuarios. Por defecto, se establece en `true`. - -`trackBackgroundEvents` -: determina si se realiza un rastreo de eventos de RUM cuando no hay ninguna vista activa. Por defecto, se establece en `false`. - -`trackWatchdogTerminations` -: determina si el SDK debe realizar un rastreo de las terminaciones de aplicaciones realizadas por Watchdog. La configuración predeterminada es `false`. - -`uiKitActionsPredicate` -: permite realizar un rastreo de las interacciones del usuario (toques) como acciones de RUM. Puedes usar la implementación por defecto de `predicate` configurando `DefaultUIKitRUMActionsPredicate` o puedes implementar [tu propio `UIKitRUMActionsPredicate`](#automatically-track-user-actions) personalizado para tu aplicación. - -`uiKitViewsPredicate` -: activa el rastreo de `UIViewControllers` como vistas de RUM. Puedes utilizar la implementación predeterminada de `predicate` configurando `DefaultUIKitRUMViewsPredicate` o puedes implementar [tu propio `UIKitRUMViewsPredicate`](#automatically-track-views) personalizado para tu aplicación. - -`urlSessionTracking` -: habilita el rastreo de tareas `URLSession` (solicitudes de red) como recursos de RUM. El parámetro `firstPartyHostsTracing` define hosts que se categorizan como recursos `first-party` (si RUM está habilitado) y tienen información de rastreo inyectada (si la función de rastreo está habilitada). El parámetro `resourceAttributesProvider` define un cierre para proporcionar atributos personalizados para los recursos interceptados que se llama para cada recurso recopilado por el SDK de RUM iOS. Este cierre se llama con información de la tarea y puede devolver atributos de recursos personalizados o `nil` si no se deben adjuntar atributos. - -`viewEventMapper` -: la devolución de llamadas de depuración de datos para las vistas. Puede utilizarse para modificar las vistas de eventos antes de que se envíen a Datadog. Para más información, consulta [Modificar o soltar eventos de RUM](#modify-or-drop-rum-events). - -`vitalsUpdateFrequency` -: establece la frecuencia preferida de recopilación de signos vitales móviles. Los valores disponibles son: `.frequent` (cada 100ms), `.average` (cada 500ms), `.rare` (cada 1s) y `.never` (que desactiva la monitorización de signos vitales). - -### Rastrear vistas automáticamente - -Para realizar un rastreo automático de las vistas (`UIViewControllers`), utiliza la opción `uiKitViewsPredicate` al activar RUM. Por defecto, las vistas se nombran con el nombre de la clase del controlador de vistas. Para personalizarlo, proporciona tu propia implementación de `predicate` que se ajuste al protocolo `UIKitRUMViewsPredicate`: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -public protocol UIKitRUMViewsPredicate { - func rumView(for viewController: UIViewController) -> RUMView? -} -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```swift -@objc -public protocol DDUIKitRUMViewsPredicate: AnyObject { - func rumView(for viewController: UIViewController) -> DDRUMView? -} -``` -{{% /tab %}} -{{< /tabs >}} - -Dentro de la implementación de `rumView(for:)`, tu aplicación debe decidir si una instancia dada de `UIViewController` debe iniciar la vista de RUM (valor de retorno) o no (retorno `nil`). El valor `RUMView` devuelto debe especificar el `name` y puede proporcionar `attributes` adicionales para la vista de RUM creada. - -Por ejemplo, puedes configurar el predicado para utilizar un check de tipo explícito para cada controlador de vista en tu aplicación: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -class YourCustomPredicate: UIKitRUMViewsPredicate { - - func rumView(for viewController: UIViewController) -> RUMView? { - switch viewController { - case is HomeViewController: return .init(name: "Home") - case is DetailsViewController: return .init(name: "Details") - default: return nil - } - } -} -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -@interface YourCustomPredicate : NSObject - -@end - -@implementation YourCustomPredicate - -- (DDRUMView * _Nullable)rumViewFor:(UIViewController * _Nonnull)viewController { - if ([viewController isKindOfClass:[HomeViewController class]]) { - return [[DDRUMView alloc] initWithName:@"Home" attributes:@{}]; - } - - if ([viewController isKindOfClass:[DetailsViewController class]]) { - return [[DDRUMView alloc] initWithName:@"Details" attributes:@{}]; - } - - return nil; -} - -@end -``` -{{% /tab %}} -{{< /tabs >}} - -Incluso puedes idear una solución más dinámica en función de la arquitectura de tu aplicación. - -Por ejemplo, si tus controladores de vista utilizan `accessibilityLabel` de forma coherente, puedes nombrar las vistas por el valor de la etiqueta de accesibilidad: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -class YourCustomPredicate: UIKitRUMViewsPredicate { - - func rumView(for viewController: UIViewController) -> RUMView? { - guard let accessibilityLabel = viewController.accessibilityLabel else { - return nil - } - - return RUMView(name: accessibilityLabel) - } -} -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -@interface YourCustomPredicate : NSObject - -@end - -@implementation YourCustomPredicate - -- (DDRUMView * _Nullable)rumViewFor:(UIViewController * _Nonnull)viewController { - if (viewController.accessibilityLabel) { - return [[DDRUMView alloc] initWithName:viewController.accessibilityLabel attributes:@{}]; - } - - return nil; -} - -@end -``` -{{% /tab %}} -{{< /tabs >}} - -**Nota**: El SDK de RUM iOS llama a `rumView(for:)` muchas veces mientras tu aplicación se está ejecutando. Es recomendado para mantener tu implementación rápida y de un solo subproceso. - -### Rastreo automático de las acciones de los usuarios - -Para realizar un rastreo automático de las acciones de toque del usuario, configura la opción `uiKitActionsPredicate` al activar RUM. - -### Rastrear solicitudes de red automáticamente - -Para realizar un rastreo automático de los recursos (solicitudes de red) y obtener información sobre su temporización, como el tiempo transcurrido hasta el primer byte o la resolución DNS, utiliza la opción `urlSessionTracking` al activar RUM y activa `URLSessionInstrumentation`: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -URLSessionInstrumentation.enable( - with: .init( - delegateClass: .self - ) -) - -let session = URLSession( - configuration: .default, - delegate: (), - delegateQueue: nil -) -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -DDURLSessionInstrumentationConfiguration *config = [[DDURLSessionInstrumentationConfiguration alloc] initWithDelegateClass:[ class]]; -[DDURLSessionInstrumentation enableWithConfiguration:config]; - -NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] - delegate:[[ alloc] init] - delegateQueue:nil]; -``` -{{% /tab %}} -{{< /tabs >}} - -Si tienes más de un tipo de delegado en tu aplicación que deseas instrumentar, puedes llamar a `URLSessionInstrumentation.enable(with:)` para cada tipo de delegado. - -Además, puedes configurar hosts primarios con `urlSessionTracking`. Esto clasifica los recursos que coinciden con el dominio dado como "primario" (first party) en RUM y propaga la información de rastreo a tu backend (si has activado el rastreo). Las trazas (traces) de red se muestrean con una frecuencia de muestreo ajustable. Por defecto, se aplica un muestreo del 20%. - -Por ejemplo, puedes configurar `example.com` como host primario y activar las funciones RUM y el rastreo: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift - -import DatadogRUM - -RUM.enable( - with: RUM.Configuration( - applicationID: "", - uiKitViewsPredicate: DefaultUIKitRUMViewsPredicate(), - uiKitActionsPredicate: DefaultUIKitRUMActionsPredicate(), - urlSessionTracking: RUM.Configuration.URLSessionTracking( - firstPartyHostsTracing: .trace(hosts: ["example.com"], sampleRate: 20) - ) - ) -) - -URLSessionInstrumentation.enable( - with: .init( - delegateClass: .self - ) -) - -let session = URLSession( - configuration: .default, - delegate: (), - delegateQueue: nil -) -``` - -Esto rastrea todas las solicitudes enviadas con la `session` instrumentada. Las solicitudes que coinciden con el dominio `example.com` se marcan como "primarias" (first party) y la información de rastreo se envía a tu backend para [conectar el recurso de RUM con su traza][1]. - - -[1]: https://docs.datadoghq.com/es/real_user_monitoring/correlate_with_other_telemetry/apm?tab=browserrum -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -@import DatadogObjc; - -DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; -DDRUMURLSessionTracking *urlSessionTracking = [DDRUMURLSessionTracking new]; -[urlSessionTracking setFirstPartyHostsTracing:[DDRUMFirstPartyHostsTracing alloc] initWithHosts:@[@"example.com"] sampleRate:20]; -[configuration setURLSessionTracking:urlSessionTracking]; - -[DDRUM enableWith:configuration]; -``` -{{% /tab %}} -{{< /tabs >}} - -Para añadir atributos personalizados a los recursos, utiliza la opción `URLSessionTracking.resourceAttributesProvider` al activar el RUM. Al establecer el cierre del proveedor de atributos, puedes devolver atributos adicionales que se adjuntarán al recurso rastreado. - -Por ejemplo, puede que desees añadir encabezados de solicitud y respuesta HTTP al recurso de RUM: - -```swift -RUM.enable( - with: RUM.Configuration( - ... - urlSessionTracking: RUM.Configuration.URLSessionTracking( - resourceAttributesProvider: { request, response, data, error in - return [ - "request.headers" : redactedHeaders(from: request), - "response.headers" : redactedHeaders(from: response) - ] - } - ) - ) -) -``` - -Si no deseas realizar un rastreo de las solicitudes, puedes desactivar URLSessionInstrumentation para el tipo de delegado: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -URLSessionInstrumentation.disable(delegateClass: .self) -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -[DDURLSessionInstrumentation disableWithDelegateClass:[ class]]; -``` -{{% /tab %}} -{{< /tabs >}} - -### Rastreo automático de errores - -Todos los "errores" y logs "críticos" enviados con `Logger` se notifican automáticamente como errores de RUM y se vinculan a la vista de RUM actual: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogLogs - -let logger = Logger.create() - -logger.error("message") -logger.critical("message") -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -@import DatadogObjc; - -DDLogger *logger = [DDLogger create]; -[logger error:@"message"]; -[logger critical:@"message"]; -``` -{{% /tab %}} -{{< /tabs >}} - -Del mismo modo, todos los tramos terminados marcados como error se notifican como errores de RUM: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -import DatadogTrace - -let span = Tracer.shared().startSpan(operationName: "operation") -// ... capture the `error` -span.setError(error) -span.finish() -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -// ... capture the `error` -id span = [[DDTracer shared] startSpan:@"operation"]; -[span setError:error]; -[span finish]; -``` -{{% /tab %}} -{{< /tabs >}} - -## Modificar o descartar eventos de RUM - -Para modificar los atributos de un evento de RUM antes de que se envíe a Datadog o para eliminar por completo un evento, utiliza la API de asignadores de eventos al configurar el SDK de RUM iOS: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -let configuration = RUM.Configuration( - applicationID: "", - viewEventMapper: { RUMViewEvent in - return RUMViewEvent - } - resourceEventMapper: { RUMResourceEvent in - return RUMResourceEvent - } - actionEventMapper: { RUMActionEvent in - return RUMActionEvent - } - errorEventMapper: { RUMErrorEvent in - return RUMErrorEvent - } - longTaskEventMapper: { RUMLongTaskEvent in - return RUMLongTaskEvent - } -) -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; - -[configuration setViewEventMapper:^DDRUMViewEvent * _Nonnull(DDRUMViewEvent * _Nonnull RUMViewEvent) { - return RUMViewEvent; -}]; - -[configuration setErrorEventMapper:^DDRUMErrorEvent * _Nullable(DDRUMErrorEvent * _Nonnull RUMErrorEvent) { - return RUMErrorEvent; -}]; - -[configuration setResourceEventMapper:^DDRUMResourceEvent * _Nullable(DDRUMResourceEvent * _Nonnull RUMResourceEvent) { - return RUMResourceEvent; -}]; - -[configuration setActionEventMapper:^DDRUMActionEvent * _Nullable(DDRUMActionEvent * _Nonnull RUMActionEvent) { - return RUMActionEvent; -}]; - -[configuration setLongTaskEventMapper:^DDRUMLongTaskEvent * _Nullable(DDRUMLongTaskEvent * _Nonnull RUMLongTaskEvent) { - return RUMLongTaskEvent; -}]; -``` -{{% /tab %}} -{{< /tabs >}} - -Cada asignador es un cierre Swift con una firma de `(T) -> T?`, donde `T` es un tipo concreto de evento de RUM. Esto permite cambiar partes de evento antes de que se envíe. - -Por ejemplo, para redactar información confidencial en una `url` de recurso de RUM, implementa una función `redacted(_:) -> String` personalizada y utilízala en `resourceEventMapper`: - -{{< tabs >}} -{{% tab "Swift" %}} -```swift -let configuration = RUM.Configuration( - applicationID: "", - resourceEventMapper: { RUMResourceEvent in - var RUMResourceEvent = RUMResourceEvent - RUMResourceEvent.resource.url = redacted(RUMResourceEvent.resource.url) - return RUMResourceEvent - } -) -``` -{{% /tab %}} -{{% tab "Objective-C" %}} -```objective-c -DDRUMConfiguration *configuration = [[DDRUMConfiguration alloc] initWithApplicationID:@""]; - -[configuration setResourceEventMapper:^DDRUMResourceEvent * _Nullable(DDRUMResourceEvent * _Nonnull RUMResourceEvent) { - return RUMResourceEvent; -}]; -``` -{{% /tab %}} -{{< /tabs >}} - -Si se devuelve `nil` desde el asignador de errores, recursos o acciones, se elimina el evento por completo; el evento no se envía a Datadog. El valor devuelto desde el asignador de eventos de vistas no debe ser `nil` (para eliminar vistas, personaliza tu implementación de `UIKitRUMViewsPredicate`; lee más en [rastreo automático de vistas](#automatically-track-views)). - -En función del tipo de evento, solo pueden modificarse algunas propiedades específicas: - -| Tipo de evento | Clave de atributo | Descripción | -| ---------------- | ------------------------------------ | ------------------------------------------------ | -| RUMActionEvent | `RUMActionEvent.action.target?.name` | Nombre de la acción. | -| | `RUMActionEvent.view.url` | URL de la vista vinculada a esta acción. | -| RUMErrorEvent | `RUMErrorEvent.error.message` | Mensaje de error. | -| | `RUMErrorEvent.error.stack` | Stack trace del error. | -| | `RUMErrorEvent.error.resource?.url` | URL del recurso al que se refiere el error. | -| | `RUMErrorEvent.view.url` | URL de la vista vinculada a este error. | -| RUMResourceEvent | `RUMResourceEvent.resource.url` | URL del recurso. | -| | `RUMResourceEvent.view.url` | URL de la vista vinculada a este recurso. | -| RUMViewEvento | `RUMViewEvent.view.name` | Nombre de la vista. | -| | `RUMViewEvent.view.url` | URL de la vista. | -| | `RUMViewEvent.view.referrer` | URL vinculada con la vista inicial de la página. | - -## Recuperar el ID de sesión de RUM - -Recuperar el ID de sesión de RUM puede ser útil para solucionar problemas. Por ejemplo, puedes adjuntar el ID de sesión a solicitudes de soporte, correos electrónicos o informes de errores para que tu equipo de soporte pueda encontrar posteriormente la sesión de usuario en Datadog. - -Puedes acceder al identificador de sesión RUM en tiempo de ejecución sin esperar al evento `sessionStarted`: - -```swift -RumMonitor.shared().currentSessionID(completion: { sessionId in - currentSessionId = sessionId -}) -``` - -## Configurar el consentimiento de rastreo (cumplimiento de GDPR) - -Para cumplir con la normativa GDPR, el SDK requiere el valor de consentimiento de rastreo durante la inicialización. - -El ajuste `trackingConsent` puede ser uno de los siguientes valores: - -1. `.pending`: el SDK de RUM iOS comienza a recopilar y procesar los datos, pero no los envía a Datadog. El SDK de RUM iOS espera el nuevo valor de consentimiento del rastreo para decidir qué hacer con los datos procesados. -2. `.granted`: el SDK de RUM iOS comienza a recopilar los datos y los envía a Datadog. -3. `.notGranted`: el SDK de RUM iOS no recopila ningún dato. Ni logs, ni trazas, ni eventos de RUM se envían a Datadog. - -Para cambiar el valor de consentimiento de rastreo después de inicializar el SDK de RUM iOS, utiliza la llamada a la API `Datadog.set(trackingConsent:)`. El SDK de RUM iOS cambia su comportamiento de acuerdo con el nuevo valor. - -Por ejemplo, si el consentimiento de rastreo actual es `.pending`: - -- Si cambia el valor a `.granted`, el SDK de RUM iOS envía todos los datos actuales y futuros a Datadog; -- Si cambias el valor a `.notGranted`, el SDK de RUM iOS borra todos los datos actuales y no recopila datos futuros. - -## Añadir propiedades de usuario - -Puedes utilizar la API `Datadog.addUserExtraInfo(_:)` para añadir propiedades de usuario adicionales a las establecidas previamente. - -```swift -import DatadogCore - -Datadog.addUserExtraInfo(["company": "Foo"]) -``` - -## Gestión de datos - -El SDK de iOS almacena primero eventos localmente y sólo carga eventos cuando se cumplen las condiciones [especificaciones de admisión][9]. - -### Borrar todos los datos - -Tienes la opción de borrar todos los datos no enviados almacenados por el SDK con la API `Datadog.clearAllData()`. - -```swift -import DatadogCore - -Datadog.clearAllData() -``` - -### Detener la recopilación de datos - -Puedes utilizar la API `Datadog.stopInstance()` para impedir que una instancia del SDK con nombre (o la instancia predeterminada si el nombre es `nil`) siga recopilando y cargando datos. - -```swift -import DatadogCore - -Datadog.stopInstance() -``` - -Al llamar a este método se desactiva el SDK y todas las características activas, como RUM. Para reanudar la recopilación de datos, debes reinicializar el SDK. Puedes utilizar esta API si deseas cambiar dinámicamente las configuraciones - -## Referencias adicionales - -{{< partial name="whats-next/whats-next.html" >}} - -[1]: https://app.datadoghq.com/rum/application/create -[2]: /es/real_user_monitoring/mobile_and_tv_monitoring/ios -[3]: /es/real_user_monitoring/mobile_and_tv_monitoring/ios/data_collected/ -[4]: https://github.com/DataDog/dd-sdk-ios/blob/master/DatadogRUM/Sources/RUMMonitorProtocol.swift -[5]: /es/real_user_monitoring/mobile_and_tv_monitoring/ios/data_collected/?tab=error#error-attributes -[6]: /es/real_user_monitoring/mobile_and_tv_monitoring/ios/data_collected/?tab=session#default-attributes -[7]: https://www.ntppool.org/en/ -[8]: /es/real_user_monitoring/error_tracking/mobile/ios/#add-app-hang-reporting -[9]: /es/real_user_monitoring/mobile_and_tv_monitoring/ios/setup \ No newline at end of file