본문으로 바로가기 본문 바로가기
WIKI 기술 지식 베이스

Prometheus·Grafana를 활용한 모니터링과 알림 구성

원문 보기 위키 갱신

StarRocks는 Prometheus와 Grafana를 조합한 모니터링·알림 솔루션을 제공합니다. 클러스터의 동작 상태를 시각화해 운영 상황을 한눈에 파악할 수 있고, 문제 발생 시 원인 추적과 장애 대응도 훨씬 수월해집니다.

출처: 문서

본문

개요

StarRocks는 Prometheus 호환 메트릭 수집 인터페이스를 제공합니다. Prometheus는 BE와 FE 노드의 HTTP 포트에 접속해 StarRocks의 메트릭 정보를 수집하고, 이를 자체 시계열 데이터베이스에 저장합니다. 이어서 Grafana는 Prometheus를 데이터 소스로 사용해 메트릭 정보를 시각화합니다. StarRocks가 제공하는 대시보드 템플릿을 활용하면 StarRocks 클러스터를 손쉽게 모니터링하고, Grafana로 알림까지 구성할 수 있습니다.

MA-1

StarRocks 클러스터를 Prometheus 및 Grafana와 통합하려면 다음 단계를 따릅니다.

  1. 필요한 구성 요소인 Prometheus와 Grafana를 설치합니다.
  2. StarRocks의 핵심 모니터링 메트릭을 파악합니다.
  3. 알림 채널과 알림 규칙을 설정합니다.

1단계: 모니터링 구성 요소 설치

Prometheus와 Grafana의 기본 포트는 StarRocks의 포트와 충돌하지 않습니다. 다만 프로덕션 환경에서는 StarRocks 클러스터와 다른 서버에 배포하는 것이 좋습니다. 리소스 충돌 위험을 줄이고, 서버가 비정상 종료될 때 알림이 함께 멈추는 상황도 예방할 수 있습니다.

또한 Prometheus와 Grafana는 자기 자신의 서비스 가용 여부는 모니터링할 수 없습니다. 따라서 프로덕션 환경에서는 Supervisor로 이 둘에 대한 하트비트(heartbeat) 서비스를 구성해 두는 것을 권장합니다.

이 튜토리얼은 모니터링 노드(IP: 192.168.110.23)에 root OS 사용자로 모니터링 구성 요소를 배포합니다. 대상은 기본 포트를 사용하는 다음 StarRocks 클러스터입니다. 이 튜토리얼을 참고해 여러분의 클러스터에 모니터링 서비스를 구성할 때는 IP 주소만 바꾸면 됩니다.

호스트 IP OS 사용자 서비스
node01 192.168.110.101 root 1 FE + 1 BE
node02 192.168.110.102 root 1 FE + 1 BE
node03 192.168.110.103 root 1 FE + 1 BE

노트

Prometheus와 Grafana는 FE, BE, CN 노드만 모니터링할 수 있으며 Broker 노드는 모니터링 대상이 아닙니다.

1.1 Prometheus 배포

1.1.1 Prometheus 다운로드

StarRocks 용도로는 Prometheus 서버 설치 패키지만 내려받으면 됩니다. 패키지는 모니터링 노드로 내려받습니다.

여기를 클릭해 Prometheus를 다운로드하세요.

LTS 버전인 v2.45.0을 예로 들면, 패키지를 클릭해 내려받습니다.

MA-2

또는 wget 명령으로 내려받을 수도 있습니다.

# The following example downloads the LTS version v2.45.0.
# You can download other versions by replacing the version number in the command.
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz

다운로드가 끝나면 설치 패키지를 모니터링 노드의 /opt 디렉터리로 업로드하거나 복사합니다.

1.1.2 Prometheus 설치

  1. /opt로 이동해 Prometheus 설치 패키지의 압축을 풉니다.

    cd /opt
tar xvf prometheus-2.45.0.linux-amd64.tar.gz

  2. 관리 편의를 위해 압축을 푼 디렉터리 이름을 prometheus로 바꿉니다.

    mv prometheus-2.45.0.linux-amd64 prometheus

  3. Prometheus가 데이터를 저장할 경로를 만듭니다.

    mkdir prometheus/data

  4. 관리 편의를 위해 Prometheus용 systemd 서비스 시작 파일을 만들 수도 있습니다.

    vim /etc/systemd/system/prometheus.service

    파일에 다음 내용을 추가합니다.

    [Unit]
Description=Prometheus service
After=network.target

[Service]
User=root
Type=simple
ExecReload=/bin/sh -c "/bin/kill -1 `/usr/bin/pgrep prometheus`"
ExecStop=/bin/sh -c "/bin/kill -9 `/usr/bin/pgrep prometheus`"
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/prometheus/data --storage.tsdb.retention.time=30d --storage.tsdb.retention.size=30GB

[Install]
WantedBy=multi-user.target

    저장한 뒤 에디터를 종료합니다.

    노트

    Prometheus를 다른 경로에 배포했다면 위 파일의 ExecStart 명령에 적힌 경로도 반드시 함께 맞춰 주세요. 또한 이 파일은 Prometheus 데이터 보존 조건을 "30일 이상" 또는 "30GB 초과"로 설정합니다. 필요에 맞게 수정할 수 있습니다.

  5. Prometheus 구성 파일 prometheus/prometheus.yml을 수정합니다. 이 파일은 내용 형식에 대한 요구가 엄격하므로 수정할 때 공백과 들여쓰기에 특히 유의해야 합니다.

    vim prometheus/prometheus.yml

    파일에 다음 내용을 추가합니다.

    global:
  scrape_interval: 15s # Set the global scrape interval to 15s. The default is 1 min.
  evaluation_interval: 15s # Set the global rule evaluation interval to 15s. The default is 1 min.
scrape_configs:
  - job_name: 'StarRocks_Cluster01' # A cluster being monitored corresponds to a job. You can customize the StarRocks cluster name here.
    metrics_path: '/metrics'    # Specify the Restful API for retrieving monitoring metrics.
    static_configs:
    # The following configuration specifies an FE group, which includes 3 FE nodes.
    # Here, you need to fill in the IP and HTTP ports corresponding to each FE.
    # If you modified the HTTP ports during cluster deployment, make sure to adjust them accordingly.
      - targets: ['192.168.110.101:8030','192.168.110.102:8030','192.168.110.103:8030']
        labels:
          group: fe
    # The following configuration specifies a BE group, which includes 3 BE nodes.
    # Here, you need to fill in the IP and HTTP ports corresponding to each BE.
    # If you modified the HTTP ports during cluster deployment, make sure to adjust them accordingly.
      - targets: ['192.168.110.101:8040','192.168.110.102:8040','192.168.110.103:8040']
        labels:
          group: be

    note

    Prometheus는 클러스터를 스케일 인/아웃한 뒤의 서비스 변화(targets)를 자동으로 감지하지 못합니다. 예를 들어 AWS에 배포된 클러스터라면 Prometheus 서비스를 호스팅하는 EC2 인스턴스에 ec2:DescribeInstances와 ec2:DescribeTags 권한을 부여하고, prometheus/prometheus.yml에 ec2_sd_configs와 relabel_configs 속성을 추가할 수 있습니다. 자세한 방법은 부록 - Prometheus 서비스 디스커버리 활성화를 참고하세요.

    구성 파일을 수정한 뒤에는 promtool로 수정 내용이 유효한지 검증할 수 있습니다.

    ./prometheus/promtool check config prometheus/prometheus.yml

    다음 메시지가 나오면 검증에 통과한 것이므로 이후 단계로 진행할 수 있습니다.

    SUCCESS: prometheus/prometheus.yml is valid prometheus config file syntax

  6. Prometheus를 시작합니다.

    systemctl daemon-reload
systemctl start prometheus.service

  7. Prometheus 상태를 확인합니다.

    systemctl status prometheus.service

    Active: active (running)이 반환되면 Prometheus가 정상적으로 시작된 것입니다.

    netstat로 Prometheus 기본 포트(9090)의 상태를 확인할 수도 있습니다.

    netstat -nltp | grep 9090

  8. Prometheus가 부팅 시 자동으로 시작되도록 설정합니다.

    systemctl enable prometheus.service

기타 명령:

  • Prometheus 중지.

    systemctl stop prometheus.service

  • Prometheus 재시작.

    systemctl restart prometheus.service

  • 실행 중인 설정을 다시 로드.

    systemctl reload prometheus.service

  • 부팅 시 자동 시작 비활성화.

    systemctl disable prometheus.service

1.1.3 Prometheus 접속

브라우저로 Prometheus 웹 UI에 접속할 수 있으며 기본 포트는 9090입니다. 이 튜토리얼의 모니터링 노드라면 192.168.110.23:9090에 접속합니다.

Prometheus 홈페이지 상단 메뉴에서 Status --> Targets로 이동합니다. 여기에서 prometheus.yml 파일에 구성한 각 그룹 잡(job)의 모니터링 대상 노드를 모두 볼 수 있습니다. 보통 모든 노드의 상태가 UP이어야 하며, 이는 서비스 통신이 정상임을 의미합니다.

MA-3

여기까지 완료되면 Prometheus 구성과 설치가 끝난 것입니다. 더 자세한 내용은 Prometheus 문서를 참고하세요.

1.2 Grafana 배포

1.2.1 Grafana 다운로드

여기를 클릭해 Grafana를 다운로드하세요.

또는 wget 명령으로 Grafana RPM 설치 패키지를 내려받을 수 있습니다.

# The following example downloads the LTS version v10.0.3.
# You can download other versions by replacing the version number in the command.
wget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.0.3-1.x86_64.rpm

1.2.2 Grafana 설치

  1. yum 명령으로 Grafana를 설치합니다. 이 명령은 Grafana에 필요한 의존성도 함께 설치합니다.

    yum -y install grafana-enterprise-10.0.3-1.x86_64.rpm

  2. Grafana를 시작합니다.

    systemctl start grafana-server.service

  3. Grafana 상태를 확인합니다.

    systemctl status grafana-server.service

    Active: active (running)이 반환되면 Grafana가 정상적으로 시작된 것입니다.

    netstat로 Grafana 기본 포트(3000)의 상태를 확인할 수도 있습니다.

    netstat -nltp | grep 3000

  4. Grafana가 부팅 시 자동으로 시작되도록 설정합니다.

    systemctl enable grafana-server.service

기타 명령:

  • Grafana 중지.

    systemctl stop grafana-server.service

  • Grafana 재시작.

    systemctl restart grafana-server.service

  • 부팅 시 자동 시작 비활성화.

    systemctl disable grafana-server.service

더 자세한 내용은 Grafana 문서를 참고하세요.

1.2.3 Grafana 접속

브라우저로 Grafana 웹 UI에 접속할 수 있으며 기본 포트는 3000입니다. 이 튜토리얼의 모니터링 노드라면 192.168.110.23:3000에 접속합니다. 로그인에 필요한 기본 사용자 이름과 비밀번호는 모두 admin입니다. 처음 로그인하면 Grafana가 기본 로그인 비밀번호를 변경하라고 안내합니다. 당장 건너뛰고 싶다면 Skip을 클릭하면 되고, 이후 Grafana 웹 UI 홈페이지로 이동합니다.

MA-4

1.2.4 데이터 소스 구성

왼쪽 위 메뉴 버튼을 클릭해 Administration을 펼친 다음 Data sources를 클릭합니다.

MA-5

나타난 페이지에서 Add data source를 클릭하고 Prometheus를 선택합니다.

MA-6

MA-7

Grafana와 Prometheus 서비스를 연동하려면 다음 구성 항목을 수정해야 합니다.

  • Name: 데이터 소스의 이름입니다. 원하는 이름으로 지정할 수 있습니다.

    MA-8

  • Prometheus Server URL: Prometheus 서버의 URL이며, 이 튜토리얼에서는 http://192.168.110.23:9090입니다.

    MA-9

구성이 끝나면 Save & Test를 클릭해 설정을 저장하고 테스트합니다. Successfully queried the Prometheus API 문구가 표시되면 데이터 소스에 접근할 수 있다는 뜻입니다.

MA-10

1.2.5 대시보드 구성

  1. 사용 중인 StarRocks 버전에 맞는 대시보드 템플릿을 내려받습니다.

    노트

    템플릿 파일은 Grafana 웹 UI를 통해 업로드해야 합니다. 따라서 템플릿 파일은 모니터링 노드가 아니라 Grafana에 접속할 때 쓰는 컴퓨터에 내려받아야 합니다.

  2. 대시보드 템플릿을 구성합니다.

    왼쪽 위 메뉴 버튼을 클릭하고 Dashboards를 클릭합니다.

    MA-11

    나타난 페이지에서 New 버튼을 펼치고 Import를 클릭합니다.

    MA-12

    새 페이지에서 Upload Dashboard JSON file을 클릭하고 앞서 내려받은 템플릿 파일을 업로드합니다.

    MA-13

    파일을 업로드한 후 대시보드 이름을 바꿀 수 있습니다. 기본 이름은 StarRocks Overview입니다. 그다음 데이터 소스를 선택하는데, 앞서 만든 데이터 소스(starrocks_monitor)를 지정합니다. 마지막으로 Import를 클릭합니다.

    MA-14

    가져오기가 완료되면 StarRocks 대시보드가 표시됩니다.

    MA-15

1.2.6 Grafana로 StarRocks 모니터링

Grafana 웹 UI에 로그인한 뒤 왼쪽 위 메뉴 버튼을 클릭하고 Dashboards를 클릭합니다.

MA-16

나타난 페이지에서 General 디렉터리 아래의 StarRocks Overview를 선택합니다.

MA-17

StarRocks 모니터링 대시보드에 들어가면 화면 오른쪽 위에서 페이지를 수동으로 새로 고치거나 자동 새로 고침 주기를 설정해 StarRocks 클러스터 상태를 모니터링할 수 있습니다.

MA-18

2단계: 핵심 모니터링 메트릭 이해

개발, 운영, DBA 등 다양한 요구를 충족하기 위해 StarRocks는 폭넓은 모니터링 메트릭을 제공합니다. 이 절에서는 실무에서 자주 쓰이는 중요 메트릭과 그에 대한 알림 규칙만 소개합니다. 나머지 메트릭의 자세한 내용은 Monitoring Metrics를 참고하세요.

2.1 FE 및 BE 상태 메트릭

메트릭 설명 알림 규칙 참고
Frontends Status FE 노드 상태입니다. 살아 있는 노드는 1로 표시되고, 죽은(DEAD) 노드는 0으로 표시됩니다. 모든 FE 노드의 상태가 alive여야 하며, 상태가 DEAD인 FE 노드가 있으면 알림을 발생시켜야 합니다. FE나 BE 노드 중 하나라도 장애가 나면 치명적인 상황으로 간주하며, 원인을 신속하게 파악하는 트러블슈팅이 필요합니다.
Backends Status BE 노드 상태입니다. 살아 있는 노드는 1로 표시되고, 죽은(DEAD) 노드는 0으로 표시됩니다. 모든 BE 노드의 상태가 alive여야 하며, 상태가 DEAD인 BE 노드가 있으면 알림을 발생시켜야 합니다.

2.2 쿼리 실패 메트릭

메트릭 설명 알림 규칙 참고
Query Error 1분 내 쿼리 실패(타임아웃 포함) 비율입니다. 값은 1분간 실패한 쿼리 수를 60초로 나누어 계산합니다. 실제 비즈니스 QPS에 맞춰 구성하면 됩니다. 예를 들어 0.05를 초기 설정값으로 쓸 수 있고, 이후 필요에 따라 조정합니다. 보통 쿼리 실패율은 낮게 유지되어야 합니다. 이 임계값을 0.05로 설정하면 1분에 최대 3번의 실패 쿼리를 허용한다는 의미입니다. 이 항목에서 알림이 오면 리소스 사용률을 점검하거나 쿼리 타임아웃을 적절히 구성하면 됩니다.

2.3 외부 동작 실패 메트릭

메트릭 설명 알림 규칙 참고
Schema Change Schema Change 작업의 실패율입니다. Schema Change는 저빈도 작업입니다. 이 항목은 실패하는 즉시 알림을 보내도록 설정할 수 있습니다. 보통 Schema Change 작업은 실패해서는 안 됩니다. 이 항목에서 알림이 발생하면 Schema Change 작업의 메모리 제한(기본값 2GB)을 늘리는 방안을 고려할 수 있습니다.

2.4 내부 동작 실패 메트릭

메트릭 설명 알림 규칙 참고
BE Compaction Score 모든 BE 노드 중 가장 높은 Compaction Score로, 현재 컴팩션 압력을 나타냅니다. 일반적인 오프라인 시나리오에서는 이 값이 보통 100 미만입니다. 다만 대량의 로딩 작업이 몰리면 Compaction Score가 크게 올라갈 수 있습니다. 대부분의 경우 이 값이 800을 넘으면 개입이 필요합니다. 보통 Compaction Score가 1000을 넘으면 StarRocks가 "Too many versions" 오류를 반환합니다. 이런 경우 로딩 동시성과 빈도를 줄이는 방안을 고려할 수 있습니다.
Clone tablet 클론(clone) 작업의 실패율입니다. 이 항목은 실패하는 즉시 알림을 보내도록 설정할 수 있습니다. 이 항목에서 알림이 발생하면 BE 노드 상태, 디스크 상태, 네트워크 상태를 확인하세요.

2.5 서비스 가용성 메트릭

메트릭 설명 알림 규칙 참고
Meta Log Count FE 노드의 BDB 메타데이터 로그 항목 수입니다. 100,000을 초과하면 즉시 알림을 발생시키도록 구성하는 것이 권장됩니다. 기본적으로 리더 FE 노드는 로그 수가 50,000을 넘으면 체크포인트를 수행해 로그를 디스크로 플러시합니다. 이 값이 50,000을 크게 벗어나면 보통 체크포인트 실패를 의미합니다. fe.conf의 Xmx 힙 메모리 구성이 적절한지 확인하세요.

2.6 시스템 부하 메트릭

메트릭 설명 알림 규칙 참고
BE CPU Idle BE 노드의 CPU idle 비율입니다. 30초 연속으로 idle 비율이 10% 미만이면 알림을 발생시키도록 구성하는 것이 권장됩니다. CPU 리소스 병목을 모니터링하는 데 쓰이는 항목입니다. CPU 사용률은 변동 폭이 커서 폴링 간격을 짧게 잡으면 오탐이 발생할 수 있습니다. 따라서 실제 비즈니스 상황에 맞게 조정이 필요합니다. 배치 작업이 여러 개 돌거나 쿼리가 많다면 임계값을 낮게 설정하는 방안도 고려할 수 있습니다.
BE Mem BE 노드의 메모리 사용량입니다. 각 BE의 가용 메모리 크기의 90%로 구성하는 것이 권장됩니다. 이 값은 Process Mem 값과 같으며, BE의 기본 메모리 제한은 서버 메모리 크기의 90%입니다(be.conf의 mem_limit 구성으로 제어). 같은 서버에 다른 서비스를 배포했다면 OOM을 피하도록 이 값을 반드시 조정하세요. 이 항목의 알림 임계값은 BE의 실제 메모리 제한의 90%로 설정해 BE 메모리 리소스가 병목에 도달했는지 확인할 수 있게 하는 것이 좋습니다.
Disks Avail Capacity 각 BE 노드의 로컬 디스크 가용 공간 비율(%)입니다. 값이 20% 미만이면 알림을 발생시키도록 구성하는 것이 권장됩니다. 비즈니스 요구 사항에 맞춰 StarRocks에 충분한 가용 공간을 확보하기를 권장합니다.
FE JVM Heap Stat 클러스터 내 각 FE 노드의 JVM 힙 메모리 사용 비율입니다. 값이 80% 이상이면 알림을 발생시키도록 구성하는 것이 권장됩니다. 이 항목에서 알림이 발생하면 fe.conf의 Xmx 힙 메모리 구성을 늘리는 것이 권장됩니다. 그렇지 않으면 쿼리 효율에 영향을 주거나 FE OOM 문제로 이어질 수 있습니다.

3단계: 이메일 알림 구성

3.1 SMTP 서비스 구성

Grafana는 이메일, 웹훅(webhook) 등 다양한 알림 방식을 지원합니다. 이 튜토리얼에서는 이메일을 예로 듭니다.

이메일 알림을 활성화하려면 먼저 Grafana에 SMTP 정보를 구성해 Grafana가 여러분의 메일함으로 메일을 보낼 수 있게 해야 합니다. 널리 쓰이는 이메일 서비스 대부분은 SMTP 서비스를 지원하며, 자신의 이메일 계정에서 SMTP 서비스를 활성화하고 인증 코드(authorization code)를 발급받아야 합니다.

이 과정을 마친 뒤 Grafana가 배포된 노드에서 Grafana 구성 파일을 수정합니다.

vim /usr/share/grafana/conf/defaults.ini

예시:

###################### SMTP / Emailing #####################
[smtp]
enabled = true
host = <smtp_server_address_and_port>
user = johndoe@gmail.com
# If the password contains # or ; you have to wrap it with triple quotes.Ex """#password;"""
password = ABCDEFGHIJKLMNOP  # The authorization password obtained after enabling SMTP.
cert_file =
key_file =
skip_verify = true  ## Verify SSL for SMTP server
from_address = johndoe@gmail.com  ## Address used when sending out emails.
from_name = Grafana
ehlo_identity =
startTLS_policy =

[emails]
welcome_email_on_sign_up = false
templates_pattern = emails/*.html, emails/*.txt
content_types = text/html

다음 구성 항목을 수정해야 합니다.

  • enabled: Grafana가 이메일 알림을 보낼 수 있는지 여부입니다. true로 설정합니다.
  • host: 사용 중인 이메일의 SMTP 서버 주소와 포트로, 콜론(:)으로 구분합니다. 예: smtp.gmail.com:465.
  • user: SMTP 사용자 이름입니다.
  • password: SMTP를 활성화한 뒤 발급받은 인증 비밀번호입니다.
  • skip_verify: SMTP 서버의 SSL 검증을 건너뛸지 여부입니다. true로 설정합니다.
  • from_address: 알림 이메일을 보낼 때 사용하는 이메일 주소입니다.

구성이 끝나면 Grafana를 재시작합니다.

systemctl daemon-reload
systemctl restart grafana-server.service

3.2 알림 채널 만들기

알림이 발생했을 때 담당자에게 어떻게 통지할지 지정하려면 Grafana에 알림 채널(Contact Point)을 만들어야 합니다.

  1. Grafana 웹 UI에 로그인하고 왼쪽 위 메뉴 버튼을 클릭해 Alerting을 펼친 다음 Contact Points를 선택합니다. Contact points 페이지에서 Add contact point를 클릭해 새 알림 채널을 만듭니다.

    MA-19

  2. Name 필드에 contact point의 이름을 지정합니다. 그다음 Integration 드롭다운 목록에서 Email을 선택합니다.

    MA-20

  3. Addresses 필드에 알림을 받을 담당자의 이메일 주소를 입력합니다. 주소가 여러 개라면 세미콜론(;), 쉼표(,) 또는 줄바꿈으로 구분합니다.

    페이지의 구성은 다음 두 항목을 제외하고 기본값으로 두어도 됩니다:

    • Single email: 활성화하면 담당자가 여러 명일 때 알림을 한 통의 이메일로 보냅니다. 이 항목을 활성화하는 것이 권장됩니다.
    • Disable resolved message: 기본적으로 알림의 원인이 해결되면 Grafana가 서비스 복구 알림을 한 번 더 보냅니다. 이 복구 알림이 필요 없다면 이 항목을 비활성화할 수 있습니다. 다만 비활성화는 권장하지 않습니다.

  4. 구성이 끝나면 페이지 오른쪽 위의 Test 버튼을 클릭합니다. 나타나는 프롬프트에서 Sent test notification을 클릭합니다. SMTP 서비스와 주소 구성이 올바르다면 대상 이메일 계정에 "TestAlert Grafana"라는 제목의 테스트 메일이 도착합니다. 테스트 알림 메일 수신을 확인했다면 페이지 하단의 Save contact point 버튼을 클릭해 구성을 마무리합니다.

    MA-21

    MA-22

"Add contact point integration"으로 각 contact point에 여러 통지 방식을 추가할 수도 있지만, 여기서는 자세히 다루지 않습니다. Contact Points에 대한 자세한 내용은 Grafana 문서를 참고하세요.

이후 설명을 위해 이 단계에서 서로 다른 이메일 주소를 사용하는 "StarRocksDev"와 "StarRocksOp" 두 개의 contact point를 만들었다고 가정합니다.

3.3 알림 정책 설정

Grafana는 알림 정책(notification policy)으로 contact point와 알림 규칙을 연결합니다. 알림 정책은 매칭 라벨을 활용해 서로 다른 알림을 서로 다른 담당자에게 유연하게 라우팅하며, 운영 중 알림 그룹화도 가능하게 합니다.

  1. Grafana 웹 UI에 로그인하고 왼쪽 위 메뉴 버튼을 클릭해 Alerting을 펼친 다음 Notification policies를 선택합니다.

    MA-23

  2. Notification policies 페이지에서 Default policy 오른쪽의 더 보기(...) 아이콘을 클릭하고 Edit를 눌러 Default policy를 수정합니다.

    MA-24

    MA-25

    알림 정책은 트리 구조를 이루며, Default policy는 알림의 기본 루트 정책입니다. 다른 정책이 설정되어 있지 않으면 모든 알림 규칙이 이 정책에 기본 매칭되고, 여기에 구성된 기본 contact point로 알림을 보냅니다.

    1. Default contact point 필드에서 앞서 만든 contact point를 선택합니다. 예를 들어 "StarRocksOp"입니다.

    2. Group by는 Grafana Alerting의 핵심 개념으로, 성격이 비슷한 알림 인스턴스를 하나의 파이프라인으로 묶는 기능입니다. 이 튜토리얼에서는 그룹화를 다루지 않으므로 기본 설정을 사용하면 됩니다.

      MA-26

    3. Timing options 필드를 펼치고 Group wait, Group interval, Repeat interval을 구성합니다.

      • Group wait: 새 알림이 새 그룹을 만든 뒤 첫 알림을 보내기까지 기다리는 시간입니다. 기본값 30초.
      • Group interval: 이미 존재하는 그룹에 대해 알림을 보내는 간격입니다. 기본값은 5분이며, 이전 알림 발송 후 5분이 지나기 전에는 이 그룹에 알림을 보내지 않는다는 의미입니다. 즉 해당 알림 인스턴스의 알림 규칙 간격이 더 짧더라도, 마지막 업데이트 배치가 전달된 뒤 5분(기본값)이 지나기 전에는 알림이 발송되지 않습니다.
      • Repeat interval: 알림을 성공적으로 보낸 뒤 다시 보내기까지 기다리는 시간입니다. 이미 존재하는 그룹에 대해 알림을 보내는 간격입니다. 기본값은 5분이며, 이전 알림 발송 후 5분이 지나기 전에는 이 그룹에 알림을 보내지 않는다는 의미입니다.

      아래와 같이 파라미터를 구성하면 Grafana는 다음 규칙으로 알림을 보냅니다. 알림 조건이 충족되면 0초(Group wait) 후 첫 알림 이메일을 보내고, 그 뒤로는 1분(Group interval + Repeat interval)마다 알림을 다시 보냅니다.

      MA-27

      노트

      앞 문단에서 "알림 임계값에 도달"이 아니라 "알림 조건이 충족"이라는 표현을 쓴 것은 오탐을 피하기 위해서입니다. 임계값에 도달한 뒤 일정 시간이 지난 시점에 알림이 발생하도록 설정하는 것이 권장됩니다.

  3. 구성이 끝나면 Update default policy를 클릭합니다.

  4. 중첩 정책(nested policy)을 만들어야 한다면 Notification policies 페이지에서 New nested policy를 클릭합니다.

    중첩 정책은 라벨로 매칭 규칙을 정의합니다. 중첩 정책에서 정의한 라벨은 이후 알림 규칙을 구성할 때 매칭 조건으로 쓸 수 있습니다. 다음 예는 라벨을 Group=Development_team으로 구성한 것입니다.

    MA-28

    Contact point 필드에서 "StarRocksDev"를 선택합니다. 이렇게 하면 Group=Development_team 라벨로 알림 규칙을 구성했을 때 "StarRocksDev"가 알림을 받도록 지정됩니다.

    중첩 정책이 부모 정책의 타이밍 옵션을 상속하게 할 수도 있습니다. 구성이 끝나면 Save policy를 클릭해 정책을 저장합니다.

    MA-29

알림 정책의 세부 동작이 궁금하거나 비즈니스에 더 복잡한 알림 시나리오가 필요하다면 Grafana 문서에서 더 많은 정보를 확인할 수 있습니다.

3.4 알림 규칙 정의

알림 정책 설정을 마쳤다면 StarRocks에 대한 알림 규칙도 정의해야 합니다.

Grafana 웹 UI에 로그인한 뒤 앞서 구성한 StarRocks Overview 대시보드를 검색해 이동합니다.

MA-30

MA-31

3.4.1 FE 및 BE 상태 알림 규칙

StarRocks 클러스터에서는 모든 FE와 BE 노드의 상태가 alive여야 합니다. 상태가 DEAD인 노드가 있으면 알림을 발생시켜야 합니다.

다음 예는 StarRocks Overview 아래의 Frontends Status와 Backends Status 메트릭을 사용해 FE와 BE 상태를 모니터링합니다. Prometheus에는 여러 StarRocks 클러스터를 등록할 수 있으므로, Frontends Status와 Backends Status 메트릭은 등록된 모든 클러스터를 대상으로 한다는 점에 유의하세요.

FE 알림 규칙 구성

Frontends Status에 대한 알림을 구성하려면 다음 절차를 따릅니다.

  1. Frontends Status 모니터링 항목 오른쪽의 더 보기(...) 아이콘을 클릭하고 Edit를 클릭합니다.

    MA-32

  2. 새 페이지에서 Alert를 선택한 다음 이 패널에서 Create alert rule을 클릭해 규칙 생성 페이지로 들어갑니다.

    MA-33

  3. Rule name 필드에 규칙 이름을 지정합니다. 기본값은 모니터링 메트릭의 제목입니다. 클러스터가 여러 개라면 구분을 위해 클러스터 이름을 접두사로 붙일 수 있습니다. 예: "[PROD]Frontends Status".

    MA-34

  4. 다음과 같이 알림 규칙을 구성합니다.

    1. Grafana managed alert를 선택합니다.
    2. 섹션 B에서 규칙을 (up{group="fe"})로 수정합니다.
    3. 섹션 A 오른쪽의 삭제 아이콘을 클릭해 섹션 A를 제거합니다.
    4. 섹션 C에서 Input 필드를 B로 수정합니다.
    5. 섹션 D에서 조건을 IS BELOW 1로 수정합니다.

    이 설정을 마치면 페이지는 다음 그림과 같이 표시됩니다.

    MA-35

    자세한 설명 보기

    Grafana에서 알림 규칙을 구성하는 절차는 보통 세 단계로 이루어집니다.

    1. PromQL 쿼리로 Prometheus에서 메트릭 값을 가져옵니다. PromQL은 Prometheus가 개발한 데이터 쿼리 DSL 언어이며, 대시보드의 JSON 템플릿에서도 사용됩니다. 각 모니터링 항목의 expr 속성이 해당 PromQL에 대응합니다. 규칙 설정 페이지에서 Run queries를 클릭하면 쿼리 결과를 볼 수 있습니다.
    2. 위 쿼리 결과 데이터에 함수와 모드를 적용해 가공합니다. 보통 Last 함수로 최신 값을 가져오고, Strict 모드를 사용해 반환값이 숫자가 아닌 데이터일 때 NaN으로 표시되도록 합니다.
    3. 가공된 쿼리 결과에 규칙을 설정합니다. FE를 예로 들면, FE 노드 상태가 alive이면 결과는 1이고, FE 노드가 죽으면 결과는 0입니다. 따라서 규칙을 IS BELOW 1로 설정하면 이 조건이 발생했을 때 알림이 트리거됩니다.

  5. 알림 평가 규칙(evaluation rule)을 설정합니다.

    Grafana 문서에 따르면 알림 규칙을 평가하는 주기와 상태가 변하는 주기를 구성해야 합니다. 쉽게 말해 "알림 규칙을 얼마나 자주 검사할지"와 "이상 상태를 감지한 뒤 얼마나 지속되어야 알림을 트리거할지(일시적 스파이크로 인한 오탐 방지)"를 구성하는 것입니다. 각 Evaluation group은 독립적인 평가 간격을 가지며, 이 간격이 알림 규칙 검사 빈도를 결정합니다. StarRocks 프로덕션 클러스터 전용으로 PROD라는 이름의 새 폴더를 만들고 그 안에 새 Evaluation group 01을 만든 다음, 이 그룹이 10초마다 검사하도록 하고 이상 상태가 30초 지속되면 알림을 트리거하도록 구성할 수 있습니다.

    MA-36

    노트

    앞서 알림 채널 구성 절에서 설명한 "Disable resolved message" 옵션, 즉 클러스터 서비스 복구 시 이메일 발송 시점을 제어하는 옵션도 위의 "Evaluate every" 파라미터의 영향을 받습니다. 즉 Grafana가 새로 검사를 수행해 서비스가 복구된 것을 감지하면 담당자에게 이메일을 보냅니다.

  6. 알림 어노테이션(annotation)을 추가합니다.

    Add details for your alert rule 섹션에서 Add annotation을 클릭해 알림 이메일의 내용을 구성합니다. 이때 Dashboard UID와 Panel ID 필드는 수정하지 않도록 주의하세요.

    MA-37

    Choose 드롭다운 목록에서 Description을 선택하고, 알림 이메일에 들어갈 설명 문구를 추가합니다. 예: "FE node in your StarRocks production cluster failed, please check!"

  7. 알림 정책과 매칭합니다.

    알림 규칙에 적용할 알림 정책을 지정합니다. 기본적으로 모든 알림 규칙은 Default policy에 매칭됩니다. 알림 조건이 충족되면 Grafana는 Default policy의 "StarRocksOp" contact point를 사용해 구성된 이메일 그룹에 알림 메시지를 보냅니다.

    MA-38

    중첩 정책을 사용하려면 Label 필드를 해당 중첩 정책으로 설정합니다. 예: Group=Development_team.

    예시:

    MA-39

    이렇게 하면 알림 조건이 충족되었을 때 Default policy의 "StarRocksOp"가 아니라 "StarRocksDev"로 이메일이 발송됩니다.

  8. 모든 구성을 마쳤다면 Save rule and exit를 클릭합니다.

    MA-40

알림 발동 테스트

FE 노드를 수동으로 중지해 알림을 테스트할 수 있습니다. 이때 Frontends Status 오른쪽의 하트 모양 기호가 녹색에서 노란색으로, 이어서 빨간색으로 바뀝니다.

녹색: 마지막 주기 검사에서 해당 메트릭 항목의 각 인스턴스 상태가 정상이었고 알림이 발생하지 않았음을 의미합니다. 다만 녹색 상태라고 현재 노드가 반드시 정상이라고 보장하지는 않습니다. 노드 서비스에 이상이 생긴 뒤 상태가 바뀌는 데 지연이 있을 수 있지만, 보통 이 지연은 분 단위 수준은 아닙니다.

MA-41

노란색: 마지막 주기 검사에서 해당 메트릭 항목의 인스턴스 중 이상이 발견됐지만, 이상 상태의 지속 시간이 아직 앞서 구성한 "Duration"에 도달하지 않았음을 의미합니다. 이 시점에는 Grafana가 알림을 보내지 않고 주기 검사를 계속하며, 이상 상태 지속 시간이 구성된 "Duration"에 도달하면 알림을 보냅니다. 이 사이에 상태가 복구되면 기호는 다시 녹색으로 돌아갑니다.

MA-42

빨간색: 이상 상태의 지속 시간이 구성된 "Duration"에 도달하면 기호가 빨간색으로 바뀌고 Grafana가 이메일 알림을 보냅니다. 기호는 이상 상태가 해결될 때까지 빨간색으로 유지되며, 해결되면 다시 녹색으로 바뀝니다.

MA-43

알림 수동 일시 중지

이상 상태를 해결하는 데 오랜 시간이 필요하거나, 이상과 무관한 이유로 알림이 계속 발생하는 경우 알림 규칙의 평가를 일시 중지해 Grafana가 알림 이메일을 계속 보내는 것을 막을 수 있습니다.

대시보드에서 해당 메트릭 항목의 Alert 탭으로 이동해 편집 아이콘을 클릭합니다.

MA-44

Alert Evaluation Behavior 섹션에서 Pause Evaluation 스위치를 ON으로 토글합니다.

MA-45

노트

평가를 일시 중지한 뒤에는 서비스가 복구되었다는 내용의 이메일을 받게 됩니다.

BE 알림 규칙 구성

위 과정을 그대로 따라 BE에 대한 알림 규칙도 구성할 수 있습니다.

Backends Status 메트릭 항목의 구성을 편집하는 절차는 다음과 같습니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD]Backends Status"로 구성합니다.
  2. Set a query and alert condition 섹션에서 PromQL을 (up{group="be"})로 설정하고, 나머지 항목은 FE 알림 규칙과 동일하게 설정합니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "BE node in your StarRocks production cluster failed, please check! Stack information for BE failure will be printed in the BE log file be.out. You can identify the cause based on the logs".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

3.4.2 쿼리 알림 규칙

쿼리 실패에 해당하는 메트릭 항목은 Query Statistic 아래의 Query Error입니다.

"Query Error" 메트릭 항목의 알림 규칙은 다음과 같이 구성합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] Query Error"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 B를 제거합니다. 섹션 A의 Input을 C로 설정합니다. 섹션 C에서는 PromQL 기본값을 사용하는데, 이는 rate(starrocks_fe_query_err{job="StarRocks_Cluster01"}[1m])이며 1분간 실패한 쿼리 수를 60초로 나눈 값을 나타냅니다. 여기에는 실패한 쿼리와 타임아웃을 초과한 쿼리가 모두 포함됩니다. 그다음 섹션 D에서 규칙을 A IS ABOVE 0.05로 구성합니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "High query failure rate, please check the resource usage or configure query timeout reasonably. If queries are failing due to timeouts, you can adjust the query timeout by setting the system variable query_timeout".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

3.4.3 사용자 작업 실패 알림 규칙

이 항목은 Schema Change 작업 실패율을 모니터링하며, BE tasks 아래의 Schema Change 메트릭 항목에 해당합니다. 0보다 클 때 알림이 발생하도록 구성해야 합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] Schema Change"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 A를 제거합니다. 섹션 C의 Input을 B로 설정합니다. 섹션 B에서는 PromQL 기본값을 사용하는데, 이는 irate(starrocks_be_engine_requests_total{job="StarRocks_Cluster01", type="create_rollup", status="failed"}[1m])이며 1분간 실패한 Schema Change 작업 수를 60초로 나눈 값을 나타냅니다. 그다음 섹션 D에서 규칙을 C IS ABOVE 0으로 구성합니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Failed Schema Change tasks detected, please check promptly. You can increase the memory limit available for Schema Change by adjusting the BE configuration parameter memory_limitation_per_thread_for_schema_change, which is set to 2GB by default".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

3.4.4 StarRocks 작업 실패 알림 규칙

BE Compaction Score

이 항목은 Cluster Overview 아래의 BE Compaction Score에 해당하며, 클러스터의 컴팩션 압력을 모니터링하는 데 사용됩니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] BE Compaction Score"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 C의 규칙을 B IS ABOVE 0으로 구성합니다. 나머지 항목은 기본값을 사용할 수 있습니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "High compaction pressure. Please check whether there are high-frequency or high concurrency loading tasks and reduce the loading frequency. If the cluster has sufficient CPU, memory, and I/O resources, consider adjusting the cluster compaction strategy".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.
Clone

이 항목은 BE tasks의 Clone에 해당하며, 주로 StarRocks 내부의 복제본 밸런싱이나 복제본 복구 작업을 모니터링하는 데 사용됩니다. 이 작업은 보통 실패해서는 안 됩니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] Clone"으로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 A를 제거합니다. 섹션 C의 Input을 B로 설정합니다. 섹션 B에서는 PromQL 기본값을 사용하는데, 이는 irate(starrocks_be_engine_requests_total{job="StarRocks_Cluster01", type="clone", status="failed"}[1m])이며 1분간 실패한 Clone 작업 수를 60초로 나눈 값을 나타냅니다. 그다음 섹션 D에서 규칙을 C IS ABOVE 0으로 구성합니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected a failure in the clone task. Please check the cluster BE status, disk status, and network status".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

3.4.5 서비스 가용성 알림 규칙

이 항목은 BDB의 메타데이터 로그 수를 모니터링하며, Cluster Overview 아래의 Meta Log Count 모니터링 항목에 해당합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] Meta Log Count"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 C의 규칙을 B IS ABOVE 100000으로 구성합니다. 나머지 항목은 기본값을 사용할 수 있습니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected that the metadata count in FE BDB is significantly higher than the expected value, which can indicate a failed Checkpoint operation. Please check whether the Xmx heap memory configuration in the FE configuration file fe.conf is reasonable".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

3.4.6 시스템 과부하 알림 규칙

BE CPU Idle

이 항목은 BE 노드의 CPU idle 비율을 모니터링합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] BE CPU Idle"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 C의 규칙을 B IS BELOW 10으로 구성합니다. 나머지 항목은 기본값을 사용할 수 있습니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected that BE CPU load is consistently high. It will impact other tasks in the cluster. Please check whether the cluster is abnormal or if there is a CPU resource bottleneck".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.
BE Memory

이 항목은 BE 아래의 BE Mem에 해당하며, BE 노드의 메모리 사용량을 모니터링합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] BE Mem"으로 구성합니다.
  2. Set a query and alert condition 섹션에서 PromQL을 starrocks_be_process_mem_bytes{job="StarRocks_Cluster01"}/(<be_mem_limit>*1024*1024*1024)로 구성합니다. 여기서 <be_mem_limit>은 현재 BE 노드의 가용 메모리 제한으로 바꿔야 하며, 이는 서버 메모리 크기에 BE 구성 항목 mem_limit의 값을 곱한 값입니다. 예: starrocks_be_process_mem_bytes{job="StarRocks_Cluster01"}/(49*1024*1024*1024). 그다음 섹션 C에서 규칙을 B IS ABOVE 0.9로 구성합니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected that BE memory usage is consistently high. To prevent query failure, please consider expanding memory size or adding BE nodes".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.
Disks Avail Capacity

이 항목은 BE 아래의 Disk Usage에 해당하며, BE 저장 경로가 위치한 디렉터리의 남은 공간 비율을 모니터링합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] Disks Avail Capacity"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 C의 규칙을 B`` IS BELOW 0.2로 구성합니다. 나머지 항목은 기본값을 사용할 수 있습니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected that BE disk available space is below 20%, please release disk space or expand the disk".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.
FE JVM Heap Stat

이 항목은 Overview 아래의 Cluster FE JVM Heap Stat에 해당하며, FE의 JVM 메모리 사용량이 FE 힙 메모리 제한에서 차지하는 비중을 모니터링합니다.

  1. Set an alert rule name 섹션에서 이름을 "[PROD] FE JVM Heap Stat"로 구성합니다.
  2. Set a query and alert condition 섹션에서 섹션 C의 규칙을 B IS ABOVE 80으로 구성합니다. 나머지 항목은 기본값을 사용할 수 있습니다.
  3. Alert evaluation behavior 섹션에서 앞서 만든 PROD 디렉터리와 Evaluation group 01을 선택하고 지속 시간을 30초로 설정합니다.
  4. Add details for your alert rule 섹션에서 Add annotation을 클릭하고 Description을 선택한 뒤 알림 내용을 입력합니다. 예: "Detected that FE heap memory usage is high, please adjust the heap memory limit in the FE configuration file fe.conf".
  5. Notifications 섹션에서 Labels는 FE 알림 규칙과 동일하게 구성합니다. Labels를 구성하지 않으면 Grafana가 Default policy를 사용해 "StarRocksOp" 알림 채널로 알림 이메일을 보냅니다.

부록

Prometheus 서비스 디스커버리 활성화

Prometheus에 서비스 디스커버리(service discovery)를 활성화하면 클러스터를 스케일 인/아웃한 뒤에도 서비스(노드)를 자동으로 감지할 수 있습니다.

note

다음 내용은 AWS를 예로 설명합니다.

  1. IAM Policy로 Prometheus 서비스를 호스팅하는 EC2 인스턴스에 다음 권한을 부여합니다.

    {
      "Version": "2012-10-17",
      "Statement": [
               {
                        "Effect": "Allow",
                        "Action": [
                              "ec2:DescribeInstances",
                              "ec2:DescribeTags"
                        ],
                        "Resource": "*"
               }
      ]
}

    AWS 리소스 인증에 대한 자세한 방법은 Authenticate to AWS resources를 참고하세요.

    이 권한이 있으면 Prometheus는 해당 리전의 인스턴스와 태그 목록을 조회할 수 있습니다.

  2. prometheus/prometheus.yml에 ec2_sd_configs와 relabel_configs 섹션을 추가합니다.

    예시:

    global:
scrape_interval: 15s # Set the global scrape interval to 15s. The default is 1 min.
evaluation_interval: 15s # Set the global rule evaluation interval to 15s. The default is 1 min.
scrape_configs:
- job_name: 'StarRocks_Cluster01'
   metrics_path: '/metrics'
   ec2_sd_configs:
      - region: us-west-2
      port: 8030
      filters:
         - name: tag:ClusterName
            values: ['test-stage-20251021']
         - name: tag:ProcessType
            values: ['FE']
      - region: us-west-2
      port: 8040
      filters:
         - name: tag:ClusterName
            values: ['test-stage-20251021']
         - name: tag:ProcessType
            values: ['BE']
   relabel_configs:
      - source_labels: [__meta_ec2_tag_ClusterName]
      regex: test-stage-20251021
      target_label: cluster
      replacement: test-stage-20251021
      - source_labels: [__meta_ec2_tag_ProcessType]
      regex: FE
      target_label: group
      replacement: fe
      - source_labels: [__meta_ec2_tag_ProcessType]
      regex: BE
      target_label: group
      replacement: be

Q&A

Q: 대시보드가 이상 상태를 감지하지 못하는 이유는 무엇인가요?

A: Grafana 대시보드는 자신이 호스팅된 서버의 시스템 시간에 기반해 모니터링 항목의 값을 가져옵니다. 클러스터에 이상이 생겼는데도 Grafana 대시보드 화면이 그대로라면 서버들의 시스템 시계가 동기화되어 있는지 확인하고, 클러스터 시간 보정을 수행하세요.

Q: 알림 등급(alert grading)은 어떻게 구현할 수 있나요?

A: Query Error 항목을 예로 들면, 알림 임계값이 서로 다른 두 개의 알림 규칙을 만들 수 있습니다. 예를 들어:

  • Risk Level: 실패율이 0.05보다 크면 위험(risk) 상태로 보고 개발팀에 알림을 보냅니다.
  • Severity Level: 실패율이 0.20보다 크면 심각(severity) 상태로 보고, 이 시점에는 개발팀과 운영팀 양쪽에 동시에 알림이 전송됩니다.

Q: 테이블 수준 메트릭, 머티리얼라이즈드 뷰 메트릭, 사용자 라벨별 연결 통계처럼 더 상세한 메트릭은 어떻게 조회할 수 있나요?

A: 기본적으로 /metrics 엔드포인트는 성능 영향을 최소화하기 위해 압축(minified) 모드로 메트릭을 수집합니다. 상세 메트릭을 조회하려면 요청에 특정 파라미터를 추가하고, ADMIN 권한을 가진 사용자의 Basic Authentication 자격 증명을 함께 제공해야 합니다.

지원 파라미터:

  • with_table_metrics=all: 모든 테이블 수준 메트릭을 수집합니다.
  • with_materialized_view_metrics=all: 모든 머티리얼라이즈드 뷰 메트릭을 수집합니다.
  • with_user_connections=all: 사용자 라벨별로 분류된 연결 통계를 수집합니다.

인증 요구 사항:

이 파라미터들은 요청에 ADMIN 사용자의 유효한 Basic Authentication 자격 증명이 포함된 경우에만 동작합니다. 요청이 익명이거나 사용자에게 ADMIN 권한이 없다면 이 파라미터는 무시되고 기본 메트릭만 반환됩니다.

Curl 명령 예시:

curl -u <admin_username>:<admin_password> \
"http://<fe_host>:<fe_http_port>/metrics?with_table_metrics=all&with_materialized_view_metrics=all&with_user_connections=all"

Prometheus 구성 예시:

Prometheus에서 상세 메트릭 수집을 활성화하려면 prometheus.yml에 params와 basic_auth를 구성합니다.

scrape_configs:
  - job_name: 'StarRocks_Detailed_Metrics'
    metrics_path: '/metrics'
    params:
      with_table_metrics: ['all']
      with_materialized_view_metrics: ['all']
      with_user_connections: ['all']
    basic_auth:
      username: '<admin_username>'
      password: '<admin_password>'
    static_configs:
      - targets: ['<fe_host>:<fe_http_port>']

note

모든 테이블 및 머티리얼라이즈드 뷰 메트릭을 수집하면 FE 노드의 부하가 늘어날 수 있습니다. 대규모 환경에서는 이 파라미터들을 신중하게 사용하세요.

더 알아보기 (Learn more)