기술이야기

기술이야기 Filebeat vs Logstash, 대규모 로그 수집 환경에서 더 적합한 선택은?! 기술이야기 Filebeat vs Logstash, 대규모 로그 수집 환경에서 더 적합한 선택은?! 대규모 시스템에서 로그는 단순한 기록이 아니라, 장애 진단과 보안 분석, 운영 자동화를 위한 핵심 데이터 소스입니다. 하지만 로그 수집량이 기하급수적으로 늘어나면 기존 Logstash 기반 아키텍처는 JVM 오버헤드와 자원 점유 문제로 병목이 발생하기 쉽습니다. 이런 한계를 보완하기 위해 주목받는 것이 Filebeat입니다. 경량 Go 기반으로 설계된 Filebeat은 CPU와 메모리 부담을 최소화하고, 수집과 전송에 집중함으로써 분산 환경에서도 안정적으로 동작할 수 있습니다. 이번 글에서는 왜 Logstash 대신 Filebeat을 선택하게 되었는지, 그리고 이를 통해 어떤 운영상의 안정성과 효율성을 확보할 수 있었는지 살펴보겠습니다. 1. 왜 Logstash 대신 Filebeat를 사용하게 되었나? 통합로그관리 시스템 개발 초창기 파일 로그 수집 에이전트로 Logstash를 사용했습니다. 그러나 고객사의 폭발적인 로그 증가와 대규모 환경 요구사항에 효과적으로 대응하고 시스템의 안정성을 위해, 로그 수집 에이전트를 Filebeat로 전환하게 되었습니다. 왜? Logstash 기반 아키텍처를 바꾸었는지, 그리고 Filebeat 도입이 가져온 기술적 이점과 주요 설정은 무엇인지 자세히 살펴보겠습니다. * 수집 에이전트 교체, 무엇이 문제였고 무엇을 얻었나? 수집해야 할 로그 소스(서버, 네트워크 장비, 보안 솔루션 등)가 폭발적으로 증가하면서, 기존의 Logstash 기반 수집 아키텍처는 다음과 같은 근본적인 한계에 직면했습니다. 안정적인 SIEM 운영을 위해서는 수집 에이전트의 경량화, 안정성, 리소스 효율성 확보가 최우선 과제였으며, 그 해답으로 Filebeat를 선택하게 되었습니다. Filebeat는 Logstash의 경량화된 버전으로, 에이전트 수집 역할을 담당합니다. 즉, 로그가 생성되는 서버에 설치되어 로그 파일을 읽고 바로 OpenSearch(이전의 Elasticsearch) 또는 Kafka와 같은 목적지로 전송하는 역할을 합니다. Filebeat는 Go 언어로 개발되어 메모리 사용량이 극히 적고, CPU 부하도 거의 발생시키지 않습니다. Filebeat로 변경은 단순히 도구를 바꾼 것이 아닌, 로그 파이프라인의 효율성과 안정성을 극대화하는 전략적 선택이었습니다. 다음으로는 Logstash에서 Filebeat로 전환함으로써 얻은 주요 장점과 기술적인 이점, 그리고 Filebeat의 주요 설정에 대해 살펴보겠습니다. 2.Filebeat 전환을 통한 구체적인 이점은?! Filebeat로의 전환은 성능 개선을 넘어, 파일 수집 아키텍처를 현대적인 분산 처리 구조로 진화시켜 안정성, 유연성, 개발 효율이라는 세 가지 핵심 이점을 확보했습니다. (How Filebeat works) [1] 데이터 흐름 제어 및 안정성 Filebeat의 가장 중요한 기능 중 하나는 백프레셔(Backpressure) 메커니즘입니다. Filebeat는 데이터를 전송하는 중앙 시스템(Kafka 또는 OpenSearch Ingest Node)에 부하가 걸려 처리 속도가 느려질 경우, 스스로 로그 전송 속도를 늦춥니다. 이 지능적인 흐름 제어 덕분에 중앙 시스템의 과부하를 막고, 데이터 파이프라인이 붕괴되는 것을 방지하여 안정적인 로그 흐름을 보장합니다. [2] 유연한 운영 환경 Filebeat는 탁월한 운영 유연성을 제공합니다. 특히 filebeat.config.inputs 기능을 활용한 동적 설정 관리는 Filebeat 재시작 없이 새로운 로그 소스를 실시간으로 추가/변경할 수 있게 해 운영의 유연성을 극대화합니다. Zenius SIEM 역시 설정 편집 기능을 제공하여 이러한 운영 유연성을 확보하고 있습니다. [3] 메타데이터 사전 분류와 ECS 정규화 fields.* 기능을 이용해 수집 단계에서 로그 유형(mtype) 등을 태깅하여 중앙 시스템의 ECS(Elastic Common Schema) 기반 정규화를 위한 '분류 키' 역할을 합니다. ECS를 통해 모든 로그가 표준화되므로, 상관관계 분석 및 일관된 검색/시각화 효율이 극대화됩니다. *여기서 ECS란?* ECS는 보안 이벤트, 로그 등 모든 데이터를 공통된 필드 이름으로 정의하는 표준 스키마입니다. 서로 다른 로그 소스(예: Apache, Windows 이벤트)에서 수집된 데이터라도 ECS를 적용하면 동일한 표준 필드(source.ip, destination.port 등)를 갖게 되어 검색과 분석이 용이해집니다. 예시) cpu_pct 라는 ECS가 있다면 “cpu > 60” 검색 시 해당 ESC가 적용된 모든 로그를 찾아 로그의 수집,출처 및 내용을보여줄 수 있음 *SIEM에서의 이점 극대화* - 일관성 확보: 모든 로그가 ECS를 기반으로 표준화되므로, 분석가들은 매번 다른 필드 이름을 외울 필요 없이 표준화된 필드로 일관성 있게 검색 및 대시보드를 구축할 수 있습니다. - 분석 효율성 확보: 모든 로그가 공통 스키마를 따르기 때문에 상관관계 분석(Correlation)을 효율적으로 수행하여 보안 위협을 신속하고 정확하게 식별하는 데 큰 도움이 됩니다. 결론적으로, Filebeat의 fields.* 기능은 단순 태깅을 넘어, 데이터를 중앙에서 ECS로 효율적이고 정확하게 정규화하기 위한 SIEM 아키텍처의 필수적인 개발 포인트입니다. 다음 내용에서는 Filebeat의 구체적인 작동 방식을 정의하는 주요 설정들을 살펴보겠습니다. 3.Filebeat 주요 설정 Filebeat를 사용하기 위해서는 filebeat.yml 파일에 주요 설정을 정의해야 합니다. 이 파일에는 어떤 로그 파일을 모니터링할지, 어떤 포맷으로 데이터를 전송할지, 그리고 어떤 목적지로 보낼지에 대한 정보가 포함됩니다. [1] Filebeat 핵심 환경 설정 (Configuration) 로그 파일 수집 자체를 제외한 Filebeat의 실행 환경, 관리 유연성, 데이터 전송 메커니즘, 그리고 운영 안정성을 정의합니다. 이러한 설정은 SIEM 아키텍처의 견고함을 결정하는 핵심 요소입니다. (설정은 환경에 따라 변경 가능하며 아래는 예시로 설정한 부분을 설명 합니다.) [2] filebeat.inputs - 로그 파일 모니터링 정의 (수집) Filebeat가 어떤 로그 파일을 읽고 수집할지 정의하며, 수집된 로그에 메타데이터를 부여하는 핵심 부분입니다. 가장 일반적인 설정은 paths를 사용하여 로그 파일의 경로를 지정하는 것입니다. 위 설정은 /var/log/secure/ 파일을 읽도록 Filebeat에 지시합니다. fields를 사용하여 로그에 메타데이터를 추가할 수 있습니다. [3] Processors - 경량 데이터 가공 로그를 목적지로 전송하기 직전에 간단한 가공을 수행하여 중앙 시스템의 부하를 줄이고 필수 메타데이터를 추가할 수 있습니다. (메타데이터 추가 예시) (Drop 설정 예시, (ex)Linux audit log 수집 시 특정 경로의 로그 제외 설정) [4] Output - 데이터 전송 목적지 정의 로그 수집 및 가공을 마친 데이터를 전송할 최종 목적지를 정의합니다. 아래 예시에서는 Kafka를 목적지로 사용하여 대규모 로그 처리 및 부하 분산의 이점을 확보합니다. Filebeat의 filebeat.yml에 있는 다양한 설정 옵션들은 로그 수집의 안정성과 효율성을 결정하는 핵심적인 요소입니다. 이러한 주요 설정 기능들을 적절히 활용한다면, 대규모 환경에서도 안정적이고 효율적인 수집 체계를 성공적으로 구축할 수 있습니다. 이제 마지막으로, Zenius SIEM에서 이러한 Filebeat 설정 기능들이 실제로 어떻게 활용되었는지 살펴보겠습니다. 4. Zenius SIEM의 Filebeat 활용 (중앙 집중식 Filebeat 관리) Zenius SIEM 솔루션은 Filebeat의 기술적 장점을 실제 운영 환경에서 활용 할 수 있도록 YML 설정 편집 및 중앙 집중식 관리 기능을 제공합니다. 이는 대규모 에이전트 환경의 운영 부담을 획기적으로 줄여주며, 고객이 Filebeat의 세밀한 기술적 기능을 직접 제어하고 커스터마이징할 수 있게 합니다. - GUI 기반 YML 편집기 및 전용 설정 기능 Zenius SIEM은 운영자가 Filebeat의 설정을 세밀하게 제어하고 편리하게 관리할 수 있도록 GUI 기반 YML 편집기를 제공합니다. 운영자는 이 환경에서 Filebeat의 모든 YML 설정 (Inputs, Processors, Output 등)을 직접 수정하고 커스터마이징 할 수 있습니다. 특히 로그 수집 안정성에 필수적인 핵심 기능, 예를 들어, 멀티라인 패턴, negate, match, tail files, 동시 수집 파일 수, include lines, exclude lines은 별도의 전용 인터페이스를 통해 더욱 편리하게 설정할 수 있도록 지원하여, 복잡한 설정도 쉽게 관리할 수 있습니다. - 중앙 집중식 설정 수백 대의 서버에 설치된 Filebeat 에이전트의 설정을 관리하고 설정과 동시에 Filebeat의 동적 설정 기능 (filebeat.config.inputs 등)을 활용하여 에이전트 재시작 없이 즉시 변경 사항을 반영한다는 것입니다. 이는 서비스 중단 없이 운영 환경을 유지할 수 있게 해줍니다. - 에이전트 제어 및 상태 모니터링 분산된 로그 수집 환경을 통합적으로 관리하기 위해, Zenius SIEM은 에이전트 제어 및 상태 모니터링 기능을 제공합니다. 각 에이전트의 실행 상태 확인, 원격 재시작, 버전 관리 등의 제어 기능을 단일 시스템에서 제공하여, 운영자가 분산된 에이전트 환경을 쉽게 관리하고 장애 발생 시 신속하게 대응할 수 있도록 돕습니다. (수집 상태 모니터링 기능) (에이전트 관리 기능) 5. 마치며 지금까지 Logstash에서 Filebeat로의 전환 배경과 그 이유, Filebeat의 주요 기능과 설정, 그리고 Zenius SIEM 환경에서의 실제 활용 사례를 중심으로 살펴보았습니다. 이번 전환은 단순한 에이전트 교체를 넘어, 대규모 환경의 요구사항에 보다 적합한 아키텍처를 구축하기 위한 전략적인 선택이었습니다. Filebeat 도입을 통해 Zenius SIEM은 다음과 같은 측면에서 운영 기반을 한층 강화할 수 있었습니다: -경량화 및 안정성 향상 Go 언어 기반의 경량 구조로 서버 자원 사용을 최소화하고, 백프레셔(Backpressure) 및 레지스트리(Registry) 기능을 통해 로그 유실 없는 안정적인 수집 환경을 구현했습니다. -운영 유연성과 분석 효율성 확보 동적 설정 관리 기능을 통해 다양한 환경에서 유연하게 운영할 수 있었으며, ECS 필드 구조(fields.*)를 적극 활용해 로그 분석과 데이터 정규화를 보다 체계적으로 수행할 수 있게 되었습니다. Zenius SIEM은 이러한 Filebeat를 중앙 집중식 관리 시스템과 통합하여, 고객 환경에 최적화된 안정적이고 효율적인 로그 수집 서비스를 제공하고 있습니다. 지금까지 Logstash에서 Filebeat로의 전환을 통해 어떤 기술적 변화가 있었고, 그것이 실제 운영 환경에 어떻게 적용되었는지를 정리해 보았습니다. 변화하는 IT 환경 속에서 로그 수집 방식 또한 지속적으로 진화하고 있으며, 앞으로도 이에 대한 다양한 시도와 고민은 계속될 것입니다. 2025.10.21

기술이야기 SIEM을 도입해야 하는 5가지 이유 기술이야기 SIEM을 도입해야 하는 5가지 이유 IT 산업의 발전에 따라 다양한 장비와 시스템에서 매일 엄청난 양의 로그가 만들어지고 있습니다. 보안 장비, 서버, 미들웨어 등에서 생성되는 로그들이 대표적입니다. 이러한 로그들을 모두 취합하여 관리하게 되면, 1년 동안 저장되는 데이터는 테라바이트(TB) 단위의 디스크 용량이 필요한데요. 이는 인프라 관리에 있어 큰 부담이 될 수 있겠죠. 이때 통합 로그 관리 시스템인 SIEM(Security Information and Event Management)이 해결책이 될 수 있습니다. 그렇다면 SIEM은 무엇일까요? SIEM은 보안 정보 관리(SIM, Security Information Management)와 보안 이벤트 관리(SEM, Security Event Management)의 이점을 결합한 로그 관리 도구입니다. 즉 수집한 로그를 통해 정보를 분석하여 보안상 위협이 되는 이벤트를 실시간으로 감지하는 솔루션이라고 할 수 있죠. 그래서 이번 시간에는 SIEM이 왜 필요한지, 그리고 어떤 특장점이 있는지 알아보도록 하겠습니다. │SIEM, 왜 필요할까? SIEM이 필요한 가장 큰 이유는 빅데이터 처리와 보안적 측면에서 설명할 수 있습니다. 빅데이터 로그는 보안 사고가 발생한 근거를 찾아내는 중요한 증거 자료로 활용됩니다. 예를 들어 대형 온라인 쇼핑몰에서는 수많은 거래가 이루어지며 해커의 침입 시도가 발생할 수 있는데요. 이러한 기록이나 비정상적인 접근을 실시간으로 감지하여 문제가 생기기 전에 미리 대응할 수 있습니다. 이처럼 보안 위협에 효과적으로 대응하려면, 수집한 로그 데이터에 대한 체계적인 분석이 필요합니다. 관리되지 않은 로그는 IT 시스템의 장애나 문제 발생 시 원인을 찾아내기 어렵기 때문이죠. 따라서 로그 분석을 위해 로그를 정규화하여 저장하고, 효율적으로 관리하기 위한 로그 압축 보관 툴이 필요합니다. 또한 시스템 로그와 애플리케이션 로그 등 각 IT 인프라에서 발생하는 수많은 로그들은 빅데이터의 영역에 속합니다. 따라서 이를 중앙집중적으로 처리하여 효과적으로 분석하고 관리하는 도구가 필요하죠. │SIEM의 주요구성 SIEM은 네트워크 범위의 로그를 수집하고, 저장하며, 분석하는 기능을 갖고 있는데요. SIEM의 구성도 그림을 통해 좀 더 자세히 살펴보겠습니다. 로그 수집 SIEM은 서버, 네트워크, 보안장비, 클라우드 등 다양한 IT 인프라에서 발생하는 로그 데이터를 Syslog나 SNMP 등을 이용해 로그와 이벤트를 모아 Collector에 수집합니다. 이를 위해 직접 대상 장비에 Agent/Agentless 방식을 활용하거나, 클라우드의 경우 API 연동을 통해 다양한 방식으로 로그를 수집하죠. 실시간으로 발생되는 로그 수집은 물론, 방화벽/IDS/IPS 등 다양한 보안 장비에 대한 로그 데이터 수집이 필요합니다. 로그 저장 로그 수집뿐만 아니라 로그 저장 역시 중요합니다. 주로 ELK Stack을 활용하거나 수집 로그에 대한 분산 처리/저장 엔진을 활용하여, 로그를 저장하게 되는데요. 주로 관계형 데이터베이스에 자제적으로 저장하는 경우가 많습니다. 인덱싱 속도와 효율을 높이기 위해 ELK Stack을 활용하여, 로그를 저장하는 것 역시 좋은 대안이 될 수 있죠. 로그 분석 로그를 수집하고 저장한 다음 단계는 로그를 분석하는 것입니다. 이때 중요한 과정이 '파싱(Parsing)'입니다. 파싱은 비정형 로그 데이터를 쿼리가 가능한 구조화된 형태로 변환하는 과정입니다. 쉽게 말해, 파싱은 비정형 로그 데이터를 자르고 인덱스를 추가하여(key-value 형식으로) 보다 쉽게 식별할 수 있습니다. 이처럼 파싱을 통해 로그를 유형별로 분류하고, 정규화 및 표준화 작업을 거쳐, 분석에 필요한 정제된 로그를 추출합니다. 이렇나 정제된 로그는 분석 과정에서 매우 유용하게 사용됩니다. 시각화 및 리포팅 수집된 로그의 핵심 지표와 요약 이벤트를 설정하여, 시각화해서 볼 수 있습니다. 또한 사용자 정의 기반의 대시보드를 통해, 다양한 컴포넌트를 활용한 로그 데이터의 시각화와 리포팅 기능 역시 제공해야 합니다. │SIEM 도입 시 얻을 수 있는 5가지 앞에서도 SIEM에 대한 이점을 잠깐 언급했지만, 사실 이밖에도 여러 특장점이 있는데요. 그 중 대표적으로 5가지를 소개해 드릴게요. 첫째, 보안 수준의 강화 기존의 ESM(Enterprise Security Management)과는 다르게 SIEM은, 많은 양의 로그 데이터를 상관 분석하여 보안 위협을 찾아낼 수 있습니다. 기업 내 정보시스템의 보안 이벤트를 관리해서, 내부와 외부를 가리지 않고 기업 전반의 통합 보안 관리가 가능해지죠. 둘째, 통합 로그 관리 [그림] Zenius SIEM : 요약뷰 다양한 레거시 인프라와 클라우드에서 발생하는 로그를 하나의 플랫폼으로 일원화하여, 로그 관리가 훨씬 쉬워집니다. 장기간 데이터를 저장하고 모든 인프라에서 발생하는 로그를 파싱하여 관리하면, 관리 포인트를 한 곳으로 모을 수 있어 기업에서는 비용과 시간을 크게 절약할 수 있습니다. 셋째, 인덱싱을 통한 로그 검색 [그림] Zenius SIEM : 호스트 및 로그유형 트리 검색 기능 호스트 및 로그 유형 별로 검색어와 조건을 설정해서 로그를 검색할 수 있습니다. 특정 시간대나 특정 검색어를 통해, 대용량의 로그 중 일부만을 추출하여 분석할 수 있어 로그 분석이 훨씬 용이해집니다. 넷째, 보안 감시 설정 및 상관 분석 [그림] Zenius SIEM : 상관분석 감시설정 수집된 다양한 로그들의 상관관계를 분석하면 더 가치 있고 유의미한 이벤트를 확인할 수 있습니다. 예를 들어 방화벽 접속 로그에서 유해 IP나 등록되지 않은 IP로의 접근을 이벤트로 설정하면, 유해 IP를 실시간으로 확인할 수 있습니다. 또한 보안 위협 상황과 거래 이상 탐지 등 시나리오 기반으로 이벤트를 정의하고 자동으로 탐지할 수 있는 상관 분석 기능도 사용할 수 있습니다. 다섯째, 컴플라이언스 준수를 위한 측면 최근 몇 년간 기업들이 고객의 개인정보를 더 잘 보호하도록 법이 강화되었습니다. 특히 해킹과 개인정보 침해 사건이 늘어나면서 기업들이 보안을 철저히 해야 할 필요성이 커졌는데요. SIEM을 이용하면 이러한 보안 요구사항을 충족하는 데 큰 도움이 됩니다. KISA에서 권고하는 정보보호 및 개인정보보호 관리체계(ISMS-P)에서는 서버, 보안 시스템 등에 대한 사용자 접속 기록과 시스템 로그를 6개월 이상 저장하고, 이를 안전하게 관리해야 한다고 명시하고 있습니다. 또한 개인정보보호법과 정보통신망법에 따르면 로그는 1년 이상 보관해야 하고, 위조나 변조를 막기 위해 물리적인 서버에 저장하고 정기적으로 백업을 해야 하죠. 하지만 SIEM 시스템을 도입하면 이러한 법적 요구사항을 쉽게 준수할 수 있습니다. 따라서, 기업은 고객의 개인정보를 안전하게 보호하고, 침해사고 발생 시 빠르게 대응할 수 있습니다. 이번 시간에는 SIEM이 왜 중요하고, 어떤 특장점이 있는지 자세히 알아보았습니다. 요즘 기업에서는 보안 관련 요소들을 각각 관리하는 것이 쉽지 않습니다. 특히 규모가 큰 기업이나 보안이 중요한 공공기관의 경우에는 통합 관리 시스템이 꼭 필요하죠. 따라서, Zenius SIEM과 같은 솔루션을 통해 로그 관리를 안정적이고 효율적으로 해보는 건 어떨까요? ?더보기 Zenius SIEM으로 로그 관리하기 2024.07.29

기술이야기 [통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기 기술이야기 [통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기 Filebeat는 Elastic Stack에서 사용하는 경량(light-weight) 데이터 수집기로 logstash 대비 상대적으로 리소스(CPU와 RAM)를 상당히 적게 소모한다는 장점이 있습니다. 또, Filebeat는 간단한 필터 기능도 제공합니다. 하지만 말 그대로 간단한 필터 기능이라 한번에 대용량의 파일을 관리해야 하는 경우 호스트 서버에 부담이 갈 정도로 많은 리소스를 사용할 수 있습니다. 따라서 브레인즈컴퍼니가 운영하는 통합로그관리 에이전트는 호스트의 서버 환경에 따라 filebeat 에이전트의 설정 파일을 수정해서 안정성을 제공하고 있습니다. 본 내용은 Filebeat 리소스 점유율이 높을 때 트러블슈팅 관련 설정 수정사항입니다. 수정에 필요한 기본 파일 위치 linux : /etc/filebeat/filebeat.yml docker: /usr/share/filebeat/filebeat.yml filebeat 프로세스 메모리 확인하는 방법 top -d 1 | egrep "PID|filebeat" 수정에 앞서 filebeat의 메인 컴포넌트인 harvester의 개념을 간략하게 설명하겠습니다. 하나의 harvester는 하나의 파일을 읽어드립니다. harvester가 실행 중인 경우 파일을 한 줄씩 읽습니다. 각 파일 당 하나의 harvester가 실행됩니다. 상단의 이미지를 보면 filebeat의 컴포넌트인 input과 harvester가 보입니다. 또한 filebeat이 harvester를 관리하며 어느 파일을 읽을지 관리하는걸 알 수 있습니다. harvester가 실행 중인 경우 파일 설명자(File Descriptor) 열린 상태로 유지됩니다. 이는 파일이 삭제되거나 파일명이 변경된다 하더라도 파일을 계속 읽게 해줍니다. 하지만 파일 설명자는 harvester가 닫힐 때까지 디스크 공간을 예약합니다. 1. filebeat.inputs: 2. - type: filestream 3. id: my-filestream-id 4. paths: 5. - /var/log/system.log 6. - /var/log/wifi.log 7. - type: filestream 8. id: apache-filestream-id 9. paths: 10. - "/var/log/apache2/*" 11. fields: 12. apache: true 13. fields_under_root: true <filebeat에서 제공하는 input example> 1. scan_frequency 파일비트가 설정된 filebeat_inputs의 path에 있는 파일들의 갱신 여부를 체크하는 주기입니다. 너무 길게 설정하면 한번에 많은 파일들을 수집하게 됩니다. 반대로 너무 짧게 설정하면 스캔을 너무 잦게 해서 CPU점유율이 올라갑니다. 적당한 조절이 필요합니다. 기본값은 10초입니다. Scan_frequeny가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency 만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 2. backoff Backoff 옵션은 파일비트가 얼마나 더 적극적으로 크롤링 하는지 지정합니다. 기본값은 1인데 1일 경우 새 줄이 추가될 경우 1초마다 확인한다는 의미입니다. Backoff가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 → 파일 갱신 시 Backoff 시간 마다 다시 확인 3. max_procs 파일비트에서 동시에 사용 가능한 최대의 cpu코어의 숫자를 설정합니다. 예를 들어32 CPU코어 시스템에서 max_procs를 1로 설정한다면 cpu사용률은 3.2%(1/32)를 넘지 않습니다. max_procs 설정돼 있으면 harvester가 아무리 많이 생성돼도 cpu의 코어 수만큼 CPU를 점유합니다. 4. harvester_limit harvester의 수가 OS가 감당할 수 있는 파일 핸들러 개수를 초과할 때 사용합니다. 한 input마다 설정되므로 inputs이 5개 선언돼 있으면 해당 input 컴퍼넌트의 harvester 개수 최대치는 5개입니다. 기본값은 0인데, 0일 경우 harvester가 무제한으로 생성 가능합니다. 리소스 관리 최적화에도 유용한데 예를 들어, input1이 input2보다 파일 개수가 3배 많고 중요성이 높을 때 3배 높은 값을 설정하는 것이 좋습니다. 5. close_eof harvester에 의해 파일이 수집되고 있을 때, EOF(End of File)에 도달하는 즉시 파일을 닫습니다. 파일이 계속 갱신된다면 데이터가 유실될 수 있는 여지가 있습니다. [참조] https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html 2022.11.17

기술이야기 통합로그관리가 필요한 3가지 이유 기술이야기 통합로그관리가 필요한 3가지 이유 로그는 IT 인프라에서 발생하는 모든 상황들을 기록한 데이터입니다. 쉽게 말해 사용자가 어떤 루트로 사이트에 접속했고, 접속한 시점부터 어떤 행동을 취했는지가 모두 기록으로 남게 되는데, 이 기록들이 로그입니다. 로그는 IT 환경에서 가장 많이 발생하지만, 데이터 처리 기술이 발달하지 않았던 시기에는 처리 비용에 비해 가치가 낮은 데이터로 여겨졌습니다. 하지만 최근들어 IT 서비스와 인프라가 다양해지고 디지털 트랜스포메이션이 가속화되면서, 로그의 양이 기하급수적으로 증가하고 사물인터넷(IoT), 빅데이터 등과 같은 신기술이 발전하면서 그 효용성 또한 날로 증가하고 있습니다. 그렇다면, 이 로그는 실제로 어떻게 활용될까요? 개발 영역에서는 버그 혹은 크래시율 수집 및 상시 트래킹, 이슈 발생 후 롤백 및 대응, 특정 기능에 대한 사용성 진단에 활용됩니다. 마케팅 분야는 채널별 ROI 진단 및 비용 최적화, 배너/프로모션/이벤트 효과 측정, 유저 세그멘테이션 및 타게팅에 사용합니다. 기획 및 디자인 영역은 기능 개선을 위한 A/B 테스트, 유저 Journey 경로 분석을 통한 UX/UI 최적화 등에서 쓰이고 있습니다. 이처럼 여러 영역에서 다양하게 쓰이는 로그를 관리하지 않고 방치해두면 어떤 일이 발생할까요? 통합로그관리가 필요한 이유에 대해 알아보겠습니다. ----------------------------------------------- I. 보안 대응체계 구축 저장만 하고 관리되지 않은 로그는 IT 시스템의 장애나 문제 발생 시 그 원인을 찾아내기가 어렵습니다. 또, 로그 데이터의 중요 정보가 외부로 유출될 위험도 커집니다. 끊임없이 발생하는 보안 사고에 대비하기 위해 통합로그관리는 반드시 필요합니다. 관리된 로그는 장애나 사고 발생 시에 그 원인을 파악하고 빠른 대처를 위한 근거 데이터로 사용할 수 있으며, 보안 체계를 마련하는 데에도 활용가능 합니다. 기업들은 로그관리 제품을 사용해 사이버 침해위협을 예방 및 감시하고, 정기적인 로그분석을 통해 강력한 보안대응체계를 구축하고 있습니다. 통합로그관리 솔루션은 보안장비(Firewall, IDC, IPS 등)의 로그와 해킹, 악성코드 등 보안/침해 관련 로그를 지속적으로 분석해 예방 체계를 구축합니다. 또, 대용량 로그의 상관분석을 통해 보안위협을 탐지하고 이상징후를 모니터링하는 등 강력한 보안 대응체계를 구축할 수 있습니다. II. 컴플라이언스 준수 로그는 보안 사고가 발생했을 때 가장 기본적인 증거 및 모니터링 자료로 활용됩니다. 이에 따라 정부에서는 데이터 관리에 대해 각종 법률을 규정하고 있어, 공공기관을 비롯한 개인정보를 다루는 온라인 사업자 및 기업 등은 해당 법규를 준수해야 합니다. 안전한 데이터 이용을 위해 2018년에 발의된 '데이터 3법' 개정안은 2020년 1월 9일 국회 본회의를 통과했습니다. 데이터 3법은 개인정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등 3가지 법률을 통칭합니다. 로그 관리 관련 규제의 주요 내용은 다음과 같습니다. i. 개인정보보호를 위해 접근 권한 부여, 변경 또는 말소 기록을 3년 이상 보관해야 합니다. ii. 개인정보 취급자는 개인정보처리시스템의 접속기록을 월 1회 이상 점검해야 하고, 그 활동의 증거를 남기기 위해 시스템에 접속했다는 기록을 1년 이상 보관해야 합니다. iii. 정보통신서비스 제공자는 접근 권한 내역을 5년간 보관하고, 접속 기록의 위·변조 방지를 위해 반드시 백업 보관해야 합니다. III. 빅데이터 처리 플랫폼 IT 인프라 확대 및 기타 비정형 로그 유입에 따라 대용량 로그에 대한 관리가 요구되고 있습니다. 특히 수집된 로그를 실시간으로 분석∙판단해 IT 서비스의 안정적 운영을 도모해야 하는 수요가 증대되고 있는데요. 오늘날의 데이터는 기존 데이터에 비해 양이 매우 방대해 기존 방법이나 도구로는 관리가 어렵습니다. 따라서 빅데이터 기술을 기반으로 하는 대용량 통합 로그관리 솔루션은 이제 IT 운영을 위한 필수 솔루션으로 자리잡았습니다. ----------------------------------------------- 이처럼 기업은 보안위협 및 이상징후 대응/컴플라이언스 준수/대용량 로그 관리를 위해 통합로그관리 솔루션을 필수로 갖춰야합니다. 브레인즈컴퍼니의 통합로그관리 솔루션 '제니우스(Zenius) Logmanager'는 이기종 장비에서 발생되는 정형∙비정형 로그 데이터의 수집/분석/관리 등을 위한 빅데이터 플랫폼입니다. 제니우스 로그매니저가 어떻게 구성돼 있는지 살펴보겠습니다. 제니우스 로그매니저는 정형/반정형 또는 비정형 로그에 대한 실시간 수집 및 신속한 분석 기능을 제공하며, 이러한 정보들을 다양한 차트와 대시보드를 통해 직관적으로 가시화합니다. 특히 로그매니저는 독보적인 인덱싱 및 검색 속도를 제공하며 확장성, 편의성, 효율성, 호환성 등의 특장점을 보유한 제품입니다. 로그 이벤트 발생 시 즉각적인 알람을 통해 빠른 문제 해결과 높은 가용성을 확보하도록 지원합니다. 2022.11.10

블로그

기술이야기