Spring Boot Actuator

스프링 부트는 애플리케이션에 대해 관리하고 모니터링을 도울 수 있는 추가적인 기능이 포함되어 있습니다.

 

이때 HTTP endpoints, JMX 둘 중 어떠한 방법으로 모니터링하고 관리할 것인지 선택할 수 있습니다.

Auditing, health, metrics 수집까지 거의 대부분 자동적으로 애플리케이션에 적용할 수 있습니다.

 

spring-boot-actuator module을 dependency에 추가함으로 써 매우 쉽게 적용할 수 있습니다.

gradle

dependencies { implementation 'org.springframework.boot:spring-boot-starter-actuator' }

 

Actuator의 용어에 대한 정의는 다음과 같습니다.

액추에이터(actuator)는 무언가를 움직이거나 제어하기 위한 기계 장치를 가리키는 제조 용어입니다.

액추에이터는 작은 변화로부터 많은 양의 움직임을 생성할 수 있다.

 

 

Endpoints

 

액츄에이터의 엔드포인트를 통해 애플리케이션과 상호작용하거나 모니터링할 수 있습니다.

스프링 부트는 몇 가지의 엔드포인트를 내장하여 제공하며 이를 사용자가 추가할 수 있습니다.

 

예를 들어 “health”라는 엔드포인트는 애플리케이션의 health check를 수행합니다.

의존성을 추가하고 스프링 부트 애플리케이션을 시작하니 다음과 같이 1개의 endpoint를 알려줍니다.

2023-02-16 14:06:03 INFO o.s.b.a.e.web.EndpointLinksResolver - Exposing 1 endpoint(s) beneath base path '/actuator’

요청 시 다음과 같은 json 데이터가 오는군요. 이는 노출된 endpoint정보를 제공하는 것입니다.

{
    "_links": {
        "self": {
            "href": "<http://localhost:8080/actuator>",
            "templated": false
        },
        "health": {
            "href": "<http://localhost:8080/actuator/health>",
            "templated": false
        },
        "health-path": {
            "href": "<http://localhost:8080/actuator/health/{*path}>",
            "templated": true
        }
    }
}

 

deafult 설정인 /actuator를 변경하고 싶다면 자동 구성파일인 management.endpoints.web.base-path 속성으로 변경할 수 있다고 합니다.

 

또한 엔드포인트에서 쿼리 파라미터 또는 request body에 사용되는 모든 timestamp는 ISO 8601 형식으로 변환해야 한다고 합니다.

 

액츄에이터의 엔드포인트의 기능이 생각보다 되게 많고 이를 외부에 잘못 노출하게 되면 정말 위험할 것 같다.(가장 우선적으로 /actuator라는 prefix부터 변경해야 할 것 같다.)

 

제공되는 기능을 몇가지 나열하자면

 

caches 정보도 알 수 있고 애플리케이션 bean 정보, 환경변수와 auto-configuration 과정에서 condition 매치와 매치실패 정보도 알려준다는 것 같다.

 

로거 설정도 변경하거나 볼 수 있고 메트릭 정보도 볼 수 있고 requestMapping path도 볼 수 있고

스케줄링 설정도 확인할 수 있고, 서블릿 기반 웹 애플리케이션이라면 스프링 세션 저장소에서 사용

자 세션을 검색하고 삭제할 수 있다.

 

더욱이 shutdown 기능도 있다.

 

Spring MVC, WebFlux기반의 웹 애플리케이션이라면 추가적으로 heapdump 파일을 받을 수 있고

log 파일과 Prometheus 서버에서 스크랩할 수 있는 형식으로 메트릭을 표시할 수 있습니다.

 

추가적으로 이를 위해선 micrometer-registry-prometheus라는 모듈을 추가해야 한다고 합니다.

implementation 'io.micrometer:micrometer-registry-prometheus'

 

기능을 알고나니까 사용하기 무서워졌다.

 

안전하게 사용할 수 없을지 찾아보다가 우형 기술블로그에서 이와 같은 주제의 글이 있어 가져왔다.

 

Security Actuator 안전하게 사용하기 | 우아한 형제들 기술블로그

Security Actuator 안전하게 사용하기 | 우아한형제들 기술블로그

 

핵심 주제는 불필요한 endpoint를 노출시키지 않는 것, 활성화시키지도 않는 것

 

이를 위해 화이트리스트를 적용하는 방식으로 구성하라는 조언이다.

 

기본적으로 모든 endpoint를 disable 상태로 변경하고 필요한 것만 include 하자.

#spring actuator
management.endpoints.enabled-by-default=false
management.endpoint.health.enabled=true

액츄에이터는 다양한 기능을 가졌기에 공격자들의 표적이 될 수 있다.

 

따라서 다른 포트로 actuator를 사용하고 default 경로를 사용하지 않고 변경하여 운영하자.

 

만약 클라우드 기반 배포를 한다면 기본 HTTP 포트를 사용하는 것은 적합한 선택일 수 있다.

 

만약 자체 네트워크에서 실행되는 경우 다른 HTTP 포트를 사용하는 것을 스프링에서는 권고하고 있다.

 

추가적으로 management.server.address 속성을 통해 관리자 주소를 지정할 수 있습니다.

 

해당 속성을 127.0.0.1로 설정하면 외부외서 접근할 수 없습니다.

# Actuator 보안 설정 샘플

# 1. Endpoint all disable
management.endpoints.enabled-by-default = false

# 2. Enable specific endpoints
management.endpoint.info.enabled = true
management.endpoint.health.enabled = true

# 3. Exclude all endpoint for JMX and Expose specific endpoints
management.endpoints.jmx.exposure.exclude = *
management.endpoints.web.exposure.include = info, health

# 4. Use other port for Actuator
management.server.port = [포트번호]

# 5. Change Actuator Default path
management.endpoints.web.base-path = [/변경된 경로]

좋은 정보를 얻었다.

 

여기서 한 가지 고민이 생긴다.

 

요청에 대한 권한을 추가했을 때 이를 어떻게 인증하여 접근하도록 할 것인지 생각해보아야 하고

 

프로메테우스 연동 시 어떤 설정을 해야 하는지 보안에는 문제가 없는지 확인해야 한다.

 

추가적으로 CORS 설정만 체크하고 넘어가자.

management.endpoints.web.cors.allowed-origins=https://example.com
management.endpoints.web.cors.allowed-methods=GET,POST

Metrics

 

스프링 부트 액츄에이터는 Micrometer에 대해 자동 구성과 의존성 관리를 제공한다고 합니다.

Micrometer는 JVM 기반 애플리케이션을 위한 metrics 측정 라이브러리입니다.

 

spring 공식문서의 integration.observaility section에는 간단한 micrometer concepts에 대한 설명이 있습니다.

 

Micrometer는 애플리케이션에서 Metrics, Traces에 대한 Observation concept을 정의한다고 합니다.

 

메트릭을 지원한다는 것은 통계를 수집하기 위해 런타임 동작하는 애플리케이션에서 타이머, 게이지 또는 카운터를 만드는 방법을 제공한다는 것입니다.

메트릭은 에러율을 추적하는데 도움이 되고, 사용량 패턴, 성능 등과 같은 부분에서 도움을 줄 수 있습니다.

 

Traces는 전체 시스템에 대한 총괄적인 시야를 제공합니다. 애플리케이션 경계를 넘나들면서 우리는 특정 요청에 대해서만 추적하거나 전체 완료 상태를 추적할 수 있습니다.

 

스프링 프레임워크는 ObservationRegistry를 설정한다면 codebase의 다양한 부분을 측정할 수 있습니다.

 

Micrometer Observation concepts

• 애플리케이션에서 특정 동작이 발생할 때 Observation을 기록합니다. 이는 ObservationHandler 구현으로 처리됩니다.
  
  
• 각 Observation에는 개별적인 ObservationContext를 가지고 있습니다. 이 context안에는 메타데이터를 추출하기 위한 모든 정보가 들어있습니다. HTTP server observation인 경우 context에는 request, response, exception등과 같은 정보가 들어있습니다.

• 각 Observation에는 KeyValues metadata가 존재합니다.
  
  
• 만약 KeyValues tuple에 대한 값이 가능한 낮고 제한된 수가 있는 경우 이를 low cardinality라고 한다. low cardinality 값은 오직 메트릭에게만 기여한다. high cardinality 값은 제한선이 없고 Traces에만 기여합니다.
  
  

조금 많이 어려운데, 관찰자가 해야 하는 행동에 대해 메트릭과 추적하는 추상화된 계층을 제공한다라고 이해하고 런타임에 발생하는 애플리케이션 동작을 수집하는 것은 메트릭이며 전체 완료 상태와 같은 경계가 필요한 정보는 Traces라는 개념이라고 이해했다.

 

 

그럼 다양하게 지원하는 모니터링 시스템 중 Prometheus 메트릭에 대해 읽어보자.

 

프로메테우스는 개별적인 애플리케이션 인스턴스에서 스크랩하거나 폴링 할 것입니다.

 

스프링 부트는 /actuator/prometheus라는 액츄에이터 엔드포인트를 제공하여 프로메테우스의 스크랩 형식을 전달해 줍니다.

 

스프링 부트 애플리케이션 액츄에이터 ↔ 프로메테우스와 통신하며 액츄에이터가 프로메테우스 포맷에 맞게 데이터를 가공해 준다. 프로메테우스는 해당 정보를 받아 통계를 제공한다.

 

아직 프로메테우스가 어떻게 저장하고 동작하는지 공식문서는 살펴보지는 않았는데, 프로메테우스를 설치한 서버의 하드디스크나 메모리는 사양이 있어야 할 것 같다는 느낌이 세게 온다.

 

기본적으로 /actuator/prometheus는 비활성화되어 있기 때문에 별도의 활성화가 필요하기에 다음과 같이 설정을 진행하자

 

Prometheus를 설치하면 prometheus.yml 파일이 존재합니다.

 

해당 파일에 다음과 같이 형식에 맞춰 입력합니다.

scrape_configs:

 - job_name: "spring"
   metrics_path: "/actuator/prometheus"
   static_configs:

     - targets: ["HOST:PORT"]

 

스프링 부트 액츄에이터가 프로메테우스가 스크랩할 수 있도록 메트릭을 제공하는 설정을 진행하자.

management.endpoint.prometheus.enabled=true
management.metrics.export.prometheus.enabled=true
management.endpoints.web.exposure.include=health,info,prometheus

 

우선 빠른 적용을 위해 여기까지 중단하자 더 읽었다간 테스트 시간이 늦어질 것 같다.

 

다음에는 프로메테우스가 뭔지 알아보고 설치까지 진행해 보자.