[Elastic] Elastic Common Schema (ECS) Guideline 번역

💡 본 문서는 Guidelines and Best Practices | Elastic Common Schema (ECS) Reference [8.4] | Elastic 문서를 번역해놓은 것으로 Elasticsearch의 경우 스키마 가이드라인과 best practices 를 따를 때 가장 잘 동작하기에 하기의 내용을 참고하여 ECS 스키마를 설계를 권장합니다!

ECS Field Levels

ECS 는 Core 와 Extended 필드로 나눠 정의한다.

Core 필드

• 모든 유즈케이스에서 가장 공통적으로 접근되는 필드를 의미
• 이 일반화된 필드들은 여러 사용 사례에 걸처 주로 컨텐츠 (검색, 시각화, 대시보드, 알럿, 머신러닝, 리포트 등) 분석에 사용된다. 이런 환경에서 동작하도록 설계된 분석 컨텐츠 필드는 관련된 어떤 데이터에서도 적절히 동작해야 함
• 이 필드들을 먼저 채우는데 집중할 것

Extended 필드

• core 필드가 아닌 모든 필드들
• 좀더 좁은 범위의 유즈케이스에 적용될 수 있으며, 유즈 케이스에 따라 더 개방적으로 해석될 수 있음
• extended 필드는 시간이 흐름에 따라 변할 가능성이 높음​

일반적인 가이드라인

• doc 은 반드시 `@timestamp` 필드를 포함해야 함
• ECS 필드를 정의하기 위해 data types 를 사용할 것
• ecs.version 필드를 써서 어떤 ECS 버전이 사용중인지 정의할 것
• 가능한 많은 필드를 ECS 로 매핑할 것

필드명 가이드라인

• 필드명은 반드시 소문자여야 함
• 각 단어들은 언더스코어 (_) 로 연결해야 함
• 언더스코어 (_) 이외의 특수문자는 허용되지 않음
• 필드가 과거 상태의 데이터를 담지 않는 이상 현재 시제를 사용할 것
• 단수/복수형을 적절히 사용할 것
  • ex) request_per_sec 보단 requests_per_sec 을 사용하는 것이 좋음
• 베이스 필드를 제외하고, 모든 필드에 prefix 를 사용할 것
  • ex) 모든 host 필드는 host. prefix 를 붙임. 이렇게 그룹핑 하는 것을 필드 셋이라 부름
• Nested 필드엔 . 을 사용할 것
  • doc 구조상 nested JSON 객체가 포함될 수 있음
  • 만약 Beats, Logstash 를 사용하면 nested JSON 객체는 자동으로 처리됨
  • 만약 API 로 ES 를 사용한다면, 필드는 . 을 포함하는 문자열이 아닌 nested 객체여야 함
  • 일반적인 것에서 구체적인 것의 순서로 작업하기
  • 중첩 필드셋을 구성할 땐 일반적인 것에서 구체적인 순서로 진행하여, host.* 와 같은 접두사가 있는 객체로 그룹핑 필드를 사용할 수 있도록 해야 함
• 의미없는 반복 지양
  • 이미 필드명의 일부가 다른 필드명으로 사용되고 있는 경우 반복하지 말 것. ex) host.host_ip 는 host.ip 가 되야 함
  • 물론 필드명 변경이 팀 내 필수적인 컨벤션을 위반하는 경우 등과 같은 상황에선 예외를 둘 수 있음
• 가급적 축약된 단어를 쓰지 말 것
  • ip, os, geo 와 같이 이미 모두가 줄여쓰고 있는 경우 등에선 예외를 둘 수 있음

​

참고

• Guidelines and Best Practices | Elastic Common Schema (ECS) Reference [8.4] | Elastic