로깅을 하기 위한 기술 스택들
- 가장 크게는 ELK(elastic search, logstash, kibana)와 PLG(Promtail, Loki, Grafana) 라인이 존재함
- 원래 ES, Kibana는 오픈 소스였으나 정책이 바뀌며 ES와 Kibana를 대체하기 위한 OpenSearch가 나옴
- OpenTelemetry는 표준화된 Observability 프레임워크로 OTLP 전송 표준을 제공하는 등 최근에 나와 많이 쓴다고 함
- 데이터 수집에서는 요즘 가장 많이 핫한 OpenTelemetry를 사용할 것임
Loki 배포 방식 및 아키텍처
- loki 하나로 저장하는 방식이 존재하지만 이는 확장성이나 안정성에서 분리함
- loki를 2개로 나누고 volumn을 각각 두는 방식은 동기화가 안됨
- 하나의 volumn으로 연결하는 방식은 기존 방식 자체가 loki 안에 메모리에 있다가 모이면 volumn으로 가는 형식이기에 실시간 조회는 잘 안된다는 단점이 존재함
Loki 방식
- 모놀리식 모드는 하나로 다하는 형식 -> 복사해서 replica를 2로 설정하면 조회마다 내용이 달라짐
- 단순 확장 모드는 read, backend, write로 나눠서 관리함
- 참고로 loki는 메모리에 저장해놓았다가 storage로 나중에 저장하기 때문에 실시간 조회를 위해서는 write pod를 조회해야함
- 마이크로 서비스 모드는 세부적으로 컴포넌트가 나누어지는 형식임
- 상황에 맞는 방식을 사용하면 됨
Loki 아키텍처
- 위는 마이크로 서비스 방식임
- write를 여러 개를 두어서 고장놔도 괜찮아짐
- 조회는 1. 쿼리 캐싱, 2. 쿼리 작은 단위로 쪼개서 backend로 넘김 -> 쿼리를 분산 시켜서 read pod로 가면 querier에서 인덱스를 확인 후 얼마 안되었다면 write pod로 많이 되었다면 직접 청크DB를 확인함
- 기존에는 index DB와, chunkDB는 filestorage를 사용하기도 하였으나 chunkDB는 많은 양을 저장해야하기에 Object Storage에 저장하는 경우도 많았음
- 이후 Block 방식의 TSDB가 나오며 한번에 저장이 가능해짐
OpenTelemetry 구조와 Log 포맷
- Extenstions는 부가 기능 담당
- Receiver는 최초로 데이터가 들어가는 곳
- Processor는 다양한 관리 기능이 들어가 있는곳
- Exporters는 로그 전송 컴포넌트 이다.
- Service는 위의 각 pod를 활성화 시키는 곳으로 Exporter든 Extensions 든 여기에 활성화를 시키지 않으면 활성화가 안됨
- Loki 포맷은 stream과 values로 되어있고 OpenTelemetry는 Resource와 ScopeLogs로 되어있음
- 둘이 비슷하다고 각각 그대로 저장되는 것이 아닌 Values로 저장 되기에 이는 주의가 필요
- OpenTelemetry는 k8s, core, contrib 등 여러 이미지가 존재하는 데 각각 호환되는 플러그인이 다르기에 주의가 필요
출처: https://inf.run/wLXM7