운영 및 유지 관리 모니터링을 효과적으로 수행하려면 어떻게 해야 합니까?

최종 분석에서 통합 모니터링 플랫폼은 본질적으로 모니터링 시스템에 필수적입니다. 모니터링의 본질로 돌아가서 먼저 전체 모니터링 시스템을 정리하겠습니다.

① 모니터링 시스템의 본질은 장애를 감지하고, 장애를 해결하고, 장애를 예방하여 비즈니스의 안정성을 확보하는 것입니다.

② 모니터링 시스템은 일반적으로 데이터 수집, 데이터 감지, 경보 관리, 오류 관리, 보기 관리 및 모니터링 관리의 6개 모듈로 구성됩니다. 데이터 수집, 데이터 감지 및 경보 처리는 모니터링의 최소 폐쇄 루프이지만 모니터링 시스템을 진정으로 개선하려면 오류 관리 폐쇄 루프, 보기 관리 및 모니터링 관리 모듈도 필수적입니다.

1. 데이터 수집

1. 수집 방법

데이터 수집 방법은 일반적으로 에이전트 모드와 비 에이전트 모드로 구분됩니다.

에이전트 모드에는 플러그인 수집, 스크립트 수집, 로그 수집, 프로세스 수집, APM 프로브 등이 포함됩니다.

비에이전트 모드에는 일반 프로토콜 수집, 웹 다이얼 테스트, API 인터페이스 등이 포함됩니다.

p>

2. 데이터 유형

모니터링되는 데이터 유형에는 지표, 로그 및 추적 데이터가 포함됩니다.

지표 데이터는 수치적인 모니터링 항목으로 주로 차원으로 식별됩니다.

로그 데이터는 문자 데이터로, 주요 목적은 모니터링을 위한 키워드 정보를 찾는 것입니다.

추적 데이터 피드백은 링크의 데이터 흐름 프로세스를 추적하고 프로세스에서 시간이 많이 걸리는 성능이 정상적인지 관찰하는 것입니다.

3. 수집 빈도

수집 빈도에는 두 번째 수준, 분 수준, 무작위의 세 가지 유형이 있습니다. 일반적으로 사용되는 수집 빈도는 분 수준입니다.

4. 수집 및 전송

수집 및 전송은 전송 개시 또는 전송 링크에 따라 분류될 수 있습니다.

전송 개시 분류에 따라 능동 수집 풀(Pull)과 수동 수신 푸시(Push)가 있다.

전송 링크 분류에 따라 직접 연결 모드와 프록시 전송.

그 중 프록시 전송은 모니터링 데이터의 네트워크 간 전송 문제를 해결할 수 있을 뿐만 아니라 너무 많은 모니터링 노드로 인해 발생하는 데이터 전송 병목 현상을 완화하는 데 사용할 수 있습니다.

5. 데이터 저장

모니터링 시스템에는 주로 세 가지 저장 옵션이 있습니다:

1 관계형 데이터베이스

예: MySQL , MSSQL, DB2; 대표적인 모니터링 시스템: Zabbix, SCOM, Tivoli;

데이터베이스 자체의 한계로 인해 대규모 모니터링 시나리오를 처리하기 어렵고 성능 병목 현상이 일반적으로 사용됩니다. 전통적인 모니터링 시스템에서

② 시계열 데이터베이스

이 시나리오를 모니터링하기 위해 설계된 데이터베이스로 InfluxDB, OpenTSDB(Hbase 기반)와 같은 지표 데이터 저장 및 계산에 적합합니다. , Prometheus 등 대표적인 모니터링 시스템 대표 : TICK 모니터링 프레임워크, Open-falcon, Prometheus

3 전체 텍스트 검색 데이터베이스

이 유형의 데이터베이스는 주로 로그 저장에 사용됩니다. Elasticsearch와 같은 데이터 검색에 매우 친숙합니다.

2. 데이터 감지

1. 데이터 처리

① 데이터 정리

데이터 정리는 로그 데이터 정리와 같습니다. 데이터 정보 밀도가 낮은 비정형 데이터이므로 유용한 데이터를 추출해야 합니다.

② 데이터 계산

많은 원시 성능 데이터는 데이터에 이상이 발생하는지 여부를 판단하는 데 직접 사용할 수 없습니다. 예를 들어, 수집되는 데이터는 디스크 사용량과 디스크 사용량의 총량입니다. 디스크 사용량을 감지하려면 기존 지표에 대해 간단한 4차 연산을 수행하여 디스크 사용량을 가져와야 합니다.

3 데이터 강화

데이터 강화는 호스트 및 컴퓨터실용 태그와 같은 일부 태그를 데이터에 추가하여 집계 계산을 용이하게 하는 것입니다.

4 지표 도출

지표 도출은 기존 지표를 통해 새로운 지표를 산출하는 것을 말한다.

2. 탐지 알고리즘

고정된 규칙과 머신러닝 알고리즘이 있습니다. 고정 알고리즘은 정적 임계값, 전년 대비 비교, 사용자 지정 규칙 등 비교적 일반적인 알고리즘인 반면, 머신러닝에는 주로 동적 기준, 결함 감지, 지표 예측, 다중 지수 상관 관계 감지 등의 알고리즘이 포함됩니다.

고정 규칙이든 기계 학습이든 해당 판단 규칙, 즉 일반적인 gt = 및/또는 조합 판단 등이 있습니다.

3. 알람 관리

1. 알람 강화

알람 강화는 후속 알람 이벤트 분석을 준비하기 위한 것이며, 처리 방법을 결정하기 위한 보조 정보가 필요합니다. 분석하고 알림을 보냅니다.

알람 강화는 일반적으로 CMDB, 지식 기반, 작업 기록 및 기타 데이터 소스를 규칙을 통해 연결하여 수행되며, 알람 필드 및 관련 정보를 강화하는 것도 수동 태깅도 강화 방법이지만 실제 시나리오에서는 어렵습니다. 높은 인건비로 인해 구현하기로 결정했습니다.

2. 경보 수렴

경보 수렴에는 억제, 차폐, 집계의 세 가지 접근 방식이 있습니다.

1 억제

즉, 반복되는 경보를 피하기 위해 동일한 문제를 억제합니다. 일반적인 억제 방식에는 흔들림 방지 억제, 종속성 억제, 시간 억제, 결합 조건 억제, 고가용성 억제 등이 포함됩니다.

② 보호

유지 관리 기간 변경, 고정된 주기 작업 등 예측 가능한 상황을 보호합니다. 이러한 이벤트는 이미 발생할 것으로 알려져 있고 이미 예상되는 이벤트입니다.

3 Aggregation

Aggregation은 유사하거나 동일한 알람을 병합하는 것입니다. 동일한 현상을 보고할 수 있기 때문입니다. 예를 들어, 비즈니스 방문 횟수가 증가하면 해당 비즈니스를 호스팅하는 호스트의 CPU, 메모리, 디스크 IO, 네트워크 IO 및 기타 성능이 급등하게 됩니다. 프로세스 알람.

3. 알람 알림

① 사람들에게 알림

일부 기존 알림 채널을 통해 사람들에게 연락할 수 있습니다.

이런 방식으로 화면을 쳐다보는 사람이 없을 때 위챗, SMS, 이메일을 통해 직원이 호출될 수 있습니다.

② 시스템에 알림

후속 이벤트 처리를 용이하게 하기 위해 일반적으로 API를 통해 타사 시스템에 푸시

또한 사용자 정의 채널 확장이 지원되어야 합니다. (예: 기업에는 자체 IM 시스템이 있으며 자체적으로 액세스할 수 있습니다.)

4. 오류 관리

경보 이벤트는 폐쇄 루프에서 처리되어야 합니다. 그렇지 않으면 모니터링이 의미가 없습니다.

가장 일반적인 프로세스는 근무 중, 작업 주문, 오류 에스컬레이션 등 수동 처리입니다.

경험 축적은 후속 오류 처리 시 참조할 수 있도록 수동으로 처리한 오류를 지식 베이스에 축적할 수 있습니다.

자동 처리는 일부 특정 알람의 견고한 처리 절차를 추출하여 특정 시나리오에서 오류 자가 복구를 실현합니다. 예를 들어 디스크 공간 알람이 발생할 때 일부 쓸모 없는 로그를 삭제합니다.

지능형 분석은 주로 결함 상관 분석, 위치 파악, 예측 등 AI 알고리즘을 사용하여 결함 위치 확인 및 처리 효율성을 더욱 향상시킵니다.

뷰 관리

보기 관리는 주로 사람들의 심리적 요구를 충족시키고 상황을 명확하게 이해하기 위한 부가 가치 기능이기도 합니다. 이는 다양한 역할(리더, 관리자, 수행자 등)에게 적합합니다.

대형 화면: 리더용, 글로벌 개요 제공

토폴로지: 운영 및 유지보수 담당자용, 경보 상관 관계 및 영향 보기 제공

대시보드: 운영 유지보수용 직원에게 우려 사항 지표에 대한 맞춤형 보기 제공

보고서: 운영 및 유지 관리 직원과 리더를 위해 주간 보고서, 일일 보고서 등과 같은 일부 통계 요약 보고서 정보를 제공합니다.

검색: 운영 및 유지 관리 인력의 경우, 유지 관리 인력은 결함 분석 시나리오에서 다양한 데이터 검색에 사용됩니다.

2. 모니터링 관리

모니터링 관리는 구현에 있어 가장 큰 과제입니다. 기업 모니터링.

처음 5개 모듈은 모두 모니터링 시스템이 외부 세계에 제공하는 서비스 기능이며, 모니터링 관리는 모니터링 시스템 자체의 관리 및 제어를 지향하며 실제 구현 프로세스의 기능적 표현에 중점을 둡니다. 주로 다음 측면을 포함합니다:

구성: 단순, 일괄, 자동

범위: 모니터링 수준의 측정 지표

지표 라이브러리: 모니터링 지표 사양

p>

모바일 단말기: 언제 어디서나 문제 처리

권한: 사용 제어

감사: 관리 준수

API: 최대 운영 및 유지 관리 데이터 출처 데이터 소비

자체 모니터링: 자체 안정성 보장

위에서 언급한 6가지 기본 모니터링 기능 모듈을 실현하기 위해 당사는 다음에 따라 통합 모니터링 플랫폼을 설계할 수 있습니다. 건축학.

주로 액세스 계층, 기능 계층, 기능 계층의 세 가지 계층으로 나뉩니다.

액세스 계층은 주로 자체 에이전트 및 플러그인의 수집 및 액세스 외에도 타사 모니터링 소스의 데이터 액세스를 지원해야 합니다. 완전한 통합 모니터링 플랫폼으로 간주됩니다.

역량 계층은 주로 데이터 수집 모듈, 데이터 저장 모듈, 데이터 처리 모듈, 데이터 탐지 모듈, AI 분석 모듈을 포함하여 모니터링의 기본적인 일반 기능을 고려합니다.

기능 계층은 사용자 사용 시나리오에 가까워야 합니다. 주로 관리와 표시라는 두 가지 기능이 있습니다. 기능 시나리오는 구축 과정에서 지속적으로 강화될 수 있습니다.

또한, 데이터 간의 상관관계를 고려하여 향후 데이터 분석을 위한 기반 마련을 고려하여 모니터링과 CMDB도 긴밀하게 연결되어야 합니다. 또한 모든 모니터링 개체는 CMDB를 사용하여 관리해야 합니다. 개념을 안내하기 위해 자동 온라인 및 오프라인 모니터링, 경보 알림 담당자 및 기타 시나리오의 자동 식별을 실현하여 모니터링 유지 관리를 단순화합니다.

통합 모니터링 플랫폼이 기업에서 더 잘 구현되기 위해서는 해당 관리 시스템을 갖추고 있어야 하며, 그 중 가장 중요한 것은 지표 관리 시스템입니다.

지표 관리 시스템의 핵심 개념:

감시 지표 시스템은 CMDB를 뼈대로, 모니터링 지표를 경선으로 사용하여 전체 통합 모니터링 플랫폼의 데이터를 유기적으로 통합합니다.

지표 관리 사양을 보완하여 지표 수명주기 관리 전반에 걸쳐 모니터링 플랫폼의 장기적이고 질서 있는 운영을 보장합니다.

기업 비즈니스 애플리케이션의 관점에서 볼 때 기업에서 모니터링하는 개체는 일반적으로 6개 계층으로 나뉘며 이는 기업 자체 상황에 따라 조정할 수도 있습니다.

인프라 계층

하드웨어 장치 계층

운영 체제 계층

구성 요소 서비스 계층

애플리케이션 성능 계층

비즈니스 운영 계층< /피>