Loki로 로그 시스템을 구성해서 쓴지 어느덧 3개월이 넘어간다.
Loki를 맨 처음에는 Loki Stack(Grafana, Promtail, Loki)로 구성해서 모놀리식 형태로 쓸 수 있지만 쓰다보면 다양한 문제점들이 발견된다.
1. 다량의 로그가 Write되면 Loki 파드가 죽는데 정확히 어떤 컴포넌트가 죽었는지 확인하기가 쉽지 않다.
2. Grafana에서 읽을 시 상당히 느리다.
3. 각 컴포넌트들에 대한 이해가 어렵다.
4. Ingest 할 때 어디에선가 쓰로틀링이 걸린다.
5. 등등
하여 사용가능한 로키 헬름 차트들은 어떤게 있으며 로키에 대한 간략한 컴포넌트 소개, 운영 시 어떤 설정값들을 적용하면 좋을지에 대해 간단히 설명하기 위해 글을 쓰게 되었다.
아직 많이 부족한 지식이지만 Loki 도입을 처음 검토하는 분들에게 어느정도 참고가 될 수도 있을 것이라 생각한다.
틀린 내용도 충분히 있을 수 있으니 틀린 내용이 있다면 댓글로 남겨주시면 감사하겠습니다.
1. Loki Helm charts
grafana/loki 관련된 Helm chart들을 살펴보면 대략 5가지 정도가 존재한다.
grafana/loki : 현재 Grafana Loki에서 중점적으로 관리 및 업데이트하고 있는 Helm chart
grafana/loki-distributed : Microservice 형태로 Loki를 관리할 수 있도록 해주는 Helm chart
-> Ingester, Querier, Index Gateway, Distributor, Query-Frontend, Ruler 등으로 구분되어 있음
grafana/loki-simple-scalable : 현재 Deprecated 되었지만 Loki를 아주 간단하게 관리할 수 있도록 도와주는 Helm chart
-> Write와 Read, Nginx gateway로만 구분되어 있다.
grafana/loki-stack : 올인원 모놀리식 형태로 사용할 수 있는 Loki Helm chart
현재 필자는 Loki-distributed를 사용하고 있다.
2. Grafana Loki Components
Grafana Loki는 각각의 역할을 하는 컴포넌트들로 구성되어 있다.
주요 컴포넌트들은 다음과 같다.
1. Distributor : 클라이언트로부터 인입되는 로그를 받아서 로그를 검증한 뒤 Ingester에게 전달한다.
여기서 클라이언트는 Promtail이 될 수도 있고 FluentD, LogStash 혹은 기타 서비스 애플리케이션 쪽 로그 라이브러리가 될 수도 있다.
Distibutor가 하는일은 여러가지이다.
유효성 검사(Validation)
전처리(Preprocessing)
제한 설정(Rate Limiting)
포워딩 (Forwarding)
..
2. Ingester : Distributor에게 로그를 전달받고 일정기간 로그를 Memory에 보관한 다음에 장기 저장소(S3, DynamoDB, ..)에 압축하여 저장하게 된다.
3. Querier : In-Memory(Querier로부터) 혹은 장기 저장소(S3, ..)에서 로그를 쿼리한 데이터를 가져온 후 Grafana 혹은 Query-Frontend에게 데이터를 반환한다.
보통 Grafana에서 로그를 검색할 때 Querier가 일을 하게 된다.
4. Query-Frontend : Grafana로부터의 요청을 수신하고 일부 유효성 검사 및 캐싱을 수행한 뒤 Query를 Querier에게 전달한다.
그 외 컴포넌트들 또한 알아보자.
1. Chunk Store : Loki의 로그를 장기 저장하기 위한 저장소이다.
(참고용)
아래 사진은 Amazon S3를 이용하여 Loki의 Chunk data들을 저장한 모습이다.
Index 또한 같은 S3에서 저장하여 관리하고 있다.
2. Index Gateway
Querier, Ruler에게 Index 쿼리를 제공하기 위해 Object Storage 및 BoltDB 인덱스를 다운로드하고 동기화한다.
-> 이렇게 하면 Grafana로부터 로그 검색 요청이 들어왔을 때 Querier나 Ruler가 불필요하게 일하지 않아도 된다.
3. Compactor와 Table Manager
Grafana Loki의 로그 보존(Retention)은 Compactor 혹은 Table Manager에 의해 수행된다.
현재 Table Manager를 통한 Retention은 TTL을 통해 달성되며 boltdb-shipper, chunk/index store 모두 작동한다.
Compactor를 통한 Retention은 boltdb-shipper 저장소에서만 지원된다.
만약 Compactor로 Retention을 적용한다면 Table Manager는 필요로 하지 않게 될 수 있다.
현재 Grafana Loki에서는 Compactor를 중점적으로 개발중인 것 같다.
다음은 Compactor 설정 예시이다.
compactor:
shared_store: s3
retention_delete_delay: 2h
retention_enabled: true
Compactor의 Retention은 limits_config에 설정해주면 된다.
https://grafana.com/docs/loki/latest/operations/storage/retention/#configuring-the-retention-period
Retention | Grafana Loki documentation
Open source Retention Retention in Grafana Loki is achieved either through the Table Manager or the Compactor. By default, when table_manager.retention_deletes_enabled or compactor.retention_enabled flags are not set, then logs sent to Loki live forever. R
grafana.com
꼭 설정을 변경한 뒤에는 해당 컴포넌트의 로그를 유심히 확인해보면 좋다.
3. Loki Configurations
우선 Loki 설정값을 어떻게 해야 하는지는 공식문서를 자세히 읽어보면 상당히 많이 나온다. 공식문서를 기반으로 추가 설명을 해보겠다.
Loki 설정값 공식 문서
https://grafana.com/docs/loki/latest/configuration/
1. Grafana Loki 모범 사례
https://grafana.com/docs/loki/latest/best-practices/
- 레이블은 Loki에서 Log를 검색할 때 필터링이 되는 기준이 되는데 여기선 정적 레이블을 가급적이면 사용하라고 가이드하고 있다.
레이블은 클라이언트에서 설정한다음에 Loki에게 Push하면 된다.
- chunk_target_size를 사용하라고 한다.
기본 1.5MB 사이즈로 모든 청크 크기를 채우도록 하는게 좋다고 한다.
- chunk_encoding은 기본값이 gzip인데 snappy를 권고한다고 한다. 이게 훨씬 더 압축을 푸는데도 빠르고 쿼리 속도도 더 빠르다고 한다.
- max_chunk_age는 2h을 권고한다고 한다. (아마 30분일 것임)
- chunk_idle_period은 1h ~ 2h을 권고한다고 한다.
- RF(Replication factor)를 항상 설정할 것을 권고한다.
데이티의 손실 가능성을 완화하기 위해 Ingester의 복제 요소를 일반적으로 3개로 설정할 것을 권고하고 있다.
그러나 복제 요소가 데이터 손실을 방지하는 유일한 요소는 아니며, 주요 목적은 롤아웃 및 재시작 중에 쓰기가 중단되지 않도록 하는 것이다.
2. Request Validation, Rate-Limit 에러
https://grafana.com/docs/loki/latest/operations/request-validation-rate-limits/
기본값으로 설정하면 필히 겪게 될 에러들이다.
https://grafana.com/docs/loki/latest/configuration/#limits_config
ingestion_rate_mb: 20
ingestion_burst_size_mb: 40
-> ingestion_rate_mb는 기본값 4이며 ingestion_burst_size_mb는 기본값 6이다.
이 값으로 설정하면 필히 쓰로틀링이 걸리게 된다. 하여 적절한 값으로 조정이 필요하다.
3. Loki Grafana 모니터링
실운영하기 위해서는 Loki의 메트릭들을 Grafana와 같은 대시보드 툴에서 확인할 수 있어야 한다.
Loki는 기본적으로 /metrics 엔드포인트로부터 각 Components들의 Metric들을 확인할 수 있다.
모든 컴포넌트들의 Service annotation에 아래의 문구를 추가해준다.
이렇게 하면 Prometheus가 자동으로 /metrics 엔드포인트로 메트릭들을 scrape 해간다.
prometheus.io/scrape: "true"
prometheus.io/path: "/metrics"
prometheus.io/port: "3100"
이런 메트릭들을 활용하여 Grafana dashboard를 구성하면 된다.
필자는 여기에 Loki 파드에 대한 CPU, Memory와 Nginx access log에 대한 모니터링을 수행하고 있다.
https://grafana.com/docs/loki/latest/operations/observability/
Observability | Grafana Loki documentation
Open source Observability Both Grafana Loki and Promtail expose a /metrics endpoint that expose Prometheus metrics (the default port is 3100 for Loki and 80 for Promtail). You will need a local Prometheus and add Loki and Promtail as targets. See configuri
grafana.com
추가 가능한 모니터링으로는 Nginx Access log 모니터링이 가능하다.
아래 글을 읽고 따라하면 다음과 같은 액세스 로그를 대시보드를 통해 확인할 수 있다.
단순 Json 형태로 액세스로그를 변환해주고 대시보드만 Import 해주면 끝이다. 아주 간단하다.
https://grafana.com/grafana/dashboards/12559-grafana-loki-dashboard-for-nginx-service-mesh/
Grafana Loki Dashboard for NGINX Service Mesh | Grafana Labs
Edit Delete Confirm Cancel
grafana.com
적용 예시)
간단한게 Loki에 대해서 알아보았다.
기존 ES가 분명히 생태계도 크고 지원되는 플러그인도 상당히 많아서 여러 회사에서 사용하고 있는 것으로 알고 있다.
하지만 Loki 또한 2.7 버전까지 나오면서 많이 발전해왔고 Grafana, Prometheus를 사용해왔다면 단순 Loki만 추가해서 단일 Grafana 대시보드에서 로그까지 확인할 수 있고, Grafana Tempo 또한 사용한다면 Log와 Trace 까지 통합할 수 있어 매우 좋다고 생각한다.
물론 아직 완벽히 ElasticSearch를 대체할 수 있는 오픈소스는 아니지만 러닝커브가 높지 않고 가볍게 사용할 수 있다는 점, Grafana 대시보드를 사용함으로써 많은 개발자 및 엔지니어에게 친숙하다는 점에서 사용할 만한 가치가 충분히 있다고 생각한다.
내용 출처
Logging/Grafana Loki 아키텍처 구성
Grafana Loki 아키텍처
medium.com
'Log,Monitorings' 카테고리의 다른 글
| [Prometheus] AlertManager로 Slack 알람 전송하는 법 알아보자 (0) | 2023.07.29 |
|---|---|
| [Observability] fluentd 보다 더 좋은(?) Vector에 대해 알아보자. (1) | 2023.06.10 |
| [EKS] 아주 가벼운 Loki + Grafana + Promtail 로그 시스템 구성 (2) | 2022.10.31 |
| [Datadog] EKS에서 운영중인 SpringBoot HikarpCP 모니터링 (Auto Discovery) (0) | 2022.09.09 |
| [Datadog] AWS Events 기반으로 Datadog 알람 설정하기 (0) | 2022.06.26 |
