Skip to content

Commit 45c629d

Browse files
committed
Update SpringBoot Post " 3편. Prometheus와 Grafana로 모니터링 대시보드 구축하기 "
- Update Post " 2025 DevHistory "
1 parent d6cb985 commit 45c629d

File tree

3 files changed

+14
-4
lines changed

3 files changed

+14
-4
lines changed

_posts/2025-01-01-2025-DevHistory.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -46,3 +46,5 @@ author: devFancy
4646
* [2편. Spring Boot 요청 흐름 추적: Logging Filter와 traceId 적용기](https://devfancy.github.io/SpringBoot-Logging-Filter/)
4747

4848
* [쿠폰 시스템 개선기: SETNX에서 Redisson RLock과 AOP를 활용한 분산락 적용](https://devfancy.github.io/SpringBoot-Coupon-System-Redisson/)
49+
50+
* [3편. Prometheus와 Grafana로 Spring Boot 기반 모니터링 대시보드 구축하기](https://devfancy.github.io/SpringBoot-Monitoring-Prometheus-Grafana/)

_posts/2025-06-07-SpringBoot-Monitoring-Prometheus-Grafana.md

Lines changed: 12 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ author: devFancy
1111

1212
이번 포스팅에서는 성능 테스트와 시스템 운영 환경에서 어떤 지표를 주시해야 하는지, 그리고 Spring Boot 환경에서 Prometheus와 Grafana를 활용해 직접 모니터링 환경을 구축한 경험을 공유하고자 합니다.
1313

14-
결국 빠른 응답 시간은 사용자 이탈률을 낮추고, 안정적인 시스템은 비즈니스 신뢰도를 높이기 때문에, 이러한 지표를 꾸준히 관찰하고 개선하는 것은 중요하다고 생각합니다.
14+
빠른 응답 시간은 사용자 이탈률을 낮추고, 안정적인 시스템은 비즈니스 신뢰도를 높입니다. 그렇기 때문에 이러한 지표를 꾸준히 관찰하고 개선하는 것은 매우 중요하다고 생각합니다.
1515

1616
이전 포스팅이었던 “[2편. Spring Boot 요청 흐름 추적: Logging Filter와 traceId 적용기](https://devfancy.github.io/SpringBoot-Logging-Filter/)”에 이어, 이번 글에서는 3편을 작성해보고자 합니다.
1717

@@ -231,11 +231,19 @@ Grafana는 Prometheus가 수집한 데이터를 가장 효과적으로 보여주
231231
232232
### 전체 아키텍처 한눈에 보기
233233
234-
[Spring Boot App] -> [Prometheus Scrapes] -> [Grafana Visualizes] -> [Developer]
234+
![](/assets/img/technology/technology-archtecture-springboot-prometheus-grafana.png)
235235
236-
(그림)
236+
위 아키텍처의 동작 흐름을 간단히 정리하면 다음과 같습니다.
237237
238-
먼저 구성한 모니터링 관련 디렉토리 구조 및 파일 위치는 다음과 같습니다.
238+
* 먼저 Spring Boot 애플리케이션 서버는 `Actuator` 를 통해 자신의 상태 메트릭을 `/actuator/prometheus` 엔드포인트에 노출합니다.
239+
240+
* 그 다음, Prometheus 서버는 주기적으로 이 엔드포인트에 방문하여 메트릭을 수집(Scrape)하고 자신의 시계열 데이터베이스에 저장합니다.
241+
242+
* 마지막으로, Grafana 서버는 Prometheus를 데이터 소스로 사용하여, 저장된 메트릭 데이터를 쿼리(Query)해와서 사용자가 볼 수 있는 대시보드로 시각화합니다.
243+
244+
결국 전체 데이터의 흐름은 **애플리케이션 -> Prometheus (수집/저장) -> Grafana (조회/시각화)** 순서로 이루어집니다.
245+
246+
이러한 아키텍처를 구현하기 위해, 프로젝트의 모니터링 관련 디렉토리 구조는 다음과 같이 구성했습니다.
239247
240248
```yaml
241249
├── infra
184 KB
Loading

0 commit comments

Comments
 (0)