Snowpark Container Services: 모니터링 서비스¶
컨테이너 로그에 액세스하기¶
Snowflake는 애플리케이션 컨테이너가 출력하는 모든 내용을 표준 출력 및 표준 오류로 수집합니다. 코드가 서비스를 디버깅하는 데 유용한 정보를 출력하도록 해야 합니다.
Snowflake는 이러한 서비스(작업 서비스 포함) 컨테이너 로그에 액세스하는 다음의 두 가지 방법을 제공합니다.
SYSTEM$GET_SERVICE_LOGS 시스템 함수 사용: 특정 컨테이너의 로그에 대한 액세스 권한을 부여합니다. 컨테이너가 종료된 후에도 잠시 동안 시스템 함수를 사용하여 로그에 계속 액세스할 수 있습니다. 시스템 함수는 서비스나 작업을 처음 작성할 때 개발 및 테스트 중에 가장 유용합니다. 자세한 내용은 SYSTEM$GET_SERVICE_LOGS 섹션을 참조하십시오.
이벤트 테이블 사용하기: 계정의 이벤트 테이블을 사용하면 해당 사양에서 로그 수집을 활성화 하는 서비스에 대한 여러 컨테이너의 로그에 액세스할 수 있습니다. Snowflake는 나중에 액세스할 수 있도록 이벤트 테이블에 로그를 유지합니다. 이벤트 테이블은 서비스와 작업의 회고적 분석에 가장 적합합니다. 자세한 내용은 이벤트 테이블 사용하기 섹션을 참조하십시오.
SYSTEM$GET_SERVICE_LOGS 사용하기¶
서비스 이름, 인스턴스 ID, 컨테이너 이름, 선택적으로 검색할 가장 최근 로그 줄 수를 제공합니다. 하나의 서비스 인스턴스만 실행 중인 경우 서비스 인스턴스 ID는 0입니다. 예를 들어, 다음 문 명령은 echo_service
서비스의 인스턴스 0에 속한 echo
컨테이너의 로그에서 후행 10줄을 검색합니다.
SELECT SYSTEM$GET_SERVICE_LOGS('echo_service', '0', 'echo', 10);
출력 예:
+--------------------------------------------------------------------------+
| SYSTEM$GET_SERVICE_LOGS |
|--------------------------------------------------------------------------|
| 10.16.6.163 - - [11/Apr/2023 21:44:03] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:08] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:13] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:18] "GET /healthcheck HTTP/1.1" 200 - |
+--------------------------------------------------------------------------+
1 Row(s) produced. Time Elapsed: 0.878s
함수를 호출하는 데 필요한 서비스 정보(예: 인스턴스 ID 또는 컨테이너 이름)가 없는 경우 먼저 SHOW SERVICE CONTAINERS IN SERVICE 명령을 실행하여 각 인스턴스에서 실행 중인 서비스 인스턴스 및 컨테이너에 대한 정보를 얻을 수 있습니다.
SYSTEM$GET_SERVICE_LOGS 함수에는 다음과 같은 제한 사항이 있습니다.
표준 출력과 표준 오류 스트림을 병합합니다. 이 함수는 출력이 어느 스트림에서 왔는지 표시하지 않습니다.
단일 서비스 인스턴스의 특정 컨테이너에 대해 캡처된 데이터를 보고합니다.
실행 중인 컨테이너에 대한 로그만 보고합니다. 이 함수는 다시 시작된 이전 컨테이너 또는 중지되거나 삭제된 서비스의 컨테이너에서 로그를 가져올 수 없습니다.
이 함수는 최대 100KB의 데이터를 반환합니다.
이벤트 테이블 사용하기¶
Snowflake는 컨테이너에서 표준 출력 및 표준 오류 스트림으로 전송된 로그를 사용자 계정에 구성된 이벤트 테이블에 캡처할 수 있습니다. 이벤트 테이블 구성에 대한 자세한 내용은 로깅, 추적 및 메트릭 섹션을 참조하십시오.
서비스 사양 파일의 spec.logExporters 필드 를 사용하여 이벤트 테이블에 저장할 스트림(모두, 표준 오류만 또는 없음)을 제어할 수 있습니다.
그런 다음 이벤트 테이블에서 이벤트를 쿼리할 수 있습니다. 계정의 활성 이벤트 테이블을 찾으려면 SHOW PARAMETERS 명령을 사용하여 EVENT_TABLE 매개 변수의 값을 확인합니다.
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
이 매개 변수는 계정의 활성 이벤트 테이블을 지정합니다.
그런 다음 해당 이벤트 테이블을 쿼리합니다. 다음 SELECT 문은 지난 한 시간 동안 기록된 Snowflake 서비스 및 작업 이벤트를 검색합니다.
SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current-event-table-for-your-account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
AND RESOURCE_ATTRIBUTES:"snow.service.name" = <service-name>
AND RECORD_TYPE = 'LOG'
ORDER BY timestamp DESC
LIMIT 10;
이 예에 표시된 것처럼 이벤트 테이블 쿼리의 WHERE 절에 타임스탬프를 포함하는 것이 좋습니다. 다양한 Snowflake 구성 요소에서 생성될 수 있는 데이터의 양 때문에 이 점이 특히 중요합니다. 필터를 적용하면 더 작은 데이터 하위 세트를 검색할 수 있으므로 쿼리 성능이 향상됩니다.
이벤트 테이블에는 다음과 같은 열이 포함되어 있으며, 이 열은 컨테이너에서 Snowflake가 수집한 로그에 관한 유용한 정보를 제공합니다.
TIMESTAMP: Snowflake가 로그를 수집한 시점을 표시합니다.
RESOURCE_ATTRIBUTES: 로그 메시지를 생성한 서비스에서 Snowflake 서비스와 컨테이너를 식별하는 JSON 오브젝트를 제공합니다. 예를 들어 서비스가 실행될 때 지정된 서비스 이름, 컨테이너 이름, 컴퓨팅 풀 이름과 같은 세부 정보를 제공합니다.
{ "snow.account.name": "SPCSDOCS1", "snow.compute_pool.id": 20, "snow.compute_pool.name": "TUTORIAL_COMPUTE_POOL", "snow.compute_pool.node.id": "a17e8157", "snow.compute_pool.node.instance_family": "CPU_X64_XS", "snow.database.id": 26, "snow.database.name": "TUTORIAL_DB", "snow.schema.id": 212, "snow.schema.name": "DATA_SCHEMA", "snow.service.container.instance": "0", "snow.service.container.name": "echo", "snow.service.container.run.id": "b30566", "snow.service.id": 114, "snow.service.name": "ECHO_SERVICE2", "snow.service.type": "Service" }
RECORD_ATTRIBUTES: Snowflake 서비스의 경우 오류 출처(표준 출력 또는 표준 오류)를 식별합니다.
{ "log.iostream": "stdout" }
VALUE: 표준 출력과 표준 오류는 줄로 나뉘며, 각 줄은 이벤트 테이블에 레코드를 생성합니다.
"echo-service [2023-10-23 17:52:27,429] [DEBUG] Sending response: {'data': [[0, 'Joe said hello!']]}"
플랫폼 메트릭에 액세스하기¶
Snowflake는 계정의 컴퓨팅 풀과 해당 컴퓨팅 풀 에서 실행 중인 서비스 에 대한 메트릭을 제공합니다. Snowflake가 제공하는 이러한 메트릭은 플랫폼 메트릭라고도 합니다.
이벤트 테이블 서비스 메트릭: 개별 서비스가 메트릭을 게시합니다. 이는 서비스에 대한 구체적인 정보를 제공하는 컴퓨팅 풀 메트릭의 하위 집합입니다. 이 기능의 목표 사용 사례는 특정 서비스의 리소스 활용도를 관찰하는 것입니다. 서비스 사양에서는 서비스가 실행되는 동안 Snowflake가 이벤트 테이블에 기록할 메트릭을 정의합니다.
컴퓨팅 풀 메트릭: 또한 각 컴퓨팅 풀은 해당 컴퓨팅 풀 내부에서 일어나는 작업에 대한 정보를 제공하는 메트릭을 게시합니다. 이를 위한 목표 사용 사례는 컴퓨팅 풀 사용률을 관찰하는 것입니다. 컴퓨팅 풀 메트릭에 액세스하려면 Prometheus 호환 API를 사용하여 컴퓨팅 풀이 게시하는 메트릭을 폴링하는 서비스를 작성해야 합니다.
이벤트 테이블 서비스 메트릭에 액세스하기¶
계정에 대해 구성된 이벤트 테이블에 서비스의 메트릭을 기록하려면 서비스 사양에 다음 섹션을 포함합니다.
platformMonitor:
metricConfig:
groups:
- <group 1>
- <group 2>
- ...
여기서 각 group N
은 관심 있는 사전 정의된 메트릭 그룹 을 참조합니다(예: system
, network
또는 storage
). 자세한 내용은 서비스 사양에 대한 설명서에서 spec.platformMonitor 필드 섹션을 참조하십시오.
서비스가 실행되는 동안 Snowflake는 이러한 메트릭을 사용자 계정의 이벤트 테이블에 기록합니다. 이벤트 테이블을 쿼리하여 메트릭을 읽을 수 있습니다. 다음 쿼리는 my_service
서비스에 대해 지난 한 시간 동안 기록된 서비스 메트릭을 검색합니다.
SELECT timestamp, value
FROM my_event_table_db.my_event_table_schema.my_event_table
WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'MY_SERVICE'
AND RECORD_TYPE = 'METRIC'
ORDER BY timestamp DESC
LIMIT 10;
계정에 대한 활성 이벤트 테이블의 이름을 모르는 경우 SHOW PARAMETERS 명령을 실행하여 계정 수준 EVENT_TABLE 매개 변수의 값을 표시합니다.
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;
이벤트 테이블에 대한 자세한 내용은 이벤트 테이블 사용하기 섹션을 참조하십시오.
예
계정에 대해 구성된 이벤트 테이블에 메트릭을 기록하는 예시 서비스를 생성하려면 다음 단계를 따르십시오.
자습서 1 에 따라 한 가지를 변경하여
echo_service
라는 이름의 서비스를 생성합니다. 서비스를 생성하는 3단계에서 다음 CREATE SERVICE 명령을 사용하여 수정된 서비스 사양에platformMonitor
필드를 추가합니다.CREATE SERVICE echo_service IN COMPUTE POOL tutorial_compute_pool FROM SPECIFICATION $$ spec: containers: - name: echo image: /tutorial_db/data_schema/tutorial_repository/my_echo_service_image:latest env: SERVER_PORT: 8000 CHARACTER_NAME: Bob readinessProbe: port: 8000 path: /healthcheck endpoints: - name: echoendpoint port: 8000 public: true platformMonitor: metricConfig: groups: - system - system_limits $$ MIN_INSTANCES=1 MAX_INSTANCES=1;
서비스가 실행된 후 Snowflake는 지정된 메트릭 그룹의 메트릭을 이벤트 테이블에 기록하기 시작하며, 이를 쿼리할 수 있습니다. 다음 쿼리는 Echo 서비스에서 지난 1시간 동안 보고된 메트릭을 검색합니다.
SELECT timestamp, value FROM my_events WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP()) AND RESOURCE_ATTRIBUTES:"snow.service.name" = 'ECHO_SERVICE' AND RECORD_TYPE = 'METRIC' AND RECORD:metric.name = 'container.cpu.usage' ORDER BY timestamp DESC LIMIT 100;
컴퓨팅 풀 메트릭 액세스하기¶
컴퓨팅 풀 메트릭은 컴퓨팅 풀의 노드와 해당 노드에서 실행 중인 서비스에 대한 인사이트를 제공합니다. 각 노드는 컨테이너에 사용 가능한 메모리 양과 같은 노드별 메트릭과 개별 컨테이너의 메모리 사용량과 같은 서비스 메트릭을 보고합니다. 컴퓨팅 풀 메트릭은 노드 관점에서 정보를 제공합니다.
각 노드에는 TCP 포트 9001에서 수신 대기하는 메트릭 게시자가 있습니다. 다른 서비스는 노드에서 포트 9001로 경로 /metrics
를 사용하여 HTTP GET요청을 할 수 있습니다. 노드의 IP 주소를 찾으려면 discover.monitor.compute_pool_name.cp.spcs.internal
호스트 이름에 대한 DNS에서 SRV 레코드(또는 A 레코드)를 검색합니다. 그런 다음 계정에서 각 노드를 적극적으로 폴링하여 메트릭을 검색하는 다른 서비스를 생성합니다.
응답의 본문은 다음 예제 메트릭에서와 같이 Prometheus 형식 을 사용하여 메트릭을 제공합니다.
# HELP node_memory_capacity Defines SPCS compute pool resource capacity on the node
# TYPE node_memory_capacity gauge
node_memory_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 1
node_cpu_capacity{snow_compute_pool_name="MY_POOL",snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"} 7.21397383168e+09
다음 사항을 참고하십시오.
응답 본문은 메트릭의 간단한 설명과 유형을 제공하는
# HELP
및# TYPE
으로 시작합니다. 이 예제에서node_memory_capacity
메트릭은gauge
유형입니다.그 다음에는 메트릭 이름, 특정 리소스(데이터 요소)를 설명하는 레이블 목록과 해당 값이 표시됩니다. 이 예제에서 메트릭(
node_memory_capacity
)은 메모리 정보를 제공하며, 노드에 7.2GB의 사용 가능한 메모리가 있음을 나타냅니다. 이 메트릭에는 다음과 같이 레이블 형태의 메타데이터도 포함됩니다.snow_compute_pool_name="MY_POOL", snow_compute_pool_node_instance_family="CPU_X64_S",snow_compute_pool_node_id="10.244.3.8"
이러한 메트릭을 원하는 방식으로 처리할 수 있습니다. 예를 들어, 메트릭을 데이터베이스에 저장하고 UI(예: Grafana 대시보드)를 사용하여 정보를 표시할 수 있습니다.
참고
Snowflake는 어떠한 메트릭 집계도 제공하지 않습니다. 예를 들어, 특정 서비스에 대한 메트릭을 얻으려면 해당 서비스의 인스턴스를 실행 중인 모든 노드를 쿼리해야 합니다.
컴퓨팅 풀의 이름이 DNS와 호환되는 이름이어야 메트릭에 액세스할 수 있습니다.
컴퓨팅 풀에서 노출된 엔드포인트는 컴퓨팅 풀에 OWNERSHIP 또는 MONITOR 권한이 있는 역할을 사용하는 서비스에서 액세스할 수 있습니다.
사용 가능한 컴퓨팅 풀 메트릭 목록은 사용 가능한 플랫폼 메트릭 섹션을 참조하십시오.
예
Prometheus를 구성하여 메트릭에 대한 컴퓨팅 풀을 폴링하는 예는 컴퓨팅 풀 메트릭 자습서 섹션을 참조하십시오.
사용 가능한 플랫폼 메트릭¶
다음은 사용 가능한 플랫폼 메트릭 그룹과 각 그룹 내의 메트릭 목록입니다. 저장소
메트릭은 현재 블록 저장소 볼륨에서만 수집됩니다.
메트릭 그룹 . 메트릭 이름 |
단위 |
타입 |
설명 |
---|---|---|---|
system . container.cpu.usage |
CPU 코어 |
게이지 |
마지막 측정 이후 사용된 평균 CPU 코어 수입니다. 1.0은 1개 CPU 코어의 최대 사용률을 나타냅니다. 최대값은 컨테이너에서 사용할 수 있는 CPU 코어 수입니다. |
system . container.memory.usage |
bytes |
게이지 |
사용된 메모리(바이트)입니다. |
system . container.gpu.memory.usage |
bytes |
게이지 |
사용된 GPU당 메모리(바이트)입니다. 소스 GPU는 ‘GPU’ 특성에 표시됩니다. |
system . container.gpu.utilization |
속도 |
게이지 |
용량 대비 GPU당 사용률 비율입니다. 소스 GPU는 ‘GPU’ 특성에 표시됩니다. |
system_limits . container.cpu.limit |
CPU 코어 |
게이지 |
서비스 사양의 CPU 리소스 제한입니다. 제한이 정의되지 않으면 노드 용량이 기본값으로 사용됩니다. |
system_limits . container.gpu.limit |
gpus |
게이지 |
서비스 사양의 GPU 개수 제한. 제한을 정의하지 않으면 메트릭이 내보내지지 않습니다. |
system_limits . container.memory.limit |
bytes |
게이지 |
서비스 사양에 따른 메모리 제한입니다. 제한이 정의되지 않으면 노드 용량이 기본값으로 사용됩니다. |
system_limits . container.cpu.requested |
CPU 코어 |
게이지 |
서비스 사양의 CPU 리소스 요청입니다. 제한이 정의되지 않으면 Snowflake에서 선택한 값이 기본값으로 사용됩니다. |
system_limits . container.gpu.requested |
gpus |
게이지 |
서비스 사양의 GPU 개수입니다. 제한을 정의하지 않으면 메트릭이 내보내지지 않습니다. |
system_limits . container.memory.requested |
bytes |
게이지 |
서비스 사양의 메모리 요청입니다. 제한이 정의되지 않으면 Snowflake에서 선택한 값이 기본값으로 사용됩니다. |
system_limits . container.gpu.memory.capacity |
bytes |
게이지 |
GPU당 메모리 용량입니다. 소스 GPU는 ‘GPU’ 특성에 표시됩니다. |
status . container.restarts |
restarts |
게이지 |
Snowflake가 컨테이너를 다시 시작한 횟수입니다. |
status . container.state.finished |
boolean |
게이지 |
컨테이너가 ‘완료됨’ 상태인 경우 이 메트릭은 값 1로 내보내집니다. |
status . container.state.last.finished.reason |
boolean |
게이지 |
컨테이너가 이전에 다시 시작된 경우 이 메트릭은 값 1로 내보내집니다. ‘이유’ 레이블은 컨테이너가 마지막으로 완료된 이유를 설명합니다. |
status . container.state.last.finished.exitcode |
정수 |
게이지 |
컨테이너가 이전에 다시 시작된 경우 이 메트릭에는 이전 실행의 종료 코드가 포함됩니다. |
status . container.state.pending |
boolean |
게이지 |
컨테이너가 ‘보류 중’ 상태인 경우 이 메트릭은 값 1로 내보내집니다. |
status . container.state.pending.reason |
boolean |
게이지 |
컨테이너가 ‘보류 중’ 상태인 경우 이 메트릭은 값 1로 내보내집니다. ‘이유’ 레이블은 컨테이너가 가장 최근에 보류 중 상태였던 이유를 설명합니다. |
status . container.state.running |
boolean |
게이지 |
컨테이너가 ‘실행 중’ 상태인 경우 이 메트릭 값은 1입니다. |
status . container.state.started |
boolean |
게이지 |
컨테이너가 ‘시작됨’ 상태인 경우 이 메트릭 값은 1입니다. |
network . network.egress.denied.packets |
패킷 |
게이지 |
정책 유효성 검사 실패로 인한 네트워크 송신 총 거부 패킷 수입니다. |
network . network.egress.received.bytes |
bytes |
게이지 |
원격 대상에서 수신한 네트워크 송신 총 바이트입니다. |
network . network.egress.received.packets |
패킷 |
게이지 |
원격 대상에서 수신한 네트워크 송신 총 패킷 수입니다. |
network . network.egress.transmitted.bytes |
바이트 |
게이지 |
원격 대상으로 전송된 네트워크 송신 총 바이트 수입니다. |
network . network.egress.transmitted.packets |
패킷 |
게이지 |
원격 대상으로 전송된 네트워크 송신 총 패킷 수입니다. |
storage . volume.capacity |
bytes |
게이지 |
파일 시스템의 크기입니다. |
storage . volume.io.inflight |
작업 |
게이지 |
활성 파일시스템 I/O 작업 수입니다. |
storage . volume.read.throughput |
바이트/초 |
게이지 |
파일 시스템 읽기 처리량은 초당 바이트 단위입니다. |
storage . volume.read.iops |
작업/초 |
게이지 |
초당 파일 시스템 읽기 작업 수입니다. |
storage . volume.usage |
bytes |
게이지 |
파일 시스템에서 사용된 총 바이트 수입니다. |
storage . volume.write.throughput |
바이트/초 |
게이지 |
초당 바이트 단위의 파일 시스템 쓰기 처리량입니다. |
storage . volume.write.iops |
작업/초 |
게이지 |
초당 파일 시스템 쓰기 작업 수입니다. |
애플리케이션 메트릭 게시 및 액세스하기¶
애플리케이션 메트릭 및 추적은 Snowflake가 생성하는 플랫폼 메트릭와 달리 서비스에서 생성됩니다. 서비스 컨테이너는 OLTP 또는 Prometheus 메트릭을 생성할 수 있으며, Snowflake는 계정에 대해 구성된 이벤트 테이블에 이를 게시합니다.
서비스 컨테이너 코드가 올바른 단위, 집계 및 계측 유형으로 메트릭을 출력하여 분석에 의미 있고 효과적인 메트릭을 생성하는지 확인해야 한다는 점에 유의하십시오.
OTLP 애플리케이션 메트릭 및 추적 게시하기¶
Snowflake는 서비스 컨테이너가 OTLP 애플리케이션 메트릭 및 추적을 게시하는 데 사용할 수 있는 OTel 수집기를 실행합니다. 즉, 서비스 컨테이너는 OTel 수집기 엔드포인트로 메트릭을 푸시할 수 있으며, 그러면 Snowflake는 원본 서비스 세부 정보와 함께 Snowflake 계정에 대해 구성된 이벤트 테이블에 기록합니다.
이 코드는 다음과 같이 작동합니다.
Snowflake는 컨테이너가 애플리케이션 메트릭과 추적을 게시할 수 있는 OTel 수집기 엔드포인트를 제공하는 다음 환경 변수를 서비스 컨테이너에 자동으로 채웁니다.
OTEL_EXPORTER_OTLP_METRICS_ENDPOINT
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
표준 OTLP 클라이언트 는 이러한 환경 변수를 찾아 OTel 수집기를 자동으로 검색합니다. 이렇게 하면 서비스 컨테이너가 이 클라이언트를 사용하여 메트릭과 추적을 게시할 수 있습니다.
OTLP 애플리케이션 추적 ID 구성하기¶
추적은 Snowflake Trail 에서 볼 수 있고 성능 조회가 가능하도록 Snowflake Trace ID 형식을 사용해야 합니다.
Snowflake는 추적 ID 생성기 설정을 간소화하기 위해 Python 및 Java 라이브러리를 제공합니다. 다음은 이러한 라이브러리를 사용하여 기본 OpenTelemetry 추적 ID 생성기를 재정의하는 방법을 보여주는 예입니다.
from opentelemetry.sdk.trace import TracerProvider
from snowflake.telemetry.trace import SnowflakeTraceIdGenerator
trace_id_generator = SnowflakeTraceIdGenerator()
tracer_provider = TracerProvider(
resource=Resource.create({"service.name": SERVICE_NAME}),
id_generator=trace_id_generator
)
자세한 내용은 PyPI에서 snowflake-telemetry-python 을 확인하십시오.
import io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk;
import com.snowflake.telemetry.trace.SnowflakeTraceIdGenerator;
static OpenTelemetry initOpenTelemetry() {
return AutoConfiguredOpenTelemetrySdk.builder()
.addPropertiesSupplier(
() ->
Map.of(...config options...)
.addTracerProviderCustomizer(
(tracerProviderBuilder, configProperties) -> {
tracerProviderBuilder.setIdGenerator(SnowflakeTraceIdGenerator.INSTANCE);
return tracerProviderBuilder;
})
.build()
.getOpenTelemetrySdk();
com.snowflake.telemetry
설치에 대한 자세한 내용은 원격 분석 클래스를 사용하도록 Java 및 Scala 환경 설정하기 섹션을 참조하십시오.
추적 ID 생성기는 다른 프로그래밍 언어에서도 구현할 수 있습니다. 16바이트 ID (빅 엔디언)에는 최상위 네 번째 바이트에 타임스탬프가 포함되어야 합니다. 나머지 바이트는 임의의 비트를 포함해야 합니다. 자세한 내용은 Python 참조 구현 섹션을 참조하십시오.
Prometheus 애플리케이션 메트릭 게시하기¶
Snowflake는 OTLP 메트릭을 푸시하는 대신 애플리케이션이 Snowflake 제공 수집기에 의해 폴링되도록 Prometheus 메트릭을 노출할 수 있는 Prometheus 메트릭을 지원합니다. Snowflake가 서비스에서 이러한 애플리케이션 메트릭을 수집하여 이벤트 테이블에 게시하려면 다음 단계를 따르십시오.
서비스가 포트에서 수신 대기하도록 하여 Prometheus 메트릭을 노출합니다.
서비스 컨테이너에서 메트릭을 가져오는 데 필요한 구성이 포함된 Snowflake 제공 컨테이너(“사이드카” 컨테이너라고도 함)를 서비스에 포함합니다.
Prometheus 사이드카는 예약된 주기로 컨테이너에서 애플리케이션 메트릭을 가져와서 Prometheus 형식을 OTLP 형식으로 변환한 다음 메트릭을 OTel 수집기로 푸시합니다. 그런 다음 OTel 수집기가 해당 메트릭을 Snowflake 계정에 대해 구성된 이벤트 테이블에 게시합니다.
참고
OpenTelemetry 에서 Prometheus Summary 메트릭 유형 을 더 이상 사용하지 않으므로 Snowflake는 이 메트릭 유형을 지원하지 않습니다. 대신 히스토그램 유형을 사용합니다.
Prometheus 사이드카 컨테이너를 서비스 사양에 다른 컨테이너로 추가하고 다음 형식을 사용하여 컨테이너가 노출하는 HTTP 엔드포인트를 지정하는 인자를 포함하십시오.
localhost:{PORT}/{METRICS_PATH}, {SCRAPE_FREQUENCY}
사이드카가 메트릭을 가져올 포트 번호, 경로, 빈도를 지정합니다.
서비스 사양 예시 조각은 포트 8000에서 서비스 컨테이너에서 매분마다 메트릭을 스크랩하고 “/metrics” 경로에서 메트릭을 가져오는 사이드카 컨테이너를 보여줍니다.
spec:
containers:
- name: <name>
image: <image-name>
.....
- name: prometheus
image: /snowflake/images/snowflake_images/monitoring-prometheus-sidecar:0.0.1
args:
- "-e"
- "localhost:8000/metrics,1m"
사양에서:
image
는 Snowflake에서 제공하는 사이드카 컨테이너 이미지입니다.args
는 프로메테우스 컨테이너가 메트릭을 스크래핑하는 데 필요한 구성을 제공합니다.컨테이너에서 제공하는 포트 8000에서. 이 포트는 이 프로메테우스 컨테이너 구성에 필요합니다.
경로 “/metrics” 사용. 선택 사항입니다. 지정하지 않으면 “/metrics”가 기본 경로가 됩니다.
매분. 선택 사항입니다. 지정하지 않으면 기본값은 “1m”입니다.
기본값을 활용하는 경우, 이는 메트릭을 스크래핑할 때와 동일한 구성입니다.
spec: ... args: - "-e" - "localhost:8000"
참고
Prometheus 사이드카 컨테이너는 작업이 아닌 서비스에 대해서만 지원됩니다. 작업에 대한 애플리케이션 메트릭을 수집하려면 OTel 수집기로 메트릭을 푸시해야 합니다.
이벤트 테이블에서 애플리케이션 메트릭 및 추적에 액세스하기¶
이벤트 테이블을 쿼리하여 애플리케이션 메트릭을 검색할 수 있습니다. 다음 쿼리는 지난 한 시간 동안 수집된 애플리케이션 메트릭을 검색합니다.
SELECT timestamp, record:metric.name, value
FROM <current_event_table_for_your_account>
WHERE timestamp > dateadd(hour, -1, CURRENT_TIMESTAMP())
AND resource_attributes:"snow.service.name" = <service_name>
AND scope:"name" != 'snow.spcs.platform'
AND record_type = 'METRIC'
ORDER BY timestamp DESC
LIMIT 10;
이벤트 테이블에 대한 자세한 내용은 이벤트 테이블 개요 섹션을 참조하십시오. 이러한 메트릭은 Snowflake 대시보드 에서 시각화할 수 있습니다.
이벤트 테이블을 쿼리하여 애플리케이션 추적을 볼 수도 있습니다. 예를 들어, 지난 1시간 동안의 애플리케이션 추적을 검색하려면 앞의 쿼리에서 record_type
조건을 다음과 같이 바꾸십시오.
AND record_type = 'SPAN' OR record_type = 'SPAN_EVENT'
추적은 Snowflake trail 뷰어에서 시각화할 수 있습니다.
메트릭과 추적에는 리소스 및 레코드 특성으로 사용자 정의 특성과 Snowflake 정의 특성이 모두 포함됩니다. snow.
접두사는 Snowflake에서 생성된 특성을 위해 예약되어 있으며, 이 접두사를 사용하는 사용자 지정 특성은 무시됩니다. Snowflake 정의 특성 목록을 보려면 사용 가능한 플랫폼 메트릭 섹션을 참조하십시오.
예제 코드 는 OTLP SDK 를 사용하여 사용자 지정 메트릭 및 추적을 통해 애플리케이션을 계측하는 것을 보여주는 예제 코드가 Python과 Java로 제공됩니다. 이러한 예에서는 추적용 Snowflake trail 뷰어와의 호환성을 위해 ID 생성을 구성하는 방법을 보여줍니다.
지침 및 제한 사항¶
노드당 이벤트 테이블에 수집되는 로그의 최대 처리량은 AWS 및 Azure의 Snowflake 계정의 경우 1 MB/초입니다.
이벤트 테이블에 수집된 메트릭과 추적의 최대 결합 처리량은 Azure와 AWS 모두에서 노드당 1 MB/초입니다.
이벤트 테이블에 수집되는 로그의 최대 레코드 크기는 16 KiB 입니다.