감시 분야의 지식 시스템에 대한 심층 탐구

소개	모니터링은 전체 운영 및 유지 관리는 물론 전체 제품 수명 주기에 있어서도 가장 중요한 부분입니다. 적시에 경고를 제공하여 사전에 결함을 감지하고, 이후에 문제 추적 및 위치 파악을 위한 자세한 데이터를 제공합니다. 업계에는 선택할 수 있는 좋은 오픈 소스 제품이 많이 있습니다. 오픈 소스 모니터링 시스템을 선택하는 것은 시간과 노동력을 절약해 주는 가장 효율적인 솔루션입니다. 물론, 모니터링에 대해 잘 모르는 친구들도 다음 글을 읽고 나면 전체 모니터링 시스템에 대해 더 깊이 이해할 수 있을 것입니다.

1. 모니터링 대상

모니터링이 무엇인지, 모니터링의 중요성, 모니터링의 목표에 대해 먼저 알아볼까요. 물론 업종, 회사, 업무, 직위가 모두 다르고 모니터링에 대한 이해도 다르지만 주목해야 할 점은 다음과 같습니다. 모니터링이 필요하다는 사실 특정 모니터링 기술을 사용하기보다는 회사의 비즈니스 관점에서 생각해보세요.

시스템의 중단 없는 실시간 모니터링: 실제로 시스템의 중단 없는 실시간 모니터링입니다(이것이 모니터링입니다).

시스템 현재 상태에 대한 실시간 피드백: 특정 하드웨어나 특정 시스템을 모니터링할 때 현재 시스템의 정상, 비정상, 결함 여부를 실시간으로 확인할 수 있어야 합니다.

서비스 신뢰성 및 보안 보장: 모니터링의 목적은 시스템, 서비스 및 비즈니스의 정상적인 작동을 보장하는 것입니다.

사업의 지속적이고 안정적인 운영 보장: 모니터링이 완벽하면 장애가 발생하더라도 최대한 빨리 장애 경보를 수신하고 처리할 수 있어 지속적이고 안정적인 사업 운영이 보장됩니다.

사업

2. 모니터링 방법

모니터링의 중요성과 모니터링의 목적을 이해했으니 이제 모니터링 방법을 이해해야 합니다.

모니터링 개체 이해: 우리가 모니터링하려는 개체를 이해하고 있나요? 예를 들어, CPU는 어떻게 작동하나요?

성능 벤치마크 지표: 이 제품의 어떤 속성을 모니터링하고 싶나요? 예를 들어 CPU 사용량, 로드, 사용자 모드, 커널 모드 및 컨텍스트 전환이 있습니다.

알람 임계값 정의: 오류로 간주되고 알람이 필요한 것은 무엇입니까? 예를 들어, 높다고 간주되는 CPU의 로드는 얼마나 됩니까? 사용자 모드와 커널 모드는 각각 얼마나 실행되고 있습니까?

장애 처리 과정: 장애 경보를 받은 경우 어떻게 처리해야 하나요? 더 효율적인 프로세스가 있나요?

3. 모니터링 코어

모니터링 방법, 모니터링 개체, 성능 지표, 경보 임계값 정의, 문제 해결 프로세스 단계에 대해 배웠습니다. 물론 모니터링의 핵심이 무엇인지 알아야 합니다.

문제 발견: 시스템 오류 경보가 발생하면 오류 경보 정보를 받게 됩니다.

포지셔닝 문제: 실패 이메일은 일반적으로 특정 호스트 실패 및 특정 실패 내용에 대해 작성합니다. 예를 들어 서버에 연결할 수 없는 경우 네트워크 문제인지 여부를 고려해야 합니다. 부하가 너무 높아 연결이 불가능하거나 특정 개발로 인해 방화벽 금지 정책이 발생하는 등의 경우 실패의 구체적인 원인을 분석해야 합니다.

문제 해결: 물론 오류의 원인을 이해한 후에는 오류 해결 우선순위에 따라 오류를 해결해야 합니다.

문제 요약: 주요 결함을 해결한 후 향후 재발을 방지하기 위해 결함의 원인과 예방을 요약해야 합니다.

4. 모니터링 도구

다음으로 회사 업무에 적합한 모니터링 도구를 선택해야 합니다. 여기서는 모니터링 도구를 간략하게 분류했습니다

기존 모니터링 도구:

MRTG(Multi Route Tffic Grapher)는 네트워크 트래픽 그래프를 그리는 데 사용할 수 있는 소프트웨어 세트로 스위스 올텐의 Tobias Oetiker와 Dave Rand가 개발했으며 GPL 라이선스를 받았습니다. MRTG의 최고 버전은 1995년에 출시되었습니다. 이는 Perl 언어로 작성되었으며 여러 플랫폼에서 사용할 수 있습니다. SNMP 프로토콜은 데이터 수집에 사용됩니다. MRTG는 웹 페이지를 통해 수집된 데이터를 가져와 GIF 또는 PNG 형식으로 이미지를 그립니다. Ganglia는 클러스터 및 그리드와 같은 크로스 플랫폼, 확장 가능한 고성능 분산 모니터링 시스템입니다. 계층화된 디자인을 기반으로 하며 다양한 기술을 사용하고 RRDtool을 사용하여 데이터를 저장합니다. 시각적인 인터페이스를 갖추고 있어 클러스터 시스템의 자동화된 모니터링에 적합합니다. 신중하게 설계된 데이터 구조와 알고리즘은 모니터링 끝에서 모니터링 끝 부분까지의 연결 오버헤드를 매우 낮게 만듭니다. 현재 수천 개의 클러스터가 이 모니터링 시스템을 사용하고 있으며, 2,000개 노드의 클러스터 환경을 쉽게 처리할 수 있습니다.

Cacti(영어로 선인장을 의미)는 PHP, MySQL, SNMP 및 RRDtool을 기반으로 개발된 네트워크 트래픽 모니터링 그래픽 분석 도구 세트입니다. snmpget을 통해 데이터를 얻고 RRDtool을 사용하여 그림을 그리지만 사용자는 복잡한 매개변수를 이해할 필요가 없습니다. RRDtool의 매우 강력한 데이터 및 사용자 관리 기능을 제공합니다. 각 사용자는 트리 구조, 호스트 장치 및 모든 사진을 볼 수 있도록 지정할 수 있습니다. 또한 사용자 인증을 위해 LDAP와 결합할 수 있으며 템플릿을 사용자 정의할 수도 있습니다. 과거 데이터 표시 및 모니터링 측면에서 그 기능은 상당히 좋습니다.

Cacti는 템플릿을 추가하여 다양한 장치의 모니터링을 재사용할 수 있게 하며, 사용자 정의 가능한 그리기 기능과 강력한 컴퓨팅 성능(데이터 오버레이 기능)을 갖추고 있습니다.

Nagios는 서비스의 실행 상태 및 네트워크 정보를 모니터링하고, 지정된 로컬 또는 원격 호스트 및 서비스의 상태를 모니터링하고, 이상 경보 알림 기능을 제공할 수 있는 기업 수준의 모니터링 시스템입니다.

Nagios는 Linux 및 UNIX 플랫폼에서 실행됩니다. 동시에 시스템 관리자가 네트워크 상태, 다양한 시스템 문제 및 시스템 관련 로그를 쉽게 볼 수 있도록 웹 인터페이스가 제공됩니다.

Nagios의 기능은 서비스 가용성 모니터링에 중점을 두고 있으며 모니터링 지표의 상태에 따라 알람을 트리거할 수 있습니다.

현재 Nagios도 일정한 시장 점유율을 차지하고 있지만 Nagios는 시대에 발맞추지 못하고 변화하는 모니터링 요구 사항을 더 이상 충족할 수 없습니다. 아키텍처의 확장성과 사용 편의성을 향상해야 합니다. Nagios XI의 상용 버전에 통합되었습니다.

Smokeping은 주로 일반 핑, www 서버 성능, DNS 쿼리 성능, SSH 성능 등을 포함한 네트워크 성능을 모니터링하는 데 사용됩니다. 하단 레이어는 RRDtool에서도 지원됩니다. 네트워크 패킷 손실과 지연이 색상과 그림자로 표시되는 것이 특징입니다. 이 레이어의 작성자는 MRTG 및 RRDtll과 같은 도구도 개발했습니다.

Smokeping의 웹사이트는 다음과 같습니다: http://tobi.oetiker.cn/hp

오픈 소스 모니터링 시스템 OpenTSDB는 Hbase를 사용하여 모든 시계열(샘플링 없음) 데이터를 저장하여 확장 가능하고 분산된 시계열 데이터베이스를 구축합니다. 2차 데이터 수집과 영구 저장을 지원하고, 용량 계획을 세울 수 있으며, 기존 경보 시스템에 쉽게 통합될 수 있습니다.

OpenTSDB는 대규모 클러스터(클러스터 내의 네트워크 장치, 운영 체제 및 응용 프로그램 포함)에서 해당 수집 지표를 획득하고 이를 저장, 색인화 및 서비스하여 웹화, 그래픽 등 이러한 데이터를 더 쉽게 이해할 수 있습니다. .

Ace 모니터링 도구:

Zabbix는 다양한 수집 방법과 수집 클라이언트를 지원하는 분산 모니터링 시스템입니다. 전용 에이전트가 있으며 SNMP, IPMI, JMX, Telnet 및 SSH와 같은 여러 프로토콜도 지원합니다. 수집된 데이터를 데이터베이스에 저장합니다. 를 분석하고 정리한 후, 조건이 충족되면 알람을 발생시킵니다. 유연한 확장성과 풍부한 기능은 다른 모니터링 시스템과 비교할 수 없습니다. 상대적으로 말하면 전반적인 기능이 뛰어납니다. 위의 다양한 모니터링 시스템을 비교하면 Zabbix는 풍부한 기능, 확장성, 보조 개발 기능 및 사용 편의성 등의 장점을 가지고 있습니다. 독자는 약간의 학습 모니터링 시스템을 구축할 수 있습니다.

Xiaomi의 모니터링 시스템: open-falcon. 오픈팔콘의 목표는 가장 개방적이고 사용하기 쉬운 인터넷 기업급 모니터링 제품을 만드는 것입니다.

3자 모니터링 도구:

현재 시장에는 Monitor Bao, Monitor Easy, Tingyun과 같은 우수한 타사 모니터링이 많이 있으며 많은 클라우드 공급업체에는 자체 모니터링이 있지만 여기에서는 이에 대해 집중적으로 다루지 않겠습니다. 제3자 모니터링에 대해서는 직접 공식 웹사이트로 이동하여 상담하실 수 있습니다. (광고 배치에 대한 이야기는 자제하세요)

5. 모니터링 과정

위에서 많이 소개했는데 어떤 모니터링 도구가 가장 적합한가요? Zabbix, Open-Falcon, LEPUS(데이터베이스 모니터링 전용) 등 여러 오픈 소스 모니터링 도구를 추천합니다.

그러나 이 기사는 전체 모니터링 시스템 생태계를 구축하기 위해 여전히 Zabbix를 기반으로 하고 있습니다.

그럼 Zabbix의 전체 프로세스에 대해 이야기해 보겠습니다.

데이터 수집: Zabbix는 SNMP, 에이전트, ICMP, SSH, IPMI 등을 통해 시스템에서 데이터를 수집합니다.

데이터 저장: Zabbix는 MySQL에 저장되며 다른 데이터베이스 서비스에도 저장할 수 있습니다.

데이터 분석: 나중에 오류를 검토하고 분석해야 할 경우 Zabbix는 오류 위치를 파악할 수 있도록 그래픽, 시간 등 관련 정보를 제공할 수 있습니다.

데이터 표시: 웹 인터페이스 표시(모바일 앱, java_php도 웹 인터페이스 개발 가능)

모니터링 및 알람: 전화 알람, 이메일 알람, WeChat 알람, SMS 알람, 알람 업그레이드 메커니즘 등(사용 가능한 알람에 관계 없음)

알람 처리: 알람을 받으면 중요하고 긴급함, 중요하고 긴급하지 않음 등 오류 수준에 따라 처리해야 합니다. 결함의 정도에 따라 관련 담당자와 협력하여 신속하게 처리하세요.

6. 모니터링 지표

모니터링 방법, 목표, 프로세스 및 모니터링에 사용할 수 있는 도구에 대해 알아봤습니다. 어떤 사람들은 정확히 무엇을 모니터링해야 하는지 궁금할 수도 있습니다. 그래서 여기에 정리했습니다:

6.1 하드웨어 모니터링

초창기에는 전산실 점검을 통해 하드웨어 장비의 불빛 깜박임을 확인하여 불량 여부를 판단했는데, 이는 인력 낭비가 심하고 반복적이고 비기술적인 작업이었습니다.

물론 이제 IPMI를 통해 하드웨어의 세부 사항을 모니터링하고 CPU, 메모리, 디스크, 온도, 팬, 전압 등에 대한 경보 임계값을 설정할 수 있습니다. (모니터링 경보 내용에 대한 합리적인 경보 범위를 직접 작성할 수 있습니다) IPMI 모니터링 하드웨어 서비스 참고 자료6.2 시스템 모니터링

중소기업은 기본적으로 모두 Linux 서버이므로 시스템 리소스 사용량을 모니터링해야 합니다. 시스템 모니터링은 모니터링 시스템의 기본입니다.

모니터링할 주요 개체:

CPU에는 컨텍스트 전환, 실행 대기열 및 사용과 같은 몇 가지 중요한 개념이 있습니다.

이것들은 CPU 모니터링에 대한 몇 가지 주요 지표이기도 합니다.

일반적으로 각 프로세서의 실행 큐는 3개를 넘지 않아야 하며, CPU 사용률은 "사용자 모드/커널 모드" 비율이 70/30, 유휴 상태는 50%를 기반으로 유지되어야 합니다. 시스템의 사용량을 고려하십시오.

CPU에 일반적으로 사용되는 도구는 다음과 같습니다: htop, top, vmstat, mpstat, dstat, 시선

Zabbix는 시스템 모니터링 템플릿을 제공합니다: Zabbix 에이전트 인터페이스

메모리: 일반적으로 메모리 사용량과 SWAP 사용량을 모니터링하는 동시에 zabbix를 사용하여 메모리 사용량 곡선 그래프를 그려 서비스 메모리 오버플로 등을 찾을 수 있습니다.

일반적으로 사용되는 메모리 도구로는 free, top, vmstat,glances

메모리 사용량: IO는 디스크 IO와 네트워크 IO로 구분됩니다. 성능 튜닝 시 보다 자세한 데이터를 모니터링하는 것 외에도 일일 모니터링은 디스크 사용량, 디스크 처리량, 디스크 쓰기 사용량에만 초점을 맞추고 네트워크는 네트워크 카드 트래픽도 모니터링합니다.

일반적으로 사용되는 도구는 다음과 같습니다: iostat, iotop, df, iftop, sar, glans

기타 시스템 모니터링에는 실행 중인 프로세스 포트, 프로세스 수, 로그인한 사용자, 파일 열기 등이 포함됩니다. (자세한 내용은 zabbix의 자체 OS Linux 템플릿 참조)

6.3 애플리케이션 모니터링

하드웨어 모니터링과 시스템 모니터링을 이해한 후 추가 작업은 서버에 로그인하여 서버가 실행 중인 서비스를 확인하는 것이며 모두 모니터링해야 합니다.

LVS, Haproxy, Docker, Nginx, PHP, Memcached, Redis, MySQL, Rabbitmq 등과 같은 애플리케이션 서비스 모니터링도 모니터링 시스템의 중요한 부분입니다. 관련 서비스는 zabbix를 사용하여 모니터링해야 합니다

서비스 모니터링의 세부적인 운영 과정은 이전에 작성자가 작성한 적이 있으므로 여기서는 하나하나 보여드리지 않겠습니다.

Zabbix는 애플리케이션 서비스 모니터링을 제공합니다: Zabbix Agent UserParameter
Zabbix에서 제공하는 Java 모니터링: Zabbix JMX 인터페이스
percona는 MySQL 데이터베이스 모니터링을 제공합니다: percona-monitoring-plulgins

6.4 네트워크 모니터링

전국의 사용자를 대상으로 하는 전자상거래 웹사이트로서, 다양한 장소와 전산실의 네트워크 상태를 상시 추적하는 것도 필요합니다.

네트워크 모니터링은 모니터링 플랫폼을 구축할 때 고려해야 할 사항이며, 특히 여러 컴퓨터실이 있는 시나리오의 경우 각 컴퓨터실 간의 네트워크 상태, 컴퓨터실 및 전국의 네트워크 상태는 모두 우리가 집중해야 할 개체입니다. 그렇다면 이 상태 정보를 마스터하는 것은 어떨까요? 네트워크 모니터링 도구인 Smokeping을 사용해야 합니다.

Smokeping은 rrdtool의 저자인 Tobi Oetiker의 작품입니다. Perl로 작성되었습니다. 주로 네트워크 성능, www 서버 성능, DNS 쿼리 성능 등을 모니터링합니다. 그리기에는 rrdtool을 사용하고, 직접 요약할 수 있습니다. 여러 에이전트의 데이터.

동시에 모니터링 지점이 상대적으로 적기 때문에 Monitor Bao, Tingyun, Keynote, Borui 등과 같은 많은 상용 모니터링 도구를 사용할 수도 있습니다. 동시에 이러한 서비스 제공업체는 CDN 상태를 모니터링하는 데 도움을 줄 수도 있습니다.

6.5 트래픽 분석

웹사이트 트래픽 분석은 운영 및 유지관리 인력이 반드시 숙지해야 하는 지식입니다. 예를 들어 전자상거래 회사의 경우:

주문 소스에 대한 통계 및 분석을 통해 특정 웹 사이트에 대한 광고 투자가 예상한 결과를 달성했는지 여부를 파악할 수 있습니다.

지역별 방문객 수는 물론, 상품 거래량 등까지 구분할 수 있습니다.

Baidu 통계, Google 분석, 웹마스터 도구 등은 페이지에 js를 삽입하기만 하면 됩니다.

하지만 데이터는 항상 상대방 손에 있고 개인화가 불편해서 구글은 파이윅(piwik)이라는 오픈소스 분석 도구를 만들었습니다

6.6 로그 모니터링

일반적으로 시스템이 실행되면 운영체제는 시스템 로그를 생성하고, 애플리케이션은 애플리케이션 액세스 로그, 오류 로그, 작업 로그, 네트워크 로그를 생성합니다. 로그 모니터링에는 ELK를 사용할 수 있습니다.

로그 모니터링의 가장 일반적인 요구 사항은 수집, 저장, 쿼리 및 표시입니다.

오픈 소스 커뮤니티에는 logstash(컬렉션) + elasticsearch(저장 + 검색) + kibana(디스플레이)와 같은 해당 오픈 소스 프로젝트가 있습니다.

이 세 가지를 결합한 기술을 ELK Stack이라 부르기 때문에 ELK Stack은 Elasticsearch, Logstash, Kibana 기술 스택의 결합을 의미합니다.

로그 정보가 수집되면 배포 업데이트에 예외가 있는 경우 Kibana에서 즉시 확인할 수 있습니다.

물론 Zabbix를 통해 오류 로그를 필터링하여 경고를 생성할 수도 있습니다.

6.7 보안 모니터링

WAF를 구현하기 위한 4레이어 iptables, 7레이어 WEB 보호 Nginx+lua 등 많은 Linux 오픈소스 보안 제품이 있지만 최종적으로 관련 로그를 ELK Stack에 수집하고 다양한 공격 유형을 그래픽으로 표시합니다. 하지만 항상 시간이 많이 걸리는 일이고, 개인적으로는 효과가 별로 좋지 않다고 생각합니다. 현재 당사는 제3자 서비스 제공업체에 연결하도록 선택할 수 있습니다.

타사 공급업체는 서비스, 백도어, 데이터베이스, 구성 감지, CGI, SMTP 등을 포괄하는 포괄적인 취약성 라이브러리를 제공합니다.

독립적인 마이닝 및 업계 공유와 결합된 호스트 및 웹 애플리케이션 취약성에 대한 포괄적인 감지로 0day 취약성을 즉시 업데이트하여 최신 보안 위험을 제거합니다

6.8 API 모니터링

API가 점점 더 중요해짐에 따라 우리가 제공하는 API가 제대로 작동하는지 확인하기 위해 이러한 데이터도 필요하다는 것은 명백합니다.
모니터 API 인터페이스 GET, POST, PUT, DELETE, HEAD, OPTIONS 요청은 가용성, 정확성 및 응답 시간이 세 가지 주요 성능 지표입니다

6.9 성능 모니터링

웹페이지 성능, DNS 응답 시간, HTTP 연결 설정 시간, 페이지 성능 지수, 응답 시간, 가용성, 요소 크기 등을 종합적으로 모니터링합니다.
Zabbix는 URL 모니터링을 제공합니다: Zabbix 웹 모니터링

6.10 비즈니스 모니터링

비즈니스 지표 모니터링이 없는 모니터링 플랫폼은 완전한 모니터링 플랫폼이 아닙니다. 일반적으로 모니터링 시스템에서는 중요한 비즈니스 지표를 모니터링하고 경보 알림 임계값을 설정해야 합니다.

예: 전자상거래 산업:

분당 생성되는 주문 수,

분당 등록하는 사용자 수

일일 활성 사용자 수

매일 얼마나 많은 프로모션이 있나요?

프로모션 활동에 소개되는 사용자 수

프로모션으로 인해 트래픽이 얼마나 발생하나요?

프로모션으로 얻는 수익은 얼마나 되나요?

기타 중요한 지표를 Zabbix에 추가한 후 화면을 통해 표시할 수 있습니다.

7. 모니터링 및 알람

장애 경보를 알리는 방법에는 여러 가지가 있습니다. 물론 가장 일반적으로 사용되는 방법은 문자 메시지, 이메일, SMS 알람입니다. 8. 알람 처리

일반 알람 후 오류를 어떻게 처리합니까? 먼저 알람 업그레이드 메커니즘을 통해 자동으로 처리할 수 있습니다. 예를 들어 Nginx 서비스가 다운된 경우 Nginx를 자동으로 시작하도록 알람 업그레이드를 설정할 수 있습니다. 하지만 일반적인 사업에서 심각한 장애가 발생하는 경우에는 일반적으로 장애 수준과 장애 업무에 따라 이를 처리할 운영 및 유지 관리 인력을 다르게 배정합니다. 물론 다양한 비즈니스 형태, 다양한 아키텍처, 다양한 서비스가 다양한 방법을 채택할 수 있습니다. 적용할 수 있는 고정된 모델은 없습니다. 9. 면접 모니터링

운영 및 유지보수 인터뷰에서 모니터링과 관련된 질문을 자주 받는데, 이 질문에 어떻게 대답해야 할까요? 하드웨어 모니터링. IPMI를 통해 SNMP(일부 제조업체와 통신하여 수행 방법을 알아볼 수 있음), 서버 온도 등을 통해 라우터 스위치를 모니터링할 수 있습니다. 물론, 하드웨어가 없고 모든 것이 클라우드에 있다면 이 단계를 건너뛰세요.

시스템 모니터링. CPU 로드, 컨텍스트 전환, 메모리 사용량, 디스크 읽기 및 쓰기, 디스크 사용량, 디스크 inode 사용량 등이 있습니다. 물론 기본 설정이 너무 낮고 알람이 자주 발생하기 때문에 트리거로 구성해야 합니다.

서비스 모니터링. 예를 들어, 회사에서 사용하는 LAMP 아키텍처인 nginx에는 자체 상태 모듈이 있고, PHP에도 관련 상태가 있으며, MySQL은 percona 공식 도구를 통해 모니터링할 수 있으며, Redis는 필터링을 위해 자체 정보를 통해 정보를 얻습니다. 방법은 비슷합니다. 아니면 자신만의 서비스를 가져오세요. 스크립트를 사용하여 모니터링하려는 콘텐츠와 알람 및 그래픽 기능을 구현하십시오.

네트워크 모니터링. 클라우드 호스트이고 컴퓨터실 전체에 있지 않은 경우 네트워크를 모니터링하지 않도록 선택할 수 있습니다. 물론 당신은 우리가 컴퓨터실 등 건너편에 있다고 말했지요. 네트워크 관련 모니터링에는 스모킹 사용을 권장합니다. 아니면 업계 전문성이 있기 때문에 네트워크 엔지니어에게 직접 맡기세요.

보안 모니터링. 클라우드 호스트인 경우 자체 보안 보호 기능을 사용하는 것을 고려할 수 있습니다. 물론 iptables를 사용할 수도 있습니다. 하드웨어인 경우 하드웨어 방화벽을 사용하는 것이 좋습니다. 클라우드를 사용하면 하루 동안 다운타임을 초래할 수 있는 오작동을 방지하기 위해 Anti-DDoS를 구매할 수 있습니다. 시스템이라면 권한, 비밀번호, 백업, 복구 등 기본적인 해결이 잘 이루어져야 합니다. 웹에서는 Nginx+Lua를 사용하여 웹 수준 방화벽을 구현할 수도 있습니다. 물론 통합 Openresty를 사용할 수도 있습니다.

웹 모니터링. 웹 모니터링에 관한 주제는 여전히 많습니다. 예를 들어, 내장된 웹 모니터링을 사용하여 페이지 관련 지연, js 응답 시간, 다운로드 시간 등을 모니터링할 수 있습니다. 이를 달성하려면 전문 상용 소프트웨어인 Monitoring Bao 또는 Tingyun을 사용하는 것이 좋습니다. 뭐 전국 곳곳에 컴퓨터실이 있잖아요. (다중 기계실이라면 따로 얘기하자)

로그 모니터링. 웹이라면 Nginx의 50x 및 40x 오류 로그와 PHP의 ERROR 로그를 모니터링하는 데 사용할 수 있습니다. 실제로 이러한 요구 사항은 수집, 저장, 쿼리 및 표시에 지나지 않습니다. 실제로 이를 달성하기 위해 오픈 소스 ELKstack을 사용할 수 있습니다. Logstash(수집), elasticsearch(저장 + 검색), kibana(표시)
비즈니스 모니터링. 우리는 많은 일을 해왔지만 결국에는 여전히 사업 운영을 보장합니다. 이런 방식으로만 우리가 수행하는 모니터링이 의미가 있을 수 있습니다. 따라서 비즈니스 수준의 모니터링은 더 중요한 비즈니스 지표(회의를 통해 확인해야 함)를 모니터링하기 위해 개발 및 디렉터와의 회의와 토론이 필요하며 간단한 스크립트를 통해 구현하고 최종적으로 트리거를 설정할 수 있습니다.

트래픽 분석. 우리는 일반적으로 awk sed xxx와 같은 여러 도구를 사용하여 로그를 분석합니다. IP, PV, UV를 계산하는 것은 그리 편리하지 않습니다. 그런 다음 Baidu Statistics, Google Statistics 및 Commerce를 사용하여 임베디드 코드를 개발할 수 있습니다. 개인 정보 보호를 피하기 위해 piwik을 사용하여 관련 트래픽 분석을 수행할 수도 있습니다.

시각화. 화면을 사용하고 일부 타사 라이브러리를 도입하여 인터페이스를 아름답게 만드는 동시에 주문량이 갑자기 증가하거나 감소한다는 점도 알아야 합니다. 즉, 갑자기 엄청난 양의 트래픽이 유입된 것입니다. 이 트래픽은 어디서 발생한 것일까요, 아니면 공격을 받은 것일까요? 모니터링 플랫폼을 결합하여 다양한 시스템 간의 비즈니스 관계를 정리할 수 있습니다.

자동 모니터링. 위에서 많은 작업을 수행했기 때문에 물론 키를 하나씩 추가할 수는 없습니다. 이는 Zabbix의 활성 모드와 수동 모드를 통해 달성할 수 있습니다. 물론 API를 통해 이를 수행하는 것이 가장 좋습니다.
요약

정말로 더욱 완전한 모니터링 시스템을 달성하고 싶다면 현재의 오픈 소스 소프트웨어로는 이를 잘 만족시킬 수 없습니다. 자격을 갖춘 회사는 Xiaomi의 오픈 소스 Open-Falcon과 같은 자체 모니터링 시스템을 개발하기 시작했습니다. Sensu 등과 같은 더 나은 오픈 소스 모니터링 프레임워크와 influxdb 및 grafana도 있으며 이를 사용하여 자신의 기업에 적합한 모니터링 플랫폼을 사용자 정의할 수 있습니다.

물론 제가 말한 내용은 여전히 ​​매우 간단합니다. 제 경험은 제한되어 있고 제 아이디어는 너무 많은 것을 제공할 수 있습니다. 위 내용은 제가 모니터링에 관해 공유하는 방법과 경험 중 일부입니다. (늙은 새들은 불평하지 마세요)

위 내용은 감시 분야의 지식 시스템에 대한 심층 탐구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!