🥇Kubernetes 로그인: EFK 및 PLG

분산 시스템의 복잡성이 증가함에 따라 모니터링은 클라우드 솔루션 성장에 있어 매우 중요한 구성 요소가 되었습니다. 그들의 행동을 이해하는 것이 필요합니다. 모든 서비스에서 데이터를 수집하고 성능 분석, 오류 시연, 가용성 및 로그가 포함된 단일 인터페이스를 전문가에게 제공할 수 있는 확장 가능한 도구가 필요합니다.

이러한 동일한 도구는 효율적이고 생산적이어야 합니다. 이 기사에서는 널리 사용되는 두 가지 기술 스택인 EFK(Elasticsearch)와 PLG(Loki)를 살펴보고 해당 아키텍처와 차이점을 살펴보겠습니다.

EFK 스택

매우 인기 있는 ELK 또는 EFK에 대해 이미 들어보셨을 것입니다. 스택은 Elasticsearch(객체 스토리지), Logstash 또는 FluentD(로그 수집 및 집계), 시각화를 위한 Kibana 등 여러 개별 부분으로 구성됩니다.

일반적인 작업 흐름은 다음과 같습니다.

탄성 검색 — 검색 및 실시간 분석 기능을 갖춘 분산 개체 스토리지입니다. 로그와 같은 반구조화된 데이터를 위한 탁월한 솔루션입니다. 정보는 JSON 문서로 저장되고 실시간으로 색인화되며 클러스터 노드에 분산됩니다. 전체 텍스트 검색을 위해 모든 고유 단어와 관련 문서를 포함하는 반전된 인덱스가 사용되며 이는 Apache Lucene 검색 엔진을 기반으로 합니다.

유창함D 데이터를 수집하고 소비할 때 데이터를 통합하는 데이터 수집기입니다. 가능한 한 JSON으로 데이터를 구성하려고 합니다. 아키텍처는 확장 가능하며 더 많은 기능이 있습니다. 수백 가지의 다양한 확장, 모든 경우에 대해 커뮤니티 지원.

키바 나 - 시계열 분석, 그래프 분석, 기계 학습 등과 같은 다양한 추가 기능을 갖춘 Elasticsearch용 데이터 시각화 도구입니다.

엘라스틱서치 아키텍처

Elasticsearch 클러스터 데이터는 모든 노드에 분산되어 저장됩니다. 클러스터는 가용성과 복원력을 향상시키기 위해 여러 노드로 구성됩니다. 모든 노드는 클러스터의 모든 역할을 수행할 수 있지만 대규모 확장 배포에서는 일반적으로 노드에 개별 작업이 할당됩니다.

클러스터 노드 유형:

마스터 노드 - 클러스터를 관리합니다. 최소 XNUMX개가 필요하며 하나는 항상 활성 상태입니다.
데이터 노드 - 인덱싱된 데이터를 저장하고 이를 사용하여 다양한 작업을 수행합니다.
수집 노드 - 인덱싱 전에 데이터 변환을 위한 파이프라인을 구성합니다.
노드 조정 - 요청 라우팅, 검색 처리 단계 감소, 대량 인덱싱 조정
경고 노드 — 경고 작업 시작
기계 학습 노드 - 기계 학습 작업을 처리합니다.

아래 다이어그램은 더 높은 데이터 가용성을 달성하기 위해 데이터가 노드 전체에 저장되고 복제되는 방법을 보여줍니다.

각 복제본의 데이터는 반전된 인덱스에 저장됩니다. 아래 다이어그램은 이것이 어떻게 발생하는지 보여줍니다.

설치

세부정보를 볼 수 있습니다. 여기에, Helm 차트를 사용하겠습니다.

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

PLG 스택

Grafana Loki로 더 잘 알려져 있으므로 이 약어를 찾을 수 없더라도 놀라지 마십시오. 어쨌든 이 스택은 입증된 기술 솔루션을 사용하기 때문에 인기를 얻고 있습니다. 널리 사용되는 시각화 도구인 Grafana에 대해 이미 들어보셨을 것입니다. Prometheus에서 영감을 받은 제작자는 수평 확장이 가능한 고성능 로그 집계 시스템인 Loki를 개발했습니다. Loki는 저널 자체가 아닌 메타데이터만 색인화하므로 사용하기 쉽고 비용 효율적일 수 있는 기술 솔루션입니다.

프롬테일 - 운영 체제에서 Loki 클러스터로 로그를 전송하는 에이전트입니다. 그라 파나 Loki의 데이터를 기반으로 한 시각화 도구입니다.

Loki는 Prometheus와 동일한 원칙을 기반으로 구축되어 Kubernetes 로그를 저장하고 분석하는 데 매우 적합합니다.

로키 아키텍처

Loki는 단일 프로세스 또는 다중 프로세스로 실행될 수 있으므로 수평 확장이 가능합니다.

또한 모놀리식 애플리케이션이나 마이크로서비스로 작동할 수도 있습니다. 단일 프로세스로 실행하면 로컬 개발이나 사소한 모니터링에 유용할 수 있습니다. 산업 구현 및 확장 가능한 워크로드를 위해서는 마이크로서비스 옵션을 사용하는 것이 좋습니다. 데이터 쓰기 및 읽기 경로가 분리되어 있으므로 필요에 따라 미세 조정 및 확장이 가능합니다.

자세히 설명하지 않고 로그 수집 시스템의 아키텍처를 살펴보겠습니다.

설명은 다음과 같습니다(마이크로서비스 아키텍처).

구성 요소 :

프롬테일 — 노드에 서비스 세트로 설치된 에이전트로, 작업에서 로그를 제거하고 Kubernetes API에 액세스하여 로그에 태그를 지정할 메타데이터를 얻습니다. 그런 다음 로그를 기본 Loki 서비스로 보냅니다. 메타데이터 매핑은 Prometheus와 동일한 태그 지정 규칙을 지원합니다.

살수 장치 — 버퍼 역할을 하는 서비스 배포자. 수백만 개의 레코드를 처리하기 위해 들어오는 데이터를 압축하여 도착하는 대로 블록으로 압축합니다. 여러 데이터 싱크가 동시에 실행되고 있지만 하나의 수신 데이터 스트림에 속하는 로그는 모든 블록에 대해 그 중 하나에만 나타나야 합니다. 이는 싱크 링과 순차 해싱으로 구성됩니다. 내결함성 및 중복성을 위해 이 작업은 n회 수행됩니다(구성되지 않은 경우 3회).

섭취기 - 서비스 수신자. 데이터 블록은 로그가 추가되어 압축되어 도착합니다. 블록의 크기가 충분해지면 블록이 데이터베이스로 플러시됩니다. 메타데이터는 인덱스로 이동하고, 로그 블록의 데이터는 청크(일반적으로 객체 스토리지)로 이동합니다. 재설정 후 수신자는 새 항목이 추가될 새 블록을 생성합니다.

색인 - 데이터베이스, DynamoDB, Cassandra, Google BigTable 등

청크 — 일반적으로 S3와 같은 객체 스토리지에 저장되는 압축 형식의 로그 블록입니다.

쿼리어 - 모든 더러운 작업을 수행하는 독서 경로. 시간 범위와 타임스탬프를 살펴본 다음 인덱스를 보고 일치하는 항목을 찾습니다. 다음으로 데이터 블록을 읽고 필터링하여 결과를 얻습니다.

이제 모든 것이 실제로 작동하는 것을 살펴보겠습니다.

설치

Kubernetes에 설치하는 가장 쉬운 방법은 helm을 사용하는 것입니다. 이미 설치하고 구성했다고 가정합니다(그리고 세 번째 버전! 약. 역자)

리포지토리를 추가하고 스택을 설치합니다.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

다음은 Etcd 지표에 대한 Prometheus 및 Etcd Pod 로그에 대한 Loki의 데이터를 보여주는 대시보드 예시입니다.

이제 두 시스템의 아키텍처에 대해 논의하고 서로의 기능을 비교해 보겠습니다.

비교

쿼리 언어

Elasticsearch는 Query DSL 및 Lucene 쿼리 언어를 사용하여 전체 텍스트 검색 기능을 제공합니다. 광범위한 운영자 지원을 제공하는 확립되고 강력한 검색 엔진입니다. 이를 통해 상황에 따라 검색하고 관련성에 따라 정렬할 수 있습니다.

링의 반대편에는 PromQL(Prometheus 쿼리 언어)의 후속 제품인 Loki에서 사용되는 LogQL이 있습니다. 로그 태그를 사용하여 로그 데이터를 필터링하고 선택합니다. 설명된 대로 일부 연산자와 산술을 사용할 수 있습니다. 여기에, 그러나 기능 측면에서는 Elastic 언어에 비해 뒤떨어집니다.

Loki의 쿼리는 태그와 연결되어 있기 때문에 메트릭과 쉽게 연관시킬 수 있으며 결과적으로 운영 모니터링을 구성하기가 더 쉽습니다.

확장성

두 스택 모두 수평 확장이 가능하지만 Loki는 별도의 읽기 및 쓰기 경로와 마이크로서비스 아키텍처를 갖추고 있어 더 쉽게 확장할 수 있습니다. Loki는 필요에 맞게 사용자 정의할 수 있으며 대용량 로그 데이터에 사용할 수 있습니다.

다중 테넌트

클러스터 다중 테넌시는 OPEX 약어의 공통 주제이며, 두 스택 모두 다중 테넌트를 제공합니다. Elasticsearch에는 여러 가지가 있습니다 길 클라이언트 분리: 각 클라이언트에 대한 별도의 인덱스, 클라이언트 기반 라우팅, 고유한 클라이언트 필드, 검색 필터. 로키는 지원 HTTP X-Scope-OrgID 헤더 형식입니다.

비용

Loki는 데이터를 색인화하지 않고 메타데이터만 색인화한다는 점에서 매우 비용 효율적입니다. 이것은 달성한다 저장 공간 절약 그리고 메모리(캐시)는 Elasticsearch 클러스터에서 사용되는 블록 스토리지보다 객체 스토리지가 저렴하기 때문입니다.

결론

EFK 스택은 다양한 목적으로 사용될 수 있으며 분석, 시각화 및 쿼리를 위한 최대의 유연성과 풍부한 기능을 갖춘 Kibana 인터페이스를 제공합니다. 머신러닝 기능을 통해 더욱 향상될 수 있습니다.

Loki 스택은 메타데이터 검색 메커니즘으로 인해 Kubernetes 생태계에서 유용합니다. Grafana 및 로그의 시계열을 기반으로 모니터링할 데이터를 쉽게 연관시킬 수 있습니다.

비용 및 장기 로그 저장 측면에서 Loki는 클라우드 솔루션에 대한 탁월한 진입점입니다.

시장에는 더 많은 대안이 있습니다. 일부는 귀하에게 더 적합할 수도 있습니다. 예를 들어 GKE에는 탁월한 모니터링 솔루션을 제공하는 Stackdriver 통합 기능이 있습니다. 우리는 이 기사의 분석에 이를 포함하지 않았습니다.

링크 :

이 기사는 직원들이 Habr을 위해 번역하고 준비했습니다. 슬럼 트레이닝 센터 — 실무 전문가(Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)의 집중 과정, 비디오 과정 및 기업 교육

출처 : habr.com

Kubernetes에 로그인: EFK와 PLG