-
계속 바뀌었던 제휴사 연동 모듈의 로그 적용기학습/회고록 2024. 11. 23. 11:59
PM: Production에는 로그를 적재하고 있지않아요! p4..쯤 안정화되면 적용할께요!!
예..?
Q. staging 에는 로그가 있는데요? 그대로 쓰면 안되나요..?
Team: 아... 로그 보안정책을 다 제대로 체크하지 못했어요..
Q. staging 서버는 어떻게 적용이 됐나요..?
PM: 데이터독 서버가 해외라 staging은 암호화처리를 하고 production은 적재하지 않는 방식으로 가기로 했어요.그렇다.
데이터독 서버는 2019년 9월에 9조 이상 가치로 미국 나스닥 시장에 상장한 해외서버였다.
여러 제휴사를 붙이고 제휴사마다의 규격을 통일화 한뒤 코드의 모듈자체에 로그 컨벤션을 완성했다.
production의 로그는 휘발성으로 남겨둔채로 DB에 적재된 통신로그에러메세지만 보다가 한계가 오기 시작하면서 다시 production 로그 적용이 p1까지 올라왔다..
p0 ~ p5는 로그 기준이다
급한순으로 p에 0 ~ 5를 붙여 작업 순위를 지정한다.로그를 다시 데이터독에 적재하자니 로그를 적재하는 데이터들의 상당수가 해외서버의 규제에 걸렸다.
회의중..
Infra Team: 그러면 Cloudwatch Seoul Region에 적재하는 방법은 어떠세요?
유레카..!
서울리전은 한국서버이므로 몇가지 제약사항이 해소되는것이였다.
따라서 Datadog으로 작성하던 로깅방법을 Cloudwatch로 바꾸는 작업을 진행햇다.
Spring boot & k8s 환경에서 Cloudwatch를 적용하는 방법은 여러가지가 있었지만 그중에서 메인 Pod에서 로깅을 위한 Fluent Bit Pod를 생성하는 Sidecar Pattern을 사용하여 로깅을 적용하였다.
1. Cloudwatch agent: Fluent Bit 가 훨씬 가벼움
2. Application AWS Logging Gradle: Application의 상태까지도 적재하길 원하여 Application이 아닌 외부에서 로깅을 적재해야됨
3. FluentBit demonset: 현재도 다른 팀에서 쓰고 있었지만 이 신규 제휴사연동모듈을 위해 Demonset을 올리는건 리소스가 너무크다고 생각함
따라서 FluentBit를 사이드카 패턴으로 올리고 작업을 진행했다.
이게 무엇인가..
전체 로깅을 적재하다보니 한줄씩 찍히는 기이한 현상이 발생하여 Datadog에서 사용되던 방식을 그대로 사용하기엔 가독성이 너무 떨어졌다.
<appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>/data/logs/application.log</file> <!-- Fluent Bit에서 모니터링하는 경로 --> <encoder> <pattern> %d{yyyy-MM-dd HH:mm:ss} %thread ${NODE_NAME} ${POD_NAME} [Lenderconnector Log] { Level: %level, Logger: %logger, HTTP_Method: %X{http_method}, Request_URL: %X{request_url}, Request_Headers: %X{request_headers}, Request_Body: %X{request_body}, HTTP_Status: %X{http_status}, Response_Headers: %X{response_headers}, Response_Body: %X{response_body}, Message: %message }%n </pattern> </encoder> </appender>
따라서 fluent bit설정중 멀티라인을 추가하여 해당 내용을 작성했다.
fluent-bit.conf: | [SERVICE] Flush 1 Log_Level info Daemon Off Parsers_File parsers.conf [INPUT] Name tail Path /data/logs/*.log Tag * Refresh_Interval 10 Mem_Buf_Limit 50MB Skip_Long_Lines On Multiline On Parser_Firstline logback_multiline Multiline_Flush 5 [OUTPUT] Name cloudwatch_logs Match * region ap-northeast-2 log_group_name {{ $service_name }} log_stream_prefix {{ $service_name }} auto_create_group false parsers.conf: | [PARSER] Name logback_multiline Format regex Regex (?<title>^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.*\[Lenderconnector Log\]) Time_Key time Time_Format %Y-%m-%d %H:%M:%S Decode_Field_As escaped message [PARSER] Name logback_continued Format regex Regex (.|\n|\s|\S)*
암호화는 추가로 정규식을 작성하여 Infra Team 에게 보낸뒤 재환님이 작업을 진행해주셨다.
- Name: "phoneNumber" Regex: "01\\d{8,9}" - Name: "userRrn" Regex: "\\d{6}?[1234]\\d{6}" - Name: "address" # Regex: "(서울특별시|서울|부산광역시|부산|대구광역시|대구|인천광역시|인천|광주광역시|광주|대전광역시|대전|울산광역시|울산|세종특별자치시|세종|경기도|경기|강원특별자치도|강원|충청북도|충북|충청남도|충남|전라북도|전북|전라남도|전남|경상북도|경북|경상남도|경남|제주특별자치도|제주)\\s([가-힣]+(시|군|구|시 [가-힣]+(군|구)))\\s([가-힣0-9\\-]+(?:읍|면|동|로|길|번길)?)\\s(\\d+)(?:-(\\d+))?(?:,\\s?(\\d+층)?\\s?(\\d+호)?)?(?:\\s?\\(([^)]+)\\))?" Regex: "([가-힣]+(시|군|구|시 [가-힣]+(군|구)))\\s([가-힣0-9\\-]+(?:읍|면|동|로|길|번길)?)\\s(\\d+)(?:-(\\d+))?(?:,\\s?(\\d+층)?\\s?(\\d+호)?)?(?:\\s?\\(([^)]+)\\))?" - Name: "name" Regex: "[가-힣]{2,5}" - Name: "accountNumber" Regex: "\\d{10,14}"
이렇게 production의 우당탕탕 로그 적용이 끝났다.
Todo list는 아직 pretty한 로깅이 적재되지않지만 한줄로 체크되는 부분을 확인했으니..
1. pretty logging
2. 불필요한 로그 제거
가 p3으로 올라왔다.
'학습 > 회고록' 카테고리의 다른 글
[회고] 제휴사 연동 서버 개발 (0) 2024.11.23 이직 전에 받았던 질문 정리 (0) 2022.10.11 2017-05-10 (0) 2017.05.10 2017-05-08 (0) 2017.05.08 2017-04-22 (0) 2017.04.22