0411.txt

안녕하세요 포프입니다.
오늘은 로깅에 대해서 얘기를 좀 해볼게요
프로그램 실행중에 로그 남겨놓고
그걸 나중에 보는
로그를 남기는 이유가 여러가지가 있겠죠
근데 일단
좀 더 로그이야기를 뒤에 하긴 할건데
그전에 한가지 짚고 넘어가야 할 얘기는
가끔
제대로 된 툴을 못만져 본, 개발툴을 못 만져본 사람 중에
디버깅과 로깅을 헷갈리는 사람들이 있어요
그건 확실히 말해주고 갈려고 해요
로그찍는 것은
올바른 디버깅은 아니예요
그냥 디버깅을 못하는 환경에서 로그를 찍어서 디버깅을 하는 것 뿐이지
디버깅을 할 수 있는 환경에서까지 디버거 쓸 줄을 몰라서
로그 찍어가면서 printf 해가면서
아 이 로그가 이거구나 그럼 고쳐야지 이런 건 잘못된 방식 이란 거예요
왜냐면 로그메시지가 만약에
있으면 당연히 고칠 수 있지만
없는 경우에는 다시 로그 메시지 집어넣고 프로그램을 실행을 시켜야 하잖아요
그리고 다시 버그를 발생시켜야 하고
그럼 그 로그보고 고쳐가는 과정이잖아요
근데 디버거 라는게 있거나 어설트가 있으면
그건 실행중에 프로그램이 멈춰 버리거나
아니면 디버거 브레이크 포인트가 걸려서 디버깅을 할 수가 있으니까
코드를 재 컴파일 할 이유는  없는거죠
그래서
제가 학생들을 가르치면서 보지만
학생들을 처음 보면은 애들이 문제 있으면 디버깅을 하는 방법을 가르쳐요
야 브레이크 포인트 여기 걸고
이렇게 이렇게 변수값 봐라
로깅으로 할 수 있는 건 그게 안되죠
브레이크 포인트 안 걸린 상황에서 로그를 찍을 수 있는 건 내가 미리 정해놓은 거만 찍는거지
콜스택이라던가 온갖 변수의 모든 값들  레지스터 값들 메모리 값들 이런 거 찍을 수 없거든요
그래서 그런 것들을 하기 위해서 있는 게 디버깅 툴이고
디버깅과 로깅은 확실히 달라요
디버깅 툴을 쓸줄을 몰라서  로그를 찍고 계시는 프로그래머들이 있다면
제가 예전에 프로그래밍의 절반은
프로그래밍의 절반은
디버깅이라고 말한 비디오가 있어요
그 비디오에서 말한 것 처럼
프로그래밍의 절반을 못하고 있는 거라고 보시면 되요
일단 디버깅과 로깅은 다른거라고 얘길하고 넘어가지만
이제 특히나 웹쪽 개발 하시는 분들
그런 분들은 로깅에 많이 의존할 수 밖에 없는 부분이 있어요 사실은
왜냐면
웹 서버를 로칼에서
어떻게 보면 이것도 개발툴이 구려서의 문제일 수도 있는데
내 컴퓨터에서 서버를 돌리면서 디버깅이 가능해야되고
심지어는 서버에 내 프로그램을 올려서
라이브 서버까지는 안 가더라도 QA서버 정도?
거기서 문제가 있을 때
내가 디버거를 꽂아서 디버깅을 할 수 있다면 로깅이 훨씬 더 필요가 없을 거예요
근데 제가 알고 있기로는 그게 잘 되는
개발툴들이 별로 없어요 현재에 있는거중
가장 편한거는 마이크로 소프트 c# ASP닷넷 코어나 ASP닷넷
이거하고 애져를 꽂았을 때는
실제 라이브 도는 서버에 디버거 꽂아서
내 컴퓨터에서 디버깅이 가능하거든요
그런 경우에는 솔직히 로깅보다는 디버깅이 당연히 중요하지만
진짜로 완벽한 프로덕션 서버에 나갔을 때
심지어 닷넷 애져 이런 좋은 툴을 쓰더라도
정말 완벽한 프로덕션에 나갔을 때는
디버거를 꽂을 수 있는 사람이 거의 없어야 정상이예요
꽂는 것 자체가 시큐리티 브리치 이기 때문에
그런 경우에는 어쩔 수 없이 실서버에서 일어나는 여러가지 문제들을 로깅들을 보면서
문제를 분석하거나 아니면
그런 문제 해결용 로깅이 아니라
단순히 인포메이션 로깅을 하는 경우도 있죠. 뭐가 이렇게 일어났다.
그러면 이제 로깅
에도 두 타입이 생기는 거예요. 하나는 문제 발생을 알기 위한 로깅과
다른 하나는 그냥 많은 정보를 로그에 적어두고
어딘가 보관해놨다가 나중에 뭔가 써야지 이런 개념이예요
그래서 지금
닷넷쪽이나 asp닷넷코어 쪽에 들어오면
대부분의 로깅이 사실은  문제해결로깅이 생각보다 많이 들어갈 일이 없고
있기야 있죠 그러나 정보용 로깅이 더 많아질 가능성이 높고
왜냐면 웬만한 건 다 디버깅이 가능하니까
라이브 서버 나가기 전에
그 외에 자바서버라던가
툴의 상성관계가 안 좋은 툴들을 보면
로그를 엄청나게 박을 수 밖에 없어요 모든 로그를
그럼 이제 로그를 박는 건 좋은데
로그를 박은 다음에 취합하는 거에 문제가 솔직히 가장 큰 문제예요
가장 단순한 로깅을 박는 방법은 대부분
자바서버 하시는 분들에게서 많이 봤는데
파일에 서버를 로깅하는거죠
시스템 printOut 한 다음에 그걸 리디렉트 해서 파일로 적거나 c#도 그러긴 해요
그럼 이제 파일에 적는데 문제는 파일이
적으면 적을수록 용량이 커지잖아요
서버가 일년동안 돌고 있으면 로그가 몇 기가바이트 될 수도 있고 있잖아요.
그러면 이 로그파일을
로테이션이란걸 많이 해요
용량이 100메가가 넘어갈 때 마다 새로운 파일을 만들고 이전 파일은 냅두거나
이런 식으로 로테이션을 하거나 매일 매일 로테이션을 하거나
그래서 로그 로테이션이란게 있고
실제 이 로그 로테이션을
백업을 만들어 놨는데
예전에 있던 로그가 웹서버에 쌓여 가면 갈수록
용량을 먹기때문에 언젠가는 용량이 넘쳐나겠죠
그러면 이걸 또 백업하는 것의 문제도 생겨요
그래서 예전에 서버를 직접 올릴 때에는
이런거 백업하는 스크립트 만들너놓고 별짓 다 했는데
요즘은 클라우드 서버를 많이 쓰기 때문에
이거를 자동으로 해줘야 한다고 생각을 누구나 하잖아요
근데 제가 아마존을 썼을 때 aws
이 로그 로테이션을
설정은 가능한데
생각보다 버튼 한번 딱 클릭으로
되게 해주는 그런 시스템이 거의 없었다고 보면 맞는 것 같아요
그래서 결과적으로는
아까 말했던 파일 기반 로그 로테이션은
플랫폼 프레임워크 asp닷넷코어나 자바스프링
네티로그를 꼽든 제티인가?
뭐 그런 거에 영향을 받을 수 밖에 없죠
왜냐면 파일 생성하는 로직 그 자체가
그 로그 라이브러리의 기본이니까
그래서 오히려 이 로깅 시스템은
요즘 추세가 그런 것도 같고
곧바로 파일 시스템이 아닌
다른 API로 쏘는게 일반적이 되가고 있어요
되게 재밌는게
API나 다른 스토리지
클라우드 스토리지 쪽으로
한때는 저도 되게 많이 고민했던 부분 이고 저도 힘들었던 부분인데
현재 지금 이제 애져에 올리는 상황이 되면은
트레이스 로그를 쓰면 되요
트레이스 로그가 뭐냐면 system.Out 과 같은 거예요
printLine, Console PrintLine
그러면 일단 그 콘솔로 프린트가 되는데
그 뒷단에 이 프린트가 되는 것을
어디로 트랜스포트 할 거냐 파일로 옮길거냐
아니면 여기 API를 쏠거냐 아니면 무슨
다른 API로 쏠거냐
이런 걸 그냥 단순하게 정해줄 수 있어요 플러그인 처럼 집어넣을 수가 있어요
그러면 실제 실행되는 웹 서버 코드는
단순히 로깅을 트레이스 로그를 하는 거죠
뭐 닷넷코어에서는 로그 자체가
아예 프레임워크에 껴서 나오니까 그걸 그냥 쓰면 되고
그럼 그렇게 로깅이 됐을 때
이제 파일 작성하는 트랜스포트는 내가 적겠지만
애져에서 앱 서비스를 쓸 때는 여기다가
어 그래 난 로깅을 파일로그 하고 며칠마다 없어지는 건 좋은데
나는 이거를
애져 블랍 스토리지에 넣을래
해서 스위치 하나 켜고
블랍 스토리지 위치만 정해주면
자동으로 클라우드 스토리지에 들어가요
그럼 그 로그를 언제든지 찾아볼 수는 있죠
문제는 찾아보는 인터페이스가  되게 구려서
되게 복잡하게 찾긴 해야 되지만
어쨌든 로깅은 남고
그 로깅 들어가는 거를
클라우드 스토리지기 때문에 용량은 무한정 늘어나거든요 그럼 늘어나게 두는 거예요
그럼 이제
너무 늘어난다 그러면 360일 정도 지난 로그는 지워라 라는 식으로 날짜를 정해줄 수 있는 방법도 있어요
그래서 로그를 정보용으로 마구마구 모아놓는 로그는  그렇게 하면 훨씬 깔끔하게 처리가 되요. 당연히
그럼 이제 그 다음에 문제는
실제 서버에서 어떤 문제가 발생했을 때
이 로그가 찍혀야되고
로그가 찍히는 것을 한눈에 쉽게 볼 수가 있어야된다.
이런 문제가 생기는거죠
그래서 예전에 몇년전만 하더라도 이제
키바나, 엘라스틱 서치 기반의
로그 취합을 해서
한눈에 보여주게 하는 그런 스택이 되게 유명했었어요
근데 이제
그건 또 개인설치를 되게 많이 해야 되고,
저도 그거를 한 때 서버에 쓸려고
전에 회사 있을 때는 직접 만들어 썼고, 만들어 줬고,
지금 있는 회사에서는 모든게 클라우드 기반이니까
아 이거 차라리 로그 스토리지에는 그런 서비스 찾아서 해보자
그래서 찾아서 엘라스틱 서치 같은 걸 넣어보려 했는데
아무래도 이제 AWS가  굉장히 대세였던 시절이다 보니까
지금도 제일 큰게 AWS지만, 애져는 훨씬 적었어요
AWS용 플러그인 이런 건 있는데
그 플러그인도
애져나 이런곳에서 보는 것 처럼 단순하게 딱  클릭 한번으로 할 수 있는 그런 플러그인이 아니라
되게 복잡하게 설정해줘야 되고
그 설정도 그냥 웹서버 클라우드 포탈에 설정이 아니라
코드 쪽에서 설정도 해야 되고
막 이런 되게 복잡한 게 있었어요
그래서 아 이거 되게 맘에 안든다 라고 하고 있다가
결과적으로 저희가 뭐로 갔냐면
애져 자체에서 제공하는 그런
애플리케이션 인사이트 라고 있어요 정확히 보면은
지금 웹서버가 도는 성능측정이나 그런 걸 위해 만들어놓은
그런 서버라고 해야되나 그런 서비스 인데
그 중에 이제
장점중에 하나는 제가 로깅으로 집어넣는 모든 메시지가
이 애플리케이션 인사이트의 API로 가게 할 수 있는 그런 모듈이 있어요
되게 간단하게 설치가 가능하고
심지어 내가 코드엔 설치를 안하더라도 애져 포탈에서 이미
디플로이 서버 상에서 설치도 가능해요
그러면 일단 제 로그가 모두 여기 다 찍히긴 찍히는거예요
근데 문제는 이게 로그가 90일동안만 가지고 있는 단점도 있고
백업을 할려면 돈을 더 내야되고 이런 문제는 있는데
어차피 아까 말했듯 백업은  블랍 스토리지로 가니까 상관이 없고
그럼 실시간으로 나오는 로그들을
다 취합이 되고 검색도 가능해요
그리고 심지어는 어떤게 시간이 얼마나 걸렸네
리퀘스트가 들어와서 이런 로그를 찍었고
이게 다른 디비를 호출했고
다른 API를 호출했는데
여기 속도가 얼마가 걸렸네 이런 걸 한눈에 보여주는 거고
이거는 웬만한 트래픽 까지는 공짜예요
그래서 되게 유용하게 쓰고 있지만
여기서 한단계 더 나가면 재밌는게 뭐였냐면
저희는 서버쪽에 문제가 있을 때
익셉션이 나는 경우도 있지만 저희 서버는 기본적으로 익셉션이 거의 안나요
그래서 저희 서버는 문제가 있으면
익셉션이 일단 났다
하면 그건 서버상에 문제예요
왜냐면 저희는 기본적으로 코딩 스탠다드 자체가
일반적인 경우에 익셥션을 쓰지 않아요
그래서 익셉션이 난다는 것은 저희가
미리 대처하지 못한 예외상황이 진짜 발생 했다는 거고
그럴 때 익셉션이 뜨면
애플리케이션 인사이트에서
알러트 자체를 만들 수가 있어요
그러면  서버에 익셉션이 뜨는 순간 이메일 쏴라 그래서 이메일을 받아요
이건 좀있다 다시 얘기 할 거지만 메일 포멧 자체가 마음에 들진 않지만
지금 얘기하자, 이메일 포멧은 그냥
서버 익셉션이 났어
지난 몇분동안에 한번이 났어 이거만 보여주고
실제 익셉션이 뭔지는 제가
애져에 들어가서 보긴 봐야되요.
그건 좀 단점이라고 생각하는데
그래서 그 시스템이 있기 때문에 저희도 똑같은 생각을 한 거예요
그러면 우리가 이미
예측을 한 문제거나 아니면 실제 일어나지 말아야 하는 경우들이 있어요
뭐 이건 절대로 널이 될 수 없는데 널이 된다거나
그러면 그런 경우에 저희는 크리티칼 로그를 찍어요
로그레벨 크리티칼 아주 미친듯이
괴로운 일, 안 좋은 일
에러
에러는 그냥 있을 수 있는 일인데 그래도 안 좋은 언젠가는 고쳐야 할 일
저희는 크리티컬이 나면 이거는
정말 119 상황이다 긴급상황이라고 생각을 하고
에러가 나면 뭐 쟁여뒀다가 일주일 뒤에 고치지 라는 그런 생각을 해요
근데 어쨌던 크리티컬이 나든
에러가 나든  저희는 이메일을 받고 싶었어요
근데 문제는 저희가 로그를 찍으면  트레이스 로그가 찍히는 거잖아요
그럼 거기에 분명히 뭐 이게 에러 등급인지 크리티컬 등급인지 찍혀요
그거에 맞게 알러트를 설정할 수 있는 방법이 없었어요 예전엔
그래서 저희가 어떤 걸 했냐면
아 그럼 어떤 걸 알러트를 집어넣을 수 있을까 하고 보니까
메트릭이란 걸로 알러트를 던질 수가 있데요
메트릭이 뭐냐면 제가 제 서버에서 애플리케이션 인사이트로 쏘는 거예요
아 나 가장 간단한거 하면  지금 남아있는
예를 들어서 저희가 유저에게 주는 어카운트가 100개로 정해져 있는데
아 지금 남아있는 어카운트 수가 90개야
이렇게 가끔 쏴주는 그런 API가 있어요
트랙을 하는 거죠 지금 값이 어떻게 되는지
그럼 90 90 90 쏴주다가 이게
40 30 20 까지 가서 딱 10이 되면
이게 그래프가 보여요 서버에서
근데 이게 10 이하로 떨어지는 순간 이메일을 쏴줘
라고 알러트를 정할 수가 있어요.
저희가 딱 그걸 고민하다 보니까
아 그럼 우리가
이 로거를 할때 로깅을 할 때
아까 트랜스포트가 가능하다고 그랬잖아요
그 밑에 이 로그메시지가 어디로 가는지는 우리가 다 플러그인을  꼽아놓을 수 있다
그래서 로거 안에다가
이 매트릭 트래커를 집어 넣었어요
그래서 크리티컬이 날 떄 마다
그냥 애플리케이션 인사이트에
크리티칼 한번 이렇게 딱 찍는거죠
그리고 에러가 날 때 마다 에러 한번 이렇게 찍어줘요
그러면 이게 0으로 있다가
1로 올라가는 순간 0을 넘어서는 순간
알러트를 박아넣으면 되요
아 이게 갑자기 0.5보다 커진 순간에 우리 이메일 쏴줘라.
그래서 저희 알러트 시스템을 그렇게 구축을 했었어요
이제 문제 생길 때 마다
5분마다 문제 생길 때 마다 이메일을 받는 건데
중요한 건 알러트가 만약
메시지가 1로 올라갔어요
에러가 날 때 마다 1을 찍잖아요
근데 에러가 떨어질 때는 0을 찍을 방법이 솔직히 없거든요
모든 로그마다 0을 찍을 수도 없고
그래서 1로 계속 유지가 되요
그럼 더이상 계속 문제가 생기더라도
알러트가 오지 않는 문제가 있었어요
그래서 이거는 그냥
웹 잡이라던가 애져 펑션 같은 거
5분마다 한번씩, 30분마다 한번씩 도는
한번씩 도는 함수를 만들어 두고
그냥 에러 매트릭 0으로 떨어뜨려,
워닝 매트릭 0으로 떨어뜨려
이런 식으로 코드가 따로 돌아요 하나씩 웹잡 서버로
그럼 이제
우리가 어쩌다가 에러가 딱 나서 에러가 1로 딱 올라갔으면 5분뒤에 다시 0을 찍어주니까
어쨋든 0보다는 높고
1보다는 낮은 평균이 생기잖아요 지난 5분간에
이게 계속 0이면 계속 0으로 가는거고
그래서 그런 식으로 해서
계속 5분마다 0으로 쏴주고
그 중간에 한번씩 에러 날 때 마다 크리티컬 에러가 날 때 마다 1로 딱 올라가면서
이메일이 오게 만들었어요
일단 기본적으로
문제가 생길 때 노티피케이션 오니까 좋았죠
그거 때문에
스펨메일 받으니까 귀찮으니까 문제 터지면 고쳐야했고
근데 아까 말했듯이 여기서 문제점은
이 메일 자체에 크리티컬이 났어 라고 밖에 안 보여주는거
그리고 그 다음에 생긴 문제는
좀 지저분하잖아요. 로그를 찍는데 거기다
로그가 에러 크리티컬 올 때 마다
메트릭 쏴주고 있고 이걸 왜 내가 해야되지
이미 이 모든 정보가
애플리케이션 인사이트에 있는데
애가 서치만 되게 만들어주고 그 서치 결과에 따라 얼러트가 나오게 하면 되는건데
라고 생각을 하고 있었죠
근데 최근에
애플리케이션 인사이트에 프리뷰 기능으로
서치 얼러트 라는 기능이 생겼어요
실제 제가 그걸 써봤는데 잘 되요
저희쪽은 앞으로 그쪽으로 이동할 것 같은데
이 개념은 뭐냐면, 서치 쿼리를 만들 수가 있어요
원하는대로,  그럼 제가 쓴 서치 쿼리가 뭐냐면
이 트레이스 로그 중에
지난 5분 동안
크리티컬 있는게 0개 이상
0개 이상이 아니지, 0개를 초과. 0.5개 이상이면
하나라도 있으면
그러면 이건 알러트 조건이다
라고 서치를 만들어두고,  이걸 5분마다 한번씩 실행이 되게 만들 수 있어요
애플리케이션 인사이트 내에서
그리고 이 조건이 만족이 됐을 때
이런 행동들을 하라고 행동들을 정할 수 있는데
행동들이 많이 좋아졌어요
첫번째는  이메일을 쏴라 라는 거고
두번째는
애져 앱이 있거든요 모바일에
그 앱으로 푸시를 쏴라 도 되요.
이 사람 계정으로 그리고
세번째가 제가 굉장히 좋아하는 건데, 웹 훅을 쏴라
웹 훅을 쏘게 되면 이걸
웹훅을 슬랙에 연결하거나 하면
슬랙에 문제가 날 때 마다 메시지를 보낼 수가 있는거예요
야 911 터졌어 긴급상황이야
야 에러 터졌어 이런 식으로
그럼 거기다가 이제 에러 메시지를 자세하게 적고 싶은데
애플리케이션 인사이트에서 보면은
거기에 있어요
최근 25개 문제생긴거25인지 50개인지 그 result를 테이블로 둬서 보내는
웹훅에 보내는 방법이 있는데
문제는 슬랙 자체에서 이 필드를
보질 않죠 슬랙에서 보는 필드는 이미 뭐 타이틀이나 텍스트에 있고
그 밑에 추가 필드는 슬랙이 아무리 받아봐야
보여주질 못하는 거예요
그래서 저는 이제 단계별로 생각하고 있는데
첫번째 단계는 그냥 이메일 쏘고 웹훅 쏘고 문제가 있다고 얘기를 해주자
지금하고 비슷한 거지만 일단 최소한
아까 로그에서 메트릭 쏴주는 일일이 그 짓을 안해도 되니까 그걸 뺄 수 있겠죠
그게 첫번째 단계고
두번째 단계로 제가 생각하는 건
이 웹훅을 보내는게
슬랙으로 직접 보내지 말고 제가 다른 서버를 따로 하나 만들어서
아니면 웹 URL을 하나 만들어서
거기로 받은 다음에 그걸 받으면
거기에 나온 바디에 있는
실제 에러 메시지들이 있어요
이건 로그 에러였고
여기에 에러메시지가 이거였다 그럼 제가 이걸 파싱을 해서
이거를 다시 바디 텍스트에 붙이는 방법, 슬랙이 이해하는
딱 하나 깨끗하게 만들어서, 슬랙에 있는 포매팅 룰 대로
이거를 다시 저희 쪽 슬랙 웹 URL로 쏴주는 거예요
그러면 이제는 앞으로는 문제가 날 떄 마다 이메일이나 이런 건 와야되고
이메일이 온 상황에서
어 에러 메시지가 뭐지? 라고 재빨리 볼 수 있는 방법은
저희쪽 슬랙 방에 들어가서
어 이 에러 메시지구나 야 이거 니문제니까 니가 고쳐
이렇게 빨리 끝낼 수가 있다는 거고
고치는 사람은 실제 애플리케이션 애저 로그인 해서
열심히 보면서 아 이게 문제였고 이런 리퀘스트가 들어왔고
좀 더 자세한 정보를 볼 수 있다는 거죠
그래서 여기까지가 제가 지금  갈려고 하는 방향이에요
문제가 생길 때 로그가 발생하는 것
그럴 경우에 그 로그를 취합해 빨리 보여주고
재빨리 대응할 수 있는 단계까지 가는게 이거겠구나
그래서
최근에 제가 많이 보고 생각하고 또 열심히 만들어 놓은
아키텍쳐 세우고 실험해보고 한 것이기 떄문에
되겠구나 라고 생각하고 있어요
오늘 얘기는  쓸데없이 길었는데
제 시작은 그랬어요 로그와 디버깅은 다른거다
디버깅 할 수 있는 걸 로그로 하고 있다는 것 자체가
개발의 절반 버리고 있는 거다 라고 생각을 하고 있고
두번째 잠깐 지나가는 얘기로는
어쩔 수 없이 로그를 쓸 수 밖에 없는 환경이란 건
생각보다 툴이 구려서 그런 경우가 많으니까
좋은 툴을 쓰는 것이 훨씬 좋다 라는 이야기를 했고
세번째는 결국 프로덕션 단계에서 서버 로그를 취합할 때
로그를 로테이션 하고 파일 로그하고 이런 거 다 있지만
점점 클라우드로 가고 있다는 가정하에
클라우드 상황에서 라면은
아까 말했던 것 처럼 블랍 스토리지나 이런 뭐
아마존이면 S3 스토리지 겠죠
그런 스토리지에 처박는 것 만으로도 로그로 대신 해야 될 문제는
좀 적다 라는게 있고
애져에서는 그걸 단순 정말 트레이스 로그에다가
콘솔로그요
버튼 하나 켜주는 걸로 가능하고
세번째는 라이브 로그의 문제인데
실제 문제가 있을 때 생기는 로그와 정보 로그는 다른 거거든요
문제가 있어 생기는 로그를 처리하는 방법에 대해서
결과적으로는 엘라스틱 서치나
키바나 이런 것 기반으로 하는
아니 그게 이름이 정확하게 뭐였지
키바나는 view 구요
엘라스틱 서치 기반으로 로그를 하는
그게 엘라스틱 서치라고 했나? 예전에 무슨 스택이라고 불렀었거든요 그거를
램프스택 이건 아니고
엘크 스택이라고 불렀어요 엘크
엘라스틱 서치, 로그 스태시, 키바나 이렇게 세가지를 해서 엘크스택이라고 불러서 했었는데
결과적으로는 엘라스틱 서치에 다 쳐박는거예요
로그 스태시는 그냥 로그를 서버에서
가져와서 엘라스틱 서치에 보내주는 이런 개념이었던 것 같고
그럼 그런 API를 쓰거나
그런 엘크스택을 이미 서비스 하는 그런 회사들도 있어요
제가 봤는데 별로 가격대 성능비용 설치비용 등으로 봤을 때
저한테는 정말 별로여서
쓸려고 쓸려고 하다가 말았어요
가입도 되있어 근데 쓸려고 하다보니까 이상해서 못쓰겠어
그 상황에서
클라우드 서비스에서 제공하는 그런 기능들이 나오기 시작하고
애져 단이라면 애플리케이션 인사이트라는
그런 훌륭한 서비스가 존재를 해요
거기에 이제 로그를 쳐박고
쳐박는거도 그냥
애플리케이션
누겟 패키지 하나 깔고 enable 하면 되요 그 순간부터
그러면 그 순간부터 보면 되는 거고
심지어는 제가 로칼에서 디버깅 하는 순간에도 보여요
그 애플리케이션 인사이트에서 정보들이
그거를 쓰면 되고 그럼 그 다음 단계는
문제가 생겼을 때 알러트를 받는 방법
제가 아까 말했던 것 처럼 메트릭을 써서 이상하게 하는 방법도 있고
작년까지는 그것밖에 안 됐어요
작년 중반까지는
이제 로그 서치알러트가 나온 상황에서는
아직 프리뷰지만 그걸 쓰기 시작하면은
이제 이런 쓸데없는거 다 안하고
모든 건 그냥 클라우드에 도는 거고
웹 서버 자체에는  문제가 없는 거고
애플리케이션 인사이트는 다른 서버니까 계들이 자체 제공하는
생각보다 공짜 티어가 굉장히 넓고요
굉장히 용량이 크고 그래서 공짜 TO를 열심히 쓰면서
서버를 잘 분리하면 공짜 TO를 계속 쓸 수  있을것도 같아요
그러면서 이제 로그
알러트 쏴주고, 알러트 쏴줄 때 이메일이나
푸시 노티피케이션 가능하면 당연히 해야되고
그 외에 정보를 빨리 보고싶으면
제가 말했던 방식으로 웹 훅 연결해서
릴레이 하는 방식으로 그렇게 하면
로그의 생성이나 로그의 대응이 굉장히 좋아질거예요
양이 많아서 빨리 얘기 하려고 했는데
너무 빨리 얘기한 것 같아서 죄송하긴 하네요
그정도로 정리가 된 것 같으니까 오늘 이만 끊을게요
포프였습니다.