Kubernetes에 로그인: 로그를 수집, 저장, 구문 분석 및 처리하는 방법

Docker 및 Kubernetes에서 로깅의 기본 사항을 살펴본 다음 프로덕션에서 안전하게 사용할 수 있는 두 가지 도구인 Grafana Loki 및 EFK 스택(Elasticsearch + Fluent Bit + Kibana)을 살펴보겠습니다.

기사의 소재는 짜낸 것입니다. 학교 "Slurm"의 공개 강의. 욕망이 있고 제작이 필요한 경우 더 나아가 전체 교육을받을 수 있습니다. 과정에 등록하십시오 Kubernetes의 모니터링 및 로깅 인프라.

도커 로깅

Kubernetes 수준에서 애플리케이션은 포드에서 실행되지만 더 낮은 수준에서는 여전히 Docker에서 정상적으로 실행됩니다. 따라서 컨테이너에서 로그를 수집하는 방식으로 로깅을 구성해야 합니다. 컨테이너는 Docker에 의해 시작되므로 Docker 수준에서 로깅이 배열되는 방식을 파악해야 합니다.

모든 독자가 알고 있기를 바랍니다. 응용 프로그램 로그는 컨테이너 내부가 아닌 stdout/stderr에 기록되어야 합니다. 로그는 Docker Daemon에 의해 집계되며 stdout/stderr로 전송되는 로그와 정확히 작동합니다. 또한 컨테이너 내부에 로그를 작성하는 것은 문제가 많습니다. 로그가 늘어나면 컨테이너가 팽창하고(컨테이너에 Logrotate가 없을 가능성이 높기 때문에) Docker Daemon은 이 로그를 인식하지 못합니다.

Docker에는 컨테이너 로깅을 수집하기 위한 여러 로깅 드라이버 또는 플러그인이 있습니다. 무료 Docker Community Edition(CE)에는 상용 Docker Enterprise Edition(EE)보다 로그 드라이버 수가 적습니다.

저는 실제로 Docker EE를 사용한 적이 없습니다. Southbridge에서는 오픈 소스 솔루션을 고수하려고 노력하며 고객은 Docker EE의 추가 기능 대부분을 필요로 하지 않습니다.

Docker CE의 로그 드라이버:

지방의 - 내부 Docker Daemon 파일에 로그 쓰기
json 파일 - 각 컨테이너의 폴더에 json-log 생성
저널링 - journald에 로그를 보냅니다.

Docker 로깅 설정은 daemon.json 파일에 있습니다.

"log-driver" 필드는 플러그인을 지정하고 "log-opts" 필드는 해당 설정을 지정합니다. 위의 예에서 "json-file" 플러그인이 지정되고 로그 크기 제한은 "max-size": "10m"입니다. 파일 수 제한(회전 설정) — "max-file": "3"; 뿐만 아니라 로그에 첨부될 값.

일부 로그 드라이버 설정은 명령줄 유틸리티를 통해 설정할 수 있습니다. 별도의 컨테이너를 다른 로그 드라이버로 실행해야 하는 경우에 유용합니다.

Docker에서 로깅 체계는 다음과 같습니다.

체계 작동 방식: json-file과 같은 로그 드라이버는 파일을 생성합니다. 로그 수집기(Rsyslog, Fluentd, Logagent 및 기타)는 이러한 파일을 수집하여 Elastic, Sematext 또는 기타 저장소의 저장소로 전송합니다.

Kubernetes 로그인 기능

단순화된 Kubernetes의 로깅 체계는 다음과 같습니다. Pod가 있고 컨테이너가 실행 중이며 컨테이너는 로그를 stdout/stderr로 보냅니다. 그런 다음 Docker는 파일을 생성하고 로그를 작성한 다음 회전할 수 있습니다.

Kubernetes 로그인 기능을 고려하십시오.

배포 간 로그 저장. 이는 올바른 로깅 설정을 위한 전제 조건입니다. 배포 사이에 로그를 저장하지 않으면 새 버전의 애플리케이션이 출시될 때 이전 버전의 로그를 덮어쓰고 컨테이너를 다시 로드해도 로그가 손실됩니다. Kubernetes에는 --previous 키가 있습니다. 이 키를 사용하면 마지막 포드가 다시 시작되기 전에 애플리케이션 로그를 볼 수 있지만 깊이는 볼 수 없습니다.

모든 인스턴스의 로그 집계. 마이크로서비스가 클라우드에서 호스팅되는 경우 클라우드 공급자가 시스템 제어를 담당합니다. 마이크로서비스가 자체 하드웨어에 있는 경우 컨테이너의 로그 외에도 시스템 로그도 수집해야 합니다.

이전에는 시스템과 마이크로서비스 모두에서 로그를 수집하는 편리한 도구가 없었습니다. 일반적으로 시스템 로그는 하나의 도구(예: Rsyslog)로 수집하고, Docker 로그는 다른 도구(예: journald로 구성된 Docker 로그 드라이버를 사용하는 journal-bit)로 수집했습니다. 저희는 journal-bit를 사용하여 컨테이너(Docker 로그 드라이버에서 로그를 journald에 기록하도록 지정)와 시스템(docker-bit) 모두에서 로그를 수집하려고 시도했습니다. CentOS Windows 7에는 이미 systemd와 journald가 있습니다. 이 방법은 작동하지만 이상적이지는 않습니다. 로그가 많으면 journal-bit이 느려지고 메시지가 손실될 수 있습니다.

실험은 계속되었고, 다른 방법이 발견되었다. CentOS 7가지 주요 시스템 로그(메시지, 감사, 보안)는 var log에 파일로 중복 저장됩니다. Docker는 로그를 JSON 파일로 저장하도록 구성할 수도 있습니다. 따라서 이러한 파일들은 다음과 같습니다. CentOS Windows 7과 Docker는 함께 빌드할 수 있습니다.

시간이 지남에 따라 ELK 스택 솔루션이 대중화되었습니다. Elasticsearch, Logstash 및 Kibana와 같은 여러 도구의 조합입니다.

Elasticsearch는 컨테이너의 로그를 저장하고, Logstash는 인스턴스의 로그를 수집하며, Kibana는 수신된 로그를 처리하고 이를 기반으로 그래프를 작성할 수 있도록 합니다. ELK Stack은 한동안 활발히 사용되어 왔지만 제 생각에는 시간이 흐르고 있습니다. 이유는 나중에 말씀드리겠습니다.

메타데이터 추가. 포드, 애플리케이션, 컨테이너는 어디에서나 실행할 수 있습니다. 또한 하나의 애플리케이션에 여러 인스턴스가 있을 수 있습니다. 로그는 동일한 형식으로 작성되며 어떤 종류의 복제본인지, 어떤 포드가 작성하는지, 어떤 네임스페이스에 있는지 이해해야 합니다. 이것이 로그에 메타데이터를 추가해야 하는 이유입니다.

구문 분석 로그. 웃기지만 로깅 및 모니터링 시스템 유지 비용이 기본 애플리케이션 비용을 초과할 수 있습니다. 초당 수만, 수십만 개의 로그가 날아가는 경우 이는 당연해 보이지만 여전히 라인을 알아야 합니다. 이 에지를 찾는 한 가지 방법은 로그를 구문 분석하는 것입니다.

일반적으로 모든 로그를 수집하고 저장할 필요는 없으며 저장을 위해 일부만 보내면 됩니다(예: "경고" 또는 "오류" 상태의 로그). nginx 또는 ingress 컨트롤러 로그에 대해 이야기하는 경우 상태가 200이 아닌 로그만 스토리지로 보낼 수 있습니다.그러나 이것은 보편적인 조언이 아닙니다. Nginx 로그를 기반으로 분석을 구축한다면 분명히 수집할 가치가 있습니다.

필터링된 데이터가 일반 분석에 충분하지 않을 수 있으므로 무분별하게 로그를 필터링하는 것은 권장되지 않습니다. 반면에 분석은 로깅 수준이 아니라 메트릭 수집 수준에서 수행되어야 할 수도 있습니다. 그러면 코드 200으로 수십만 줄을 저장할 필요가 없습니다. 한 가지 접근 방식은 수신 컨트롤러의 메트릭에서 트래픽 및 오류에 대한 정보를 얻는 것입니다.

일반적으로 여기에서 신중하게 생각해야 합니다. 무엇을 저장하고 싶은지, 그렇지 않으면 로깅 시스템이 기본 프로젝트보다 더 많은 리소스를 사용하는 상황이 발생하기 때문입니다.

아직 로깅에 대한 표준 솔루션이 없습니다.. 가장 일반적인 Prometheus 솔루션이 하나 있는 모니터링과 달리 로깅에는 표준이 없습니다.

이 강의에서는 두 가지 도구를 살펴볼 것입니다. 하나는 인기가 있고 두 번째는 인기를 얻고 있습니다. 그 외에도 다른 것들이 있지만 이 기사에서는 다루지 않겠습니다.

위에서 설명한 모든 기능을 고려할 때 Kubernetes 로그인은 이제 다음과 같은 방식으로 표시될 수 있습니다.

컨테이너 로그는 유지되고 회전되지만 수집기 에이전트가 나타나 로그를 선택하고 저장을 위해 전송합니다(다이어그램 - 로깅 백엔드). 에이전트는 각 노드에서 실행되며 일반적으로 Kubernetes에서 실행됩니다.

이제 로깅 도구를 고려하십시오.

그라파나 로키

그라파나 로키 최근에 등장했지만 이미 꽤 유명해졌습니다. 장점: 설치가 쉽고, 리소스를 거의 사용하지 않으며, TSDB(시계열 데이터베이스)에 데이터를 저장하므로 Elasticsearch를 설치할 필요가 없습니다. 지난 글에서 프로메테우스가 이런 데이터베이스에 데이터를 저장한다고 썼는데, 이것이 두 제품 사이의 많은 유사점 중 하나입니다. 개발자들은 심지어 Loki가 "로깅 세계를 위한 프로메테우스"라고 주장합니다.

읽지 않은 사람들을 위한 TSDB에 대한 약간의 여담 이전 기사: TSDB는 많은 양의 데이터, 시계열을 저장하는 작업을 훌륭하게 수행하지만 장기 저장용으로 설계되지 않았습니다. 어떤 이유로 로그를 XNUMX주 이상 저장해야 하는 경우 다른 데이터베이스로의 전송을 구성하는 것이 좋습니다.

Loki의 또 다른 장점은 Grafana가 데이터 시각화에 사용된다는 것입니다. 매우 편리합니다. Grafana에서는 모니터링 데이터를 보고 같은 위치에서 Loki를 연결하여 로그를 봅니다. 로그를 사용하여 그래프를 작성할 수 있습니다.

Loki 아키텍처는 다음과 같습니다.

DaemonSet를 사용하면 Promtail 또는 Fluent Bit와 같은 모든 클러스터 서버에 에이전트가 배포됩니다. 에이전트는 로그를 수집합니다. Loki는 그것들을 집어 자신의 TSDB에 저장합니다. 메타데이터는 즉시 로그에 추가되므로 편리합니다. 포드, 네임스페이스, 컨테이너 이름, 심지어 라벨로도 필터링할 수 있습니다.

Loki 설치 지침

Loki는 친숙한 Grafana 인터페이스에서 실행됩니다. Loki에는 Prometheus의 PromQL과 이름 및 구문이 유사한 LogQL이라는 자체 쿼리 언어도 있습니다. Loki 인터페이스에는 쿼리가 포함된 프롬프트가 있으므로 이를 암기할 필요는 없습니다.

LogQL 설명서

Grafana 인터페이스의 Loki

필터를 사용하여 Loki는 코드("400", "404" 및 기타)를 찾을 수 있습니다. 전체 노드에서 로그를 봅니다. "오류"라는 단어가 포함된 모든 로그를 필터링합니다. 로그를 클릭하면 이벤트에 대한 모든 정보가 포함된 카드가 열립니다.

Loki에는 필요한 로그를 추출할 수 있는 도구가 충분히 있습니다. 솔직히 말해서 기술적으로는 더 있을 수 있습니다. 이제 Loki는 적극적으로 개발하고 인기를 얻고 있습니다.

Elastic + Fluent Bit + Kibana(EFK 스택)

EFK 스택은 더 고전적이지만 똑같이 인기 있는 로깅 도구입니다.

기사 시작 부분에서 ELK(Elasticsearch + Logstash + Kibana)에 대해 언급했지만 이 스택은 생산성이 낮고 동시에 리소스 집약적인 Logstash로 인해 구식입니다. 대신 그들은 더 가볍고 생산적인 Fluentd를 사용하기 시작했고 얼마 후 그는 구조에 나섰습니다. 유창한 비트 - 훨씬 더 가볍고 더 생산적인 에이전트 수집기.

개발자에 따르면 Fluent Bit는 Fluentd보다 성능이 100배 이상 뛰어납니다. 이를 보면 Fluent Bit가 더 널리 사용되었습니다.

Fluent Bit는 Fluentd보다 기능이 적지만 주요 요구 사항을 충족하므로 주로 Fluent Bit를 사용합니다.

EFK 스택 작동 방식: 에이전트는 모든 포드(일반적으로 모든 클러스터 서버에서 실행되는 DaemonSet)에서 로그를 수집하여 스토리지(Elasticsearch, PostgreSQL 또는 Kafka)로 보냅니다. Kibana는 저장소에 연결하고 거기에서 필요한 모든 정보를 검색합니다.

키바 나 사용자 친화적인 웹 인터페이스로 정보를 제공합니다. 차트, 필터 등이 있습니다.

로그를 사용하여 전체 대시보드를 만들 수 있습니다.

유창한 비트 기능

Fluent Bit는 일반적으로 Logstash보다 덜 들리므로 자세히 살펴보겠습니다. Fluent Bit는 논리적으로 6개의 모듈로 나눌 수 있으며 Fluent Bit의 기능을 확장하는 일부 모듈에 플러그인을 연결할 수 있습니다.

입력 모듈 파일, 시스템 서비스, 심지어 tcp-socket에서도 로그를 수집합니다(엔드포인트만 지정하면 Fluent Bit가 그곳으로 이동하기 시작합니다). 이러한 기능은 시스템과 컨테이너 모두에서 로그를 수집하기에 충분합니다.

프로덕션에서는 플러그인을 가장 자주 사용합니다. 꼬리 (로그가 있는 폴더에 설정 가능) 및 시스템 (그는 로그를 수집할 서비스를 알 수 있습니다).

파서 모듈 로그를 공통 보기로 가져옵니다. 기본적으로 Nginx 로그는 문자열입니다. 플러그인을 사용하면 이 문자열을 JSON으로 변환할 수 있습니다. 필드와 해당 값을 설정합니다. JSON은 더 유연한 정렬 옵션이 있기 때문에 문자열 로그보다 작업하기가 훨씬 쉽습니다.

필터 모듈. 이 수준에서는 불필요한 로그가 제거됩니다. 예를 들어 로그는 값이 "경고"이거나 특정 레이블이 있는 저장소로만 전송됩니다. 선택한 로그가 버퍼링됩니다.

버퍼 모듈. Fluent Bit에는 메모리 버퍼와 디스크 버퍼의 두 가지 유형의 버퍼가 있습니다. 버퍼는 오류나 장애가 발생한 경우에 필요한 임시 로그 저장소입니다. 누구나 RAM에 저장하기를 원하므로 일반적으로 디스크 버퍼를 선택합니다. 그러나 디스크로 이동하기 전에 로그가 여전히 메모리로 언로드된다는 점을 명심하십시오.

라우팅/출력 모듈 로그 전송을 위한 규칙 및 주소를 포함합니다. 이미 언급했듯이 로그는 Elasticsearch, PostgreSQL 또는 예를 들어 Kafka로 보낼 수 있습니다.

흥미롭게도 Fluent Bit에서 Fluentd로 로그를 보낼 수 있습니다. 첫 번째는 더 가볍고 기능이 떨어지기 때문에 이를 통해 로그를 수집하고 Fluentd로 보낼 수 있으며 추가 플러그인의 도움을 받아 추가로 처리하고 저장소로 보낼 수 있습니다.

Elasticsearch를 사용할 계획이라면…

마지막으로 Elasticsearch를 프로덕션에서 로그 리포지토리로 사용하려는 사람들을 위한 두 가지 팁입니다.

1. 알림 설정 ElastAlert. 이 프로그램은 일반 로그 스트림에서 중요한 메시지를 분리하고 메일 또는 기타 채널에서 이에 대해 경고합니다. 맞아요 얼마 안남았어요 프로젝트가 곧 중단될 수 있다는 슬픈 소식.
2. 앱으로 로그 회전 큐레이터 또는 Elasticsearch API에 대한 호출. 원칙적으로 Elastic 자체는 이제 타사 도구를 사용하지 않고 인덱스 수명을 관리하기 위해 중요한 조치를 취하고 있습니다. 일반적으로 로그를 오랫동안 보관하는 것은 의미가 없습니다. 5주 후에는 로그가 필요하지 않을 것입니다. 정말 중요한 경우 XNUMX주 안에 확실히 해결될 것입니다. 극단적인 경우 오래된 로그를 보관하고 장기 저장을 위해 어딘가로 보낼 수 있습니다. 법적으로 최대 XNUMX년 동안 보관해야 하는 특수 로그에 대해 들었습니다. 개인적으로 나는 이것을 본 적이 없지만 그러한 정보를 일반 로그와 동일시하지 않고 별도로 저장할 수도 있습니다.

계속 될 ...

작성자: Marcel Ibraev, 인증된 Kubernetes 관리자, 회사에서 실습 엔지니어 사우스 브리지, 연사 및 코스 개발자 슬럼.

출처 : habr.com