ZO

1. 들어가며.

Prometheus와 Grafana를 활용해 데이터를 수집하고 대시보드를 구성하던 중, 기존에 설정된 패널에서 "Found Duplicate Series for the Match Group" 오류가 발생하며 정상적으로 데이터를 표시하지 못하는 문제가 발생했습니다. 이 글에서는 해당 오류가 발생한 원인과 해결 방법을 정리합니다.

2. 오류 발생 원인

2.1 문제가 발생한 PromQL 쿼리 예시

오류가 발생한 PromQL 쿼리는 SNMP Exporter를 통해 수집한 ifHcInoctets 메트릭(네트워크 인터페이스의 바이트 단위 수신량)을 활용한 아래와 같은 형태였습니다.

ifHcInoctets{instance="$instance", type="$type", category="network"}

이 쿼리는 특정 instance 및 type에 해당하는 네트워크 트래픽 데이터를 가져오는 과정에서 중복된 시계열(series)이 존재하여 오류가 발생한 것입니다.

2.2 type 라벨 중복 문제

오류의 원인은 type 라벨에 두 개의 서로 다른 값(“active”와 “standby”) 이 존재했기 때문입니다. 이는 연동 작업 중 IP 설정 오류로 인해 원래 type='standby'로 설정되어야 할 대상이 type='active'로 잘못 설정되었고, 이후 이를 수정하여 Prometheus를 재시작하면서 동일한 instance에 대해 두 개의 type 값을 가지는 시계열이 생성되었기 때문입니다.

Prometheus에서는 동일한 instance와 같은 라벨 조합을 가진 메트릭이 중복될 경우, irate()와 같은 함수에서 오류가 발생할 수 있습니다. 아래는 실제 패널상에서 보여지는 에러이미지입니다.

3. 해결 방법

중복된 시계열을 해결하는 방법은 여러 가지가 있습니다.

3.1 불필요한 메트릭 삭제 (필자가 선택한 방법)

 *delete_series API 사용 방법

해당 메트릭이 실수로 수집된 것이므로 사용하지 않도록 제거하는 방법을 선택했습니다. Prometheus의 delete_series API를 사용하면 특정 메트릭을 삭제할 수 있습니다.

curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={instance="10.10.10.10",type="active"}'

이 명령어를 실행하면 특정 instance 값과 일치하는 시계열 데이터가 삭제됩니다.

* Admin API 활성화 필요

하지만 기본적으로 Prometheus는 admin-api가 비활성화되어 있어, 위 명령어를 실행하면 다음과 같은 오류가 발생할 수 있습니다.

이 경우 Prometheus 설정 파일 또는 실행 인자에 다음 옵션을 추가해야 합니다.

--web.enable-admin-api

필자는 Prometheus를 Docker Compose로 운영 중이므로, docker-compose.yml 파일에서 아래 이미지와 같이 Prometheus 컨테이너에 해당 옵션을 추가한 후 재시작했습니다.

설정을 추가한 후 Prometheus를 재시작하고 다시 delete_series API를 실행하면, 중복된 시계열이 삭제되며 정상적으로 Grafana 패널이 표시되는 것을 확인할 수 있습니다.

4. 결론

이번 오류는 Prometheus에서 동일한 instance에 대해 두 개의 type 값(active/standby)이 존재하여 중복된 시계열이 생성되면서 발생했습니다. 해결 방법으로는 불필요한 시계열 삭제, PromQL 쿼리 수정 등을 선택할 수 있으며, 필자는 delete_series API를 활용해 메트릭을 삭제하는 방식으로 해결했습니다.

Prometheus와 Grafana를 운영하면서 중복된 시계열 문제를 방지하려면, 라벨 관리에 신경 쓰고 불필요한 중복 데이터를 최소화하는 것이 중요합니다. 이후 동일한 문제가 발생하지 않도록 수집 설정을 주의 깊게 관리하는 것이 필요합니다.

0. 개요

기존 모니터링인 Nagios에서 시스템 메트릭 모니터링을 하기 위하여 Prometheus+Grafana+NodeExporter로

내부 서버 모니터링을 시작했습니다. 온프레미스 장비들에 node_exporter 설치 후 시스템 메트릭을 수집하는 도중, /var/log/messages에 다음과 같은 ACPI 관련 커널 오류가 발생하는것을 확인 할 수 있었습니다.  

ACPI Error: SMBus or IPMI write requires Buffer of length 66, found length 32 (20090903/exfield-286)

이 오류는 ACPI(Advanced Configuration and Power Interface)와 관련된 SMBus(System Management Bus) 또는 IPMI(Intelligent Platform Management Interface) 요청 중 버퍼 길이 불일치로 인해 발생합니다. 

1. 문제원인 

Node Exporter가 /sys/class/hwmon 경로에서 하드웨어 센서 값을 수집할 때 일부 하드웨어 플랫폼 또는 펌웨어가 이러한 쿼리를 완벽하게 지원하지 못하여 커널 오류가 발생합니다. 주로 펌웨어버젼이 낮을경우에 발생합니다.

2. 해결방법

이 문제를 해결하려면 Node Exporter에서 하드웨어 모니터링(hwmon) 수집기를 비활성화해야 합니다.

1) node_exporter 서비스파일 수정

1. Node_exporter 서비스 파일 오픈

sudo vi /etc/systemd/system/node_exporter.service

2. ExecStart 라인을 찾아 다음과 같이 --no-collector.hwmon 옵션을 추가합니다:

ExecStart=/usr/local/bin/node_exporter --no-collector.hwmon

만약 Centos6와 같은 구버젼의 Daemon파일은 아래와 같은절차로 진행합니다.

1. Node_exporter 데몬파일 오픈

vi /etc/init.d/node_exporter

2. start 함수에  --no-collector.hwmon 설정 추가

start(){
	echo -n"Starting $PROGNAME: "
    cd /usr/shared/node_exporter/
    daemon --user $USER --pidfile="$LOCKFILE" "$PROG --no-collector.hwmon &>$LOGFILE &"
    echo $(pidofproc $PROGNAME) >$LOCKFILE
    echo
}

2) 서비스 리로드 및 재시작

1. systemd 데몬을 리로드하여 변경사항을 적용합니다.

sudo systemctl daemon-reload

2. node_exporter 서비스를 재시작 합니다.

sudo systemctl restart node_exporter

위 작업 진행 후 더이상 /var/log/messgaes에 관련 로그가 발생하지 않습니다.

3. 결론

Node Exporter에서 hwmon 수집기를 비활성화하여 과도한 로그 발생을 방지했습니다. 하드웨어 센서 모니터링이 비활성화되는 단점이 있지만, ACPI 상호작용이 Node Exporter와 호환되지 않는 시스템에서는 실용적인 해결책입니다.

Nagios/nrpe 모니터링을 사용하며, nrpe 클라이언트에서 위와 같은 에러가 발생시에 대응 방법을 찾아보면 

https://support.nagios.com/kb/article/nrpe-v3-v4-compatibility-with-previous-versions-516.html

위 공식홈페이지에 설명이 되어있는데, 내용을보면 Nagios메인버젼의 nrpe_Plugin 버젼은 높고 nrpe의 버젼이 낮을 경우에만 설명이 되어있다. 

ex) check_nrpe -2 -H {hostip} (2버젼 통신), check_nrpe -3 -H {hostip} (3버젼 통신)

내부적으로 os업데이트작업을 진행중인데, 이와 반대로 nrpe 버젼이높고 nagios 메인서버의 nrpe_plugin버젼이 낮을때 경우가 발생하여  해결 방법을 간단히 적어보려고한다.

nagios_nrpe_plugin version : 3.2.0

nrpe_version : 4.1.0

기존의 모니터링 대상은 check_nrpe 명령어를 통해 모니터링을 하기에 최대한 건드리지 않고 작업을 진행했다.

작업절차 : 

1. nagios_nrpe_plugin 4버젼 컴파일설치

2. 설치완료된 파일 커맨드 세팅

3. 재기동

1. nagios_nrpe_plugin 4버젼 컴파일 설치

wget --no-check-certificate -O nrpe.tar.gz https://github.com/NagiosEnterprises/nrpe/archive/nrpe-4.1.0.tar.gz 
tar xvzf nrpe.tar.gz
cd nrpe-nrpe-4.1.0
./configure --disable-ssl --enable-command-args
make check_nrpe

make 까지 완료되면 /root/nrpe-nrpe-4.1.0/src 디렉토리내에 check_nrpe 바이너리파일이 생성된다. 

2. 설치 완료된 파일 커맨드 세팅

커맨드경로에 맞춰서 해당 파일을 옮겨주고 이름도 변경해준다.

mv /root/nrpe-nrpe-4.1.0/src/check_nrpe /usr/lib64/nagios/plugins/check_nrpe4

옮겨준뒤 command.cfg에 check_nrpe4를 생성해준다.

vi $nagios_home_path/etc/object/command.cfg

define command {

                     command_name   check_nrpe4

                     command_line /usr/lib64/nagios/plugins/check_nrpe4 -H $HOSTADDRESS$ -c $ARG1$

}

위와 같이 check_nrpe4를 선언해준뒤 해당 클라이언트 파일의 명령어를 변경해준다.

]#vi $nagios_home_path/etc/object/client.cfg

define service{

                    use local-service

                    host_name test

                    check_command check_nrpe!check_disk1  # check_nrpe => check_nrpe4 변경
                    notifications_enabled 1

}

3. 재기동

service nagios restart

재기동 후 클라이언트 로그에 에러 로그가 안찍힌다면 정상 설정 완료

###추가 내용

단순히 nagios서버에서만 설정을 할 경우 아래와 같은 에러가 발생할수있다.

Error: (!log_opts) Could not complete SSL handshake with $HOSTIP: 1

클라이언트에서 위와 같은 에러가 발생할수있는데, 이는 nagios서버에서는 disable ssl을 진행했으나, 클라이언트 사이드에서 ssl인증을 진행하여 발생하는 에러다. 아래와 같이 작업하여 nagios와 동일하게 nrpe도 disable-ssl을 진행해주자.

vi /etc/sysconfig/nrpe

NRPE_SSL_OPT="-n"
#-n 추가

위와 같이 -n옵션 추가후 nrpe 재기동시 정상적으로 통신되는걸 볼수있다.