서비스 모니터링은 서비스를 운영하는데 매우 중요한 요소이다.Redis는 캐시 용도로 사용되기도 하지만, 빠른 접근이 필요하지만 다소 중요하지 않는 정보를 저장하는 저장소로도 사용이 될 수 있다.이러한 경우에는 데이터가 저장되기 때문에 redis 장애 시 시스템에 문제가 생길 수도 있다.이러한 상황을 빠르게 탐지하고, 사전에 차단하기 위해서는 모니터링 시스템이 필요하다. 기본 구성은 Prometheus, Grafana를 활용한다.   https://kkang-joo.tistory.com/72  https://kkang-joo.tistory.com/76 Redis Exporter 설치prometheus doc의 다양한 exporter : https://prometheus.io/docs/instrumentin..

기존의 Monolithic 방식에서 MSA로 전환되면서 독립성, 확장성과 같은 많은 이점을 얻었다. 하지만, MSA를 적용하며 겪는 단점도 존재한다. 서비스가 분산되어 있어, 서비스 간 통신에 복잡성 증가 장애 추적 및 모니터링에 대한 어려움 Service Discovery : callee 서비스의 논리적, 물리적 위치가 변경되었을 때 caller에서 찾는데 어려움 Circuit breaking : callee 서비스의 문제가 있을 때, caller 서비스에 해당 장애가 전파되지 않도록 하기 위한 추가적인 노력 필요 이러한 단점들을 극복하기 위해서는 MSA 서비스들은 서비스 간 커뮤니케이션을 통제하는 추가적인 로직이 필요하게 된다. 이러한 작업들을 각각의 서비스에 중복으로 넣지 않고 인프라에서 해당 작업..

MSA 환경을 구성하게 되면, 각각의 서비스들의 상태들을 모니터링하는 것이 기존 형식보다는 까다로워진다. 모놀리식인 경우에는 하나의 application으로 구성되어 있어 해당 application의 상태 정보만 잘 모니터링하면 되었지만 각각의 모듈이 나누어진 MSA 환경에서는 모니터링할 target들이 더 많아진다. MSA 환경에서의 모니터링은 Prometheus, Grafana를 통해 이루어질 수 있다. prometheus 메트릭(metric)이라는 데이터 모델을 기반으로 하는 monitoring, alert 툴 Grafana : 메트릭 정보를 시각화해 주는 툴 위의 그림을 기준으로 보면 prometheus를 통해 spring-boot-application의 모니터링 데이터를 수집 grafana에서 ..

grafana docker image https://hub.docker.com/r/grafana/grafana grafana docker compose restart : https://kkang-joo.tistory.com/70 volume : https://kkang-joo.tistory.com/45 privileged : docker container 내에서 host의 리눅스 커널 기능을 모두 사용할 수 있다(host의 주요 자원에 접근 권한 획득) version: "3.8" services: grafana: image: grafana/grafana-oss:9.5.2 container_name: grafana ports: - "3000:3000" volumes: - "grafana_volume:/va..