반응형
1. 파일을 이용한수집
application에서는 로그를 파일로만 남기고 별도로 로그 파일을 읽는 프로세스를 만들어서 전송하는 방식
장점
- application과 log extract가 관심사 분리(SOC)가 가능함 아키텍처 상으로 역할과 동작이 구별되니 유연성이 높아짐
- 컨테이너 환경을 이용해서 application과 extaction 리소스를 분리하면, 수집기 때문에 application에 부담을 주지 않음
단점
- application, log extraction를 별도로 관리해야 함
- application은 정상인데 log extaction이 비정상일 경우 application의 이상으로판단될 수 있음
- 아무래도 하나의 server에다가 몰빵을 했기 때문에 부분적 삑사리도 전체적인 관계성이 나타날 수 있음
- application은 정상인데 log extaction이 비정상일 경우 application의 이상으로판단될 수 있음
2. Network를 이용한 Push
application에서 직접 로그 수집기로 프로토콜을 이용해서 전송방법 ( 간단하게 기능몰빵 )
장점
- 로그 전송의 성공, 실패 여부를 application 에서 모두 확인 가능
단점
- application의 로직과 로그 전송을 같은 process에 수행하므로 서로 영향이 있을 수밖에 없음
- 로그 전송 때문에 application 부하, 병목 가능성 농후
- 디버깅 복잡해짐
3. Network를 이용한 Polling
application은 시스템의 정보, 로그 정보 등에 대해서 스크랩 할 수 있는 채널만 열어두고 수집기에서 주기적으로 가져가는 방식
log 보다는 매트릭(통계 정보, 상태 정보) 수집에 더 적합함
장점
- application과 매트릭에 수집에 대한 관심사 분리가 가능함
- application에서 개발자가 수집에 대한 관리를 할 필요가 없음
- 만약 서버가 갑자기 늘어나더라도 log controller 에서 각각 서버 경로만 잡아주면 확장성이 가능함
- 분산 환경, 컨테이너 환경, 자동화 인프라 환경에서 사용성이 편하고 확장성이 높음
단점
- polling 주기나 수집 시점에 따라 값이 바뀌기에 특정 순간 원하는 정보를 볼 수 없음
- 이건 단점이라고 볼 수는 없고 아예 적합하지 않다고 볼 수 있음
그러면 다음과 같은 설계 방식들은 어떨때 사용하는 것이 가장 좋을까?
1. 즉시 알람이 와야할경우 ex) 구매 완료 등등
-> network push
2. 그냥 일반적으로 수집하고 찾고싶은 순간에 찾아보는것
-> 파일이용한 수집
3. 얼마나 요청이 왓는지 통계 정보
-> 매트릭이기 때문에 network pooling
4. 시스템 정보를 확인하고싶을때
-> network pooling
반응형
