Trino 관측성 — JMX 메트릭, Web UI, 그리고 느린 쿼리 진단

Trino 클러스터가 느려지거나 쿼리가 실패할 때, "왜?"에 답할 수 있어야 운영이 됩니다. 관측성이 없으면 사용자 민원에 끌려다니며 추측으로 대응할 수밖에 없거든요. 다행히 Trino 는 풍부한 관측 수단 — JMX 메트릭, Web UI, system 테이블, 이벤트 리스너 — 을 기본 제공합니다.

이 글은 무엇을 모니터링해야 하는지, 어떻게 수집·시각화하는지, 그리고 느린 쿼리를 만났을 때 어떤 순서로 파고들지 함께 살펴봅니다.

이 글에서 배우는 것

• Trino 관측성의 4계층(JMX·Web UI·system 테이블·이벤트 리스너)이 각각 어떤 질문에 답하는지
• Prometheus/Grafana 로 클러스터 건강을 지속적으로 모니터링하는 방법
• Web UI 를 이용해 단건 쿼리의 병목(스테이지·스큐·spill)을 찾는 절차
• system.runtime 테이블로 실시간 현황을 SQL 로 조회·자동화하는 방법
• 이벤트 리스너로 쿼리 이력을 적재해 감사·비용 분석에 활용하는 방법

1. 관측성 4계층

2. JMX 메트릭과 Prometheus

Trino 는 내부 상태를 JMX 로 노출하고, JMX 를 SQL 로 조회하는 jmx 카탈로그도 제공합니다. 프로덕션에서는 보통 Prometheus 로 수집 → Grafana 로 시각화 → Alertmanager 로 알림을 구성하면 됩니다.

한 문장으로: JMX 메트릭은 클러스터 전체의 건강을 시계열로 추적하는 가장 기본적인 수단입니다.

코디네이터는 /metrics 엔드포인트(또는 JMX exporter)로 Prometheus 포맷 메트릭을 내보낼 수 있습니다. 아래 scrape 설정을 여러분의 Prometheus 에 추가해 봅시다.

# Prometheus scrape 예시
scrape_configs:
  - job_name: trino
    metrics_path: /metrics
    static_configs:
      - targets: ['trino-coordinator:8080']

꼭 봐야 할 핵심 지표

queued 쿼리 수·클러스터 메모리·워커 노드 수, 이 세 지표를 대시보드 맨 위에 올려두세요 — 대부분의 장애가 여기서 먼저 드러나거든요.

jmx 카탈로그로 즉석 조회

-- 클러스터 메모리 풀 상태를 SQL 로
SELECT node, freebytes, maxbytes
FROM jmx.current."trino.memory:name=general,type=memorypool";

3. Web UI — 단건 쿼리 진단의 핵심

코디네이터 Web UI(기본 8080/8443)는 실시간 쿼리 목록과 각 쿼리의 상세 분석을 제공합니다. 느린 쿼리 한 건을 파고들 때 가장 강력한 도구죠.

Query Detail 에서 여러분이 꼭 확인해야 할 항목은 다음과 같습니다.

데이터 스큐 진단: 한 워커의 split·처리 시간만 유독 길다면, 특정 키에 데이터가 몰린 것입니다. 조인 키 분포를 의심하고, 필요하면 파티션/버킷 설계를 재검토하세요.

4. system 테이블 — SQL 로 현황 조회

system.runtime 스키마를 이용하면 클러스터 상태를 SQL 로 바로 조회할 수 있어 자동화·정기 리포트에 아주 유용합니다. 아래 쿼리들을 바로 실행해 봅시다.

-- 지금 실행/대기 중인 쿼리 (메모리 큰 순)
SELECT query_id, state, user, resource_group_id,
       total_memory_reservation, elapsed_time, query
FROM system.runtime.queries
WHERE state IN ('RUNNING', 'QUEUED')
ORDER BY total_memory_reservation DESC;
 
-- 활성 워커 노드
SELECT node_id, http_uri, node_version, state
FROM system.runtime.nodes;
 
-- 오래 도는 쿼리 찾기 (예: 10분 초과)
SELECT query_id, user, elapsed_time, query
FROM system.runtime.queries
WHERE state = 'RUNNING' AND elapsed_time > INTERVAL '10' MINUTE
ORDER BY elapsed_time DESC;

-- 폭주 쿼리 강제 종료
CALL system.runtime.kill_query(query_id => '20260605_120000_00001_abcde',
                               message => 'admin killed: runaway scan');

5. 이벤트 리스너 — 쿼리 감사와 장기 분석

Web UI 와 system 테이블은 휘발성입니다(코디네이터 재시작·이력 보존 한도). 장기 분석·감사를 위해서는 이벤트 리스너를 설정해 쿼리 시작/완료 이벤트를 외부에 적재해야 합니다.

# etc/event-listener.properties
event-listener.name=...      # 예: HTTP, Kafka, 또는 커스텀 플러그인

이벤트에는 쿼리 텍스트, 사용자, 소스, 실행 시간, 스캔 바이트, 메모리, 성공/실패, 오류 코드 등이 담깁니다. 이를 Kafka/HTTP 로 받아 Iceberg 테이블에 적재하면 — Trino 자신으로 — 아래처럼 다양한 분석을 할 수 있습니다.

-- 어제 가장 비싼(스캔량 많은) 쿼리 Top 20
SELECT user, scanned_bytes / 1e9 AS scanned_gb, elapsed_ms, query
FROM iceberg.audit.query_log
WHERE event_date = current_date - INTERVAL '1' DAY
ORDER BY scanned_bytes DESC
LIMIT 20;
 
-- 사용자/소스별 실패율 추세
SELECT user, count(*) AS total,
       count_if(state = 'FAILED') AS failed,
       count_if(state = 'FAILED') * 1.0 / count(*) AS fail_rate
FROM iceberg.audit.query_log
WHERE event_date >= current_date - INTERVAL '7' DAY
GROUP BY user
ORDER BY fail_rate DESC;

이 쿼리 로그는 보안 감사, 비용 분석(누가 자원을 많이 쓰나), 그리고 Resource Group 정책 튜닝의 근거로 활용하면 됩니다.

한 문장으로: 이벤트 리스너는 "어제 누가 무슨 쿼리를 얼마나 썼는가"를 데이터 기반으로 답할 수 있게 해 주는 유일한 수단입니다.

6. 느린 쿼리 진단 절차

느린 쿼리를 만나면 당황하지 말고 아래 순서대로 좁혀 들어가 봅시다.

(EXPLAIN/통계 상세는 별도 글 "Trino Cost-Based Optimizer 깊이 보기", 메모리·spill 은 "Trino 메모리 관리와 Resource Groups" 를 참고하세요.)

7. 증상 → 지표 → 처방 빠른 표

8. 알림(Alerting) 권장 규칙

Grafana/Alertmanager 로 최소한 다음 규칙을 걸어두세요. 이것만 있어도 장애를 사전에 감지할 수 있습니다.

• 활성 워커 수가 기대치 아래로 N분 지속
• 클러스터 메모리 사용률 > 85% N분 지속
• queued 쿼리 수 > 임계값 N분 지속
• 쿼리 실패율 > 임계값
• 코디네이터 헬스체크(/v1/info) 실패

9. 정리

Trino 관측성의 핵심은 "전체인가 단건인가"를 먼저 가르고, JMX 대시보드 → Web UI → EXPLAIN ANALYZE 순으로 좁혀 들어가는 것입니다. 여기에 이벤트 리스너로 쿼리 이력을 쌓아두면, 사후 감사와 비용 분석은 물론 Resource Group 정책을 데이터 기반으로 튜닝할 수 있습니다. 추측이 아니라 지표로 운영하는 것 — 그것이 안정적인 Trino 클러스터의 조건입니다.

마치며 — 핵심 요약

• JMX + Prometheus/Grafana 로 클러스터 건강(queued 쿼리 수·메모리·워커 수)을 상시 모니터링하고, 이 세 지표를 대시보드 최상단에 배치하세요.
• Web UI 는 단건 쿼리 진단에 최강입니다. Peak Memory·스테이지별 시간·Spilled Data·split 분포를 순서대로 확인하면 병목을 찾을 수 있습니다.
• system.runtime 테이블 을 활용하면 실시간 현황 조회와 kill_query 자동화를 SQL 한 줄로 처리할 수 있습니다.
• 이벤트 리스너 로 쿼리 이력을 Iceberg 등 외부 저장소에 적재해 두면 보안 감사·비용 분석·Resource Group 정책 튜닝의 근거 데이터가 됩니다.
• 느린 쿼리 진단은 "클러스터 전체인가, 단건인가"를 먼저 나누고 JMX → Web UI → EXPLAIN ANALYZE 순으로 좁혀가는 것이 정석입니다.
• 알림 규칙(워커 수 감소·메모리 85% 초과·실패율 급증)을 미리 설정해 두면 사용자가 민원을 내기 전에 여러분이 먼저 알 수 있습니다.

이 글은 Trino 440번대 기준으로 작성되었습니다. Trino 모니터링 대시보드 구축이나 쿼리 감사·비용 분석 체계 수립이 필요하시면 언제든 문의해 주세요.

— Data Dynamics 엔지니어링 팀