- 인쇄
- PDF
이벤트 문제
- 인쇄
- PDF
Classic/VPC 환경에서 이용 가능합니다.
Cloud Insight 서비스를 이용하면서 다음과 같은 문제를 겪을 수 있습니다. 문제별 원인과 해결 방법을 확인하고 적절하게 조치해 주십시오.
Server(VPC)의 is_process_up으로 모니터링 중 이상이 없는데 이벤트 발생
Server(VPC)의 is_process_up으로 모니터링 중 이상이 없는데도 이벤트가 발생합니다.
원인
Plugin Process의 is_process_up 데이터는 사용자가 등록한 process name의 PID가 새롭게 생성될 때를 기준으로 수집됩니다. 만약 asterisk(*)를 포함한 process name을 등록했다면, 일치하는 모든 프로세스의 PID 목록이 대상이 됩니다.
is_process_up이 변동되는 조건은 아래와 같습니다.
- is_process_up = 1: PID 목록이 유지되거나, 새로운 PID가 추가될 때
- is_process_up = 0 : PID 목록 중 일부 혹은 전체가 사라질 때
따라서 다음과 같은 경우 Main 프로세스가 정상임에도 is_process_up이 0이 될 수 있습니다.
- Main 프로세스의 Sub 프로세스가 일시적으로 생성되었다 삭제된 경우
- Main 프로세스의 Sub 프로세스가 일시적으로 삭제되었다 생성된 경우
- Main 프로세스의 Sub 프로세스가 줄어든 경우
<예시> process name으로 *httpd* 를 등록한 경우 시간에 따른 PID 변화와 is_process_up / process_count 메트릭 값
Time | PID (Main) | PIDs (sub) | is_process_up | process_count | Detail |
---|---|---|---|---|---|
12:00 | 123 | - | 1 | 1 | sub process 없음 |
12:01 | 123 | 124, 125 | 1 | 3 | sub process 생성 |
12:02 | 123 | 124 | 0 | 2 | sub process 중 일부 삭제 |
12:03 | 123 | 124, 126 | 1 | 3 | sub procsss 생성 |
12:04 | 123 | 124, 127 | 0 | 3 | sub process 중 일부 갱신 |
12:05 | 123 | - | 0 | 1 | sub process 전체 삭제 |
12:06 | - | - | 0 | 0 | main process 삭제 |
해결 방법
Apache 서비스의 정상 유무를 판단하기 위해 *httpd*와 같은 process name을 모니터링하는 경우가 많습니다. 이와 같은 경우, is_process_up으로 모니터링 시에는 정상적인 모니터링이 되지 않을 수 있습니다. 만약 Apache 서비스가 종료된다면 *httpd*의 process_count가 0이 될 것이므로 process_count == 0 과 같은 조건으로 모니터링하는 것을 권고합니다.
Event Rule 생성 시 삭제한 File, Process, Port Plugin의 디멘션 노출
Event Rule 생성 시 삭제한 File, Process, Port Plugin의 디멘션이 계속 노출됩니다.
원인
삭제한 File, Process, Port Plugin의 디멘션은 삭제 이후 Event Rule 생성 화면에서 최대 2일간 노출될 수 있습니다. File, Process, Port Plugin 삭제 시 수집된 메트릭 정보는 바로 삭제되지만 디멘션 정보는 해당 디멘션을 가진 메트릭이 수집되지 않은 상태로 2일간 유지될 경우 삭제됩니다.
해결 방법
해당 디멘션을 가진 메트릭이 수집되지 않은 상태로 2일이 지나기 전에는 디멘션이 삭제됩니다. 기간이 지난 후에 다시 확인해 주십시오.
Event Rule의 Total Rule Count 값과 감시 대상 및 감시 항목의 값 불일치
Event Rule을 생성했는데 Total Rule Count 값이 감시 대상 및 감시 항목의 값과 일치하지 않습니다.
원인
Event Rule의 Total Rule Count는 실제로 생성된 Rule을 기준으로 산정됩니다. 이때 실제 Rule 생성 여부는 설정한 감시 대상이 감시 항목에 대해 메트릭을 수집하고 있는지에 따라 결정됩니다.
예를 들어, 감시 대상이 3개이고 그 중 2개에 대해서만 실제 감시 항목 메트릭을 수집하고 있는 경우, Total Rule Count는 3이 아닌 2로 표기됩니다.
해결 방법
감시 대상 중 일부에 대해서 감시 항목 메트릭이 수집되지 않는 경우를 확인해 주십시오.
- 감시 대상 서버 중 일부가 감시 항목 메트릭에 설정된 디멘션에 대해 수집되고 있지 않은 경우
- 감시 항목 메트릭의 타입이 Extended여서 상세 모니터링 설정이 필요하나, 감시 대상 서버 중 일부가 상세 모니터링 설정이 되지 않은 경우
- 감시 대상 서버 중 일부가 중지 상태로 전환되어 메트릭 수집이 중단된 경우
- 감시 대상 서버 중 일부가 내부 방화벽이나 방화벽 솔루션 등에 의해 메트릭 수집이 정상적으로 되지 않는 경우
- 감시 대상 서버 중 일부가 Agent 문제로 인해 정상적으로 메트릭 수집이 되지 않는 경우
- Event Rule을 설정하는 시점에 실제 Metric이 수집되지 않아 Total Rule Count에서 제외되었던 감시 대상에 대해 향후 메트릭이 수집될 경우(이 경우, 자동으로 Total Rule Count에 추가됨)
이벤트 조건을 만족하지 않았지만 이벤트 발생
이벤트 발생 후 조건을 변경했는데, 변경한 조건을 만족하지 않았는데도 이벤트가 발생했습니다.
원인
기존에 발생한 이벤트가 있는 상태에서 해당 이벤트의 조건을 변경할 경우, 기존 이벤트가 종료되면서 당시 설정된 조건으로 종료 이벤트 알림이 발생합니다.
duration 등을 고려하지 않은 예시는 다음과 같습니다.
시간 | process_count | 조건 | 설명 |
---|---|---|---|
00:00 | 0 | process_count = 1 | 이벤트 미발생 |
00:01 | 1 | process_count = 1 | process_count = 1 내용의 이벤트 알림 발생 |
00:02 | 1 | process_count = 0 | process_count = 0 내용의 종료(Resolve) 이벤트 알림 발생 |
00:03 | 0 | process_count = 0 | process_count = 0 내용의 이벤트 알림 발생 |
해결 방법
조건을 변경하여 발생된 종료 이벤트의 당시 설정한 실제 조건을 확인하려면, 네이버 클라우드 플랫폼 콘솔의 Services > Cloud Insight > Event 메뉴에서 확인해 주십시오.
CPU 사용률이 이벤트 룰 조건보다 낮음에도 이벤트 발생
CPU 사용률이 이벤트 룰 조건보다 낮은데도 이벤트가 발생했습니다.
원인
CPU/used_rto
메트릭은 CPU 개수에 따라 cpu_idx:0~N
의 디멘션이 존재합니다. 디멘션을 선택하지 않고 이벤트 룰을 생성한 경우 모든 디멘션의 메트릭이 대상이 되며, 각 디멘션에 따른 메트릭 중 하나라도 조건에 해당하면 이벤트가 발생합니다.
<예시> 서버의 CPU 개수가 2개이고 이벤트 룰 및 메트릭 값이 아래와 같을 때 CPU/used_rto
값이 45이지만, 디멘션 cpu_idx: 0
에 해당하는 값이 60으로 조건을 만족하기 때문에 이벤트가 발생합니다.
감시 항목 및 조건
메트릭: CPU/used_rto
디멘션: 선택안함
조건: >= 50
집약 방법: AVG
지속시간: 1 minute일정 시점
Min1
데이터시간 CPU/used_rto (cpu_idx: 0) CPU/used_rto (cpu_idx: 1) CPU/used_rto 00:01 60 30 45
해결 방법
서버의 평균 CPU 사용률에 대한 이벤트 설정이 필요한 경우, SERVER/avg_cpu_used_rto
메트릭을 이용해 주십시오.
이벤트 발생 내용과 Event 메뉴에 노출되는 데이터가 상이함
이벤트 발생 내용과 Event 메뉴에 노출되는 데이터가 다릅니다.
원인
네이버 클라우드 플랫폼 콘솔의 Services > Cloud Insight > Event 메뉴에서 확인할 수 있는 그래프는 이벤트 시작 일시와 종료 일시에 따라 조회되는 데이터의 집계 주기(예: Min5
)가 다릅니다. 실제 이벤트 룰을 발생시킨 데이터를 확인하려면 집계 주기가 Min1인 데이터를 확인해야 합니다.
해결 방법
Dashboard를 별도로 구성하거나, Event Rule 메뉴에서 해당 이벤트 룰의 상세 보기를 통해 조회 기간을 1시간 이내로 설정하여 Min1 데이터를 조회해 주십시오.
CPU 사용률이 높은 서버 데이터가 CPU 사용률 위젯에 표시되지 않음
Service Dashboard에서 위젯 데이터 TOP 10으로 조회 시 CPU 사용률이 높은 서버 데이터가 CPU 사용률 위젯에 표시되지 않습니다.
원인
Service Dashboard TOP 10 목록을 선정하는 기준은 아래와 같습니다.
- 최근 10분의
Min1
메트릭 값을 조회하여 정렬한 후 상위 10개를 선정 - 최근 10분의
Min1
데이터가 없다면 임의로 10개를 선정
위젯 데이터가 TOP 10일 경우, 노출될 서버 목록을 선정해야 하기 때문에 이때 선정을 위해 사용하는 데이터는 (endTime - 10분, endTime) 기간에 조회된 데이터입니다. 해당 데이터는 실제로 대시보드 상에 표기하지 않고, 내부적으로만 사용하는 데이터입니다. CPU 사용률이 높은 서버가 TOP 10에서 조회되지 않았다면, 위 기준에 따라 해당 서버의 (endTime - 10분, endTime) 기간의 CPU 사용률 Min1
metric 값이 상위 10개에 포함되지 않은 것일 수 있습니다.
위젯 데이터 TOP 10은 설정한 조회 기간의 종료 시점(endTime)을 기준으로 10분 전 데이터로 비교하기 때문에 실제 조회하는 전체 기간에서의 기대하는 목록으로 노출되지 않을 수 있습니다.
해결 방법
CPU 사용률이 높은 서버의 데이터가 Service Dashboard TOP 10의 수집 기준에 포함되지 않았을 가능성이 높으므로 문제 상황이 아닙니다. 자세한 내용은 원인을 참고해 주십시오.
이 가이드에서 원하는 정보를 찾지 못했거나 추가로 필요한 정보가 있으신 경우, 언제든지 아래의 피드백 아이콘을 클릭하여 의견을 보내 주십시오. 전달해 주신 의견을 참고하여 더 유용한 정보를 제공하겠습니다.