일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
Tags
- test #비교
- CI #CD #CI/CD
- dify
- 백준 #10430
- lvm #lv #vg #pv
- jgrp000032 #ocp #
- dump #jattach
- OCP
- function #사용자 정의 함수
- bootstrap #css #CSS
- DB #mariaDB #SQL
- Grid #CSS
- EKS
- Python #pakage
- EFK
- Kafka #카프카
- shell #shell script
- jmap #jstack
- Linux #wc
- 티스토리챌린지
- 네트워크 #NW
- 오블완
- NameSpace #NS
- PODS #POD #pods #pod #파드 #재기동 #롤링재기동 #rolling
- Node #POD #Container
- Excel #엑셀
- lenova #레노버 #노트북
- publishnotreadyaddress
- istio #k8s #kubernetes
- Swap Memory
Archives
- Today
- Total
BEOM_IT
EFK 본문
728x90
반응형
Private/Public의 전체 구조는
로그를 저장하는 DB=elastic Search,
로그 수집=Fluentd,
저장한 로그를 보여주는 툴=Kibana
개인정보 로그를 제외하고 Private/Public 모두 Elastic Search에 저장
- 서비스,온라인배치, 일반배치, 쿠버네티스 컨트롤 플레인4종류
- 개인정보 로그는 public은 S3, private은 kafka를 거치지 않고 바로 전송
- 나머진 로그는 kafka를 거쳐 Elastic Search에 저장
구조: Pod생성(log 생성) ->FluentD -> Kafka -> 설치형 FluentD -> ElasticSearch(Managed)
- 로그양이 적다면 Kafka 단계를 건너뛰고 FluentD->ElasticSearch
- Kafka는 설치형으로 Pod형태가 아니지만 FluentD는 Pod형태로 기동된다.
일반적으로 수집한 데이터는 Elasticsearch로 바로 전송 가능하지만 부하가 많이 발생할 경우 Elasticsearch가 정상적으로 쓰기를 하지 못해 실패할 경우를 대비해 중간에 Buffer를 토픽으로 Kafka로 전송하고, VM에 설치된 td-agent(Fluentd)에서 kafka 토픽을 전송받아 통합 로그를 ElasticSearch로 전송하는 구조
Public과 Private의 fluentd는 Pod와 관련한 여러 로그정보(컨테이너 서비스로그,온라인/온디멘드 배치정보,기타 로그정보)를 프로듀서로서 Kafka 토픽으로 전송하며, 개인정보 로그는 s3로 전송, 운영계에는 Kafka에 로그전송 이외의 쓰레드 덤프전송을 별도로 담당하는 Rclone을 사용해 별도로 s3(Cloud Storage)에 Dump/GC Log를 2분 주기로 저장
728x90
반응형
'DevOps > Kubernetes' 카테고리의 다른 글
Fluentd (0) | 2023.07.18 |
---|---|
ElasticSearch (0) | 2023.07.18 |
[openshift]oc get ns 와 oc get ns [ns명]차이 (0) | 2023.07.18 |
Node,Container,POD 삼각관계? (0) | 2023.07.18 |
Canary(카나리) 배포 (0) | 2023.07.18 |