글 쓰는 시간

Alert rules 설정

이전 글에서는 디스코드 웹 훅을 만들고 그라파나와 연동을 해보았다.

이번 글에서는 그라파나에서 Alert rules에 장애 조건을 설정하고,

장애 발생 시 연동한 디스코드로 경고 메시지를 보내는 설정을 해볼것이다.

구현하기

이번 글에서는 간단히 특정 상황 발생 시 디스코드로 경고 메시지를 발송하는 정도로 구현할 것이다.

기본적으로 그라파나는 프로메테우스 서버에서 받은 데이터를 이용하므로 프로메테우스 서버는 항상 켜져있어야 한다.

순서는 아래와 같다.

1. 그라파나의 Alert rules 설정
2. 결과 확인

1. 그라파나의 Alert rules 설정

다음은 그라파나에서 경고 메시지를 보낼 조건을 설정한다.

우리의 그라파나 서버는 프로메테우스에서 받은 데이터를 토대로 하므로 애플리케이션 상태에 따른 조건을 설정할 수 있다.

프로메테우스 설정을 원하는대로 설정하여 여러 애플리케이션 서버나 DB 서버의 알림 설정을 할 수 있다.

본인은 prometheus.yml 파일을 간단히 아래처럼 설정하였다.

# prometheus.yml
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

# Here it's Prometheus itself.
scrape_configs:
  - job_name: "spring-actuator"
    metrics_path: '/actuator/prometheus'
    scrape_interval: 15s
    static_configs:
      - targets: [ 'localhost:8080' ]

Alerting 탭에서 Alert rules 페이지로 이동하여 새로운 규칙을 추가한다.

1-1. 규칙 이름

규칙 이름을 설정한다.

1-2. 경고 메시지 발송 조건 설정

경고 메시지 발송 조건을 설정한다.

• 최상단의 Query 측에서 프로메테우스(혹은 다른 DataSource)에서 받은 데이터로 쿼리를 작성할 수 있다.
• 아래쪽 Expressions로 Query 결과를 이용한 표현식을 통해 조건을 설정할 수 있다.

필요하다면 Query, Expressions를 추가할 수도 있다.

본인은 Query 결과를 이용하여 Expressions에서 조건을 설정해보았다.

아래 사진의 promQL은 내려가있는 인스턴스가 있는지 확인하는 쿼리이다.

여기서 up은 인스턴스의 활성화 여부이며, 0은 비활성화 상태이고 1은 활성화된 상태임을 뜻한다.

count는 괄호 안의 조건에 맞는 결과의 갯수를 반환한다.

count(up == 0)에서 비활성화 된 인스턴스가 없으면 no data를 반환하므로 OR vector(0) 을 추가하여 0을 반환하도록 한다.

쿼리 값(A 값)이 0보다 크면 경고 메시지를 발송하도록 설정하였다.

1-3. 서비스 상태 확인 간격 및 메시지 발송 시간 설정

Evaluation behavior은 서비스의 상태 확인에 관련된 세부 설정이다.

여기서 서비스 상태를 얼마 간격으로 다시 확인하는지, 장애 발견 후 얼마 뒤에 메시지를 발송할 지 설정한다.

본인은 아래처럼 설정하였다.

ㄴFolder

디렉토리를 설정할 수 있다.

본인은 rules 라는 디렉토리를 만들었다.

ㄴEvaluation group

Evaluation group에서 해당 그룹은 얼마 간격으로 서비스 상태를 다시 확인하는지 설정할 수 있다.

본인은 테스트의 용이성을 위해 아래처럼 10초 간격으로 상태를 다시 확인하는 그룹을 만들고 설정하였다.

ㄴPending peorid

Pending peorid에서 장애 발생 후 얼마 뒤에 메시지를 보낼지 설정한다.

이 또한 테스트 용이성을 위해 10초 간격으로 설정하였다.

1-4. 장애 발생 시 메시지를 전송할 경로 설정

연동한 디스코드 웹 훅 경로로 메시지를 보내도록 Contact point를 지정한다.

1-5. 경고 메시지 내용 설정

아래처럼 경고 메시지 내용을 설정할 수 있다.

Add custom annotation 으로 원하는 내용을 추가할 수도 있다.

본인은 job 이름과 스프링부트 애플리케이션 상태를 확인할 수 있는 패널 경로를 넣어주었다.

여기까지 설정 했으면 우상단의 저장 버튼을 누르면 Alert rule이 추가되고, 아래처럼 추가된 Alert rule을 확인할 수 있다.

2. 결과 확인

알림 설정이 제대로 동작하는지 확인해보기 위해 애플리케이션을 종료해보았다.

아래처럼 디스코드로 설정한 경고 메시지가 잘 전달됨을 확인할 수 있다.

참고자료

서비스 장애 알림

스프링부트 액추에이터, 프로메테우스, 그라파나를 이용하여 메트릭을 수집 및 시각화하였다.

이렇게 메트릭을 수집하면 비즈니스적인 인사이트를 얻을 수도 있지만, 특정 메트릭의 이상 수치 또한 파악할 수 있다.

만약, 이상 수치 또는 비정상적인 응답 값을 보일 때 경고 메시지를 보내도록 알림 설정을 하면 좀 더 빠르게 대처할 수 있을 것이다.

경고 메시지를 전송하도록 설정할 수 있는 방법은 Alert manager, 그라파나 등 여러가지가 있다.

이 중 그라파나가 제공하는 알림 기능을 이용해 디스코드로 경고 메시지를 보내도록 설정해보려 한다.

사실 프로메테우스의 Alert manager로 알림 설정을 해보려 했지만 실패했다.

그 대안으로 선택한게 그라파나이고, 이번 글에서는 디스코드 웹 훅을 만들고 그라파나와 연동을 해볼것이다.

사용 기술

• Spring Boot 3.2.4 / gradle-kotlin
• Java 17
• Spring Boot Actuator, Prometheus, Grafana, Discord

구현하기

순서는 아래와 같다.

1. 디스코드 웹 훅 생성
2. 그라파나와 디스코드 연동
3. 디스코드 연동 확인

1. 디스코드 웹 훅 생성

디스코드와 연동하려면 디스코드의 웹 훅을 만들어둬야 한다.

웹 훅을 만들려면 디스코드 서버 권한이 있어야 하기 때문에 본인은 연습용으로 디스코드 서버를 하나 만들었다.

1-1. 채널 설정창으로 이동

권한이 있는 상태에서 아래처럼 알람을 설정하고자 하는 채널의 톱니 모양 버튼을 누른다.

1-2. 웹 후크 만들기

채널 설정 창에서 연동 탭으로 이동하면 웹 후크 만들기 버튼이 보인다.

1-3. 웹 후크 URL 복사

만들기 버튼으로 들어가면 자동으로 해당 채널에 웹 훅을 생성해준다.

이제 여기서 복사한 웹 후크 URL를 그라파나와 연동한다.

2. 그라파나와 디스코드 연동

1에서 만든 디스코드 웹 훅을 그라파나와 연동할것이다.

2-1. Contact point 추가 페이지로 이동

그라파나의 기본 포트인 localhost:3000으로 접속하고 Alerting 탭에서 Contact point 페이지로 이동하면 아래와 같다.

여기서 Add contact point 버튼을 눌러서 Contact point 추가 페이지로 이동한다.

2-2. 새로운 Contact point 추가

Contact point 이름을 설정해주고, Integration에서 디스코드를 선택한다.

Webhook URL 에 1-3에서 복사한 웹 훅 URL을 넣어준다.

바로 저장을 해도 되지만 Test를 눌러서 원하는대로 연동이 되는지 확인할 수도 있다.

3. 디스코드 연동 확인

3-1. 테스트 연동 메시지 확인

연동이 되었다면 테스트를 눌렀을 때 아래처럼 메시지가 잘 온다

3-2. Contact point 등록 확인

저장 후 Contact points 페이지로 이동하면 우리가 추가한 디스코드 웹 훅이 등록되었음을 확인할 수 있다.

그라파나로 애플리케이션 상태 확인

이전 글에서 로컬에 프로메테우스 및 그라파나를 설치해보고 적용까지 해보았다.

공유 대시보드 중에는 스프링부트 애플리케이션 상태를 확인할 수 있는 대시보드가 있다.

임의로 몇 가지 장애 상황을 만들어보고 이 대시보드로 애플리케이션 상태를 확인해보았다.

장애 상황은 아래와 같이 설정했다.

1. JVM 메모리 고갈
2. 커넥션 풀 고갈
3. error 로그 급증

사용 기술

• Spring Boot 3.2.4 / gradle-kotlin
• Java 17
• Spring Boot Actuator, Prometheus, Grafana

1. memory 고갈

의도적으로 List에 문자열을 채워 애플리케이션의 힙 메모리를 가득 채워보았다.

예시 코드는 아래와 같다.

해당 엔드포인트를 여러번 호출하면서 그래프 추이를 살펴보았다.

TrafficController

private List<String> list = new ArrayList<>();

@GetMapping("/jvm")
public String jvm() {
    log.info("[jvm]");
    for (int i = 0; i < 1000000; i++) {
        list.add("hi" + i);
    }
    return "jvm success";
}

로컬에서 한거라 메모리를 다 채우기 힘들어서 도중에 멈췄지만 아래와 같이 메모리 사용량을 그래프로 확인할 수 있다.

2. Connection pool 고갈

커넥션 풀 고갈을 위해 의도적으로 커넥션을 열고 close() 해주지 않았다.

예시 코드는 아래와 같다.

해당 엔드포인트를 여러번 호출하면서 그래프 추이를 살펴보았다.

TrafficController

@Autowired
DataSource dataSource;

@GetMapping("/jdbc")
public String jdbc() throws SQLException {
    log.info("jdbc");
    Connection conn = dataSource.getConnection();
    // conn.close(); // 커넥션을 닫지 않아본다.
    return "ok";
}

2-1. 정상 상태

Hikari CP 커넥션 풀 기본 설정인 10개 중 8개를 사용해보니 아래와 같은 그래프를 확인할 수 있었다.

2-2. 커넥션 풀 고갈

커넥션 풀을 10개를 다 쓰고 추가로 커넥션 풀이 필요한 요청을 하면 그 요청은 이전 커넥션 풀이 반환될 때 까지 대기상태가 된다.

일정 시간 대기하다가 여전히 사용 가능한 커넥션 풀이 없다면 그 요청은 Timeout이 된다.

요청이 Timeout이 되어 반려되면 아래와 같이 Connection Timeout Count가 올라간다.

3. error 로그 급증

에러 로그를 급증시켜보았다.

예시 코드는 아래와 같다.

해당 엔드포인트를 여러번 호출하면서 그래프 추이를 살펴보았다.

TrafficController

@GetMapping("/error-log")
public String errorLog() {
    log.error("error log");
    return "error";
}

아래처럼 에러로그가 증가하는 그래프를 확인할 수 있었다.