logstash를 사용해 데이터를 수집하는 동안 시간 보정한 옵션을 정리합니다.
filter {
date {
match => ["date","yyyy-MM-dd'T'HH:mm:ss.SSS"]
target => "date_gmt"
timezone => 'Asia/Seoul'
}
}
ruby {
code => "event.set('ymd', event.get('[@timestamp]').time.localtime.strftime('%y-%m-%d'))"
}
%{ymd}
logstash 내부에서 사용하는 시간이 물리 서버의 타임존을 그대로 사용하지 않고 gmt시간을 그대로 사용하는 것으로 보여 타임존 보정을 했습니다
filter에서 타임존을 아시아/서울로 보정을 하고
ruby문법을 통해 get('[@timestamp]')를 해서 현재 시간을 얻오내고 그 값을 ymd로 처리했습니다. ymd로 처리된 변수는 이후에 %{ymd}를 사용해서 사용할 수 있습니다.
logstash의 편라함 때문에 다양하게 사용하게 되는데요. 파일 데이터를 hdfs에 올리거나 elasticsearch에 보내거나 다른 kafka로 보내는 방법으로 사용합니다. 보통은 데이터 원본에 시간 정보가 있긴 한데 logstash 자체 적으로도 시간 값을 추가해서 넘기게 됩니다. elasticsearch에 index 된 데이터를 볼 때 이 징보로 시간순으로 볼 때가 있습니다.
logstash를 여러 프로젝트에서 사용해 봤는데 안정성 문제를 본적이 없습니다. 매번 안정 적으로 동작했고 성능 이슈도 네트워크 문제가 있었지 logstash자체 문제가 있었던 적은 없습니다. 사용할 때마다 고민되는 것을 수집할 데이터 종류마다 logstash를 띄울 것인지 통합해서 하나로 띄울 것인지에 대한 고민을 하게 됩니다. 너무 여러 개 띄워두면 관리하기가 어려웠고 하나로 모으면 데이터 하나 수정을 위해 모두 종료해야 하는 단점이 있었습니다. 제 형향은 최대한 구분 지어 유지하는 건데 또 다른 필요한 환경이 생긴다면 하나로 모아서 실행할 수도 있을 거 같습니다.
파일 read인 경우 offset정보를 자체 유지해서 종료했다 실행 해도 이전 offset 정보를 읽어서 처리합니다. 파일을 읽어 드리는 데 사용하고 있다면 큰 걱정 없이 종료해도 됩니다.
비슷한 수집 용도로 flume가 있는데 java 코드로 source, channer, sink를 직접 개발할 수 있게 되어 있어서 커스텀한 수집 구조를 만들기 위해 유용한 오픈소스 입니다. 예전 프로젝트 때 파일을 커스텀하게 읽고 kafka로 전송하는 용도로 사용 했습니다. 파일을 순서대로 읽고 모두 읽었다는 처리를 하기위한 커스텀이었고 kafka로 전송 후 원래 대로 복구할 수 있도록 하는데 사용되었습니다.
