#filebeat

새로 올린 배치 서버는 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