안녕하세요
.net core api 서버를 운영하고 있습니다.
이번에 api 로그 적재부터 분석까지 아키텍쳐 고민을 하고 있습니다.
일단 request api의 routepath, querystring, body 등 로우데이터를 적재하고 필요시 etl 하려고합니다.
aws를 쓰고있는데 다른 분들은 어떻게 적재하고 분석하시는지 궁금합니다.
api 로그가 아닌 일반 사용자 로그도 궁금합니다~!
querystring은 가능한 key/value로 바꿔서 적재하는게 검색에 편리합니다.
routepath가 좀 중의적인가 싶은데, request path와 route path를 둘다 기록해주는것이 좋습니다.
분석과 관련된 내용은 아주 길어지는데요 간단하게만 답변드리자면 etl 여부는 로그를 적재할 검색엔진의 스키마 지원여부에 따라 다릅니다.
aws cloudwatch나, aws athena 는 스키마를 적용하지 않습니다.
이때는 json object 형태로 그냥 막 꽂아넣어도 상관없습니다.
elasticsearch는 스키마가 필수입니다. 제가 템플릿으로 지정하지 않아도 입력된 데이터로 맵핑이 설정되고 그래서 종종 response.body.c 가 문자열 “1” 일 수도 있고 때로는 response.body.c가 정수형 1 일수도 있는데요, 이때 두번째 elasticsearch put index에서 에러가 생기면서 입력이 안됩니다.
보통 response, request처럼 구현에 따라 값이 변할 수 있는 값들은 json serialize등을 통해 텍스트 포멧으로 넣을 수 있습니다.
그렇게 되면 response.body = “{"c":1}” 이나response.body = “{"c":"1"}” 처럼 들어가겠죠 (미리보기를 보니 이스케이프 문자가 깨지네요, 대충이해하시죠?)
이렇게 만들고 이후에 읽어들일 때 body가 필요한 경우에만 어플리케이션 레이어에서 처리할 수 있습니다.
하지만 이렇게 하면 metric 계산을 할 수 있지만 request/response body 필드 검색은 힘든데요,
검색에 필요한 필드들만 key/value로 put 할 때부터 미리 지정하거나,설계할 때부터 같은 이름은 같은 타임으로 정한다는 룰이 잘 지켜지는것이라고 생각합니다. 예를들어 id 같은 네이밍은 안쓰는것이죠, userid 가 int, itemid 가 string 일때, 둘다 오브젝트의 id, id라고 했다면 충돌이 발생하지만 네이밍을 잘 선언하는것만으로도 위와같은 스키마 충돌을 쉽게 회피할 수 있습니다.
개인적으로 가장 좋은 방법은 네이밍을 통해 회피하는것인데요, 이건 휴먼에러의 여지가 항상 있는 부분이라 유닛테스트와 코드리뷰가 건전하게 설립되지 않았다면 회피하기 힘들고, 모니터링이 잘 적용되어있지 않다면 발생했을 때 발견하기 힘들다는 위험성이 있습니다. 하지만 이 부분이 잘 지켜졌을 때, 코드의 완성도도 비교적 높아지고 네이밍과 오브젝트간 관계에 대해서도 높은 완성도를 지키는데 도움이 되리라 봅니다.
2개의 좋아요
답변 감사합니다.
질문 글을 게시하고서 우선 적재를 1차로 하고, 분석에 대한 니즈가 생겼을 때 그 환경에 맞도록 제공하자 라고 생각하고 serilog를 이용하여 json 포맷으로 적재를 해두었습니다.
한 번에 분석 레벨까지 가기보다 중간에 로우 데이터를 적재하여 유연하게 다음 작업을 진행하려구요
정성이 담긴 답변을 달아주셔서 감사합니다
분석 니즈가 생기면 또 고민을 해봐야겠네요!
1개의 좋아요