2019년 7월 10일엔지니어링

Beats 환경에서 Elastic Common Schema(ECS)로 마이그레이션

2019년 2월에 관련 블로그 게시물과 웨비나를 통해 Elastic Common Schema(ECS)를 소개했습니다. 간단히 요약하자면, ECS는 공통된 필드 및 데이터 유형 세트를 정의함으로써 서로 다른 데이터 소스를 균일하게 검색, 시각화 및 분석할 수 있도록 지원합니다. 이는 유사하지만 서로 다른 데이터 소스를 동시에 사용하는 경우가 많은 다양한 공급업체 표준으로 구성된 이기종 환경에 큰 이점을 제공합니다.

또한, ECS를 구현하는 것이 결코 간단한 작업이 아닌 이유에 대해서도 설명했습니다. 사실 ECS와 호환되는 이벤트를 생성하려면 데이터 수집 프로세스 중에 이벤트 소스에서 내보내는 수많은 필드를 복사하거나 이름을 변경해야 합니다.

이미 Elasticsearch 인덱스 템플릿을 구성했고 Logstash 또는 Elasticsearch 수집 파이프라인으로 변환 함수 몇 개를 작성해보았다면, 여기에 어떤 작업이 수반되는지 금방 알아차리실 것이라고 언급하며 ECS에 대한 소개를 마쳤었습니다. Elastic Stack 데이터 수집 파이프라인을 설계한 방법에 따라 환경을 ECS로 마이그레이션하는 데 필요한 작업량이 달라집니다. 다양한 경우 중, Beats 및 Beats 모듈을 사용 중인 경우에는 ECS로의 큐레이션된 마이그레이션이 가능합니다. Beats 7 이벤트는 이미 ECS 형식을 지원하며, 기존 분석 콘텐츠과 새로운 ECS 데이터를 연결하는 작업만 남아 있습니다. 다른 다양한 경우 중에는 각종 방식의 사용자 정의 파이프라인을 사용자가 구축한 경우가 있습니다.

6월에는 ECS로 마이그레이션하는 방법을 다룬 웨비나도 진행했습니다. 이 블로그 게시물은 웨비나에서 다룬 내용을 기반으로 Beats 환경 내에서 ECS로 마이그레이션하는 방법에 대해 자세히 살펴봅니다. 사용자 정의 데이터 수집 파이프라인을 ECS로 마이그레이션하는 작업은 향후 블로그 게시물에서 다룰 예정입니다.

이 블로그 게시물에서는 다음과 같은 내용을 다룹니다.

Elastic Stack 7을 사용하여 ECS로 마이그레이션
ECS로의 마이그레이션에 대한 개념적인 개요
Beats 환경을 ECS로 마이그레이션하는 데 대한 개요
자체 마이그레이션 전략 수립
마이그레이션 예제
결론
참고 자료

Elastic Stack 7을 사용하여 ECS로 마이그레이션

Beats에서 사용하는 수많은 이벤트 필드의 이름을 변경하면 사용자에게 큰 영향을 미친다는 것을 깨닫고 Elastic에서는 최신 메이저 릴리즈인 Elastic Stack 버전 7에서 ECS 필드 이름을 도입했습니다.

이 게시물은 Elastic Stack 6.8에서 7.2로 업그레이드하는 맥락에서 Beats에서 ECS로 마이그레이션하는 방법에 대한 개략적인 개요로 시작합니다. 그런 다음 하나의 Beats 이벤트 소스에 대한 단계별 마이그레이션 예제를 살펴보겠습니다.

이 블로그 게시물은 버전 7로의 마이그레이션 중 일부만 다룹니다. 스택 업그레이드 가이드라인에 따르면, Beats는 Elasticsearch와 Kibana를 업그레이드한 이후에 업그레이드해야 합니다. 따라서 이 블로그 게시물의 마이그레이션 예제에서는 Beats 업그레이드만 다루며, Elasticsearch 및 Kibana가 이미 버전 7로 업그레이드되었다고 가정합니다. 따라서 ECS 이전 스키마에서 ECS로 Beats를 업그레이드하는 데 초점을 맞출 수 있습니다.

Elastic Stack 7 마이그레이션을 계획할 때는 앞서 언급한 가이드라인을 검토하고, Kibana 업그레이드 도우미를 살펴보고, 사용 중인 스택의 모든 부분에 대한 업그레이드 노트와 변경 사항을 주의 깊게 검토해야 합니다.

참고: Beats 도입을 고려 중이라 Beats 6의 데이터가 없다면 마이그레이션에 대해 걱정할 필요가 없습니다. Beats 버전 7.0 이상을 사용하면 별도 설정 없이 바로 ECS 형식의 이벤트를 생성할 수 있습니다.

ECS로의 마이그레이션에 대한 개념적인 개요

ECS로 마이그레이션하려면 다음 단계를 수행해야 합니다.

데이터 소스를 ECS로 변환
ECS 이전 이벤트 형식과 ECS 이벤트 간의 차이 및 충돌 해결
ECS 이벤트를 사용하도록 분석 콘텐츠, 파이프라인 및 애플리케이션 조정
원활한 전환을 위해 ECS 이전 이벤트가 ECS와 호환 가능하게 만들기
모든 소스를 ECS로 마이그레이션한 후 필드 별칭 제거

이 블로그 게시물에서는 Beats 환경을 ECS로 마이그레이션하는 맥락에서 이러한 각 단계에 대해 구체적으로 설명합니다.

아래 개요를 살펴본 후 Filebeat 모듈 하나를 6.8에서 7.2로 업그레이드하는 단계별 예제를 살펴보겠습니다. 이 마이그레이션 예제는 여러분의 워크스테이션에서 쉽게 따라 하며 마이그레이션의 각 부분을 수행하고 그 과정에서 실험도 진행할 수 있도록 고안되었습니다.

Beats 환경을 ECS로 마이그레이션하는 데 대한 개요

위에서 설명한 마이그레이션의 각 부분을 해결하는 방법에는 여러 가지가 있습니다. Beats 이벤트를 ECS로 마이그레이션하는 맥락에서 하나씩 살펴보겠습니다.

데이터 소스를 ECS로 변환

Beats는 많은 큐레이션된 이벤트 소스와 함께 제공됩니다. Beats 7.0부터는 각 이벤트 소스가 이미 ECS 형식으로 변환되어 있습니다. 이벤트에 메타데이터를 추가하는 Beats 프로세서(add_host_metadata 등)도 ECS로 변환됩니다.

하지만 Beats는 때때로 이벤트에서 단순한 전송 수단의 역할을 한다는 것을 이해하는 것이 중요합니다. Winlogbeat 및 Journalbeat에서 수집한 이벤트와 사용자 정의 로그 및 이벤트를 사용하는 모든 Filebeat 입력(Filebeat 모듈 자체 제외)을 예로 들 수 있습니다. 현재 직접 수집 및 구문 분석 중인 각 사용자 정의 이벤트 소스를 ECS에 매핑해야 합니다.

스키마 차이 및 충돌 해결

이 ECS로의 마이그레이션의 본질은 여러 데이터 소스에 걸쳐 필드 이름을 표준화하는 것입니다. 이는 많은 필드가 이름이 변경되고 있음을 의미합니다.

필드 이름 변경 및 필드 별칭

두 형식 간에 전환하는 동안 ECS 이전 이벤트 및 ECS 이벤트를 처리하는 몇 가지 방법이 있습니다. 주요 옵션은 다음과 같습니다.

새 인덱스가 이전 필드 이름을 인식하도록 Elasticsearch 필드 별칭을 사용합니다.
동일한 이벤트에서 데이터를 복제합니다(이전 필드 및 ECS 필드 모두 채우기).
아무것도 하지 않습니다. 이전 콘텐츠는 이전 데이터에서만 작동하고, 새 콘텐츠는 새 데이터에서만 작동합니다.

가장 간단하고 비용 효율적인 접근 방식은 Elasticsearch 필드 별칭을 사용하는 것입니다. 이것이 Elastic에서 Beats 업그레이드 절차로 선택한 마이그레이션 경로입니다.

그러나 필드 별칭에는 몇 가지 한계가 있으며 완벽한 솔루션은 아닙니다. 그러면 필드 별칭이 어떤 작업을 수행할 수 있고 그 한계는 무엇인지 살펴보겠습니다.

필드 별칭은 새 인덱스의 Elasticsearch 매핑에 있는 추가 필드입니다. 이를 사용하면 새 인덱스가 이전 필드 이름을 사용하는 쿼리에 응답할 수 있습니다. 하나의 필드만 표시하도록 간소화된 예를 살펴보겠습니다.

새 인덱스의 필드 별칭

더 정확히 말하면, 필드 별칭은 다음에 도움이 됩니다.

별칭 필드 집계 및 시각화
별칭 필드 필터링 및 검색
별칭 필드에 대한 자동 완성

다음은 필드 별칭의 주의 사항입니다.

필드 별칭은 순전히 Elasticsearch 매핑(검색 인덱스)의 기능입니다. 따라서 문서 소스 또는 해당 필드 이름은 수정하지 않습니다. 문서는 이전 필드 이름 또는 새 필드 이름으로 구성됩니다. 다음은 문서에서 필드에 직접 액세스하기 때문에 별칭이 도움이 되지 않는 몇 가지 경우입니다.
- 저장된 검색에 표시되는 열
- 데이터 수집 파이프라인의 추가 처리
- Beats 이벤트를 사용하는 모든 애플리케이션(예: Elasticsearch API를 통해)
필드 별칭이 필드 항목 자체이므로 동일한 이름의 새 ECS 필드가 있으면 별칭을 만들 수 없습니다.
필드 별칭은 리프 필드에서만 작동합니다. 다른 중첩된 필드를 포함하는 객체 필드와 같은 복잡한 필드에는 별칭을 지정할 수 없습니다.

이러한 필드 별칭은 Beats 7 인덱스에서 기본 옵션으로 생성되지 않으므로, Beats의 설정 단계를 진행하기 전에 각 Beat의 YAML 구성 파일에서 migration.6_to_7.enabled: true를 설정하여 필드 별칭을 활성화해야 합니다. 이 옵션 및 해당 별칭은 Elastic Stack 7.x의 수명 동안 사용할 수 있으며 8.0에서 제거됩니다.

충돌

ECS로 마이그레이션할 때 사용 중인 소스에 따라 필드 충돌이 발생할 수도 있습니다.

일부 충돌 유형은 실제로 사용 중인 필드에 대해서만 탐지된다는 점에 유의하십시오. 즉, 사용하지 않는 소스의 변경 또는 충돌은 사용자에게 영향을 미치지 않습니다. 그러나 마이그레이션을 계획할 때는 해결해야 할 모든 충돌을 확인할 수 있도록 테스트 환경에서 두 가지 형식(Beats 6 및 7)으로 각 데이터 소스의 이벤트 샘플을 수집해야 합니다.

충돌에는 다음과 같이 두 가지 종류가 있습니다.

필드의 데이터 유형이 더욱 적절한 유형으로 변경됩니다.
ECS 이전에 사용 중이던 필드 이름도 ECS에서 정의되지만 의미가 다릅니다. 이를 호환되지 않는 필드라고 부릅니다.

각 충돌 유형에 따라 발생하는 정확한 결과는 달라집니다. 그러나 일반적으로 필드가 데이터 유형을 변경하거나 중첩과 관련하여 호환되지 않는 필드도 변경되는 경우(예: 키워드 필드가 객체 필드가 됨), ECS 이전 소스와 ECS 소스 전체에서 동시에 필드를 쿼리할 수는 없습니다.

Beats 6 및 7 인덱스에 데이터가 수신될 때 Kibana 인덱스 패턴을 새로 고치면 이러한 충돌이 나타납니다. 인덱스 패턴을 새로 고친 후에 충돌 경고가 표시되지 않으면 해결해야 할 충돌이 남아 있지 않은 것입니다. 경고가 표시되는 경우 충돌만 표시하도록 데이터 유형 선택기를 설정할 수 있습니다.

데이터 유형 선택기에서 충돌 선택

이러한 충돌을 처리하는 방법은 이전 데이터를 재색인하여 새 스키마와의 호환성을 높이는 것입니다. 유형 변경으로 인한 충돌은 해결하기가 매우 간단합니다. 좀 더 적절한 데이터 유형을 사용하도록 Beats 6 인덱스 패턴을 덮어쓰기하고, 업데이트된 매핑이 적용되도록 새 인덱스로 재색인한 다음, 이전 인덱스를 삭제하면 됩니다.

호환되지 않는 필드가 있는 경우 삭제할지 또는 이름을 변경할지 결정해야 합니다. 필드 이름을 변경할 경우 먼저 인덱스 패턴에서 필드를 정의해야 합니다.

ECS 이벤트를 사용하도록 환경 조정

너무 많은 필드 이름이 변경되어 Beats와 함께 제공되는 샘플 분석 콘텐츠(예: 대시보드)가 새 ECS 필드 이름을 사용하도록 모두 수정되었습니다. 새 콘텐츠는 Beats 7.0 이상에서 생성된 ECS 데이터에서만 작동합니다. 이러한 점을 감안하여 Beats 설정은 기존 Beats 6 콘텐츠를 덮어쓰지 않고 대신 각 Kibana 시각화의 두 번째 복사본을 만듭니다. 각각의 새로운 Kibana 시각화는 이전과 이름이 동일하며 끝에 “ECS”가 추가됩니다.

Beats 6 샘플 콘텐츠 그리고 이전 스키마를 기반으로 하는 사용자 정의 콘텐츠는 필드 별칭 덕분에 Beats 6 및 7 데이터에서 대부분 계속 작동합니다. 그러나 앞서 설명한 것처럼 필드 별칭은 ECS로 마이그레이션하는 데 도움이 되는 부분적이고 일시적인 솔루션일 뿐입니다. 따라서 새 필드 이름을 사용하도록 사용자 정의 대시보드를 업데이트하거나 복제하는 작업도 마이그레이션의 일부로 포함되어야 합니다.

다음 표를 통해 살펴보겠습니다.

ECS 이전 (Beats 6, 사용자 정의 대시보드)	ECS (Beats 7)
[Filebeat System] Syslog 대시보드	[Filebeat System] Syslog 대시보드 ECS
이전 필드 및 별칭 집계 이전 필드 및 별칭 필터링 저장된 검색에서 이전 필드만 표시	새 필드만 집계 새 필드만 필터링 저장된 검색에서 새 필드만 표시

Kibana에서 분석 콘텐츠를 검토하고 수정하는 것 외에도 이벤트 파이프라인의 모든 사용자 정의 부분과 더불어 Elasticsearch API를 통해 Beats 이벤트에 액세스하는 애플리케이션을 검토해야 합니다.

ECS 이전 이벤트가 ECS와 호환 가능하게 만들기

데이터 유형 충돌 및 호환되지 않는 필드 문제를 해결하기 위해 재색인을 사용하는 방법에 대해서는 이미 설명했습니다. 재색인을 통해 이러한 두 가지 변경 유형을 해결하는 것은 선택 사항이지만, 구현하기가 매우 간단하므로 대부분의 경우 이 방법을 사용하는 것이 유용합니다. 간단한 사용 사례에서는 충돌을 무시하는 것이 실행 가능한 솔루션이 될 수 있지만, 잠재적인 필드 충돌은 Beats 7 데이터를 수집하기 시작하는 순간부터 클러스터에서 Beats 6이 수명을 다하는 순간까지 영향을 미칩니다.

재색인

필드 별칭에서 제공하는 지원만으로는 충분하지 않은 경우, 이전 데이터를 재색인하여 Beats 6 데이터에 ECS 필드 이름을 다시 채울 수도 있습니다. 이렇게 하면 ECS 필드를 사용하는 모든 새 분석 콘텐츠(새 Beats 7 콘텐츠 및 업데이트된 사용자 정의 콘텐츠)가 Beats 7 데이터 외에 이전 데이터도 쿼리할 수 있습니다.

데이터 수집 도중 이벤트 수정

Beats 7 에이전트를 롤아웃하는 데 오래 걸릴 것으로 예상되는 경우, 단순히 이전 인덱스를 재색인하는 것 이상의 작업을 수행할 수 있습니다. 데이터 수집 중에 수신되는 Beats 6 이벤트를 수정할 수도 있습니다.

재색인을 수행하고 필드 복사, 삭제 또는 이름 변경과 같은 문서 조작을 수행할 수 있는 몇 가지 방법이 있습니다. 가장 간단한 방법은 Elasticsearch 수집 파이프라인을 사용하는 것입니다. 이 방법에는 다음과 같은 몇 가지 이점이 있습니다.

_simulate API로 쉽게 테스트할 수 있습니다.
파이프라인을 사용하여 이전 인덱스를 재색인할 수 있습니다.
파이프라인을 사용하여 계속 수신되고 있는 Beats 6 이벤트를 수정할 수 있습니다.

수신되고 있는 이벤트를 수정하려면 대부분의 경우 파이프라인으로 전송하도록 Elasticsearch 출력의 ‘파이프라인’ 설정을 구성하기만 하면 됩니다. 이는 Logstash 및 Beats에 해당합니다.

Filebeat 모듈은 이미 수집 파이프라인을 사용하여 구문 분석을 수행하고 있습니다. 이 또한 수정할 수 있습니다. Filebeat 6 파이프라인을 덮어쓰고 조정 파이프라인에 콜아웃을 추가하기만 하면 됩니다.

필드 별칭 제거

필드 별칭이 더 이상 필요하지 않으면 해당 별칭을 제거하는 것을 고려해야 합니다. 필드 별칭을 사용하는 것이 모든 데이터를 복제하는 것보다 가볍다고 말씀드렸지만, 여전히 중요한 리소스인 클러스터 상태의 메모리를 사용합니다. 또한 Kibana 자동 완성 기능에도 표시되어 일을 불필요하게 복잡하게 만듭니다.

이전 필드 별칭을 제거하려면 Beats 구성(예: filebeat.yml)에서 migration.6_to_7.enabled 설정을 제거하거나 false로 설정하고, ‘설정’ 작업을 다시 수행한 다음, 템플릿을 덮어쓰면 됩니다.

더 이상 별칭을 포함하지 않도록 템플릿을 덮어쓴 후에도 인덱스가 롤오버될 때까지 기다려야 인덱스 매핑에서 별칭이 제거됩니다. 인덱스가 롤오버된 후에는 별칭이 포함된 Beats 7 데이터가 클러스터에서 수명이 종료될 때까지 기다려야 별칭이 완전히 사라집니다.

자체 마이그레이션 전략 수립

Beats 데이터를 ECS로 마이그레이션하는 데 도움이 되는 Beats의 기능을 검토했습니다. 또한, 마이그레이션을 더 원활하게 진행하기 위해 적용할 수 있는 추가 단계도 설명했습니다.

각 데이터 소스에 필요한 작업을 개별적으로 평가해야 합니다. 중요도가 가장 떨어지는 데이터 소스에 대해 더 적은 작업을 수행할 수 있는 옵션이 있을 수 있습니다.

다음은 각 데이터 소스를 살펴볼 때 고려할 수 있는 몇 가지 기준입니다.

보유 기간은 어떻게 되며, 이는 외부 조건에 따른 필수 사항입니까? 이 마이그레이션 중에 더 일찍 데이터를 삭제하는 옵션이 있습니까?
데이터 연속성이 필요합니까? 아니면 전환할 수 있습니까? 이는 위에서 설명한 대로 다시 채울 필요가 있는지를 확인하는 데 도움이 됩니다.
Beats 7을 롤아웃하는 데 얼마나 걸립니까? Beats 6 이벤트가 수신되는 대로 수정해야 합니까?

여러 필드를 다시 채우려면 Beats 리포지토리에서 dev-tools/ecs-migration.yml 파일을 확인해야 합니다. 이 파일에는 Beats 6에서 7로 마이그레이션 시 변경되는 모든 필드가 나열되어 있습니다.

마이그레이션 예제

이 블로그 게시물의 나머지 부분에서는 Beats를 6.8에서 7.2로 업그레이드하여 ECS로 마이그레이션할 수 있는 방법, 별칭이 어떻게 도움이 되는지와 그 한계, 충돌을 해결하는 방법, 최신 이전 데이터를 재색인하여 전환을 지원하는 방법, 그리고 계속 수신되고 있는 Beats 6 이벤트를 수정하는 방법을 단계별로 보여드리겠습니다. 이 예제에서는 Filebeat의 Syslog 모듈을 사용합니다.

이미 언급했듯이 이 예제에서는 Elastic Stack의 전체 업그레이드는 다루지 않습니다. Elasticsearch 및 Kibana가 이미 버전 7로 업그레이드되었다고 가정하고 데이터 스키마를 ECS로 업그레이드하는 방법에 집중하겠습니다.

따라 해보시려면 Elasticsearch 7과 Kibana 7의 가장 최신 버전을 사용하십시오. 무료 체험판 Elastic Cloud 계정을 사용하거나 Elasticsearch 및 Kibana 설치 지침에 따라 로컬로 실행할 수 있습니다.

Beats 6.8 실행

이 데모에서는 Filebeat 6.8과 7.2를 동시에 동일한 머신에서 실행합니다. 따라서 아카이브 설치(.zip 또는 .tar.gz 사용)를 통해 둘 다 설치하는 것이 중요합니다. 아카이브 설치는 해당 디렉터리에 자동으로 포함되므로 프로세스를 쉽게 수행할 수 있습니다.

Elasticsearch 및 Kibana 7이 실행 중인 상태에서 Filebeat 6.8을 설치하십시오. Windows를 사용하는 경우에는 대신 Winlogbeat를 설치하여 실험해 볼 수 있습니다.

대부분의 시스템에서 Syslog는 시간대를 지정하지 않고 현지 시간을 타임스탬프에 사용합니다. add_locale 프로세서를 통해 각 이벤트에 시간대를 추가하도록 Filebeat를 구성한 다음, 그에 따라 타임스탬프를 해석하도록 시스템 모듈의 파이프라인을 구성합니다. 이렇게 하면 나중에 최근에 수신된 이벤트를 볼 때 ECS 마이그레이션의 유효성을 확인할 수 있습니다.

filebeat.yml에서 "프로세서" 섹션을 찾아 add_locale 프로세서를 추가합니다. 프로세서 섹션 아래에 다음 모듈 구성을 추가합니다.

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_locale: ~
filebeat.modules:
  - module: system
    syslog:
      var.convert_timezone: true

Elasticsearch와 Kibana를 로컬에서 실행하고 있다면, 위의 구성으로 충분합니다. Elastic Cloud를 사용하는 경우에는 filebeat.yml에 클라우드 자격 증명을 추가해야 합니다. 이 두 자격 증명 모두 클러스터를 생성할 때 Elastic Cloud에서 확인할 수 있습니다.

cloud.id: 'my-cluster-name:a-very-long-string....'
cloud.auth: 'username:password'

이제 Filebeat 6.8이 시스템 로그를 캡처할 수 있도록 준비하겠습니다.

./filebeat setup -e
./filebeat -e

[Filebeat System] Syslog 대시보드라는 대시보드를 통해 데이터가 수신되고 있는지 확인합니다. Filebeat가 설치된 시스템에서 생성된 가장 최근의 Syslog 이벤트가 표시됩니다.

이 대시보드에는 시각화 및 저장된 검색이 포함되어 있다는 점이 흥미롭습니다. 이는 필드 별칭의 어떤 기능이 우리에게 도움이 되고 또 어떤 기능이 도움이 되지 않는지를 보여주는 데 유용합니다.

Beats 7(ECS) 실행

현실을 직시해 봅시다. 모든 환경에서 Beats의 한 버전에서 다른 버전으로 즉각적으로 전환할 수 있는 것은 아닙니다. 일정 기간 동안 Filebeat 6과 7에서 동시에 이벤트가 수신될 것으로 예상됩니다. 그럼 이 예제에서도 똑같이 해보겠습니다.

이를 위해서는 동일한 시스템에서 Filebeat 7.2를 6.8과 함께 실행하면 됩니다. 다른 디렉터리에서 Filebeat 7.2를 추출하고 6.8에서 적용한 것과 동일한 구성 변경을 적용합니다.

하지만 아직 설정을 실행하지 마세요! Beats 7의 경우 필드 별칭을 생성하는 마이그레이션 설정도 활성화해야 합니다. filebeat.yml의 맨 끝에서 이 줄의 주석 처리를 제거합니다.

migration.6_to_7.enabled: true

이제 7.2 구성 파일에는 이 추가 마이그레이션 속성, add_locale 프로세서, 시스템 모듈의 구성, 그리고 필요한 경우 클라우드 자격 증명이 포함됩니다.

다른 터미널에서 Filebeat 7.2를 시작하겠습니다.

./filebeat setup -e
./filebeat -e

충돌

대시보드를 살펴보기 전에 Kibana 인덱스 관리로 바로 이동하여 새 인덱스가 생성되었고 데이터가 들어오고 있는지 확인하겠습니다. 다음과 같은 항목이 표시됩니다.

새 인덱스가 생성되었음을 확인

인덱스 패턴으로 이동하여 filebeat-* 인덱스 패턴을 새로 고칩니다. 6.8 및 7.2 데이터에 대해 인덱스 패턴을 새로 고치면 몇 가지 충돌이 발생하게 됩니다. 오른쪽의 데이터 유형 선택기를 All field types에서 conflict로 변경하면 충돌에 집중할 수 있습니다.

데이터 유형 선택기를 충돌로 변경

위의 두 가지 충돌을 살펴보고, 어떻게 해결할 수 있는지 알아보겠습니다.

먼저, syslog 관련 충돌인 system.syslog.pid를 살펴보겠습니다. 인덱스 관리 페이지로 이동하여 6.8에 대한 매핑을 보면 필드가 keyword로 색인된 것을 확인할 수 있습니다. 7.2 인덱스 매핑을 보면 system.syslog.pid가 process.pid의 별칭인 것을 확인할 수 있습니다. 이것은 괜찮습니다. 충돌의 원인이 아닙니다. 그러나 별칭 뒤에 process.pid의 데이터 유형을 보면 데이터 유형이 이제 long인 것을 알 수 있습니다. keyword에서 long으로 변경되면서 데이터 유형이 충돌했습니다

두 번째, 호환되지 않는 필드로 인해 발생한 충돌을 살펴보겠습니다. 이는 모든 Filebeat 마이그레이션의 source 필드에 흔하게 발생합니다. Filebeat 6에서 source는 일반적으로 파일 경로(또는 때로는 syslog 소스 주소)를 포함하는 keyword 필드입니다. ECS에서 그러니까 Filebeat 7 필드 매핑에서 source는 네트워크 이벤트 소스(source.ip, source.port 등)를 설명하는 데 사용되는 중첩 필드가 있는 객체가 됩니다. source라는 이름의 필드가 Beats 7에 여전히 존재하므로 여기에 별칭 필드를 만들 수 없습니다.

마이그레이션 절차의 일부로 작업할 수 있는 두 개의 필드를 확인했습니다. 이 부분은 잠시 후에 다시 다루겠습니다.

별칭

Beats 6 [Filebeat System] Syslog 대시보드를 그대로 열어둡니다. 이 대시보드를 처음 로드한 이후 filebeat-* 인덱스 패턴이 변경되었으므로 Command-R 또는 F5를 사용하여 전체 페이지를 다시 로드하겠습니다.

새 탭에서 새 대시보드 [Filebeat System] Syslog 대시보드 ECS를 엽니다.

6.8 대시보드 하단에 있는 저장된 검색을 보면 데이터의 차이를 확인할 수 있습니다. 일부 이벤트에는 system.syslog.program 및 system.syslog.message에 대한 값이 있지만 그렇지 않은 이벤트도 있습니다. 값이 비어 있는 이벤트를 열면 7.2에서 가져온 동일한 Syslog 이벤트이지만 필드 이름은 서로 다르다는 것을 알 수 있습니다. ECS 대시보드의 탭에서 동일한 기간을 보면 동일한 동작이 반대로 수행된 것을 확인할 수 있습니다. ECS 필드 process.name 및 message는 7.2 이벤트에 대해 채워지지만 6.8 이벤트에 대해서는 채워지지 않습니다.

Syslog 로그 표시

이는 필드 별칭이 우리에게 도움이 되지 않는 하나의 구체적인 예입니다. 저장된 검색은 인덱스 매핑이 아니라 문서의 콘텐츠를 사용합니다. 개요에서 이미 언급했듯이 연속성이 필요한 경우, 재색인을 통해 다시 채우면(그리고 수신되는 이벤트를 변경하면) 이 문제가 해결됩니다. 이 방법은 잠시 후에 살펴보고,

지금은 필드 별칭이 우리에게 어떤 도움을 주는지 알아보겠습니다. 6.8 대시보드에서 도넛 시각화를 살펴보고 바깥 원 위에 마우스를 올리면 system.syslog.program의 값이 표시됩니다.

Syslog 호스트 이름 및 프로세스 그래프

원의 한 섹션을 클릭하여 하나의 프로그램에서 생성한 메시지를 필터링합니다. 프로그램 이름에 대한 필터만 선택하겠습니다.

적용할 필터 선택

방금 7.2에는 더 이상 존재하지 않는 필드인 system.syslog.program에 필터를 추가했습니다. 그러나 저장된 검색에서는 여전히 두 메시지 세트를 모두 볼 수 있습니다.

저장된 검색에 표시되는 두 메시지 세트

7.2 요소를 살펴보면 필터가 해당 필드에 성공적으로 적용되었음을 알 수 있습니다. 이는 system.syslog.program에 대한 필터가 7.2 데이터에서 작동한다는 것을 보여줍니다. system.syslog.program 별칭 덕분입니다.

Elasticsearch 집계를 기반으로 하는 시각화에도 6.8 및 7.2 모두에서 마이그레이션된 system.syslog.program 필드에 대한 결과가 올바르게 표시되고 있습니다.

필터가 활성화되지 않은 7.2 대시보드로 돌아가면 6.8 및 7.2 데이터를 모두 볼 수 있습니다. 그런데 6.8에서 했던 것과 동일한 필터를 적용하면 다른 동작이 나타납니다. process.name:iTunes를 필터링하면 이제 7.2 이벤트만 반환됩니다. 그 이유는 6.8 인덱스에 process.name이라는 이름의 필드도 별칭도 없기 때문입니다.

6.8 및 7.2 데이터를 모두 표시

원활한 마이그레이션을 위해 재색인

재색인을 통해 데이터 유형 충돌 해결, 호환되지 않는 필드 해결, 연속성을 유지하기 위한 ECS 필드 다시 채우기라는 마이그레이션의 3가지 측면을 해결하는 방법을 설명했습니다. 이제 각각의 예를 한 가지씩 살펴보겠습니다.

Beats 6 데이터를 수정하는 방법은 다음과 같습니다.

데이터 유형 충돌: system.syslog.pid의 데이터 유형을 keyword에서 long으로 변경합니다.
호환되지 않는 필드: Filebeat의 콘텐츠를 log.file.path에 복사한 후 source 필드를 삭제합니다. 이렇게 하면 ECS의 소스 필드 세트와의 충돌이 제거됩니다. Beats 6.6 이상에서는 이미 log.file.path를 동일한 값으로 채웠지만, Beats 6의 이전 버전에서는 그렇지 않으므로 조건부로 이를 복사합니다.
ECS 필드 process.name을 system.syslog.process의 값으로 다시 채웁니다.

다음은 이러한 변경을 수행하는 방법입니다.

새 데이터 유형을 사용하도록 Filebeat 6.8 인덱스 템플릿을 수정하고 필드 정의를 추가 및 제거합니다.
필드를 제거하거나 복사하여 6.8 이벤트를 수정하는 새로운 수집 파이프라인을 만듭니다.
_simulate API로 파이프라인을 테스트합니다.
파이프라인을 사용하여 이전 데이터를 재색인합니다.
또한, 이벤트가 수신될 때 이를 수정할 수 있도록 Filebeat 6.8 수집 파이프라인의 끝에 이 새 파이프라인에 대한 호출을 추가합니다.

인덱스 템플릿 변경

인덱스 템플릿에서 데이터 유형 개선을 수행해야 하며 인덱스가 롤오버될 때 적용됩니다. 기본적으로 다음 날 롤오버됩니다. 6.8에서 인덱스 수명 주기 관리(ILM)를 사용하고 있는 경우 rollover API를 사용하여 롤오버를 강제 수행할 수 있습니다.

다음과 같이 Kibana 개발자 도구에서 현재 인덱스 템플릿을 표시합니다.

GET _template/filebeat-6.8.1

인덱스 템플릿은 수정할 수 없으며, 완전히 덮어써야 합니다(설명서). 전체 인덱스 템플릿으로 PUT API 호출을 준비하는 동안 다음과 같이 몇 가지 사항을 조정합니다.

source에 대한 정의를 제거합니다(- 아래의 모든 줄).
program.name에 대한 필드 정의를 추가합니다.
system.syslog.pid 필드의 유형을 long으로 변경합니다.

PUT _template/filebeat-6.8.1
{
  "order" : 1,
  "index_patterns" : [
    "filebeat-6.8.1-*"
  ]
  ...
  "mappings": {
    "properties" : {
-     "source" : {
-       "ignore_above" : 1024,
-       "type" : "keyword"
-     },
      "program" : {
        "properties" : {
          "name": {
            "type": "keyword",
            "ignore_above": 1024
          }
        }
      },
      "system" : {
        "properties" : {
          "syslog": {
            "properties" : {
              "pid" : {
                "type" : "long"
              }
      ...      
}

API 호출 본문이 준비되면 실행하여 인덱스 템플릿을 덮어씁니다. 많은 ECS 필드를 다시 채울 계획이라면 ECS git 리포지토리에서 샘플 ECS Elasticsearch 템플릿을 확인하십시오.

재색인

다음 단계는 Beats 6.8 이벤트를 수정하기 위한 새 수집 파이프라인을 작성하는 것입니다. 예를 들어, system.syslog.program을 process.name으로 복사하고, source를 log.file.path(이미 채워져 있지 않은 경우)로 복사하고, source 필드를 제거합니다.

PUT _ingest/pipeline/filebeat-system-6-to-7
{ "description": "Pipeline to modify Filebeat 6 system module documents to better match ECS",
  "processors": [
    { "set": {
        "field": "process.name",
        "value": "{{system.syslog.program}}",
        "if": "ctx.system?.syslog?.program != null"
    }},
    { "set": {
        "field": "log.file.path",
        "value": "{{source}}",
        "if": "ctx.containsKey('source') && ctx.log?.file?.path == null"
    }},
    { "remove": {
        "field": "source"
    }}
  ],
  "on_failure": [
    { "set": {
        "field": "error.message",
        "value": "{{ _ingest.on_failure_message }}"
    }}
  ]
}

수집 파이프라인과 Painless 언어(if 절에서 사용)에 대해 자세히 알아봅니다.

완전히 채워진 이벤트를 사용하여 _simulate API로 이 파이프라인을 테스트할 수 있지만, 이 블로그 게시물에 적합한 좀 더 간소화된 테스트가 있습니다. log.file.path가 이미 채워진 이벤트(Beats 6.6 이상)와 그렇지 않은 이벤트(6.5 이하)가 있습니다.

POST _ingest/pipeline/filebeat-system-6-to-7/_simulate
{ "docs":
  [ { "_source": {
      "log": { "file": { "path": "/var/log/system.log" } },
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}},
    { "_source": {
      "source": "/var/log/system.log",
      "system": {
        "syslog": {
          "program": "syslogd"
    }}}}
  ]
}

API 호출의 응답에는 수정된 두 이벤트가 포함되어 있습니다. source 필드가 사라지고 두 이벤트의 값이 모두 log.file.path에 저장되어 있으므로 파이프라인이 제대로 작동한다는 것을 확인할 수 있습니다.

이제 마이그레이션하는 모든 Filebeat 인덱스에 이 수집 파이프라인을 사용하여 더 이상 쓰기를 수신하지 않는 인덱스(예: 어제 및 이전 인덱스)에 대해 재색인을 수행할 수 있습니다. _reindex docs를 읽고 백그라운드에서 재색인하는 방법, 재색인 작업을 조절하는 방법 등을 파악하시기 바랍니다. 다음은 우리가 예제에 사용한 몇 가지 이벤트에 적합한 간단한 재색인입니다.

POST _reindex
{ "source": { "index": "filebeat-6.8.1-2019.07.04" },
  "dest": {
    "index": "filebeat-6.8.1-2019.07.04-migrated",
    "pipeline": "filebeat-system-6-to-7"
}}

이 블로그 게시물을 따라 하고 있으며 오늘의 인덱스만 있는 경우, 언제든지 API 호출을 시도하고 마이그레이션된 인덱스의 매핑을 검사해도 좋습니다. 그러나 이후에 오늘의 인덱스를 삭제하지 마십시오. Filebeat 6.8이 여전히 데이터를 보내고 있기 때문에 다시 생성됩니다.

그렇지 않은 경우, 비활성 인덱스가 재색인된 후에는 새 인덱스에 원하는 모든 수정 사항이 적용되었는지 확인한 다음 이전 인덱스를 삭제할 수 있습니다.

수신되는 이벤트 수정

대부분의 Beats는 Elasticsearch 출력의 수집 파이프라인으로 직접 보내도록 구성할 수 있습니다(Logstash의 Elasticsearch 출력에서도 동일). 이미 수집 파이프라인을 사용하고 있는 이 데모에서는 Filebeat 모듈로 작업하고 있으므로 대신 모듈의 파이프라인을 수정해야 합니다.

Filebeat 6.8의 설정을 통해 처리하도록 설치한 수집 파이프라인을 filebeat-6.8.1-syslog-pipeline이라고 합니다. 여기에서는 Filebeat Syslog 파이프라인의 끝에 자체 파이프라인에 대한 콜아웃을 추가하기만 하면 됩니다.

다음과 같이 수정하려는 파이프라인을 표시합니다.

GET _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline

다음으로, PUT API 호출 아래에 전체 파이프라인을 붙여넣어 파이프라인을 덮어쓸 API 호출을 준비합니다. 그런 다음 끝에 ‘파이프라인’ 프로세서를 추가하여 새 파이프라인을 호출합니다.

PUT _ingest/pipeline/filebeat-6.8.1-system-syslog-pipeline
{ "description" : "Pipeline for parsing Syslog messages.",
  "processors" :
  [
    { "grok" : { ... }
    ...
    { "pipeline": { "name": "filebeat-system-6-to-7" } }
  ],
  "on_failure" : [
    { ... }
  ]
}

이 API 호출을 실행하면 수신되는 모든 이벤트가 색인되기 전에 ECS에 더 잘 맞게 수정됩니다.

마지막으로, _update_by_query를 사용하면 파이프라인을 수정하기 직전에 라이브 인덱스의 문서를 수정할 수 있습니다. source 필드가 아직 남아있는 문서를 찾으면 여전히 업데이트가 필요한 문서를 확인할 수 있습니다.

GET filebeat-6.8.1-*/_search
{ "query": { "exists": { "field": "source" }}}

그리고 다음 항목만 재색인합니다.

POST filebeat-6.8.1-*/_update_by_query?pipeline=filebeat-system-6-to-7
{ "query": { "exists": { "field": "source" }}}

충돌 확인

충돌이 발생한 모든 인덱스가 삭제되면 재색인된 인덱스만 남게 됩니다. 인덱스 패턴을 새로 고쳐 충돌이 사라졌음을 확인할 수 있습니다. Filebeat 7 대시보드로 돌아가면 process.name 필드의 다시 채우기 덕분에 6.8의 데이터를 더 유용하게 사용할 수 있음을 알 수 있습니다.

프로세스 이름 필드를 다시 채운 후의 대시보드

이 예제에서는 하나의 필드만 다시 채웠습니다. 물론 필요한 만큼 많은 필드를 다시 채울 수 있습니다.

마이그레이션 후 정리

마이그레이션을 수행하려면 새 ECS 필드 이름을 사용할 수 있도록 API를 통해 Beats 이벤트를 사용하는 사용자 정의 대시보드 및 애플리케이션을 수정해야 합니다.

Beats 7로 완전히 마이그레이션한 후 필드 별칭을 더 이상 사용하지 않게 되면 해당 별칭을 제거하여 앞에서 설명한 메모리 절감 효과를 얻을 수 있습니다. 별칭을 제거하려면 filebeat.yml에서 migration.6_to_7.enabled 속성을 제거하고 다음과 같이 Filebeat 7.2 템플릿을 덮어씁니다.

./filebeat setup --template -e -E 'setup.template.overwrite=true'

앞서 Filebeat 6.8 템플릿을 변경한 것과 마찬가지로 별칭이 없는 새 템플릿은 다음에 Filebeat 7.2 인덱스가 롤오버될 때 적용됩니다.

결론

이 게시물에서는 Beats 환경에서 ECS로 데이터를 마이그레이션하는 데 필요한 단계를 설명하고, 업그레이드 절차의 이점과 그 한계를 알아봤습니다. 이러한 한계는 이전 데이터를 재색인하고, 수집 프로세스 중에 현재 수신되고 있는 Beats 6 데이터를 수정하여 해결할 수 있습니다.

마이그레이션에 대해 개괄적으로 설명한 후 Filebeat의 시스템 모듈을 6.8에서 7.2로 업그레이드하는 단계별 예제를 진행했습니다. 우리는 Filebeat 6.8의 이벤트와 7.2의 이벤트 간 차이점을 살펴본 다음, 사용자가 이전 데이터를 재색인하고 계속 들어오는 대로 수정하기 위해 취할 수 있는 모든 단계를 살펴보았습니다.

스키마를 도입하면 기존 설치에 큰 영향을 미칠 수밖에 없지만, 이러한 마이그레이션이 그만한 가치가 있다고 확신합니다. Elastic Common Schema 소개 및 Observability가 Elastic Common Schema를 좋아하는 이유를 읽어보면 그 이유를 알 수 있습니다.

사용자 환경에서 Beats 이외의 데이터 수집 파이프라인을 사용하는 경우, 계속 지켜봐 주십시오. 사용자 정의 수집 파이프라인을 ECS로 마이그레이션하는 방법에 대해 설명하는 다른 블로그 게시물을 준비하고 있습니다.

ECS에 대한 질문이 있거나 Beats 업그레이드에 도움이 필요한 경우 토론 포럼으로 이동하여 질문에 elastic-common-schema라고 태그를 지정하십시오. 설명서에서 ECS에 대해 자세히 알아보고 GitHub에서 ECS에 기여할 수 있습니다.

참고 자료

설명서

블로그 및 동영상

일반

토론 포럼 에서 ECS에 대해 질문하고 질문에 “elastic-common-schema”라고 태그를 지정
공식 ECS 설명서
ECS Github 리포지토리

Elasticsearch Platform

ELK Stack

Elastic Cloud

Observability

Security

Search

산업별

솔루션별

고객 스포트라이트

개발자

소통

학습

도움말

Elastic에서 어떤 일이 진행되고 있는지 확인