728x90
한번 더 이야기하지만전투에서 실패한 지휘관은 용서할 수 있지만 경계에서 실패하는 지휘관은 용서할 수 없다는 말이 있다. 이 말을 서비스를 운영하는 개발자에게 맞추어 보면 장애는 언제든지 발생할 수 있다. 하지만 모니터링(경계)은 잘 대응하는 것이 중요하다.
서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련 있는 곳을 빠르게 찾아서 대응할 수 있을 것이다.
세상에는 수 많은 모니터링 툴이 있고, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 된다.
그라파나 대시보드
핀포인트
이런 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다.
(실제로는 라이브러리등을 통해서 자동화되는 경우가 많다.)
모니터링 툴에 지표 전달
- 예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달한다고 가정해보자. 그러면 각각의 정보를 JMX 모니터링 툴이 정한 포멧에 맞추어 측정하고 전달해야 한다.
모니터링 툴 변경
- 그런데 중간에 사용하는 모니터링 툴을 변경하면 어떻게 될까?
- 기존에 측정했던 코드를 모두 변경한 툴에 맞도록 다시 변경해야 한다. 개발자 입장에서는 단순히 툴 하나를 변경했을 뿐인데, 측정하는 코드까지 모두 변경해야 하는 문제가 발생한다.
- 이런 문제를 해결하는 것이 바로 마이크로미터라(Micrometer)는 라이브러리이다.
마이크로미터 추상화
- 마이크로미터는 애플리케이션 메트릭 파사드라고 불리는데, 애플리케이션의 메트릭(측정 지표)을 마이크로미터가 정한 표준 방법으로 모아서 제공해준다.
- 쉽게 이야기해서 마이크로미터가 추상화를 통해서 구현체를 쉽게 갈아끼울 수 있도록 해두었다.
- 보통은 스프링이 이런 추상화를 직접 만들어서 제공하지만, 마이크로미터라는 이미 잘 만들어진 추상화가 있기 때문에 스프링은 이것을 활용한다. 스프링 부트 액츄에이터는 마이크로미터를 기본으로 내장해서 사용한다.
- 로그를 추상화 하는 SLF4J 를 떠올려보면 쉽게 이해가 될 것이다.
- 개발자는 마이크로미터가 정한 표준 방법으로 메트릭(측정 지표)를 전달하면 된다. 그리고 사용하는 모니터링 툴에 맞는 구현체를 선택하면 된다. 이후에 모니터링 툴이 변경되어도 해당 구현체만 변경하면 된다. 애플리케이션 코드는 모니터링 툴이 변경되어도 그대로 유지할 수 있다.
마이크로미터가 지원하는 모니터링 툴
- AppOptics
- Atlas
- CloudWatch
- Datadog
- Dynatrace
- Elastic
- Ganglia
- Graphite
- Humio
- Influx
- Instana
- JMX
- KairosDB
- New Relic
- Prometheus
- SignalFx
- Stackdriver
- StatsD
- Wavefront
각 모니터링 툴에 대한 자세한 내용은 마이크로미터 공식 매뉴얼을 참고하자
728x90
'스프링 부트(핵심 원리와 활용)' 카테고리의 다른 글
| Ch08. 마이크로미터, 프로메테우스, 그라파나 - 다양한 메트릭 (0) | 2023.04.26 |
|---|---|
| Ch08. 마이크로미터, 프로메테우스, 그라파나 - 메트릭 확인하기 (0) | 2023.04.25 |
| Ch07. 액츄에이터 - 액츄에이터와 보안 (0) | 2023.03.29 |
| Ch07. 액츄에이터 - HTTP 요청 응답 기록 (0) | 2023.03.29 |
| Ch07. 액츄에이터 - 로거 (0) | 2023.03.29 |