#logmonitoring

[mindbridgeconsulting]

Elastic search for Application Performance Monitoring

[leeilly-blog1]

filebeat & kafka

새로 올린 배치 서버는 aws ec2 인스턴스에 올라가 있고, 그 인스턴스에 docker로 filebeat을 띄어놓았다. 그리고 기존 상용 서버에는 docker가 아닌, 그냥 데몬으로 filebeat을 실행해놓았다. 

일단 docker로 올린 filebeat은 임의로 종료되는 케이스가 아직까지 없다. 반면 데몬으로 돌고 있던 filebeat은, 퇴근 전 실행중인것을 확인하고 다음날 출근해서 확인하면 죽어있다. 

-> 이것도 확인해봐야 하는 문제 

그리고, 다시 filebeat을 띄우면, 그 동안 수확하지 못하고 쌓여있던 로그들을 긁어서 조금 많은 양의 데이터를 kafka로 보내기 때문인지, filebeat은 아래와 같은 로그 메시지를 찍는다.

2019-11-21T10:32:37.813+0900 INFO kafka/log.go:53 producer/broker/1 maximum request accumulated, waiting for space

정확히 어떤 의미일까? 구글링 구글링.

일단, 에러는 아님.

This is not an exception but an info message. kafka client's buffer is full, and it's probably waiting for some ACKs before sending more messages.

filebeat의 송신 버퍼가 full이라는 뜻.

The message is logged because the send buffers are full. The kafka client is waiting for ACK from kafka for an older batch in order to flush it's buffers. So network of kafka itself might create some backpressure. All in all data will not be lost, as filebeat will retry until there is enough space. 

내 설정을 확인해 보자.

1. producer인, filebeat 설정.

output.kafka:    ...    required_acks: 1    compression: gzip    max_message_bytes: 1000000

2. kafka broker 설정. (server.properties)

num.network.threads=3

# The number of threads that the server uses for processing requests, which may include disk I/O num.io.threads=8

# The send buffer (SO_SNDBUF) used by the socket server socket.send.buffer.bytes=102400

# The receive buffer (SO_RCVBUF) used by the socket server socket.receive.buffer.bytes=102400

# The maximum size of a request that the socket server will accept (protection against OOM) socket.request.max.bytes=104857600

어떻게 조정해야할까?

[leeilly-blog1]

elastic stack 로그 모니터링 시스템 구성

동기?

지금 회사에서는 어플리케이션 로그를 확인하려면, 서버에 들어가서 vi로 로그 파일을 열어서 확인해야한다. 개발 장비나, 백오피스는 인스턴스 하나로 서비스되고 있어서 비교적 로그 확인이 쉽..다. 그러나 상용 서비스는 서버도 여러 대, 인스턴스도 여러개로 운영되고 있어서 로그를 확인하기가 쉽다고 할 수 없다. 그리고 보통 로그를 확인하는 경우는, 에러가 발생하고 있거나 장애 원인에 대해 확인하기 위한 다소 급박한 상황이다 ^^ 여러 장비, 여러 서비스의 로그를 한곳에서 확인할 수 있는 대시보드를 만들고 싶었다. 

대부분의 스타���업에서 로그 모니터링 시스템으로 ELK를 사용한다. ELK로 대충 어떻게 구성한다라는 것은 여기저기서 주워들어서 알고 있었지만 직접 구성해본적은 이번이 처음이라 디테일한 부분에서 난관이 있었다. 

 작업한 내용들을 정리하려고 한다.

Elastic Stack

ELK라고 부르는 (E elasticsearch L logstash K kibana) 와  서버에 쌓이는 로그를 전송해줄 Filebeat 까지를 Elastic stack 으로 본다. 그리고 여기저기 서버에서 로그가 많이 몰릴것을 예상해서, 중간 버퍼로 Kafka를 사용한다.

(일반적인) 구성

Filebeat

로그 데이터를 전달하고 중앙화하기 위한 경량의 Producer.

서버에 에이전트로 설치되는 Filebeat는 지정한 로그 파일 또는 위치를 모니터링하고 로그 이벤트를 수집한 다음 인덱싱을 위해 Elasticsearch 또는 Logstash로 전달한다.

Filebeat를 시작하면 설정에서 지정한 로그데이터를 바라보는 하나이상의 inputs을 가진다. 지정한 로그 파일에서 이벤트(데이터발생)가 발생할 때마다 Filebeat는 데이터 수확기(harvester)를 시작한다. 하나의 로그 파일을 바라보는 각 havester는 새 로그 데이터를 읽고 libbeat에 보낸다. 그리고 libbeat는 이벤트를 집계하고 집계된 데이터를 Filebeat 설정에 구성된 출력으로 데이터를 보낸다.

Kafka

로그 모니터링 시스템에서, 생산자는 filebeat

로그 모니터링 시스템에서 소비자는 logstash 

Kafka에 대한 포스트

https://leeilly.tumblr.com/post/189185876586/kafka-%EC%B9%B4%ED%94%84%EC%B9%B4

Elasticsearch

데이터를 저장하고 분석하는 엔진 역할을 수행하는 핵심 모듈

Kibana

ElasticSearch에 있는 데이터를 시각화 할 수 있는 GUI 분석 툴