공통 설정
예시 구성 화면: 공통 설정 예시 YAML:version 속성이 추가된다는 점에 유의하십시오. 이는 해당 구성을 저장할 때 사용된 플러그인의 버전을 나타냅니다.
HTTP protocol
HTTP 경로
사용자 지정 HTTP 헤더
password 필드와 유사함).
일반/보안 헤더용 YAML 예시:
추가 설정
이 추가 설정은 선택 사항입니다. 예시 YAML:OpenTelemetry
로그
로그용 쿼리 빌드 속도를 높이기 위해 로그 쿼리에 사용할 기본 데이터베이스/테이블과 컬럼을 설정할 수 있습니다. 이렇게 하면 쿼리 빌더에 실행 가능한 로그 쿼리가 미리 로드되어 관측성 워크플로에서 Explore 페이지를 더 빠르게 탐색할 수 있습니다. OpenTelemetry를 사용하는 경우 “Use OTel” 스위치를 활성화하고 기본 로그 테이블을otel_logs로 설정해야 합니다.
이렇게 하면 선택한 OTel 스키마 버전에 맞게 기본 컬럼이 자동으로 재정의됩니다.
로그에 OpenTelemetry가 필수는 아니지만, 단일 로그/트레이스 데이터셋을 사용하면 데이터 링크을 통해 더 원활한 관측성 워크플로를 구현하는 데 도움이 됩니다.
로그 구성 화면 예시:
로그 구성 YAML 예시:
“View logs” 링크 비활성화
로그 구성의 트레이스 ID 연관 관계 섹션에는 “View logs” 링크 표시 토글이 있습니다. 이 토글은 플러그인이 쿼리 결과의 트레이스 ID 필드에 “View logs” 데이터 링크를 추가할지 여부를 제어합니다. 이 토글은 기본적으로 활성화되어 있습니다. 동일한 쿼리 유형의 “View logs” 링크에는 로그 기본값을 구성할 필요가 없지만, 트레이스 쿼리 결과에서 교차 신호로 연결되는 “View logs” 링크에는 로그 기본값을 구성해야 합니다. 링크를 숨기려면 토글을 끄거나 YAML에서showLogLinks: false로 설정하십시오.
트레이스
트레이스용 쿼리 빌드 속도를 높이기 위해, 트레이스 쿼리에 사용할 기본 데이터베이스/테이블과 컬럼을 설정할 수 있습니다. 이렇게 하면 실행 가능한 트레이스 검색 쿼리가 쿼리 빌더에 미리 로드되어, 관측성 작업 시 Explore 페이지에서 더 빠르게 탐색할 수 있습니다. OpenTelemetry를 사용하는 경우 “Use OTel” 스위치를 활성화하고, 기본 트레이스 테이블을otel_traces로 설정해야 합니다.
이렇게 하면 선택한 OTel 스키마 버전을 사용하도록 기본 컬럼이 자동으로 재정의됩니다.
OpenTelemetry가 필수는 아니지만, 트레이스에 OpenTelemetry 스키마를 사용할 때 이 기능이 가장 잘 작동합니다.
트레이스 구성 화면 예시:
트레이스 구성 YAML 예시:
“View trace” 링크 비활성화
트레이스 구성의 트레이스 ID 연관 관계 섹션에는 Show “View trace” links 토글이 있습니다. 이 토글은 플러그인이 쿼리 결과의 트레이스 ID 필드에 “View trace” 데이터 링크를 추가할지 여부를 제어합니다. 토글은 기본적으로 활성화되어 있습니다. 동일한 쿼리 유형의 “View trace” 링크에는 트레이스 기본값을 구성할 필요가 없지만, 로그 쿼리 결과의 교차 신호 “View trace” 링크에는 필요합니다. 링크를 숨기려면 토글을 끄거나 YAML에서showTraceLinks: false로 설정하십시오.
컬럼 별칭
- 스키마와 대부분의 중첩 속성/타입을 알고 있습니다
- 데이터를 맵(Map) 타입에 저장합니다
- JSON을 문자열로 저장합니다
- 선택한 컬럼을 변환하기 위해 함수를 자주 적용합니다
테이블에 정의된 ALIAS 컬럼
Date 유형으로 변환하는 TimestampDate 별칭을 생성합니다.
이 데이터는 첫 번째 컬럼처럼 디스크에 저장되지 않으며, 쿼리 시점에 계산됩니다.
테이블에 정의된 별칭은 SELECT *로 반환되지 않지만, 이는 서버 설정에서 구성할 수 있습니다.
자세한 내용은 ALIAS 컬럼 유형 문서를 참조하십시오.
컬럼 별칭 테이블
기본적으로 Grafana는DESC table의 응답을 바탕으로 컬럼 추천을 제공합니다.
경우에 따라 Grafana에 표시되는 컬럼을 완전히 재정의해야 할 수 있습니다.
이렇게 하면 컬럼을 선택할 때 Grafana에서 스키마를 숨길 수 있어, 테이블의 복잡도에 따라 사용자 경험을 개선할 수 있습니다.
이 방식의 장점은 테이블에 정의된 별칭보다 테이블을 변경하지 않고도 더 쉽게 업데이트할 수 있다는 점입니다. 일부 스키마에서는 이런 항목이 수천 개에 이를 수 있으며, 이로 인해 기본 테이블 정의가 복잡해질 수 있습니다. 또한 사용자가 무시해야 하는 컬럼을 숨길 수도 있습니다.
Grafana에서 별칭 테이블은 다음과 같은 컬럼 구조를 가져야 합니다:
ALIAS 컬럼의 동작을 재현하는 방법입니다:
DESC example_table의 결과 대신 별칭 테이블의 결과를 확인합니다:
두 가지 alias 방식 모두 복잡한 타입 변환이나 JSON 필드 추출에 사용할 수 있습니다.