Cloud Insight 문제 해결
    • PDF

    Cloud Insight 문제 해결

    • PDF

    Article Summary

    Classic/VPC 환경에서 이용 가능합니다.

    Cloud Insight 문제 해결에서 Cloud Insight 사용 중 사용자가 만날 수 있는 문제 상황과 해결 방법을 설명합니다.

    Cloud Insight 문제 해결에서 설명되지 않거나 해당 가이드를 숙지하여도 직접 해결하기 어려운 경우, 다음을 통해 궁금한 점을 확인하거나 문제 해결 방법을 문의해 주십시오.

    Q. 서버가 Hang이 걸려 Metric 수집도 되지 않고, 알림도 오지 않습니다.

    A. 서버가 Hang이 걸리면 Agent가 CPU를 할당받지 못하기 때문에 동작하지 않습니다. Hang을 발생시키고 있는 원인인 프로세스가 Hang 상태를 스스로 해제하거나 해당 프로세스를 강제로 종료할 때까지 이 문제가 지속될 수 있습니다. 만약 서버에 아무런 입력이 되지 않을 경우, 서버를 강제로 재기동해야 할 수 있습니다. 서버가 Hang, Agent, 네트워크 이슈 등으로 정상 동작하지 않을 경우, Server(Classic) 또는 Server(VPC)의 agent_status Metric을 사용하여 확인해 주십시오.

    Q. Server(VPC)의 is_process_up으로 모니터링 중 이상이 없는데 Event가 발생합니다.

    A. 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 메트릭 값

    TimePID (Main)PIDs (sub)is_process_upprocess_countDetail
    12:00123-11sub process 없음
    12:01123124, 12513sub process 생성
    12:0212312402sub process 중 일부 삭제
    12:03123124, 12613sub procsss 생성
    12:04123124, 12703sub process 중 일부 갱신
    12:05123-01sub process 전체 삭제
    12:06--00main process 삭제

    보통 *httpd*와 같은 process name을 모니터링 하는 이유는 apache 서비스의 정상 유무를 판단하기 위함일 것입니다.
    이와 같은 경우, is_process_up으로 모니터링 할 시에는 정상적인 모니터링이 되지 않을 수 있기 때문에 process_count == 0 과같은 조건을 통해 모니터링 하는 것이 유리합니다. (apache 서비스가 종료된다면 *httpd*의 process_count가 0이 될 것이므로)

    Q. Event Rule 생성 시 삭제한 File/Process/Port Plugin 의 Dimension이 계속 노출됩니다.

    A. 삭제한 File/Process/Port Plugin 의 Dimension 은 삭제 이후 Event Rule 생성 화면에서 최대 2일간 노출될 수 있습니다. File/Process/Port Plugin 삭제 시 수집된 Metric 정보는 바로 삭제되지만, Dimension 정보는 해당 Dimension을 가진 Metric이 수집되지 않은 상태로 2일간 지속될 경우 삭제합니다.

    Q. Event Rule을 생성하였는데 Total Rule Count 값이 감시 대상 및 감시 항목의 값과 일치하지 않습니다.

    A. Event Rule의 Total Rule Count는 실제로 생성된 Rule을 기준으로 산정되는데, 이때 실제 Rule 생성 여부는 설정한 감시 대상이 감시 항목에 대해 Metric을 수집하고 있는지 여부에 따라 결정됩니다.

    <예시> 감시 대상이 3개이고 그중 2개에 대해서만 실제 감시 항목 Metric을 수집하고 있는 경우, Total Rule Count는 3이 아닌 2로 표기됩니다.

    감시 대상 중 일부에 대해서 감시 항목 Metric이 수집되지 않는 경우는 다음과 같습니다.

    • 감시 대상 서버 중 일부가 감시 항목 Metric에 설정된 Dimension에 대해 수집이 되고 있지 않은 경우
    • 감시 항목 Metric의 Type이 Extended여서 상세 모니터링 설정이 필요하나, 감시 대상 서버 중 일부가 상세 모니터링 설정이 되지 않은 경우
    • 감시 대상 서버 중 일부가 중지 상태로 전환되어 Metric 수집이 중단된 경우
    • 감시 대상 서버 중 일부가 내부 방화벽이나 방화벽 솔루션 등에 의해 Metric 수집이 정상적으로 되지 않는 경우
    • 감시 대상 서버 중 일부가 Agent 동작 이슈로 인해 Metric 수집이 정상적으로 되지 않는 경우
    • Event Rule을 설정하는 시점에 실제 Metric이 수집되지 않아 Total Rule Count에서 제외되었던 감시 대상에 대해 향후 Metric이 수집될 경우(이 경우에는 자동으로 Total Rule Count에 추가됩니다.)

    Q. Server의 proc_mem_usert가 Memory의 mem_usert보다 높게 나옵니다.

    A. 각 Metric에 대한 설명은 다음과 같습니다.

    • SERVER/proc_mem_usert: 서버 내 전체 프로세스의 메모리 사용률
    • MEMORY/mem_usert: 서버 전체 메모리 사용률

    일반적으로 프로세스 외에도 여러 요소가 서버 메모리를 사용하기 때문에 MEMORY/mem_usert가 SERVER/proc_mem_usert보다 큰 경향을 보입니다.

    SERVER/proc_mem_usert가 MEMORY/mem_usert보다 큰 경우는 다음의 두 가지 경우에 해당합니다.

    • SERVER/proc_mem_usert는 모든 프로세스가 사용 중인 RSS(프로세스가 점유하고 있는 Local Memory + 프로세스가 참고하고 있는 Shared Memory)의 합입니다. 많은 프로세스가 동일한 Shared Memory page를 참고하는 경우, RSS에 중복되어 합산되기 때문에 이론적으로 RSS의 합이 실제 메모리 사용률보다 높게 집계될 수 있습니다.

    • RSS는 프로세스가 CPU를 사용할 때만 그 값이 업데이트됩니다. CPU 부하가 매우 높은 상황에서는 프로세스별로 CPU를 할당받지 못할 수 있으므로 RSS 값이 정상적으로 업데이트되지 않을 수 있습니다. 따라서 전체 RSS 값의 합이 실제 메모리 사용률보다 클 수 있습니다.

    정확한 메모리 사용률을 확인하려면 SERVER/proc_mem_usert보다 MEMORY/mem_usert를 사용해 주십시오.

    Q. CPU의 used_rto가 Server의 avg_cpu_used_rto보다 높거나 낮게 나옵니다.

    A. 각 Metric에 대한 설명은 다음과 같습니다.

    • CPU/used_rto: 각 vCPU의 사용률
      • <예시> vCPU가 4개인 경우, cpu_idx: 0~3 중 하나의 사용률
    • SERVER/avg_cpu_used_rto: 서버 전체의 평균 CPU 사용률

    Linux 아키텍처 특성상 특정 프로세스는 모든 CPU를 균등하게 사용하지 않고, 특정 CPU를 더 많이 사용하는 경우가 있습니다. 이러한 경우 CPU/used_rto는 SERVER/avg_cpu_used_rto보다 높거나 낮게 나타날 수 있습니다.

    서버의 정확한 평균 CPU 사용률을 확인하려면 CPU/used_rto보다 SERVER/avg_cpu_used_rto를 사용해 주십시오.

    Q. Event가 발생한 후 Condition을 조정하면 이에 따른 Event가 발생하지 않습니다.

    A. Condition을 조정하더라도 이미 발생한 Event가 종료되어야만 새로운 Condition에 따른 Event가 발생합니다.

    만약 Event가 종료되지 않은 상황에서 Condition을 조정한 후 이를 기반으로 새롭게 Event를 발생시키고 싶은 경우, Rule 비활성화 기능을 이용할 수 있습니다. Rule을 비활성화하여 Event를 강제 종료한 뒤 Condition을 조정하고 다시 비활성화를 해제하면 조건에 부합할 경우 새로운 Event가 발생합니다.

    Rule 비활성화에 관한 자세한 내용은 Rule 상세 조회 또는 Event Rule 수정을 참고해 주십시오.

    Q. Agent가 정상적으로 실행 중인데 Cloud Insight에 데이터가 수집되지 않습니다.

    A. Agent가 정상적으로 실행 중이더라도 서버 내부 방화벽 설정, 보안 솔루션 설치 등으로 인해 Agent에서 Cloud Insight로 Outbound 통신이 막혀있을 수 있습니다. 다음 Port 목록을 확인한 후 방화벽 해제 여부를 확인해 주십시오.

    Classic 환경

    SourceDestinationPortDescription
    고객 VM 대역real-collector.nsight.ncloud.com (10.250.5.199)​​​​​​TCP 9973Cloud Insight 메트릭 수집 서버
    고객 VM 대역real-ntp.nsight.ncloud.com (10.250.5.117)​​​UDP 123Cloud Insight NTP 서버
    고객 VM 대역real-wai.nsight.ncloud.com (10.250.5.118)​​​​​​TCP 10280Cloud Insight 관련 정보 조회 서버
    고객 VM 대역repo-nsight.ncloud.com (10.213.208.165)​​TCP 80,443Cloud Insight Repository 서버
    10.250.26.62고객 VM 대역ICMPCloud Insight Ping Check 모니터링 서버
    10.250.26.63고객 VM 대역ICMPCloud Insight Ping Check 모니터링 서버

    VPC 환경

    SourceDestinationPortDescription
    고객 VM 대역collector.nsight.ncloud.com (169.254.80.17)​​​TCP 9973Cloud Insight 메트릭 수집 서버
    고객 VM 대역ntp.nsight.ncloud.com (169.254.80.19)UDP 123Cloud Insight NTP 서버
    고객 VM 대역wai.nsight.ncloud.com (169.254.80.18)​​​TCP 10280Cloud Insight 관련 정보 조회 서버
    고객 VM 대역nsight.ncloud.com (169.254.80.16)​​TCP 80,443Cloud Insight Repository 서버
    169.254.80.22고객 VM 대역ICMPCloud Insight Ping Check 모니터링 서버
    169.254.80.23고객 VM 대역ICMPCloud Insight Ping Check 모니터링 서버

    Q. 네이버 클라우드 플랫폼의 서비스 데이터가 대시보드에서 조회되지 않습니다.

    A. 네이버 클라우드 플랫폼의 각 서비스에서 기본으로 제공하는 Basic Metric은 Cloud Insight에서 별다른 설정 없이 조회할 수 있습니다. 추가적으로 제공되는 Extended Metric은 각 서비스의 콘솔에서 설정이 필요합니다. (Server(VPC)의 경우 상세 모니터링 설정을 통해 설정할 수 있습니다.) 각 서비스에서 제공하는 Basic/Extended Metric은 API 가이드의 서비스 목록을 통해 확인할 수 있습니다. 또한 Extended Metric은 설정 시점부터 수집되기 때문에 Cloud Insight에서 조회하려면 조회 기간을 확인해 주십시오.

    Q. ASG 정책을 액션으로 등록했을 때 서버가 지속적으로 생성/삭제됩니다.

    A. Event Rule 생성 시 액션으로 ASG 정책을 설장한 경우, Event 발생 시 ASG 정책을 실행하게 됩니다. 이때 ASG 정책의 쿨다운 타임을 두고 계속해서 정책이 실행되며, Event가 종료되면 해당 정책 실행이 종료됩니다. 따라서 해당 Event가 종료되기 전까지 서버가 지속적으로 생성되거나 삭제될 수 있습니다.

    Q. Custom Schema를 생성했는데 콘솔에서 조회되지 않습니다.

    A. 생성된 Custom Schema로 데이터가 수집되어야 콘솔에서 확인할 수 있습니다. 데이터 전송은 SendData API를 참고해 주십시오. 데이터 수집이 시작된 후 Custom Schema 생성 시 설정한 집계 주기(Interval)에 따라 일정 시간이 지난 후에 데이터를 조회할 수 있습니다.

    Q. API로 데이터를 보냈는데 콘솔에서 조회되지 않습니다.

    A. Cloud Insight에서 데이터를 조회할 때 기본으로 설정되어 있는 기간은 조회 시점으로부터 1시간 이전입니다. API로 데이터를 보낸 시점이 포함되도록 기간을 설정한 후 조회해 주십시오.

    Q. API로 보낸 데이터와 대시보드에서 조회되는 결과가 다른 것 같습니다.

    A. Cloud Insight에서는 수집된 데이터를 일정 주기마다 여러 집계 함수를 이용하여 연산합니다. 연산된 결과가 조회되기 때문에 API로 보낸 데이터와 다르게 표시될 수 있습니다. Cloud Insight에서 데이터를 조회할 때 집계 주기(Interval)를 확인해 주십시오. 집계 주기와 집계 함수는 Custom Schema 생성 시 설정할 수 있습니다.

    Q. 별도 작업을 하지 않았는데 어느 시점 이후 메트릭이 수집되지 않습니다.

    A. root(/) 경로의 디스크 사용률이 99% 이상인 시점 이후부터는 Cloud Insight Agent가 정상 동작하지 않을 수 있습니다.
    따라서 해당 경로 디스크 용량 확보 및 점검이 필요합니다. 용량 확보 및 점검 이후 agent를 재시작하여 정상 수집되는지 확인합니다.


    이 문서가 도움이 되었습니까?

    Changing your password will log you out immediately. Use the new password to log back in.
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.