백업 등을 모니터링하고 해당 데이터의 추세를 파악하기위한 최고의 도구 [닫기]

나는 nagios, opennms 및 zenoss에 대한 연구를 수행했지만 내가 찾고있는 것을 찾았다는 확신이 없습니다.

지금 저의 주요 원동력은 백업을 모니터링하는 것입니다. 여기에는 mysql, mssql 및 결국 일부 파일 시스템 백업이 포함됩니다.

서로 다른 시스템의 백업 프로세스를 래핑하고 통계를 수집하는 도구가 있습니다. 따라서 다음과 같은 항목이 있습니다.

• 백업 된 데이터베이스 수
• DB 백업 파일의 크기
• 압축 된 DB 백업 파일의 크기
• 백업 시간
• zip 파일 시간

A) 일정에 따라 작업이 실행되지 않으면 알림을받을 수 있기를 원합니다. B) 알림을 트리거하는 통계에 임계 값을 설정할 수 있습니다. C) 통계를 추세 화하고 그래프로 표시 할 수 있기를 원합니다.

HTTP POST를 통해이 정보를 모니터링 응용 프로그램으로 보낼 계획입니다. 또는 모니터링 응용 프로그램이 로그 파일에서도이를 가져올 수 있습니다.

그러나 모니터링 및 경향이있는 다른 "임의"(모니터링 시스템의 관점에서) 정적을 갖는 다른 프로세스가 있으므로 유연성이 매우 중요합니다.

또한 툴은 네트워크 인터페이스, 서버로드 등의 일반적인 모니터링 및 트 렌딩을 수행 할 수 있어야합니다. 백업 모니터링이 완료되면 해당 항목도 포함 시키려고합니다.

감사.

후속 조치 :

주어진 순서대로 다음을 시도하기로 결정했습니다.

• Zabbix : 다른 것보다 "원 스톱 상점"으로 보였으며 Ubuntu Lucid RC에 쉽게 설치할 수 있습니다.
• 견해
• Nagvis w / nagvis, pnp4nagios, nagiosgraph
• 선인장과 NPC 플러그인
• Munin : 단순함이 약간 두려웠지만 장기적으로는 축복이 될 수 있습니다.

일단 결정을 내렸다가 다시 게시 할 때까지는 시간이 걸릴 수 있습니다.

자체 모니터링 솔루션을 작성하는 대신 모든 기본 모니터링 및 경고 기능이 이미 구현되도록 기존 도구를 사용하는 것이 좋습니다. Nagios를 선택하면 서버 및 네트워크 리소스에 대한 기본 모니터링이 무료로 제공되며 다음 플러그인은 필요한 나머지 부분을 대부분 제공합니다.

check_file_ages_in_dirs 는 백업 파일이 존재하는지 알려줍니다. 여기 에 몇 가지 기본 예제로 작성한 블로그 게시물이 있습니다.

check_file 은 파일 크기와 내용을 모니터링 할 수 있으므로 (regexes 사용) 백업 통계를 파일로 출력하고 모니터링 할 수 있습니다.

Nagios에서 얻을 수없는 한 가지는 추세와 그래프입니다. 설치 가 간단하고 Nagios와 마찬가지로 기여 플러그인 스택이 있기 때문에 Munin 을 살펴 보는 것이 좋습니다 .

이것은 zabbix로 설정하기가 매우 쉽습니다.

사용자 지정 (매우 강력한) 임계 값을 설정하는 것은 쉽습니다. 원하는 식을 작성할 수 있으므로 "이 5 대의 서버 중 3 대 이상이 백업에 성공하지 못한 경우 알림"과 같은 것이 가능합니다. 6 가지 심각도 수준 및 에스컬레이션을 사용하여 유연한 알림 및 경고를 얻을 수 있습니다.

zabbix는 데이터 저장 및 시각화 기능을 번들로 제공합니다. 모든 데이터는 데이터베이스에 저장되며 단일 메트릭을 그래프 화하기 위해 구성이 필요하지 않습니다. "무료"에 대한 그래프 만 얻을 수 있습니다. 장기 저장 및 추세 분석을 위해 1 시간 평균이 계산됩니다.

백업에 대한 데이터를 zabbix로 가져 오는 것과 관련하여 여러 가지 가능성이 있습니다. 파일에서 읽을 수 있고, 사용자 정의 명령을 실행할 수 있으며, 명령 줄 유틸리티 zabbix_sender를 사용하여 모니터링되는 시스템에서 푸시 할 수 있습니다.

확장은 쉽습니다. 데이터를 반환하는 모든 사용자 지정 명령을 사용하여 해당 데이터를 수집, 저장 및 시각화 할 수 있습니다.

물론 운영 체제, 응용 프로그램, snmp 및 ipmi 장치 등의 일반적인 모니터링이 가능합니다.

실행

백업은 backupninja에 의해 조정됩니다 . 나는 내 bash 스크립트의 래퍼를 사용한다-단일 백업 로그를 갖기 위해. 각 스크립트는

 function handle {
         echo Error
         error problem occured
 }
 set -e
 trap handle ERR

따라서 명령 (예 : mysqldump 또는 rsync)이 실패 할 때마다 로그에 오류가 발생합니다.

모든 백업은 rdiff 저장소에 들어가 므로 n 일 단위로 증가합니다.

모든 백업은 rsync를 사용하여 중앙 스토리지 서버로 전송됩니다.

스토리지 서버에서 모든 백업은 매일 확인되며 로컬 디스크의 데이터를 성공적으로 확인한 후 외부 USB 드라이브로 복사됩니다.

확인

모든 서버의 backupninja.log는 nagios에 의해 모니터링됩니다. DEBUG 및 INFO 메시지 만 포함되어 있는지 확인합니다. 다른 것은 경고를 유발합니다.

모든 백업은 테스트 파일을 '만지고'존재 및 최신 상태는 nagios를 사용하여 중앙 백업 저장소 서버에서 모니터링됩니다.

또한 더 중요한 SQL 덤프의 크기 (신선도는 아님)와 완전성 (예 : mysql 덤프의 끝에서 나는 새로운 타임 스탬프를 예상 함)을 확인합니다.

-2010-04-22 23:21:02에 덤프 완료

모든 rdiff 아카이브는 데이터가 USB 드라이브에 동기화되기 전에 매일 확인 된 다음 동기화 된 후에 다시 확인됩니다. 야간 전송이 중단 되더라도 USB 디스크에 일관된 저장소가 있습니다. 검사 결과는 nagios에 의해 검사 된 내용과 최신 정보를 파일에 기록합니다.

USB 디스크는 매주 회전하며 경우에 대비하여 오프라인으로 저장됩니다. 이것은 더 많은 양의 데이터에는 과잉 일 수 있지만 ~ 300GB의 천천히 변경되는 파일 / 덤프에는 적합합니다.

트렌드

간단한 사용자 정의 munin 플러그인을 사용 하여 각 rdiff 저장소의 diff / data 크기를 플로팅합니다.

실행하는 데 걸리는 시간은 backupninja 로그에서 확인할 수 있지만 지금은 신경 쓰지 않습니다.

nagios는 트 렌딩을 수행 할 수 있지만 플러그인에서 perfdata ( http://nagios.sourceforge.net/docs/1_0/perfdata.html ) 를 출력해야합니다 . pnp4nagios http://docs.pnp4nagios.org/pnp-0.4/start 를 사용하면 모든 것이 그래프로 표시됩니다.

opsview http://www.opsview.org/ 를 사용 하는 것이 nagios 및 pnp4nagios를 구성하는 것보다 훨씬 쉽다는 것을 알았습니다. 특히 당신이 직장에서 유일하게 리눅스에 정통한 관리자라면. Opsview는 웹 브라우저에서 거의 모든 작업을 수행 할 수있는 훌륭한 웹 UI가있는 nagios입니다. nagios이므로 과거에 사용했던 모든 nagios 플러그인을 사용할 수 있습니다. 훌륭한 도구입니다.

경고를위한 Nagios , 그래프를위한 Cacti 및 일부 쉘 또는 펄 스크립트는 원하는대로 정확하게 수행합니다. 이들을 함께 사용하면 기꺼이 노력하는 양에 따라 거의 모든 것을 할 수 있습니다.

OpenNMS를 권장 합니다. 패키지는 완전히 오픈 소스이며 적극적으로 지원되며 정기적으로 향상됩니다. 참고로 Wiki 구성 정보에서 Symantec Backup Exec 을 모니터링했습니다 .

그들의 웹 사이트에서 ..

OpenNMS는 오픈 소스 모델로 개발 된 세계 최초의 엔터프라이즈 급 네트워크 관리 플랫폼입니다. 커뮤니티 지원 오픈 소스 프로젝트와 상업 서비스, 교육 및 지원 조직으로 구성됩니다.

공개 : 저는 여기서 상업적인 관심이 없지만 위에서 언급 한 "상업 서비스, 교육 및 지원 조직"인 OpenNMS Group 의 소유자 는 저의 친구입니다.

이것은 Circonus ( http://circonus.com/ )로 쉽게 수행 할 수 있습니다 . 우리는 Resmon XML DTD를 통해 이와 같은 메트릭을 정기적으로 가져옵니다.