LogQL, KQL 및 SPL 쿼리를 SQL로 마이그레이션

운영 쿼리를 SQL로 이동하는 것은 찾기 및 바꾸기 연습이 아닌 데이터 모델 마이그레이션입니다. LogQL는 로그 스트림 및 레이블 선택기로 시작하고 Kusto 쿼리 언어는 테이블 형식 파이프라인을 사용하며 Splunk SPL는 명령을 통해 검색 결과를 변환합니다. SQL는 관계로 시작하여 선택, 그룹화, 조인 및 투영을 명시적으로 만듭니다.

가장 안전한 마이그레이션은 구문을 변경하기 전에 질문과 결과 계약을 유지합니다.

먼저 의미 계약을 작성하세요.

모든 쿼리에 대해 다음을 기록합니다.

• 그것이 뒷받침하는 결정;
• 소스 및 시간 창
• 행 또는 이벤트 그레인
• 구문 분석된 필드 및 해당 유형
• 그룹화 차원;
• 분자와 분모;
• null, 중복, 재시도 및 지연 도착 규칙;
• 예상 열 및 정렬 순서.

동일한 제한된 간격에 대해 이전 쿼리와 새 쿼리를 실행합니다. 먼저 총계를 비교한 다음 그룹 수준 결과를 비교하고 대표 원시 행을 비교합니다. 시각적으로 유사해 보이는 결과라도 여전히 다른 분모를 사용할 수 있습니다.

공유된 예시 이벤트

아래 번역에서는 완료된 API 요청당 하나의 입력된 행을 가정합니다.

{
  "timestamp": "2026-07-28T16:04:00Z",
  "event_name": "api_request_completed",
  "service": "checkout-api",
  "route": "/v1/orders/:id",
  "status_code": 503,
  "latency_ms": 842,
  "request_id": "req_01J...",
  "release": "2026.07.28"
}

이전 시스템이 "GET /v1/orders/123 returned 503 in 842ms"와 같은 메시지만 저장하는 경우 먼저 파서를 추가하거나 계측을 변경하세요. SQL는 기록된 적이 없는 안정적인 경로 템플릿이나 신뢰할 수 있는 숫자 유형을 복구할 수 없습니다.

컨셉 맵

이 표는 정확한 동등성이 아닌 의도를 매핑합니다. 예를 들어 Loki 레이블은 스트림 인덱싱 및 카디널리티 제약 조건에 참여합니다. SQL 열은 자동으로 동일한 저장 동작을 갖지 않습니다.

예시 1: 최근 오류 필터링

LogQL

{service="checkout-api"} | json | status_code >= 500

KQL

ApiRequestCompleted
| where Timestamp > ago(1h)
| where Service == "checkout-api" and StatusCode >= 500
| project Timestamp, Route, StatusCode, LatencyMs, RequestId
| order by Timestamp desc

SPL

index=production service=checkout-api status_code>=500 earliest=-1h
| table _time route status_code latency_ms request_id
| sort - _time

SQL

SELECT
  timestamp_utc,
  route,
  status_code,
  latency_ms,
  request_id
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '1 hour'
  AND service = 'checkout-api'
  AND status_code >= 500
ORDER BY timestamp_utc DESC
LIMIT 200;

명시적 제한은 탐색 쿼리가 제한되지 않은 인시던트 창을 반환하지 않도록 보호합니다. 이는 집계 보고서의 일부가 아닙니다.

예시 2: 경로별 오류율 계산

파이프라인 언어를 사용하면 분자를 쉽게 볼 수 있고 분모는 이전 단계에서 암시되는 경우가 많습니다. SQL 결과에 두 가지를 모두 유지합니다.

SELECT
  route,
  COUNT(*) AS requests,
  SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
  ROUND(
    100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
      / NULLIF(COUNT(*), 0),
    2
  ) AS error_rate_pct
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
  AND service = 'checkout-api'
GROUP BY route
ORDER BY error_rate_pct DESC, requests DESC;

하나의 구문 분석된 로그 항목이 하나의 SQL 행에 해당하고 재시도 또는 여러 줄 메시지가 그레인을 변경하지 않는다는 것을 확인할 때까지 LogQL count_over_time를 COUNT(*)로 변환하지 마십시오.

예시 3: 시간 차트 작성

KQL summarize ... by bin(Timestamp, 5m), SPL timechart span=5m 및 LogQL 범위 집계는 모두 시계열을 표현합니다. DataFusion SQL에서 휴대용 첫 번째 단계는 시간 버킷입니다.

SELECT
  date_trunc('hour', timestamp_utc) AS hour,
  release,
  COUNT(*) AS requests,
  approx_percentile_cont(latency_ms, 0.95) AS p95_latency_ms
FROM api_request_completed
WHERE timestamp_utc >= now() - INTERVAL '7 days'
GROUP BY date_trunc('hour', timestamp_utc), release
ORDER BY hour ASC, release ASC;

엔진에서 지원하고 이벤트 볼륨에 적합한 버킷을 선택하세요. 불완전한 최신 버킷을 제외하거나 주석을 답니다.

예시 4: 파이프라인을 공통 테이블 표현식으로 교체

각 단계가 이전 테이블을 변환하므로 파이프라인을 읽을 수 있습니다. SQL 공통 테이블 표현식은 해당 모양을 유지할 수 있습니다.

WITH recent_requests AS (
  SELECT *
  FROM api_request_completed
  WHERE timestamp_utc >= now() - INTERVAL '24 hours'
    AND service = 'checkout-api'
),
route_summary AS (
  SELECT
    route,
    COUNT(*) AS requests,
    SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors
  FROM recent_requests
  GROUP BY route
)
SELECT
  route,
  requests,
  errors,
  ROUND(100.0 * errors / NULLIF(requests, 0), 2) AS error_rate_pct
FROM route_summary
WHERE requests >= 100
ORDER BY error_rate_pct DESC;

step1 또는 filtered보다는 의미에 맞게 스테이지 이름을 지정하세요. 결과 쿼리는 쉽게 검토하고 테스트할 수 있습니다.

구문 분석은 마이그레이션 위험입니다

기존 쿼리는 정규식, JSON 추출, 자동 필드 검색 또는 공급업체별 검색 시간 구문 분석에 따라 달라질 수 있습니다. 각 파생 필드의 목록을 작성합니다.

타입이 지정된 필드가 존재하고 프로듀서 전체에서 수정될 때까지 이중 수집을 실행합니다. 단일 happy-path 서비스가 일치했기 때문에 이전 파서를 제거하지 마십시오.

재설계가 필요한 공급업체별 기능

일부 구성은 일반 SQL에 강제로 적용되어서는 안 됩니다.

• LogQL 스트림 레이블 및 래핑 해제 작업은 스토리지 선택과 구문 분석을 결합합니다.
• KQL에는 풍부한 동적 값, 시계열 및 이상 기능이 있습니다.
• SPL에는 검색 시간 지식 개체, 트랜잭션 및 명령별 동작이 있습니다.
• 각 시스템은 서로 다른 기본 시간대, Null 의미, 제한 및 대략적인 집계 알고리즘을 적용합니다.

사건이나 데이터 유형에 가장 적합한 도구인 경우 공급업체 쿼리를 유지합니다. 목표는 언어 순수성이 아닌 공유 질문을 위한 신뢰할 수 있는 SQL 이벤트 모델입니다.

LogQL 쿼리 예제, Kusto 쿼리 연산자 및 Splunk 검색 참조에 대한 현재 자사 참조를 참조하세요.

검증 및 컷오버

마이그레이션된 각 쿼리에 대해 다음을 수행합니다.

1. 대표 간격을 고정합니다.
2. 소스 행 수를 비교합니다.
3. 고유한 작업 식별자를 비교합니다.
4. null과 구문 분석 실패 횟수를 비교합니다.
5. 총계뿐만 아니라 모든 출력 그룹을 비교합니다.
6. 허용되는 차이점을 설명합니다.
7. 최소한 하나의 정상적인 트래픽 주기를 통해 두 대시보드를 모두 실행합니다.
8. 사용자가 새 결과를 수락할 때까지 이전 쿼리에 대한 롤백 링크를 유지합니다.

엔진 및 유형 문제의 경우 SQL 쿼리 문제 해결을 사용하고, 계측 롤아웃의 경우 로그를 구조화된 이벤트로 마이그레이션을, 전체 계약 및 시각적인 내용을 보려면 SQL 요리책을 사용하세요. 출력.