C ++ 애플리케이션 모니터링


10

새로운 중앙 집중식 모니터링 솔루션 (Zenoss)을 구현하고 있습니다. SNMP, JMX를 사용하면 서버, 네트워킹 및 Java 프로그램을 간단하게 통합 할 수 있습니다.

그러나 문제는 이기종 (Solaris x86, RHEL Linux, Windows) 환경에서 사용자 지정 C ++ 응용 프로그램을 모니터링하고 관리하는 모범 사례는 무엇입니까?

내가 볼 수있는 가능성은 다음과 같습니다.

  1. 넷 SNMP
  • 장점
  1. 각 서버의 단일 중앙 데몬
  2. 잘 알려진 표준
  3. 모니터링 솔루션에 쉽게 통합
  4. 우리는 이미 서버에서 Net SNMP 데몬을 실행합니다
  • 단점 :
    1. 복잡한 구현 (MIB, Net SNMP 라이브러리)
    2. C ++ 개발자를위한 새로운 기술
  • rsyslog
    • 장점
    1. 각 서버의 단일 중앙 데몬
    2. 잘 알려진 표준
    3. 모니터링 솔루션에 알 수없는 통합 (텍스트를 기반으로 경고를 할 수는 있지만 메모리 사용량, 대기열 깊이, 스레드 용량 등과 같은 원격 측정을 보내는 데 얼마나 효과적입니까?)
    4. 간단한 구현
  • 단점 :
    1. 가능한 통합 문제
    2. C ++ 개발자를위한 다소 새로운 기술
    3. 모니터링 공급 업체를 전환하면 발생할 수있는 이식 문제
    4. 아마도 애드혹 통신 프로토콜 (또는 RFC5424 구조화 된 데이터 사용)이 필요할 것입니다. Zenoss가 사용자 정의 Zenpack 코딩없이이를 지원하는지 여부는 알 수 없습니다.
  • 임베디드 JMX (JVM 포함 및 JNI 사용)
    • 장점
    1. Java 및 C ++ 모두에 대한 일관된 관리 인터페이스
    2. 잘 알려진 표준
    3. 모니터링 솔루션에 쉽게 통합
    4. 다소 간단한 구현 (우리는 이미 다른 목적 으로이 작업을 수행함)
  • 단점 :
    1. 복잡성 (JNI, 기본 C ++과 Java 사이의 썽킹 계층, 기본적으로 관리 코드를 두 번 작성)
    2. 가능한 안정성 문제
    3. 상당히 많은 메모리를 사용하여 각 프로세스마다 JVM이 필요합니다.
    4. JMX는 C ++ 개발자를위한 새로운 기술입니다
    5. 각 프로세스에는 자체 JMX 포트가 있습니다 (각 시스템에서 많은 프로세스를 실행 함)
  • 로컬 JMX 데몬, 프로세스가 연결됨
    • 장점
    1. 각 서버의 단일 중앙 데몬
    2. Java 및 C ++ 모두에 대한 일관된 관리 인터페이스
    3. 잘 알려진 표준
    4. 모니터링 솔루션에 쉽게 통합
  • 단점 :
    1. 복잡성 (기본적으로 관리 코드를 두 번 작성)
    2. 그런 데몬을 찾거나 쓸 필요가있다
    3. JMX 데몬과 C ++ 프로세스 사이에 프로토콜이 필요합니다.
    4. JMX는 C ++ 개발자를위한 새로운 기술입니다
  • CodeMesh JunC ++ ion
    • 장점
    1. Java 및 C ++ 모두에 대한 일관된 관리 인터페이스
    2. 잘 알려진 표준
    3. 모니터링 솔루션에 쉽게 통합
    4. 공유 JVM 모드에서 실행될 때 각 서버의 단일 중앙 데몬
    5. 다소 간단한 구현 (코드 생성 필요)
  • 단점 :
    1. 복잡성 (코드 생성, 프록시 코드 생성을 위해 GUI 및 여러 번의 조정이 필요함)
    2. 가능한 JNI 안정성 문제
    3. 상당히 많은 메모리를 사용하는 각 프로세스마다 JVM이 필요합니다 (임베디드 모드).
    4. Solaris x86 (거래 차단기)을 지원하지 않습니다
    5. Solaris x86을 지원하더라도 컴파일러 호환성 문제가있을 수 있습니다 (Solaris에서 STLPort와 Forte의 홀수 조합 사용)
    6. 임베디드 프로세스에서 실행될 때 각 프로세스마다 고유 한 JMX 포트가 있습니다 (각 시스템에서 많은 프로세스를 실행합니다)
    7. 비 C ++ 프로세스의 공유 JMX 서버를 배제 할 수 있음 (?)

    내가 누락 된 합리적으로 표준화 된 간단한 솔루션이 있습니까?

    다른 합리적인 솔루션이 없다면,이 솔루션들 중 어떤 것이 커스텀 C ++ 프로그램에 일반적으로 사용됩니까?

    내 생각에 Net SNMP는 사람들이 그렇게하는 방식이지만 결정을 내리기 전에 다른 사람들의 의견과 경험을 원합니다.

    답변:


    1

    나는 Zenoss에 익숙하지 않지만 이런 종류의 일에 nagios 를 사용했을 때 c / c ++ 프로세스가 소켓에서 수신 대기 하고 진단 및 상태 정보를 전달 하는 사용자 정의 nagios 플러그인 을 작성하게됩니다.

    첫 번째 단계는 프로세스가 청취하도록하는 데 사용하려는 lib를 선택하는 것입니다. C ++ 소켓 라이브러리 와 같은 것이이를 수행합니다. 거기에는 복잡한 것이 없습니다. 프로세스 만 들으십시오.

    그런 다음 프로세스가 특정 자극을받을 응답을 정의해야합니다. 이것은 실제로 '서비스'를 정의한 다음 프로세스에 해당 서비스에 해당하는 신호를 보내는 것을 의미합니다 (적어도 nagios 사용). 가장 간단한 방법은 '프로세스 핑'을 생성하여 실행중인 프로세스에 성공적으로 연결할 수 있는지 확인하는 것입니다. 당신이 사용자 정의 nagios 플러그인보다 알고 있다면 적어도 프로세스는 여전히 살아있다.

    당신이 할 수있는 훨씬 더 복잡한 것들이 있지만 아이디어는 충분히 간단합니다. 객체 내에 캡슐화 된 프로세스 리스닝 코드의 작은 라이브러리를 작성하고 하나 또는 모든 실행 파일을 빌드 할 때마다 표준화 된 방식으로 사용자 지정 C ++ 항목으로 가져올 수 있습니다.

    내 이해는 Zenoss도 이것을 할 수 있습니다 .

    아마도 Zenoss가 파이썬이기 때문에 듣기 c ++ 실행 파일에 연결하기 위해 Twisted 와 같은 것을 사용하여 사용자 정의 플러그인을 작성합니다 .


    1

    나는 당신이 명명 한이 제품에 익숙하지 않지만 Windows의 경우 perfmon을 사용하여 메모리 소비를 모니터링합니다. 프로그램되지 않은 풀 오류와 같은 특수 카운터가 있습니다. 내 의견으로는 이것은 간단한 확인 방법입니다.

    Windows에서는 원격으로 perfmon을 사용하여 많은 작업을 수행하거나 WMI를 사용하여 동일한 카운터에 연결하고 작업을 수행하기 위해 WMI에서 일부 자동화를 수행 할 수 있습니다.


    1

    우리가 최근에 당신과 같은 과정을 겪었을 때 나는 이것을 선택하고 있습니다 : 우리는 C / C ++ 서비스 내에서 메트릭의 노출 및 후속 원격 모니터링을 가능하게하는 경량의 비 블로킹 오픈 소스 솔루션을 찾고있었습니다 ( ~ 3000 정도입니다.

    SNMP가 가장 가까이 왔지만 소스와 모니터링 시스템으로의 통합은 고통스럽고 실시간 프로세스에는 적합하지 않습니다.

    결국, 우리 는 공유 메모리 기술을 사용하여 공개 소스로 만든 CMX 라는 새로운 솔루션을 개발하기로 결정했습니다 . www.cern.ch/cmx 에서 확인할 수 있습니다 .


    0

    나는 c ++ 측면에 익숙하지 않지만 Java 에서는 Graphite 와 함께 CodaHale 메트릭을 광범위하게 사용 합니다. CodaHale은 인스턴스의 로컬 메모리에 인스턴스별로 메트릭을 저장 한 다음 백그라운드 스레드를 사용하여 1 분마다 흑연 서버에 메트릭을 플러시합니다 (구성 가능). 흑연에서는 여러 인스턴스를 집계하고 결함이있는 인스턴스를 식별 할 수 있습니다. 흑연 클러스터를 유지 관리하는 복잡성을 원하지 않으면 HostedGraphite 를 사용할 수 있습니다 .

    이 설정은 메트릭 집계 또는보고에 대한 단일 실패 지점이 없음을 의미합니다 (시간 기반 집계는 노드 자체에서 발생하고보고 집계는 분산 흑연 클러스터 (또는 호스트 흑연)에서 발생 함).

    마지막으로, Seyren 을 사용 하여 모니터링 데이터 위에 경고를 제공 할 수 있습니다 .


    0

    Windows를 사용하는 경우 이벤트 로그에 기록한 다음 WMI 또는 유사한 프로세스를 사용하여 이벤트를 읽으십시오. 모니터링을 원할 경우 성능 모니터 카운터를 앱에 추가하고 perfmon이이를 읽도록합니다. 둘 다 Windows의 시스템 서비스입니다.

    Linux에서는 분명히 융통성이있는 경향이 있지만, nagios 스타일 서버로 데이터를 보내는 사용자 정의 소켓을 사용하여 nagios 스타일 모니터가 항상 구현되는 것을 보았습니다.

    SMNP 가 사용되는 여러 곳을 보았는데 솔직히 말해서, 왜 당신이 완전히 이질적인 환경을 운영하고 있다면 그것을 사용하지 않는 이유를 알 수 없습니다.

    당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
    Licensed under cc by-sa 3.0 with attribution required.