Page History
...
과거에는, 시스템을 모니터링하기 위해 직접 어플리케이션을 만들어 사용했습니다. 기본적으로 서비스 제어가 가능했으며 CPU/Memory/패킷량등을 주기적으로 수집을 하여 문제발생시 매일 보고가능 기능이였습니다. 과거 손수제작한 모니터링툴 및 일일 보고예:
⇒붉은색 서비스 이상으로 체크대상 하지만 이역시, 운영박스가 늘어남에 따라, Enterprise급의 모니터링툴이 필요했으며, 도입된 것이 OpenNMS였습니다. 개발팀이 성장하고, 수익이 발생하는 시점 특정 도메인 서비스 개발에 집중을 하게되면 스타업일때 제작하였던 툴들을 오픈툴 혹은 상용툴로 교체하게됩니다.
...
이상적 로그 포맺과 활용법
| Code Block | ||
|---|---|---|
| ||
에러 포맺...(공통화 필요) |날짜시간 | 에러레벨 | 쓰레드번호 | APP이름 | 시도사용자 | API,기능이름 | 상세 로그 | 소요시간(적을수 있을시) | [2017-07-28 12:58:30,963] [INFO] [1] [테스트APP] [1234564] [BuyinAPI] [Buyin Job Completed type:C domain:C ,00:00:02.345] 쓰레드번호: 쓰레드 번호를 적는이유? 동시 처리성체크를위해, 쓰레드 개수 최적화 체크및 성능조정을 위해서 시도사용자 : 사용자의 ID를 통해, 해당 사용자에게만 일어나는문제인지? 전체적으로 발생하는 문제인지 확인을 위해서, 사용자와 관련없는 시스템로그는 admin으로 기입 APP이름및 API이름 : 문제를 일으키는 코드를 빠르게 찾기위해서 ( APP가 다중노드일시 APP_1 , APP_2 로 네이밍하여 특정노드만 발생하는 문제인지 빠르게 확인가능) 소요시간 : 주로 완료시 적을수 있으며, 시도-완료 시간의 성능 확인을 위해서, 완료시간-시도시간으로 계산가능하지만 기입시 성능 그래프화가능 (필수값은 아님) 한가지 기능(예>결제)에대해 진행 Step을 세분화해서 로그기록 ( 시도/완료or실패/경고로 스텝별 구분) 코드 표현예: |
...
try{
log.info("결제시도됨......")
시도 코드
실패or성공 코드
log.ok("결제성공",시도후걸린시간) or log.error("결제실패")
}
exception(e){
log.warn(e.text + "성공했는지 실패했는지 모르겠음");
//시도 요청후, 대상 서버에서는 성공을 하였으나, Timeout이 발생하여 결과를 못받는 케이스
(돈은 결제되고,상품을 못받을수 있는케이스)
}
==> 로그를 위와같은 형태로 통일하지 않으면, 부모가 발생한 Exception을 자식도 책임안질시,
알수없는 상위 예외처리기에 의해 적힌 로그로는 해당문제 파악 불가능해짐
로그 패턴예 : 해당로그수는 그래프화가되어 수치화가 되어 비교할수 있어야합니다.
#정상적인 결제 완료
[2017-07-28 12:58:30,963] [INFO] [1] [결제APP_A] [1234564] [결제API_A] [결제가시도됨 {추가정보},NA]
==> 로그 분석방법 2017년 7월28일에 결제APP_A를 1234564 이용자가 결제 API_A를 이용해 결제가 시도됨
[2017-07-28 12:59:30,963] [INFO] [1] [결제APP_A] [1234564] [결제API_A] [결제가완료됨 {추가정보},00:00:01.234567]
#정상적인 결제 실패
[2017-07-28 12:58:30,963] [INFO] [1] [결제APP_A] [1234564] [결제API_A] [결제가시도됨 {추가정보},NA]
[2017-07-28 12:59:30,963] [ERROR] [1] [결제APP_A] [1234564] [결제API_A] [결제가취소됨 {결제실패 Step상세로그},00:00:01.234567]
==> 결제 실패 패턴이 많이 발생시, 명시된 ERROR라 할지라도 해당 세부 Step을 추적필요
#결제가 완료인지 실패인지 모르겠으나 실패로 추측
[2017-07-28 12:58:30,963] [INFO] [1] [결제APP_A] [1234564] [결제API_A] [결제가시도됨 {추가정보},NA]
[2017-07-28 12:59:30,963] [WARN] [1] [결제APP_A] [1234564] [결제API_A] [타이아웃 or 메모리풀 or 디스크풀등등이 발생함 ,00:00:01.234567]
==> WARN에서 메모리풀/디스크풀등이 발생시 FATAL로그 전환 ( 누적되다가 어플리케이션이 의도치 않게 죽게됨)
/ 실제 디스크풀일시는 로그적지못함
/ 메모리풀일시 일시적으로 작동가능 (가비지 컬렉트의 작동으로 메모리확보/풀 반복이일어나며 이로 인해 CPU 100에서 반복되다가 어플리케이션 뻗음)
==> FATAL이라고 판단할지라도 자기자신이 스스로 완료처리없이 어플리케이션을 CLOSE하는것은 위험합니다.
이경우 자신의 Health(하트비트 또는 헬쓰체크)를 남이 체크할수 있는 API를 만들어...., BIGIP(L4) 관리장비에서 특정노드
이상감지시...새로운 사용자가 해당노드에 접근못하도록 해당 노드 접근을 OFF하는 기능을 활용할수 있습니다.
#결제기능 오류
[2017-07-28 12:58:30,963] [INFO] [1] [결제APP_A] [1234564] [결제API_A] [결제가시도됨 {추가정보},NA]
==> 결제가 시도 되지만 완료및 에러가 없음 실제 장애시 많이 발생하는 케이스,"결제가시도됨" 로그수와
"결제가완료됨"+ "결제실패수" 로그수를 비교하여 특정시간에 문제가 발생하는건지?
특정 노드에서만 발생하는지 문제확인필요하며,
데드락/어플리케이션락/전역 Exception핸들링 처리로 발생할수 있는문제 |
정리
로그시스템과 모니터링 시스템은 별개일수 있으나,모니터링에 이상징후를, 로그 시스템에서 검색 또는 반대가 가능하여 서로 연관성을 찾는 것이 중요하다고 생각합니다. 모니터링 시스템의 특정구간 이상 징후가 발생할때, 실제 개발한 서버에서 로그를 발견할수 있다면 발생한 문제에 대해 개선할수 있는 지점을 찾을수 있는 중요한 단서가 될수 있습니다.
...