장애 예측

Table of contents

1. 장애 예측 탐지
2. 메뉴이동
3. 장애예측 알림 생성
   1. 탐지 조건
   2. 상세 옵션
4. 장애예측 알림 조회
5. 장애예측 알림 수정
6. 장애예측 알림 삭제
7. 장애예측 알림 시나리오

장애 예측 탐지

임계치 알림은 사용자가 수치를 입력하고, 이상탐지는 최근(과거)의 대한 이상치를 판단했다면, 장애예측은 미래에 대한 이상치를 판단합니다.

최근에 대한 이상치는 판단하지 않습니다.

메뉴이동

클러스터 설정 ➡ 클러스터 환경설정 ➡ 알림 ➡ 장애예측 알림

장애예측 알림 생성

알림 탭의 이상탐지 알림 ‘생성’ 버튼을 이용하여 등록합니다.

탐지 조건

상세 옵션

장애예측 알림의 설정은 대부분 이상탐지와 동일하며, 알고리즘에 대한 선택은 존재하지 않습니다.

• Holt winters 알고리즘 사용

장애예측 알림 조회

알람을 생성하면 좌측 목록에서 바로 확인할 수 있으며, 필터를 통해 원하는 항목만 골라볼 수 있습니다.

장애예측 알림 수정

장애예측 알림 목록에서 수정 버튼을 클릭하면 수정 화면으로 이동합니다. 수정 화면은 생성 화면과 동일한 구조이며, 기존에 입력된 정보가 표시툅니다.

장애예측 알림 삭제

장애예측 알림 목록에서 삭제 버튼을 클릭하면 해당 확장 기능이 삭제됩니다.

장애예측 알림 시나리오

장애예측 알림이 정상적으로 발생하는지 확인하기 위해 테스트 대상 애플리케이션의 ActiveService 값을 기준으로 알림 정책을 생성한다.

ActiveService는 현재 처리 중인 서비스 요청 수를 의미한다. 평상시에는 값이 0으로 수집될 수 있으므로, 본 예제에서는 Query 방식을 사용하여 최소값을 1로 보정한다.

clamp_min(sum(apm_ActiveService{exported_namespace="test1",application="jpetstore"}) by (application), 1)

위 쿼리는 test1 네임스페이스의 jpetstore 애플리케이션에 대한 ActiveService 값을 조회한다. 값이 0인 경우에는 1로 보정하고, 부하 발생 시 증가한 값은 그대로 사용한다.

1. 장애예측 알림 생성

2. 장애예측 알림 생성

장애예측 알림 생성 화면에서 다음 항목을 입력한다.

• 알림 활성화 클릭
• 이름
• 설명

3. 알림 규칙 생성

• 알림 규칙 이름
• 알림 규칙 설명
• Query 선택 - 아래 쿼리를 입력한다.

clamp_min(sum(apm_ActiveService{exported_namespace="test1",application="jpetstore"}) by (application), 1)

• 탐지 방향 - 모두 감지
• 탐지 민감도
  • 상향 초과 - 상
  • 하향 미만 - 상
• 임계 조건 - 보다 크다 / 5

4. 수신자 및 옵션

• 수신자 목록 - 사전에 생성해둔 수신자 선택
• 알림 수준 - 경고
• 모니터링 주기 - */1 * * * *
• 알림 주기 - 1
• 훈련기간 - 최근 1일
• 훈련 스케줄 - */1 * * * *

이후 생성하기 버튼을 클릭한다.

5. 부하 발생

장애예측 정책 생성 후 학습이 완료되면, 테스트용 부하 생성 Deployment를 생성한다.
본 예제에서는 jpetstore의 delay.jsp로 다수의 동시 요청을 보내 ActiveService 값을 증가시킨다.

다음 명령어로 부하 테스트 Deployment를 생성한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jpetstore-thread-bomb
  namespace: test1
spec:
  replicas: 0
  selector:
    matchLabels:
      app: jpetstore-thread-bomb
  template:
    metadata:
      labels:
        app: jpetstore-thread-bomb
    spec:
      containers:
      - name: thread-bomb
        image: curlimages/curl:8.10.1
        command:
        - /bin/sh
        - -c
        - |
          echo "Thread Bomb Started. Target: http://jpetstore.test1:8080/delay.jsp"
          while true; do
            echo "[$(date)] Firing 30 requests..."
            i=1
            while [ $i -le 30 ]; do
              curl -s -o /dev/null -w "request $i: HTTP %{http_code}\n" --max-time 15 http://jpetstore.test1:8080/delay.jsp &
              i=$((i+1))
            done
            wait
            sleep 5
          done

위 Deployment 생성 후, 테스트 시점에 Pod를 실행한다.

kubectl scale deploy -n test1 jpetstore-thread-bomb --replicas=1

Pod가 정상적으로 실행되었는지 확인한다.

kubectl get deploy,pod -n test1 | grep thread-bomb

jpetstore-thread-bomb은 delay.jsp에 30개의 동시 요청을 반복적으로 전송한다. 요청이 일정 시간 지연되면서 처리 중인 요청 수가 증가하고, 이에 따라 ActiveService 값이 임계값 이상으로 상승한다.

6. ActiveService 값 확인

다음 명령어로 ActiveService 값이 임계값보다 크게 증가했는지 확인한다.

kubectl run -n test1 promq --rm -i --restart=Never --image=curlimages/curl:8.10.1 -- \
curl -sG 'http://thanos-querier.acc-system:9090/api/v1/query' \
--data-urlencode 'query=clamp_min(sum(apm_ActiveService{exported_namespace="test1",application="jpetstore"}) by (application), 1)'

결과의 마지막 값이 5보다 크면 이상탐지 알림 조건을 만족한다.

7. 장애예측 알림 확인

모니터링 주기가 지난 뒤 알림이 정상적으로 생성되면, 설정한 수신자에게 알림 메일이 발송된다.

수신자 메일함에서 이상탐지 알림 메일이 도착했는지 확인한다.

또는 콘솔의 모니터링 > 알림 로그 메뉴에서 생성된 알림 이력을 확인할 수 있다.

테스트 이후 부하 발생 시키던 pod는 scale down 하여 부하 테스트를 종료한다.

kubectl scale deploy -n test1 jpetstore-thread-bomb --replicas=0