좌충우돌 개발 블로그

기존에는 서버에 직접 로그스태시를 설치하여 카프카와 ES를 연동했다.

그래서 메모리 문제가 발생할 때 설정을 수정하고 재시작했었고 서버에 문제가 생기는 경우 로그 수집이 중단됐었다.

서버를 더 늘리면 되는데 그때마다 증설이 어려워 kubernetes를 이용해보기로 했다.

helm install -f values.yaml logstash elastic/logstash
helm upgrade -f values.yaml logstash elastic/logstash

기존에는 서버별로 수집하는 토픽을 설정했다면 쿠버네티스로 이전하면서 필터가 비슷한 경우 아니면 전부 분리할 수 있었다.

replica 수를 설정하여 파티션 만큼 로그스태시를 올릴 수 있어 속도 개선이나 장애 상황에 유연하게 대응할 수 있었다.

또한 파드별로 리소스 제한을 하여 특정 토픽에 메모리 문제가 생겨도 해당 파드만 재시작되어 다른 토픽 수집이 안됐던 것을 방지할 수 있었다.

참고 문헌

1. https://github.com/elastic/helm-charts/tree/main/logstash

젠킨스 자체를 쿠버네티스 환경에 helm을 이용하면 쉽게 구축할 수 있었다.

하지만 기존에 사용하던 플러그인들과 각종 환경들을 그대로 가져오는 것이 문제였다.

플러그인의 경우 사용 중인지 아닌지 판별이 어려웠다.

plugins.jenkins.io/{plugin-name}에 있는 플러인 이름을 확인한 다음 values.yaml에서 installPlugins에 작성하여 배포했다.

https://github.com/jenkinsci/helm-charts/blob/0572830631b4a8bef26cff0286a99b9747686be1/charts/jenkins/values.yaml#L241-L245

작업들의 경우 ThinBackup을 이용하여 백업한 뒤 tar로 묶어서 scp로 다운로드했다.

그리고 백업 파일을 젠킨스가 올라간 파드에 kubectl cp 라는 명령어로 업로드하여 쉽게 작업들을 이전할 수 있었다.

Go 언어를 사용하여 플러그인을 사용하면 go를 쉽게 설치하여 사용할 수 있었다.

하지만 ansible 같은 설치를 별도로 해주어야 하는 프로그램들이 있어 젠킨스에서 제공하는 도커 이미지로는 할 수 없었다.

그리고 젠킨스 파드 내에서 프로그램 설치를 시도했지만 권한을 막아두었기에 에이전트를 띄워서 작업할 수 있는지 해보았다.

테스트를 해보니 작업을 수행할 때마다 파드를 띄우고 끝나면 종료하는 형식이었다.

python이 설치된 이미지를 활용할 수는 있겠지만 매번 ansible을 설치하거나 ansible이 설치된 커스텀 이미지를 만들어야 했다.

이런 것들이 번거롭기에 커스텀 젠킨스 이미지를 생성하여 사용하였다.

FROM jenkins/jenkins:2.375.2-lts-jdk11

USER root

RUN apt-get update && apt-get install -y build-essential python3 python3-pip
RUN pip install ansible

USER jenkins

참고 문헌

https://github.com/jenkinsci/helm-charts/tree/main/charts/jenkins

https://plugins.jenkins.io/thinBackup/

https://hub.docker.com/r/jenkins/jenkins

배열에 넣은 로그를 개별 로그처럼 나누어서 볼 수 있도록 split 함수를 이용했었는데 메모리 문제(OOM)가 발생했었다.

그래서 해당 기능을 하는 것을 별도로 만들어서 사용하고 있었는데 다시 문제가 생겼다.

우선은 logstash.yml에서 pipeline.workers, pipeline.batch.size, pipeline.batch.delay 등을 조절하여 급한 불을 껐다.

그리고 GC도 CMS에서 G1으로 변경하여 어느 정도는 안정적으로 구동되는 걸 확인할 수 있었다.

그럼에도 메모리 사용량이 많아서 다시 검색해보니 split 함수 자체에 문제가 있었던 것을 알 수 있었다.

def register(params)
    @field = params['field']
    @target = params['target']
end

def filter(event)
    data = event.get(@field)
    event.remove(@field)
    a = []
    data.each { |x|
        e = event.clone
        e.set(@target, x)
        a << e
    }
    a
end

코드를 보면 배열에 해당하는 부분을 가져온 다음에 제거하지만 이를 JSON으로 파싱한 로그에 다시 할당하는데

이 로그에 최초 로그가 있어 이것이 배열의 수만큼 복사되어 발생한 문제였다.

JSON으로 파싱한 다음 원본 로그의 필드를 제거하고 split이 동작하도록 하여 메모리 이슈는 어느 정도 해소했다.

참고 문헌

https://discuss.elastic.co/t/how-to-split-into-multiple-events-dynamically-for-a-given-json-tried-from-various-question-in-forums/167745/9

https://github.com/logstash-plugins/logstash-filter-split/blob/main/lib/logstash/filters/split.rb#L89

기존에 사용 중이던 ElasticSearch 서버가 근래에 자주 다운됐었다.

그래서 새로운 방식으로 로그를 수집해보려고 했었다.

Hadoop에 JSON으로 저장해서 Zeppelin에서 보려고 하니 불편 사항이 많았다.

다른 것들이 더 있을까 하고 찾아봤지만 ElasticSearch와 Kibana 만큼 로그를 검색하고 조회하는 도구가 없었다.

결국 두 개를 사용하기로 하고 Logstash 만 다른 걸 이용해보려고 하다가 Apache Flume이 생각나서 적용해보려고 했다.

구조는 Source -> Channel -> Sink 로 돼있고 설정이 어려워 보이지 않아 시도해보았다.

하지만 java.lang.NoClassDefFoundError: org/elasticsearch/common/io/BytesStream

에러가 발생하면서 종료됐다.

찾아보니 ElasticSearch jar 파일을 별도로 추가해야한다고 해서 추가했는데도 되지 않았다.

무엇인가 이상하여 찾아보니 Flume에서 제공하는 라이브러리에서

org.elasticsearch.common.xcontent.XContentFactory.jsonBuilder를 임포트하여 사용하는데

해당 패키지는 ElasticSearch 6.x 이상에서는 없어진 패키지였다.

Flume을 굳이 사용하고자 한다면 sink 를 직접 만들어서 사용해야 해서 Logstash로 선회했다.

(물론 fluentd를 사용해도 되지만 다른 곳에서 사용하여 다른 것을 써보고 싶었다)

참고 문헌

1. https://github.com/apache/flume/blob/trunk/flume-ng-sinks/flume-ng-elasticsearch-sink/src/main/java/org/apache/flume/sink/elasticsearch/ElasticSearchLogStashEventSerializer.java
2. https://github.com/elastic/elasticsearch/tree/5.6/core/src/main/java/org/elasticsearch/common/xcontent