Docker에서 여러 로그 스트림을 갖는 방법

세 가지 유형의 로그를 세 개의 별도 파일 (액세스 로그, 일반 응용 프로그램 로그 및 시스템 로그)에 기록하는 응용 프로그램이 있습니다. 이러한 로그의 형식과 목적은 매우 다릅니다. 또한 중앙 로그 시스템으로 별도로 보내는 별도의 로그 전달자가 있습니다.

이벤트 스트림으로서의 처리 로그 원칙을 기반으로 파일 사용에서 표준 출력으로의 이동을 고려하고 있습니다. 이 방법의 이점을 알고 있지만 이는 다른 형식의 로그를 병합 한 스트림을 가져 와서 중앙 시스템 (Kibana / Splunk)으로 보내기 전에 다시 분할해야 함을 의미합니다. / 등) 또는 내부에 있습니다.

이 상황에 어떻게 접근해야하는지에 대한 도구 나 권장 사항이 있는지 궁금합니다.

docker logging

— 슈 투피
소스

그만한 가치가 없다고 생각합니다. "원칙"때문에 로그 스트림을 병합 한 다음 분할하기가 더 어려운 이유는 무엇입니까? 파일이 좋습니다. 파일이 작동합니다. 이것은 과도하게 들린다. 모든 로그를 syslog에 다른 태그 등으로 파이프한다고 말할 수 있지만 팀의 누군가가 제안한 경우 말해야합니다 .. 실망합니다.

— Assaf Lavie

파일을 사용하면 다른 유형의 관리 악몽이 있기 때문에 특히 도커 컨테이너 내부에서 생성되는 경우가 있습니다. 지금은 표준 출력로 전환 단점처럼 보이는 들어 우리의 사용 사례에 대한 혜택을보다 중요한, 그러나 우리는 이미 우리의 파일 기반의 접근 방식에 문제가있는

— SztupY

나는 "악몽"에 대해 모른다. 나는 이것이 지금까지 수행 된 방식이라는 것을 알고 있으며,이 작업을 수행하는 데 도움이되는 많은 소프트웨어가 있습니다. 로그 파일이 회전하고 체크 포인트로 읽습니다. 파일은 이에 대한 훌륭한 추상화입니다. 나는 오래되고 친숙한 패턴에 대한 두려움 때문에 새로운 악몽을 파는 원리를 사지 않을 것입니다. 로그 레코드는 파일에 쓰거나 메모리에서 처리됩니다 (적어도 컨테이너에서 이동하는 한). 인 메모리 스트림 스플리터 및 병합을 통해 로그 파일의 안정성을 달성하십시오.

— Assaf Lavie

@AssafLavie 당신은 그것을 upvoted 할 수있는 답변으로 작성해야합니다. IMHO 그것은 완벽하게 유효한 관점입니다.

— Dan Cornilescu

나는 같은 질문으로 여기에왔다. 간단한 사실은 docker의 내장 로깅 기능이 stdout / stderr로 이동하는 모든 것에 의존하므로 로깅 드라이버와 주변에 구축 된 타사 도구의 생태계도 마찬가지입니다. 나는 모든 로그를 호스트 볼륨으로 덤프하려고하지만 컨테이너를 k8s 또는 openshift 또는 gke 또는 다른 것으로 이동할 때 도커를 따라 가면 계속 돌아가서 관리해야한다는 것을 알고 있습니다. stdout 접근 방식이 훨씬 부드럽습니다. 한편 나는이 합법적 인 질문에 대한 답을 계속 찾을 것입니다

— Rhubarb

답변:

나는 여전히 병합 / 분할 접근법을 찾고 있지만 Kubernetes 문서에서 권장하는이 접근법은 올바른 해결책처럼 보입니다 . 각 개별 로그마다 사이드카 컨테이너를 사용하십시오 .

"사이드카"는 다른 도커 컨테이너와 함께 어떤 방식 으로든 사용하는 도커 컨테이너입니다. 이 경우, 세 개의 로그 각각에 대해 로그를 스캔하거나 테일링하고 stdout으로 출력하는 별도의 컨테이너가 있습니다.

이렇게하면 각 로그 사이드카 컨테이너에 자체 stdout의 자체 도커 로그가 있습니다. 이와 같이 분리하면 표준 도커 및 kubernetes 등을 사용하여 분리 또는 집계 할 수 있습니다. Kubernetes 페이지의 내용은 다음과 같습니다.

이 방법을 사용하면 응용 프로그램의 여러 부분에서 여러 로그 스트림을 분리 할 수 있으며이 중 일부는 stdout 또는 stderr에 대한 쓰기 지원이 부족할 수 있습니다. 로그 리디렉션의 논리는 최소이므로 큰 오버 헤드가 거의 없습니다. 또한 stdout 및 stderr이 kubelet에서 처리되므로 kubectl 로그와 같은 내장 도구를 사용할 수 있습니다.

"별도의 로그 스트림"은 docker documentation에 설명 된 docker 가 다른 컨테이너의 로그에 적용하는 내장 태그에서 비롯됩니다 .

태그 로그 옵션은 컨테이너의 로그 메시지를 식별하는 태그의 형식을 지정하는 방법을 지정합니다. 기본적으로 시스템은 컨테이너 ID의 처음 12자를 사용합니다. 이 동작을 무시하려면 태그 옵션을 지정하십시오.

— 대황
소스

이 로그-사이드카 컨테이너 접근 방식의 단점은 "CPU 및 메모리 사용량이 낮더라도 로그를 파일에 기록한 다음 stdout으로 스트리밍하면 디스크 사용량을 두 배로 늘릴 수 있다는 점"이라고 언급 할 가치가 있습니다. 실제로이 접근법을 시도하는 사람이 있는지 궁금합니다.

— yusong

나중에 그들을 분리하기 위해 하나의 스트림으로 병합한다는 아이디어는 고통스러워 들립니다. 나는 이것을 스스로 할 이유가 없었지만, 여기에서 내가 시작할 것입니다 :

도커 컨테이너를 실행할 때 호스트에서 로그를 쉽게 보거나 전달할 수 있도록 볼륨을 만듭니다.
remote_syslog2 와 같은 것을 사용 하여 로그를 로그 수집기에 전달하십시오.

호스트에서도 약간의 설정을 수행하는 것이 우아하지는 않지만 느낌이 들지 만, 플레이 북을 실행하고 상자에 배포하는 동안 플레이 북을 실행할 수있는 것과 같은 것을 사용하는 경우 너무 길어서는 안됩니다 나쁜.

— Bradym
소스

이 솔루션은 명명 된 파이프와 결합 할 수 있지만 명명 된 파이프의 유일한 문제점은 현재 모든 시스템에서 작동하지 않는다는 것입니다. Mac

— Jens