# EFK

raiders032

EFK 구축에 앞서 먼저 로깅을 생성하는 HTTP API 애플리케이션을 만들어 보자. 실제로 진행 중인 프로젝트에서 클라이언트가 HTTP API를 호출했을 때 INTERNAL SERVER ERROR가 발생한 적이 있다. 원인을 파악하기 위해서 해당 API 요청과 관련된 로그만 조회해서 보고 싶었지만 쿠버네티스에서 기본적으로 제공하는 로깅 기능으로는 관련된 로그만 찾는 것이 매우 불편했다. 따라서 요청마다 고유한 ID를 부여하고 모든 로그 포맷을 변경하여 모든 로그에 요청 ID를 출력하도록 변경하면 해당 요청과 관련된 로그를 검색하기 쉬울 것이라고 생각했다. 따라서 이번 데모 애플리케이션을 통해 로그 포맷에 요청 ID를 추가하는 로그 포맷을 작성해 본다. 요청 당 유니크한 식별자를 할당하는 일은 Servl

raiders032

1 Logging Architecture EFK를 적용하기에 앞서 먼저 kubernetes의 cluster-level logging 아키텍처를 이해하는 것이 중요하다. 우리가 EFK를 사용하는 이유는 컨테이너 런타임에서 제공하는 기본 기능으로 로그를 저장하고 분석 및 조회하기가 어렵기 때문이다. 예를 들어 컨테이너가 죽거나, 파드가 노드에서 퇴출 당하거나, 노드가 죽었을 경우에도 애플리케이션의 로그를 보고 싶지만 컨테이너 런타임에서 제공하는 기본 기능으로 이러한 요구사항을 완벽히 충족시키긴 어렵다. 컨테이너의 로그는 현재 실행 중인 컨테이너와 이전 컨테이너의 로그만 보관하고 있기 때문에 예전 컨테이너의 로그를 별도의 장치 없이 볼 수 없다. 또한 쿠버네티스를 사용하면 애플리케이션 파드의 복제본 수

ethan_traillog

일하다 보니 부서 내 어디선가 EFK를 쓴다는 말을 들었다. 용어가 AWS의 컴포넌트들이랑 비슷해서 AWS에 있는 하나의 컴포넌트 겠거니 했는데 로그수집 및 모니터링에 유용한 툴 이라고 한다. 쿠버네티스 환경에 MSA로 띄워져 있는 각각의 역할을 하는 서비스들,,, 지금은 10개 내외로 띄워져 있지만 서비스가 확장되고 여러 기능들이 생길때마다 늘어나는 파드들이 생길 것이다. 지금은 기능이 많이 없어서 어떤 서비스에서 장애가 나면 대충 어떤 파드에서 에러가 낫겟거니 유추가 가능하지만 1년뒤에도 내가 이 파드가 어떤 서비스를 제공하고 있는지 다 알지는 못할 것 같다. 임시로 모든파드에 있는 로그들을 마스터서버 디렉토리에 마운트 시켜놓긴 했지만 로그들을 일일이 보려면 여전히 불편하긴 하다. 그래서 EFK란가 뭔가를 구축해보려 한다. 필자는 아직도 저게 다 뭔지 무슨 기능을 하는지는 아직도 모른다. 지금 쓰면서 알아가보자 우선 EFK는 ElasticSearch + Fluentd +

sosimina

0. 로깅이란 정보를 제공하는 일련의 기록인 로그(log)를 생성하도록 시스템을 작성하는 활동. 프린트 줄 넣기(printlning)는 간단한, 보통은 일시적인, 로그를 생성하기만 한다. 시스템 설계자들은 시스템의 복잡성 때문에 로그를 이해하고 사용해야 한다. 로그가 제공하는 정보의 양은, 이상적으로는 프로그램이 실행되는 중에도, 설정 가능해야한다. 일반적인 로그 기록의 이점 로그는 재현하기 힘든 버그에 대한 유용한 정보를 제공할 수 있다. 로그는 성능에 관한 통계와 정보를 제공할 수 있다. 설정이 가능할 때, 로그는 예기치 못한 특정 문제들을 디버그하기 위해, 그 문제들을 처리하도록 코드를 수정하여 다시 적용(deploy)하지 않아도, 일반적인 정보를 갈무리할 수 있게 한다. > 로그 라이브러리 종류 java.util.logging Apache Commons logging Log4j Logback

squarebird

배경 최근 Cloud Engineer에서 DevOps Engineer로 직무변경을 하며 이직에 성공했습니다. 인수인계를 받고 클라우드 구성을 파악한 뒤 가장 처음으로 맡게된 업무가 기존의 로그수집 환경을 개선하는 것이었습니다. 현재 직장에서는 서비스의 로그 수집을 별도 EC2에 설치한 LogStash에서 Kubernetes Cluster에 Container로 배포된 Fluentd 기반의 로그수집 방식으로 전환하는 작업을 진행하고 있습니다. 현재 환경은 Service -> LogStash ->Confluent(kafka)-> AWS OpenSearch(Elastic Search)로 로그를 수집하고 있는데, 이를 Service -> Fluentd -> AWS OpenSearch(Elastic Search) 형태로 전환하는 것입니다. 현재 LogStash가 설치된 EC2와 Confluent Kafka로 이어지는 구성에서

ur2e

? logstash_pop.conf 작성 logstash 실행 키바나에서 인덱스 추가 💻 opensearch 자습서 https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/search-example.html 샘플 데이터 인덱싱 도메인에 대한 OpenSearch Dashboards URL으로 이동합니다. OpenSearch Service 콘솔의 도메인 대시보드에서 URL을 찾을 수 있습니다. 이름 암호로 로그인 ![](https

seokbin

1. 배경 쿠버네티스 클러스터를 운영하며 안정적인 관리를 위해 로그 시스템을 구축하기 위해 EFK Stack을 테스트 한 내용을 기록합니다. 멀티 클러스터 환경에서 발생하는 로그를 한 개의 키바나에서 볼 수 있도록 설치합니다. 기본 흐름은 다음과 같습니다. Fluent-bit 는 Daemonset으로 생성되어 모든 서버에 생성되어 로그를 전송합니다. Fluentd는 로그를 수집해 적절히 파싱해 ElasticSearch로 보냅니다. ElastciSearch에서 수집한 로그를 Kibana에서 시각화 합니다. Fluent-bit 없이 Fluentd만 설치하여 로그를 보낼 수 있지만 규모가 큰 클러스터에서 Fluentd의 작업량이 많아져 부하가 생기기 때문에 로그를 전송하는 역할만하는 Flu

repush

Kubernetes설치 HELM 설치 Prometheus Monitoring >https://soundcloud.com/ 프로메테우스가 원래 사용되었던 서비스가 soundcloud였는데 오픈소스로 공개했다고 한다. 쿠버네티스만을 위한 구성은 아니고 다양한 환경에서 사용될 수 있다. CPU, Memoty, Network IO, Disk IO Heapster + InfluxDB: X metrics-server: DB 없음, 실시간 CPU, Memory Prometheus >https://prometheus.io/docs/introducti

seho100

Elasticsearch란? >Elasticsearch는 Apache Lucene(아파치 루씬) 기반의 Java 오픈소스 분산 검색 엔진입니다. Apache Lucene은 검색 라이브러리인데 이를 단독으로 사용할 수 있게 되었으며, 방대한 양의 데이터를 신속하게, 거의 실시간으로 저장, 검색, 분석할 수 있습니다. Elastic Searchsms 검색을 위해 단독으로 사용되기도 하며, ELK(Elasticsearch + Logstatsh + Kibana) 또는 EFK(Elasticsearch + Fluentd + Kibana) 스택으로 사용되기도 합니다. EFK Stack Elasticsearch Fluentd로 받은 데이터를 검색 및 집계를 하여 필요한 관심 있는 정보를 획득 Fluentd 다양한 데이터 소스(HTTP, TCP)등으로부터 데이터를 받아 원하는 형태로 가공한 후 다양한 목적지(Elasticsearch,