반응형
https://www.youtube.com/watch?v=5ofsNyHZwWE
Why we Need Logs?
k8s에 여러 MicroService 앱이 배포되어 있다고 가정하자.
- nodejs / python
- postgres DB
- RabbitMQ
각각의 앱은 "어떤 동작을 하고 있는지" 로그를 생성한다. 로그는 보통 아래 세 가지 목적으로 쓰임.
- Compliance
- Security
- Debugging
How Application Logs data?
- Write to files. 일반적인 방식.
단, 로그데이터 분석에는 제약이 따름.
UI나 visualization tool 없이는 cross application log 확인도 어려운 편
로그마다 format도 다름 (timestamps, log level 등)
- Log DB (ElasticSearch 등) 에 저장하는 방식. visualization도 보통 같이 지원함.
단, 각각의 앱에서 직접 config을 설정해줘야 함.
3rd party Application (예시의 경우 postgres, rabbitmq, k8s nginx ingress) 또는 system (infra) 로그의 경우 "how they log" 을 바꿀 수가 없다.
따라서 Collecting & Consuming Logs With Unified Format 은 쉽지 않은 과제.
Unified Logging Layer의 등장
- Fluentd가 logging layer 역할.
- 특정 애플리케이션에서 network outage / data spikes가 발생하더라도 문제 없음
- json / nginx / custom format 등 다양한 형태로 만들어진 로그를 uniform format으로 통일
- Add addtion data to each log entry. pod name / namespace 등. 이렇게 특정 필드를 추가한 뒤, 해당 필드로 grouping해서 조회하는 것도 가능하다.
fluentd는, 이렇게 만들어진 로그를 원하는 Destination으로 전송할 수 있음.
- routing 설정이 가능함.
- 예컨대 python 로그는 데이터분석을 위해 MongoDB에 쌓이도록 하고
- nodejs 로그는 elasticSearch와 MongoDB에 동시에 보내고
How to Configure?
- Fluentd는 K8s 클러스터에 DaemonSet으로 배포해 사용하며, configuration file을 사용해서 설정을 변경할 수 있다.
- 각각의 usecase에 적용할 수 있는 Plugin 사용 가능
- input plugin: fluentd에 input으로 넣을 수 있는 여러 data Source가 정의되어 있음
- Parser plugin: Line by Line으로 parsing 로직 정의 가능.
- 각각의 Log를 key-value pair로 지정. log-level, message, dates, user_id, ip_address ...
- Filter plugin: record_transformers 사용해서 특정 데이터를 추가 / 변경 / 삭제하는 로직을 추가할 수 있음.
- 예컨대 personal data 비식별화 등의 작업을 여기서 처리할 수 있음.
- Output plugin: 로그를 어디로 보낼 것인지.
tag 개념을 사용하면 log의 Grouping / filtering이 가능하다.
- 예컨대 myapp.* 인 모든 로그는 json으로 parsing한다던가
- myserivce.* 인 로그는 elasticsearch로 보낸다던가.
source에 정의한 Tag를 사용하므로, which logs should go where를 쉽게 정의할 수 있다.
Built-in Reliability
- fluentd는 로그데이터를 destination에 전송하기 전까지는 hard drive에 저장.
- fluentd가 일시적으로 죽거나 문제가 생기더라도 로그 손실이 발생하진 않음
- 따라서 Redis같은 external storage가 필요하지 않다
- destination (elasticsearch, mongoDB 같은) 에 문제가 생겨서 접근 불가능할 경우, auto retry until the endpoint becomes available.
- high available through clustering
다양한 Usecase. k8s뿐만 아니라 iot / bare metal server 등에도 활용할 수 있음.
반응형