본문 바로가기

전체 글

(285)
모니터링 시스템 구축을 위한 리서치 Index 0) 요구사항 우리팀 서버에 문제가 생겼을 때 알 수 있어야 한다. 현 시스템이 DB 로그에 보는 것에 익숙하지 않다. Kubernates에 접근하기 어려우며, 서버 배포 환경을 이해하기 어려운 구조이다. API Application 필터링 해서 로그를 봐야 한다. Kubernates는 로그를 보는데 가독성이 떨어진다. → 시각화의 필요성 Kubernates 인스턴스 모니터링 + 각각의 pod 요소들의 전반적인 메트릭은 Prometheus가 보기 편하다. 서버 모니터링과 서비스 모니터링의 차이점 서버 모니터링 : 여러대의 서버 중 1대라도 죽는 경우를 모니터링 서비스 모니터링 : 사용자 입장에서 서비스가 안되는 경우가 모니터링 *** 경고 시스템의 구성 요건** 우리 팀이 빠르게 이해할 수 있..
이미지 리소스 한 번에 교체 with SQL postgres DB에 테이블을 만들어서 image 리소스(url 주소)를 관리하고 있었다. -> API로 프론트엔드에 데이터를 내려주기 위해 해당 컬럼에 있는 이미지 url 주소를 SQL 명령어로 한 번에 교체할 수 있었는데, 다음과 같이 진행하였다. UPDATE DB 테이블 이름 SET 업데이트 하고자 하는 테이블의 컬럼 이름 = REPLACE(업데이트 하고자 하는 테이블의 컬럼 이름, '기존 이미지 URL 주소','바꾸고자 하는 이미지 URL 주소') 그리고 나서 db 테이블로 가서 새로고침을 해주니 해당 컬럼의 이미지 경로가 모두 변경되어 있었다. 명령어 한 번으로 컬럼 내부의 데이터를 한 번에 변경할 수 있는 SQL의 장점을 간단하게나마 느낄 수 있는 경험이었다.
timestamp 값이 내려가지 않았던 문제 수정 문제 상황 db 테이블에는 timestamp 컬럼에 값이 존재했는데, timestamp 값이 계속해서 null로 내려가는 문제가 있었다. responseData.data.metadata.attributes.forEach((attribute) => { if (attribute.value === 'Used') { const findHistory = benefitTxHistoryList.find((history) => history.traitType === attribute.type); if (findHistory) { attribute.timestamp = findHistory.timestamp; } else { attribute.timestamp = null; } } else { attribute.time..