엔터티 유형 구성 설명¶

이 문서는 엔터티 유형의 세 가지 구성인 Data Schema, 표시 열, 연결된 뷰에 대해 설명합니다.

Data Schema: 사용자가 추가할 수 있는 엔터티 필드 정의
표시 열: 엔터티 목록의 기본 표시 열, 기본 숨김 열 및 고정 열 정의
연결된 뷰: 엔터티 상세 페이지에 표시할 로그, 이벤트, 트레이스, 대시보드 등 연결된 뷰 정의

Data Schema¶

Data Schema는 엔터티 유형에 사용자 정의 필드를 추가하는 데 사용됩니다. 시스템이 먼저 공식 기준 Schema를 로드한 후, 사용자가 구성한 추가 필드를 덮어씁니다.

공식 기준 Schema¶

시스템이 엔터티 유형에 대해 공식 기준 Schema를 이미 제공하며, 사용자는 프런트엔드 인터페이스에서 구체적인 공식 필드 세부 정보를 확인할 수 있습니다.

사용자가 구성하는 Data Schema는 추가 필드만 선언하면 되며, 공식에서 이미 정의한 최상위 메타데이터와 기본 필드를 다시 선언할 필요가 없습니다.

다시 선언할 필요가 없는 내용은 다음과 같습니다.

유형	예시
최상위 메타데이터	`kind`, 최상위 `name`, `version`, `entity_type`
공식 소스 구성	`sources`
공식 기본 필드	`name`, `display_name`, `description`, `project`, `env`, `owner`, `lifecycle`, `tier`
공식 관계 필드	`component_of`, `depends_on`
공식 공통 확장 필드	`custom_tags`, `contact`, `link`

필드는 공식 Schema 또는 custom_properties에 먼저 정의되어야 유효한 엔터티 필드가 됩니다. 정의되지 않은 필드는 데이터 보고, 표시 열 구성 또는 연결된 뷰 변수에 나타나더라도 엔터티 필드로 저장되거나 표시되지 않으며, 시스템이 해당 필드를 무시합니다.

기본 구조¶

사용자 정의 필드는 custom_properties 아래에 통일하여 작성합니다.

custom_properties:
  - name: service_level_objective
    type: number
    description: "서비스 목표 달성률"
    validation:
      min: 0
      max: 100

필드 설명:

필드	설명
`custom_properties`	사용자 추가 필드 목록
`name`	사용자 정의 필드명. 필수 입력이며, 공식 필드와 이름이 중복될 수 없음
`type`	필드 유형
`description`	필드 설명
`required`	필수 입력 여부
`validation`	필드 검증 규칙
`mappings`	여러 소스 Payload에서의 필드 이름 매핑
`weight_overrides`	필드 수준 소스 가중치 재정의

필드명 충돌 규칙¶

사용자 정의 필드명은 공식 필드명과 중복될 수 없습니다.

충돌이 발생하는 경우:

공식 필드는 항상 유지됨
사용자 정의 필드는 적용되지 않음
사용자는 사용자 정의 필드명을 수정한 후 저장해야 함

예를 들어, 공식 필드에 이미 env가 존재하는 경우 다음과 같이 구성하지 마십시오.

custom_properties:
  - name: env
    type: string

공식 필드에 이미 contact가 존재하는 경우, 내부 구조를 다시 정의하려고 시도하지 마십시오.

custom_properties:
  - name: contact
    type: array
    items:
      type: object

필드 유형¶

카테고리	type	설명
기본 스칼라	`string`	문자열, 길이 제한, 정규식 매칭, 빈 문자열 필터 지원
기본 스칼라	`integer`	정수, 숫자 범위 검증 지원
기본 스칼라	`number`	숫자, 부동소수점 및 정밀도 제어 지원
기본 스칼라	`boolean`	불리언 값
집합 컨테이너	`array`	배열, `items` 필수 정의
집합 컨테이너	`object`	객체, 중첩 필드 지원
시맨틱 제약	`enum`	열거형 값, `allowed_values` 필수 정의
시맨틱 제약	`urn`	시스템 내 엔터티 참조
시맨틱 제약	`datetime`	시간, ISO 8601 형식 사용
시맨틱 제약	`uri`	URL/URI 주소

구성 예시¶

custom_properties:
  - name: service_level_objective
    type: number
    description: "서비스 목표 달성률"
    validation:
      min: 0
      max: 100

  - name: endpoints
    type: array
    description: "서비스 액세스 엔드포인트"
    min_items: 1
    items:
      type: object
      required: [ip, port]
      properties:
        - name: ip
          type: string
          validation:
            pattern: "^((25[0-5]|(2[0-4]|1\\d|[1-9]|)\\d)\\.?\\b){4}$"

        - name: port
          type: number
          validation:
            min: 1
            max: 65535

        - name: protocol
          type: enum
          allowed_values:
            - http
            - https
            - tcp

구성 권장 사항¶

사용자 정의 필드는 custom_properties 아래에만 작성
전체 공식 DataSchema를 복사하지 마십시오.
공식 필드를 다시 정의하지 마십시오.
공식 Schema 또는 custom_properties에 없는 필드는 무시되며, 유효한 엔터티 필드로 저장되거나 표시되지 않습니다.
array 유형은 items를 반드시 정의해야 합니다.
enum 유형은 allowed_values를 반드시 정의해야 합니다.
사용자 정의 필드가 필수 입력인 경우 필드 수준에서 required: true를 사용하십시오.

표시 열¶

표시 열은 엔터티 목록에서 열 표시 방식을 구성하는 데 사용됩니다.

기본 구조¶

table_columns:
  - name
  - entity_type

  - field: project
    fixed: true
    hidden: false

  - field: owner
    hidden: false

  - field: env
    hidden: true

  - field: business_owner
    fixed: false
    hidden: false

필드 설명¶

필드	설명
`field`	열에 해당하는 필드명
`fixed`	고정 표시 열 여부. 기본값은 `false`
`hidden`	기본 숨김 여부. 기본값은 `false`

구성 규칙¶

field는 엔터티에 존재하는 필드여야 합니다. 공식 필드이거나 사용자가 custom_properties에 추가한 필드일 수 있습니다. 정의되지 않은 필드는 표시되지 않습니다.
fixed: true는 고정 열을 의미합니다. 고정 열은 항상 표시되며, 표시 열 활성화/비활성화 목록에 나타나지 않습니다.
hidden: false는 기본 표시를 의미합니다.
hidden: true는 기본 표시되지 않음을 의미하지만, 사용자는 표시 열 구성에서 수동으로 활성화할 수 있습니다.
name, entity_type과 같은 약어 표기는 field: name, field: entity_type과 동일하며 기본 표시됩니다.

fixed: true와 hidden: true를 동시에 구성하는 것은 권장되지 않습니다. 동시에 존재하는 경우 고정 열로 처리되어 항상 표시됩니다.

예시¶

table_columns:
  - field: name
    fixed: true

  - field: project

  - field: owner

  - field: env
    hidden: true

  - field: service_level_objective
    hidden: false

연결된 뷰는 엔터티 유형을 기반으로 상세 페이지 뷰(예: 로그, 이벤트, 트레이스, 컨테이너, Pod 및 대시보드 뷰)를 바인딩하는 데 사용됩니다. 엔터티 상세 정보를 조회할 때 시스템이 해당 엔터티 유형에 바인딩된 뷰를 읽어 표시합니다.

공식 내장 뷰¶

시스템이 엔터티 유형에 따라 일부 공식 내장 뷰를 제공할 수 있습니다. 사용자는 표시할 필요가 없는 공식 뷰를 수동으로 끌 수 있습니다.

사용자 정의 연결된 뷰¶

사용자 정의 연결된 뷰는 telemetrySelectors 아래에 작성합니다.

기본 구조:

telemetrySelectors:
  - name: "오류 로그"
    type: explorer
    viewName: logs
    query: "service='{{metadata.service}}'"

  - name: "메트릭"
    type: dashboard
    timerange: "30m"
    viewName: "서비스 개요"

필드 설명¶

`name`¶

엔터티 상세 페이지에서 탭(Tab)에 표시되는 이름입니다.

name: "오류 로그"

`type`¶

연결된 뷰 유형. 현재 두 가지 유형을 지원합니다.

type	설명
`dashboard`	대시보드
`explorer`	탐색기

`explorer` 유형 구성¶

explorer는 로그, 이벤트, 트레이스, 컨테이너, Pod 등 탐색기 목록을 연결하는 데 사용됩니다.

`viewName`¶

탐색기 유형. 현재 지원하는 유형:

viewName	설명
`logs`	로그 탐색기
`event`	이벤트 탐색기
`trace`	트레이스 탐색기
`container`	컨테이너 탐색기
`pod`	Pod 탐색기

`query`¶

필터 조건. DQL 쿼리 구문을 사용합니다.

변수를 통해 현재 엔터티 속성을 참조할 수 있습니다.

{{metadata.field}}

예시:

query: "service='{{metadata.service}}'"

더 복잡한 조건도 작성할 수 있습니다.

query: "service='{{metadata.service}}' AND df_status NOT IN ['ok','info']"

query에서 참조하는 {{metadata.field}}는 정의된 엔터티 필드에서 가져와야 합니다. 필드가 존재하지 않거나 값이 비어 있으면 쿼리 조건이 데이터와 일치하지 않을 수 있습니다.

`explorer` 예시¶

- name: "오류 로그"
  type: explorer
  viewName: logs
  query: "service='{{metadata.service}}' AND df_status NOT IN ['ok','info']"

- name: "이벤트"
  type: explorer
  viewName: event
  query: "service='{{metadata.service}}'"

`dashboard` 유형 구성¶

dashboard는 상세 페이지에서 대시보드를 표시하는 데 사용됩니다.

`timerange`¶

대시보드 쿼리의 시간 범위입니다.

timerange: "30m"
timerange: "1h"
timerange: "24h"

`keys` 및 `notinkeys`¶

특정 엔터티 조건을 충족할 때만 해당 대시보드를 표시합니다.

# 현재 엔터티의 database_type 값이 MySQL인 경우 표시
keys: { database_type: "MySQL" }

# 현재 엔터티에 host 필드가 있고 database_type 값이 MySQL인 경우 표시
keys: { host: "*", database_type: "MySQL" }

# 현재 엔터티의 database_type 값이 MySQL이 아닌 경우 표시
notinkeys: { database_type: "MySQL" }

`viewName`¶

대시보드 이름입니다.

참고

액세스 가능한 대시보드 이름을 입력해야 합니다.
이름이 대시보드와 일치해야 합니다. 그렇지 않으면 올바르게 열리지 않습니다.
동일한 이름의 시스템 뷰와 사용자 뷰가 존재하는 경우 사용자 뷰가 우선 적용됩니다.

`dashboard` 예시¶

- name: "메트릭"
  type: dashboard
  timerange: "30m"
  viewName: "서비스 개요"

- name: "메트릭"
  type: dashboard
  keys: { database_type: "MySQL" }
  timerange: "1h"
  viewName: "인프라 MySQL 모니터링 뷰"

전체 예시¶

telemetrySelectors:
  - name: "오류 로그"
    type: explorer
    viewName: logs
    query: "service='{{metadata.service}}' AND df_status NOT IN ['ok','info']"

  - name: "이벤트"
    type: explorer
    viewName: event
    query: "service='{{metadata.service}}'"

  - name: "서비스 개요"
    type: dashboard
    timerange: "30m"
    viewName: "서비스 개요"

  - name: "메트릭"
    type: dashboard
    keys: { database_type: "MySQL" }
    timerange: "1h"
    viewName: "인프라 MySQL 모니터링 뷰"

  - name: "메트릭"
    type: dashboard
    keys: { database_type: "Oracle" }
    timerange: "1h"
    viewName: "인프라 Oracle 모니터링 뷰"

구성 권장 사항¶

explorer.query에서 참조하는 {{metadata.field}}는 엔터티에 실제로 존재하는 속성이어야 합니다.
dashboard.viewName은 액세스 가능한 대시보드를 가리켜야 합니다.
keys는 엔터티 속성 값에 따라 다른 대시보드를 표시하는 데 적합합니다.
하나의 엔터티 유형에 여러 연결된 뷰를 구성할 수 있습니다. telemetrySelectors 아래에 직접 추가하면 됩니다.

엔터티 유형 구성 설명¶

Data Schema¶

공식 기준 Schema¶

기본 구조¶

필드명 충돌 규칙¶

필드 유형¶

구성 예시¶

구성 권장 사항¶

표시 열¶

기본 구조¶

필드 설명¶

구성 규칙¶

예시¶

연결된 뷰¶

공식 내장 뷰¶

사용자 정의 연결된 뷰¶

필드 설명¶

name¶

type¶

explorer 유형 구성¶

viewName¶

query¶

explorer 예시¶

dashboard 유형 구성¶

timerange¶

keys 및 notinkeys¶

viewName¶

dashboard 예시¶

전체 예시¶

구성 권장 사항¶

이 페이지가 도움이 되었나요? ×

`name`¶

`type`¶

`explorer` 유형 구성¶

`viewName`¶

`query`¶

`explorer` 예시¶

`dashboard` 유형 구성¶

`timerange`¶

`keys` 및 `notinkeys`¶

`viewName`¶

`dashboard` 예시¶

이 페이지가 도움이 되었나요?