이것은 모니터링 소프트웨어에 대한 정식 질문 입니다.
서버를 모니터링해야합니다. 모니터링 솔루션을 결정할 때 고려해야 할 사항은 무엇입니까?
관련 : 서버를 모니터링하기 위해 어떤 도구를 사용합니까?
—
Chris S
이것은 모니터링 소프트웨어에 대한 정식 질문 입니다.
서버를 모니터링해야합니다. 모니터링 솔루션을 결정할 때 고려해야 할 사항은 무엇입니까?
답변:
거기에는 많은 모니터링 솔루션이 있습니다. 모든 사람은 자신의 취향을 가지고 있으며 각 비즈니스마다 고유 한 요구가 있으므로 정답은 없습니다. 그러나 모니터링 솔루션을 선택할 때 원하는 것을 파악할 수 있도록 도와 드릴 수 있습니다.
일반적으로 모니터링 시스템은 두 가지 주요 목적을 제공합니다. 첫 번째는 시간이 지남에 따라 데이터를 수집하고 저장하는 것입니다. 예를 들어 CPU 사용률을 수집하고 시간이 지남에 따라 그래프를 표시 할 수 있습니다. 두 번째 목적은 상황이 응답하지 않거나 특정 임계 값 내에 있지 않은 경우 경고하는 것입니다. 예를 들어, 핑으로 특정 서버에 도달 할 수 없거나 CPU 사용률이 특정 백분율을 초과하는 경우 경고를 원할 수 있습니다. Splunk와 같은 로그 모니터링 시스템도 있지만이를 별도로 처리하고 있습니다.
이 두 가지 주요 역할은 때때로 단일 제품에서 제공되며 다른 경우에는 각 목적에 맞는 제품을 보유하는 것이 더 일반적입니다.
폴러 :
모든 모니터링 시스템은 데이터를 수집하기 위해 일종의 폴러가 필요합니다. 모든 데이터가 같은 방식으로 수집되는 것은 아닙니다. 환경을보고 필요한 데이터와 수집 방법을 결정해야합니다. 그런 다음 선택한 모니터링 시스템이 필요한 것을 지원하는지 확인하십시오. 몇 가지 일반적인 방법은 다음과 같습니다.
환경에 기본적으로 하나의 OS 또는 기본 OS가있는 경우 특정 시스템에 다른 시스템보다 더 많은 옵션이있을 수 있습니다.
구성 :
모니터링 시스템에서 많은 객체 재사용이 발생하는 경향이 있습니다. 예를 들어 여러 서버에서 Apache 또는 IIS와 같은 특정 응용 프로그램을 모니터링하려고합니다. 또는 서버 그룹에 특정 임계 값을 적용하려고합니다. 특정 그룹의 사람들이 "통화 중"상태 일 수도 있습니다. 따라서 훌륭한 템플릿 시스템은 모니터 시스템에 필수적입니다.
구성은 일반적으로 사용자 인터페이스 또는 텍스트 파일을 통해 수행됩니다. 사용자 인터페이스 옵션은 일반적으로 더 쉽지만 텍스트 파일은 재사용 및 변수에 더 나은 경향이 있습니다. 따라서 IT 직원에 따라 전력보다 단순성을 선호 할 수 있습니다.
사용자 인터페이스 :
요즘 시스템 모니터링을위한 가장 일반적인 인터페이스는 웹 인터페이스입니다. 웹 인터페이스와 관련하여 평가해야 할 사항은 다음과 같습니다.
경고 엔진 :
경고 엔진은 유연하고 안정적이어야합니다. 알림을받는 방법에는 여러 가지가 있습니다.
찾을 다른 기능은 다음과 같습니다.
문제가 발생하면 경고를 받게된다는 것을 신뢰하는 것이 중요합니다. 이것은 두 가지로 귀결됩니다.
데이터 저장 :
시스템이 데이터를 저장하는 것보다 시스템이 데이터 (예 : 그래프를 포함하는 시스템)를 수집하고 저장하는 경우 상점과 그래프 모두에 대한 매우 일반적인 구현은 예를 들어 RRD입니다.
데이터 저장소에서 찾아야 할 일부 기능은 다음과 같습니다.
그래프 라이브러리 :
그래프는 트렌드를 빠르게 식별하고 히스토리를 기반으로 무언가의 현재 상태에 컨텍스트를 제공하는 데 유용 할 수 있습니다. 발생하기 전에 상황을 예측하는 데 도움이 될 수있는 추세 (예 : 디스크 공간 부족)가 포함됩니다. 그래프를 통해 원하는 방식으로 명확한 정보를 얻을 수 있습니다.
액세스 제어 :
대규모 조직의 경우 특정 관리자 만 특정 항목을 조정할 수 있으므로 액세스 제어가 필요할 수 있습니다. 공개 대시 보드를 원할 수도 있습니다. 이것이 중요한 경우 모니터링 시스템에 필요한 제어 기능이 있는지 확인해야합니다.
보고 :
좋은 보고서를 제공하는 시스템을 통해 장기간 개선해야 할 사항을 식별 할 수 있습니다. 예를 들어 "어떤 시스템이 가장 많이 다운됩니까?"와 같은 것들에 대한 좋은 대답을 줄 수 있습니다. 이것은 경영진이 특정 사물에 돈을 쓰도록 설득하려고 할 때 중요 할 수 있습니다.
특수 기능 :
일부 모니터링 시스템은 특정 제품을 대상으로하거나 다른 제품보다 더 많은 지원을받습니다. 예를 들어, 모니터링해야 할 주요 사항이 SQL Server이거나 VMWare 제품을 많이 사용하는 경우 이들이 얼마나 잘 지원되는지 확인할 수 있습니다.
사전 정의 된 모니터링 템플릿 :
사전 정의 된 템플릿이 많은 시스템 (또는 많은 템플릿을 만든 사용자 기반이있는 시스템)은 시간을 크게 절약 할 수 있습니다.
발견 :
환경이 크거나 변화하는 경우. 일부 시스템은 API를 통해 새 시스템을 추가하거나 스캔을 실행하여 새 서버 또는 구성 요소를 찾을 수있는 기능을 제공합니다.
분산 모니터링 : 모니터링
할 여러 위치가있는 경우 많은 독립 시스템이 WAN을 통해 모니터링하는 대신 각 위치에 폴러를 모니터링하는 것이 도움이 될 수 있습니다.
거기에는 많은 모니터링 시스템이 있습니다. 이 오래된 질문에 대한 요약 목록이 있습니다. 빠른 참조를 위해 가장 많이 듣는 부분은 다음과 같습니다.
내가 무엇을 사용해야하는지 말할 수없는 이유는 모든 조직마다 고유 한 요구 사항이 있기 때문입니다. 올바른 선택을하려면 위의 모든 구성 요소를 고려하여 조직에 어떤 기능이 중요한지 파악해야합니다. 그런 다음 필요한 것을 제공한다고 주장하는 시스템을 찾아보십시오. 이 중 일부는 비용이 많이 들거나 무료이거나 무료입니다. 이 모든 것을 고려하면 선택을 할 수 있습니다. 내가 사용한 것에서 그들은 완벽하지는 않지만 적어도 당신은 맞는 것을 얻으려고 노력할 수 있습니다.
모니터링과 경고를 구분하는 데 도움이됩니다. 모니터링은 데이터를 수집하고 그래프를 만드는 것을 의미합니다. 경고는 한밤중에 서버가 다운되면 SMS를 보내라는 의미입니다.
Nagios는 경고 용입니다. Cacti와 Munin은 모니터링을위한 것입니다. 다른 제품은 두 기능을 결합합니다. Zenoss와 Zabbix가 그 예입니다.
몇 가지 질문에 대답하는 것으로 시작하겠습니다.
서버, 네트워크 장치, 응용 프로그램 또는 세 가지 모두를 모니터링해야합니까?
모니터링하는 데 사용할 수있는 방법에 제한이 있습니까? 서버에 NRPE와 같은 모니터링 클라이언트를 설치할 수 있습니까, 아니면 SNMP를 사용 하시겠습니까?
누가 그래프를 사용하고 누가 경고를 사용합니까? 최종 결과는 어떻습니까? 인터페이스의 모양과 느낌이 중요합니까 (기업인이 이것을 사용합니까, 아니면 기술 직원 만 사용합니까?)
시간, 기술 및 하드웨어 측면에서 귀하의 자원은 무엇입니까? 최소한의 스크립팅 기능이 있습니까? 기본 솔루션이 필요하십니까?
제 생각에는 경고와 모니터링의 첫 번째 규칙은 간단하게 유지해야합니다! 조직은 데이터를 알리고 수집하는 방법에 따라 살거나 죽을 수 있으며 대부분의 경우 자체적으로 복잡해집니다. 기본부터 시작하여 거기서부터 구축하십시오.
소프트웨어가 제공 하는 서비스 에 대해 생각하고, 이러한 서비스가 실패 할 때 또는 이러한 서비스의 실패 위험 이 증가 할 때 경고를 보냅니다 .
모니터링 전략의 이론은 모니터링 및 경고를 일종의 서비스 수준 계약에 연결하는 것 입니다. 결국, nji0019.myserver.com에 대한 TCP 연결 수가 급격히 증가 할 필요는 없지만 돈을 잃고 있다는 사실을 알고 싶습니다. 많은 경고를 제공하고 경고 사이의 종속성을 정의하는 다양한 도구가 있지만 이러한 검사 중 다수는 사용자에게 제공 하는 서비스 와 직접 관련이 없습니다 .
웹 사이트를 제공하는 기능 및 해당 웹 사이트를 수정하는 기능 (예 : 일종의 CMS)과 같이 제공하는 중요한 서비스를 식별하십시오. 그것들은 (예를 들어 웹 페이지를 얻을 수 있고 모니터링 할 수 있는지 모니터링하여) 확인해야합니다. 이 두 서비스 (자본 S와 함께 사용)가 실패하면 알림 메시지가 표시됩니다.
사이트가 적절한 시간 내에 응답하는 것이 중요하면 경고도 트리거해야합니다. "SLA 위반"에 해당합니다.
일반적으로 서비스가 실패 할 위험이 있으며, 두 번째 서버, 슬레이브 데이터베이스 또는 여분의 네트워크 카드와 같은 중복성을 도입한다는 사실로 인해 위험이 완화 될 수 있습니다.
중복성이 손실 된 경우 서비스는 여전히 문제가되지 않지만 서비스 실패 위험이 커졌습니다.
이것이 경고를 발생시키는 두 번째 주요 이유입니다. 중복성이 사라지거나 (예 : 두 번째 서버가 사망 한 경우) 또는 위험이 증가 할 수있는 임박한 위험이 있습니다 (예 : 디스크에 500Mb 만 남아 있거나 디스크 추세는 디스크가 약 5 시간 내에 가득 찼음을 나타냅니다).
그러나 check_mk는 호스트 당 50-60 개의 검사를 제공합니다.
아니요.이 모든 것이 당신이 예를 들어 check_mk와 같이 과도하게 많은 자동 점검을 버리고 싶지 않다는 것을 의미하지만, 어떤 점검이 실패하면 어떤 점검이 영향을 받는지에 각각의 점검을 분류해야한다는 것을 의미합니다.
/ var / 파티션이 가득 차면 어떤 서비스가 영향을 받습니까? eth0 인터페이스가 다운되면 어떤 서비스가 영향을 받습니까? ... 일부 방화벽에 의해 아웃 바운드 TCP 연결이 차단 된 경우? ... 스레드 수가 800을 초과하면? ... 데이터베이스가 다운되면?
2 대의 웹 서버와 소유하지 않은로드 밸런서 뒤에 사이트를 제공하는 데이터베이스 서버 (예 : ISP)가 있습니다. 제공하는 서비스는 두 서버의 포트 80이며 데이터베이스 다운 타임 (세번째 서버의 데이터베이스)과 같이 살아남을 수있는 거대한 캐시를 가지고 있습니다.
이 시나리오에서 웹 서버가 완전히 실패하면 사이트가 다운되지 않습니다. 일어난 일은 실패 의 위험이 막 올라가 도록 중복성이 사라 졌다는 것입니다 . 그 경고를 트리거합니다.
잘 조정 된 캐시가 제 위치에 있기 때문에 데이터베이스가 완전히 실패해도 사이트를 제공하는 기능에는 전혀 영향을 미치지 않을 수 있습니다. 그러면 웹 사이트를 제공 하는 서비스에는 영향을 미치지 않지만 웹 사이트를 업데이트하거나 주문을 수락하는 다른 서비스에는 영향을 줄 수 있습니다.
각 서비스에는 서비스를 복원하거나 중단을 피하는 것이 얼마나 중요한지를 지정하는 자체 서비스 수준이 있습니다.
경고를받을 때마다 다음 중 하나를 수행해야합니다.-경고의 원인이되는 문제를 해결하기 위해 모니터링되는 시스템 변경 (예 : 드라이브 교체 또는 로그 회전 재구성 등)-경고가 발생하지 않도록 모니터링 시스템 변경 다음 번에 상황이 발생했을 때 보냈습니다. (예 : 디스크가 80 % 대신 최대 90 %까지 채워질 수 있도록 "디스크 여유 공간"레벨을 변경하십시오.)
나는 주로 Nagios와 그 자세한 구성에 익숙하며 Check-mk의 다중 사이트에 매료되었습니다. 나는 최근 check_mk가이 사고와 잘 어울리는 비즈니스 인텔리전스 (1.11 이후) 개념을 가지고 있다는 것을 배웠다. nagios의 검사가 더 큰 서비스의 일부이며 "서비스"의 상태를 많은 검사 상태의 함수로 정의하여 최악 또는 최상의 상태로 집계하는 규칙을 정의 할 수 있습니다.
모니터링 솔루션을 선택할 때 기업이 잊고있는 가장 중요한 점 중 하나는 즉각적인 운영 문제를 해결 하는 것이 아니라 내일의 예상치 못한 문제를 해결하는 것입니다. 당연히 즉각적인 문제를 해결하는 것이 중요하지만 많은 경우에이 근시안 전략이 회사의 생존을 보장하지는 않습니다.
시장에는 수십 가지 훌륭한 모니터링 솔루션이 있습니다. 또한 요구 사항을 충족하는 소규모 솔루션을 선정하는 것은 어렵고 긴 작업이며 예산에 맞는 솔루션을 찾는 것이 훨씬 더 어렵습니다. 흥미로운 부분은 현재와 미래에 맞는 것을 찾는 것입니다 . 그리고 경험 + 직관 + 매우 중요한 요소 인 신뢰 의 문제라는 것을 감지하는 평가 프로세스 가 없습니다. 이것은 해킹 하기 쉽지 않습니다 .
경험상, 특히 해당 분야의 회사에 영향을 미치는 경우, 후보 모니터링 솔루션 세트의 성공 사례 를 검색하고 발굴 하십시오. 공급 업체에 성공 사례를 문의하고 고객 중 한 명과 대화 할 수있는 권한을 요청하십시오. 이를 두려워하지 않는 회사는 고객과의 실제 관계가 있으며이를 숨기지 않으며 오늘날에는 매우 드문 일입니다.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... 모두 기복이 있지만 실제 문제 는 어느 것이 미래에 더 잘 적응하는지 찾는 것입니다.
원격 시스템 모니터링을 고려중인 경우 테스트가 수행되는 실제 위치를 찾는 것이 좋습니다. 연결 문제는 과거의 일이 아니며 하드웨어가 특정 지역의 그룹에 서비스를 제공하는 경우 해당 특정 위치에서 리소스를 사용할 수 있는지 확인하고자 할 수 있습니다.