지리적으로 분산 된 내결함성 및 "지능형"응용 프로그램 / 호스트 모니터링 시스템


12

인사말,

분산 모니터링 시스템에 대한 의견과 견해를 묻고 싶습니다. 무엇을 사용하고 있으며 어떤 것이 내 박스를 체크 할 수 있는지 알고 있습니까?

요구 사항은 매우 복잡합니다.

  • 단일 실패 지점이 없습니다. 정말. 나는 심각하게 죽었다! '마스터'및 '작업자'모두 단일 / 다중 노드 장애를 허용 할 수 있어야하며 모니터링 위치 ( "사이트")에 여러 노드가 없거나 동일한 네트워크에 있다고 가정 할 수 있습니다. 따라서 이것은 아마도 DRBD 또는 Keepalive와 같은 전통적인 HA 기술을 배제 할 것입니다.

  • 분산 논리, 여러 데이터 센터 및 여러 대륙에 여러 네트워크에 5 개 이상의 노드를 배포하고 싶습니다. 고객의 관점에서 네트워크 및 응용 프로그램에 대한 "새 눈"보기, 50 개 이상의 노드 또는 500 개 이상의 노드가있을 때 모니터링 논리에 대한 보너스 포인트가 저하되지 않습니다.

  • 야구장 수치에 대해 상당히 합리적인 수의 호스트 / 서비스 확인 (la Nagios)을 처리 할 수 ​​있어야하며 호스트 당 1500-2500 개의 호스트와 30 개의 서비스를 가정합니다. 더 많은 모니터링 노드를 추가하여 상대적으로 선형으로 확장 할 수 있다면 정말 좋을 것입니다. 아마도 5 년 안에 호스트 당 5000 개의 호스트와 40 개의 서비스를 모니터링하려고 할 것입니다! 위의 '분산 논리'에 대한 참고 사항을 추가하면 다음과 같이 말할 수 있습니다.

    • 정상적인 상황에서 이러한 검사는 $ n 또는 n %의 모니터링 노드에서 실행해야합니다.
    • 장애가 감지되면 다른 $ n 또는 n %의 노드에서 검사를 실행하고 결과를 상관시킨 다음이를 사용하여 경보를 발행하기위한 기준이 충족되었는지 여부를 판별하십시오.
  • 그래프 및 관리 친화적 인 기능. SLA를 추적하고 '고 가용성'애플리케이션이 연중 무휴 24 시간 가동되는지 여부를 아는 것이 다소 유용합니다. 이상적으로 제안 된 솔루션은 최소한의 faff로 "즉시"보고해야합니다.

  • 맞춤형 검사 개발을위한 견고한 API 또는 플러그인 시스템이 있어야합니다.

  • 경고에 대해 합리적이어야합니다. 하나의 모니터링 노드가 코어 라우터가 다운 되었다는 것을 반드시 SMS를 통해 (3am!) 알고 싶지 않습니다 . 내가 않는 그들의 정의 비율이 알고 싶은 동의 뭔가 펑키이 벌어지고 있음) 기본적으로 제가 여기에 대해 이야기하고있는 것은 "쿼럼"논리, 또는 분산 광기에 정신의 응용 프로그램입니다!

상용 및 공개 소스 옵션을 모두 고려하고 싶습니다. 수백만 파운드의 비용이 드는 소프트웨어를 사용하지 않으려 고합니다 .-) 또한 모든 상자를 표시하는 아무것도 없을 수 있음을 인정합니다. 집단에게 물어보고 싶었습니다.

모니터링 노드와 배치에 대해 생각할 때, 이들 중 대부분은 임의의 ISP 네트워크에있는 전용 서버이므로 대부분 제어 할 수 없습니다. BGP 피드 및 기타 복잡한 네트워킹 기술에 의존하는 솔루션은 적합하지 않을 수 있습니다.

또한 Nagios, Zabbix 및 친구들을 포함하여 과거에 오픈 소스 맛의 대부분을 평가, 배포 또는 많이 사용 / 사용자 정의했음을 지적해야합니다.이 도구는 실제로 나쁜 도구는 아니지만 전체적으로 평평합니다. 특히 제 질문과 '지능적'경고에서 논의 된 논리와 관련하여 분산 된 측면입니다.

필요한 사항을 명확하게 설명해 드리겠습니다. 건배 남자와 여자 :-)


2
정말 이상합니다. 비슷한 질문을하려고했습니다. 이번 주에는 사이트 중단에 대한 고객 불만이 있었지만 특정 위치에서만 발생했습니다. Google 경보 시스템에서 이러한 문제를 감지하지 못했습니다. 우리는 공급자에게 연락하여 일부는 백본 문제가 있음을 확인했습니다. 그래서 나는 또한 해결책에 관심이 있습니다. 감사!
splattne

그리고 마지막 해결책은 무엇입니까?
ewwhite

답변:


4

실제로 대답은 아니지만 몇 가지 조언 :

  • nagios @ goldman sachs 에 관한 프리젠 테이션을 확인하십시오 . 중복성, 확장 성 : 수천 개의 호스트, 자동화 된 구성 생성이라는 문제에 직면했습니다.

  • 중복 nagios 설정이 있었지만 훨씬 작은 규모-80 서버, 총 ~ 1k 서비스. 하나의 전용 마스터 서버, 하나의 슬레이브 서버가 하루에 몇 번 정기적으로 마스터에서 구성을 가져옵니다. 두 서버 모두 동일한 시스템의 모니터링을 다루었으며 서로간에 상태를 교차 점검했습니다. 나는 주로 맞춤형 제품 별 검사를 호출하기위한 프레임 워크로 nagios를 사용했습니다 [ '인공적인 흐름 제어'를 수행하는 스크립트를 실행하는 크론 작업, SQL에 기록 된 결과웨어, nrpe 플러그인이 마지막 x 분 동안의 실행을 성공적으로 / 실패했는지 확인하는웨어]. 모두 매우 훌륭하게 작동했습니다.

  • 당신의 쿼럼 논리는 좋은 것 같습니다-나의 '인공적인 흐름'과 약간 비슷합니다-기본적으로 계속 진행합니다. 그리고 nrpe는 어떤 종류의 플래그를 확인하거나 [sql db with timestamp-status] 일을 어떻게하고 있는지 확인하십시오.

  • 확장 가능한 계층 구조를 만들고 싶을 것입니다. 다른 노드의 개요를 수집하는 노드가 있으며 첫 번째 시점에서 프리젠 테이션을 봅니다. 모든 단일 검사에 대해 기본 nagios 분기는 모니터링되는 서비스 수가 많을수록 과도합니다.

몇 가지 질문에 대답하기 위해 :

  • 필자의 경우 환경 모니터링은 마스터 마스터가 아닌 일반적인 마스터-슬레이브 설정 [primary sql 또는 app server + hot standby]이었습니다.
  • 내 설정에는 '휴먼 필터링 팩터'-SMS 알림의 '백업'인 리졸버 그룹이 포함되었습니다. 다른 이유로 24/5 교대 근무 한 기술자 그룹이 이미 있었으며 너무 많은 부담을주지 않는 추가 작업으로 'nagios 메일 확인'을 받았습니다. 그리고 그들은 db-admins / it-ops / app-admins ware가 실제로 문제를 일으키고 고치는 것을 확인하는 책임을지고;-]
  • zabbix 에 대한 많은 좋은 소식을 들었 습니다. 트렌드를 경고하고 플로팅하는 데 사용했지만 결코 사용하지 않았습니다. 나를 위해 munin 은 트릭을 수행합니다. 나는 서버의 munin 목록에 '빨간색'[critical] 색상이 있는지 확인하는 간단한 nagios 플러그인 검사를 해킹했습니다. 추가 검사입니다. munin rrd-files에서 값을 읽을 수 있으므로 모니터링되는 시스템에 보내는 쿼리 수를 줄일 수 있습니다.

1
@astinus-현명한 경고에 적합합니다. 사용자 정의 알림 스크립트를 사용했습니다. nagios에 의존하는 대신 메일 / 호출기로 알림 메시지를 fifoque에 저장하고 소비자에게 사용자 정의 논리 (매우 유연한 통화 일정 등을 기반으로 함)를 기반으로 메시지를 발송했다고 덧붙였습니다. 잠시 동안 50 smses를 얻지 못합니다. 나는 비슷한 접근법을 더 큰 규모로 봅니다. nagios는 단지 골격이며 사람들은 스크립트를 사용하며 실제로는 그 기능을 거의 사용하지 않습니다.
pQd

1
계층 구조와 관련하여 현재 내가 가지고있는 것은 etc / 디렉토리에 모든 호스트에서 공유되고 동일한 / cores / $ NAME (예 : 동일) 인 '코어'구성이 포함 된 완전히 "모듈 식"Nagios 설정입니다. : Mail, Web, Network, DNS) : 서버간에 100 % 이식 가능합니다. cfg_dir에 포함 =) 모듈 별 명령, 플러그인 및 해당 디렉토리에 모든 것을 넣습니다 . 필요한만큼 많은 Nagios 상자에 모듈을 복사하기 만하면> 1 서버에서 이러한 검사를 수행하는 것은 매우 쉽습니다. 그러나 경고 논리는 문제를 일으 킵니다 :-)
nixgeek

1
@ astinus # 2. 내 경우에는 구성 복제 마스터-> 슬레이브가 6 시간마다 발생합니다. 마스터가 막 죽는 경우 [정전 등]-슬레이브는 마스터가 죽었다는 것을 모두에게 경고합니다 [서버 간 교차 점검]. 구성이 잘못되어 마스터가 죽으면 다른 시나리오를 상상할 수 있습니다. 구성 동기화를 슬레이브에 동기화하기 전에 최대 5 분이 걸리면 알림이 표시됩니다. 구성 동기화 직전에-불행히도 우리는 모니터링 시스템을 갖지 못합니다. '파수꾼을 볼 사람은 누구입니까?' 아마도 또 다른 매우 간단한 nagios 일 것입니다.
pQd

1
@ pQd-흥미롭게도 사용자 지정 알림 스크립트에서 논리를 구현하는 것이 좋습니다. 그러나 50 개의 모니터링 호스트를 말했을 때 2 명 이상의 호스트에서 중복 알림을 피하는 것은 꽤 까다로워 요. 누구나 (공개) 누군가가 공유 논리를 Rabbit 또는 Amazon과 같은 적절한 '메시지'전달 시스템에 넣는 것을 보지 못했습니다. SQS.
nixgeek

1
내 경우에는 @astinus # 3 '이소 osi 모델'의 '레벨 8'솔루션 : 기본 nagios는 전화 + 메일을받는 사람들에게 24/5 'resolver group'으로 SMS를 보내고 2 번째 nagios는 메일 링 만 ' 리졸버 그룹 '. 이관하기 전에 중복을 필터링하는 것은 해당 그룹의 책임입니다.
pQd

1

당신이 요구하는 것은 Shinken이 Nagios를 위해 한 것과 매우 흡사합니다.

Shinken은 Nagios 재작 성입니다.

  • 현대 언어 (Python)
  • 최신 분산 프로그래밍 프레임 워크 (Pyro)
  • 영역 (다중 테넌시), HA, 스페어 모니터링
  • Livestatus API
  • Nagios 플러그인 호환
  • 기본 NRPE 실행
  • 객체의 비즈니스 중요도
  • 비즈니스 규칙을 객체 상태에 적용 할 수 있습니다 (클러스터 또는 풀 가용성 관리)
  • 그래프는 흑연 또는 RRDtool 기반 PNP4nagios를 사용할 수 있습니다
  • 대규모 환경에서 안정적으로 구축
  • 대규모 배포에서는보고를 위해 Splunk와 페어링하거나 RRDtool이 적합하지 않은 Graphite를 살펴볼 수 있습니다.

이것은 생각을위한 음식이어야합니다.

건배

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