HighLoad++, Mikhail Makurov, Maxim Chernetsov(Intersvyaz): Zabbix, 서버 한 대에서 100kNVPS

다음 HighLoad++ 컨퍼런스는 6년 7월 2020일과 XNUMX일에 상트페테르부르크에서 개최됩니다. 세부 정보 및 티켓 링크. HighLoad++ 모스크바 2018. "모스크바" 홀. 9월 15일 00:XNUMX. 논문과 제출.

* 모니터링 - 온라인 및 분석.
* ZABBIX 플랫폼의 기본 제한 사항.
* 분석 스토리지 확장을 위한 솔루션입니다.
* ZABBIX 서버 최적화.
* UI 최적화.
* 40k NVPS 이상의 부하에서 시스템을 운영해 본 경험이 있습니다.
* 간략한 결론.

미하일 마쿠로프(이하 – MM): - 안녕하세요 여러분!

막심 체르네초프(이하 – MCH): - 좋은 오후에요!

MM: – 맥심을 소개하겠습니다. Max는 재능 있는 엔지니어이자 제가 아는 최고의 네트워크 전문가입니다. Maxim은 네트워크 및 서비스, 개발 및 운영에 참여하고 있습니다.

MCH: – 그리고 미하일에 대해 말씀드리고 싶습니다. Mikhail은 C 개발자입니다. 그는 우리 회사를 위해 여러 가지 고부하 트래픽 처리 솔루션을 작성했습니다. 우리는 Intersvyaz 회사의 터프한 남자 Chelyabinsk의 도시 Urals에서 살고 일합니다. 우리 회사는 16개 도시에서 백만 명의 사람들에게 인터넷 및 케이블 TV 서비스를 제공하는 업체입니다.

MM: – 그리고 Intersvyaz는 단순한 제공업체가 아닌 IT 회사라고 말할 가치가 있습니다. 우리 솔루션의 대부분은 IT 부서에서 만들어집니다.

A : 트래픽을 처리하는 서버부터 콜센터 및 모바일 애플리케이션까지. 현재 IT 부서에는 매우 다양한 역량을 갖춘 약 80명의 직원이 있습니다.

Zabbix 및 해당 아키텍처 정보

MCH: – 이제 개인 기록을 세우고 Zabbix(이하 “Zabbix”)가 무엇인지 XNUMX분 안에 말씀드리겠습니다.

Zabbix는 기업 수준의 즉시 사용 가능한 모니터링 시스템으로 자리매김했습니다. 여기에는 고급 에스컬레이션 규칙, 통합을 위한 API, 호스트 및 메트릭의 그룹화 및 자동 감지 등 삶을 더 쉽게 만드는 많은 기능이 있습니다. Zabbix에는 소위 확장 도구인 프록시가 있습니다. Zabbix는 오픈 소스 시스템입니다.

건축에 대해 간략히 설명합니다. 세 가지 구성 요소로 구성되어 있다고 말할 수 있습니다.

• 섬기는 사람. C로 작성되었습니다. 스레드 간의 정보 처리 및 전송이 다소 복잡합니다. 수신부터 데이터베이스 저장까지 모든 처리가 이루어집니다.
• 모든 데이터는 데이터베이스에 저장됩니다. Zabbix는 MySQL, PostreSQL 및 Oracle을 지원합니다.
• 웹 인터페이스는 PHP로 작성되었습니다. 대부분의 시스템에는 Apache 서버가 함께 제공되지만 nginx + php와 함께 사용하면 더 효율적으로 작동합니다.

오늘은 Zabbix와 관련된 회사 생활의 한 가지 이야기를 들려드리고자 합니다...

Intersvyaz 회사의 삶에 대한 이야기. 우리에게는 무엇이 있고 무엇이 필요합니까?

5~6개월 전이에요. 퇴근하고 어느날..

MCH: - 미샤, 안녕하세요! 당신을 붙잡을 수 있어서 기뻐요. 대화가 있어요. 모니터링에 다시 문제가 발생했습니다. 큰 사고가 났을 때 모든 것이 느려졌고 네트워크 상태에 대한 정보가 없었습니다. 불행하게도 이런 일이 처음은 아닙니다. 당신의 도움이 필요해요. 어떤 상황에서도 모니터링이 작동하도록 합시다!

MM: - 하지만 먼저 동기화를 해보자. 나는 몇 년 동안 거기를 보지 않았습니다. 제가 기억하는 한, 우리는 약 8년 전에 Nagios를 버리고 Zabbix로 전환했습니다. 그리고 이제 우리는 6개의 강력한 서버와 약 XNUMX개의 프록시를 보유하고 있는 것 같습니다. 내가 혼란스러운 게 있나요?

MCH: - 거의. 15개의 서버 중 일부는 가상 머신입니다. 가장 중요한 것은 그것이 우리에게 가장 필요한 순간에 우리를 구해주지 않는다는 것입니다. 마치 사고처럼 서버 속도가 느려지고 아무것도 볼 수 없습니다. 구성을 최적화하려고 시도했지만 최적의 성능 향상을 제공하지 못했습니다.

MM: - 알았습니다. 뭔가를 보셨나요? 이미 진단에서 뭔가를 파헤치셨나요?

MCH: – 가장 먼저 처리해야 할 것은 데이터베이스입니다. MySQL은 지속적으로 로드되어 새로운 지표를 저장하며, Zabbix가 여러 이벤트를 생성하기 시작하면 데이터베이스는 말 그대로 몇 시간 동안 과부하 상태가 됩니다. 이미 구성 최적화에 대해 말씀드렸지만 올해 말 그대로 하드웨어가 업데이트되었습니다. 서버에는 SSD RAID에 XNUMXGB 이상의 메모리와 디스크 어레이가 있으므로 장기적으로 선형적으로 확장할 필요가 없습니다. 우리는 무엇을해야합니까?

MM: - 알았습니다. 일반적으로 MySQL은 LTP 데이터베이스입니다. 분명히 우리 규모의 측정 항목 아카이브를 저장하는 데 더 이상 적합하지 않습니다. 그것을 알아 봅시다.

MCH: - 하자!

해커톤 결과로 Zabbix와 Clickhouse가 통합되었습니다.

얼마 후 우리는 흥미로운 데이터를 받았습니다.

데이터베이스 공간의 대부분은 메트릭 아카이브가 차지했으며 1% 미만이 구성, 템플릿 및 설정에 사용되었습니다. 그때쯤 우리는 클릭하우스 기반의 빅데이터 솔루션을 XNUMX년 넘게 운영하고 있었다. 이동 방향은 우리에게 분명했습니다. 봄 해커톤에서 저는 서버 및 프런트엔드용 Clickhouse와 Zabbix의 통합을 작성했습니다. 당시 Zabbix는 이미 ElasticSearch를 지원하고 있었고 우리는 이를 비교하기로 결정했습니다.

Clickhouse와 Elasticsearch의 비교

MM: – 비교를 위해 Zabbix 서버가 제공하는 것과 동일한 로드를 생성하고 시스템이 어떻게 작동하는지 살펴보았습니다. 우리는 CURL을 사용하여 1000줄씩 일괄적으로 데이터를 썼습니다. 우리는 Zabbix가 수행하는 로드 프로필에 대해 Clickhouse가 더 효율적일 것이라고 미리 가정했습니다. 결과는 우리의 기대를 뛰어넘었습니다.

동일한 테스트 조건에서 Clickhouse는 XNUMX배 더 많은 데이터를 작성했습니다. 동시에 두 시스템 모두 데이터를 읽을 때 매우 효율적으로(소량의 리소스) 소비되었습니다. 그러나 Elastics는 녹음할 때 많은 양의 프로세서가 필요했습니다.

전체적으로 Clickhouse는 프로세서 소비 및 속도 측면에서 Elastix보다 훨씬 뛰어났습니다. 동시에 데이터 압축으로 인해 Clickhouse는 하드 드라이브를 11배 적게 사용하고 디스크 작업을 약 30배 적게 수행합니다.

MCH: – 예, Clickhouse의 디스크 하위 시스템 작업은 매우 효율적으로 구현됩니다. 데이터베이스에 거대한 SATA 디스크를 사용하고 초당 수십만 라인의 쓰기 속도를 얻을 수 있습니다. 기본 제공 시스템은 샤딩, 복제를 지원하며 구성이 매우 쉽습니다. 일년 내내 사용해도 매우 만족스럽습니다.

리소스를 최적화하려면 기존 기본 데이터베이스 옆에 Clickhouse를 설치하여 CPU 시간과 디스크 작업을 많이 절약할 수 있습니다. 측정항목 아카이브를 기존 Clickhouse 클러스터로 이동했습니다.

우리는 기본 MySQL 데이터베이스를 Zabbix 서버와 하나의 시스템에 결합하고 MySQL 전용 서버를 버릴 수 있을 정도로 많이 줄였습니다.

Zabbix에서는 폴링이 어떻게 작동하나요?

4 개월 전

MM: – 글쎄요, 기지 문제를 잊을 수 있을까요?

MCH: - 그건 확실합니다! 우리가 해결해야 할 또 다른 문제는 느린 데이터 수집입니다. 이제 우리의 15개 프록시 서버 모두가 SNMP 및 폴링 프로세스로 인해 과부하되었습니다. 그리고 신규 서버를 새로 설치하는 것 외에는 방법이 없습니다.

MM: - 엄청난. 하지만 먼저 Zabbix에서 폴링이 어떻게 작동하는지 알려주세요.

MCH: – 간단히 말해서 20가지 유형의 지표와 이를 얻는 방법이 XNUMX가지가 있습니다. Zabbix는 "요청-응답" 모드에서 데이터를 수집하거나 "트래퍼 인터페이스"를 통해 새 데이터를 기다릴 수 있습니다.

원래 Zabbix에서는 이 방법(Trapper)이 가장 빠르다는 점은 주목할 가치가 있습니다.

부하 분산을 위한 프록시 서버가 있습니다.

프록시는 Zabbix 서버와 동일한 수집 기능을 수행하여 서버로부터 작업을 수신하고 수집된 지표를 Trapper 인터페이스를 통해 보낼 수 있습니다. 이는 부하를 분산하기 위해 공식적으로 권장되는 방법입니다. 프록시는 NAT 또는 느린 채널을 통해 작동하는 원격 인프라를 모니터링하는 데에도 유용합니다.

MM: – 아키텍처에서는 모든 것이 명확합니다. 소스를 살펴봐야 하는데...

며칠 후

nmap fping이 어떻게 승리했는지에 대한 이야기

MM: “내가 뭔가를 파낸 것 같아요.”

MCH: - 말해 주세요!

MM: – 가용성을 확인할 때 Zabbix는 한 번에 최대 128개의 호스트를 확인한다는 것을 발견했습니다. 나는 이 숫자를 500으로 늘리고 핑(ping)에서 패킷 간 간격을 제거해 보았습니다. 이로 인해 성능이 두 배로 향상되었습니다. 하지만 나는 더 큰 숫자를 원합니다.

MCH: – 실제로 실제로 수천 개의 호스트의 가용성을 확인해야 하는 경우가 있는데, 이를 위해 nmap보다 빠른 것을 본 적이 없습니다. 나는 이것이 가장 빠른 방법이라고 확신합니다. 해 보자! 반복당 호스트 수를 크게 늘려야 합니다.

MM: – 600개 이상을 확인하시나요? XNUMX?

MCH: - 최소 XNUMX천개는 됩니다.

MM: - 좋아요. 제가 말하고 싶었던 가장 중요한 것은 Zabbix에서 대부분의 폴링이 동기식으로 수행된다는 것입니다. 반드시 비동기 모드로 변경해야 합니다. 그런 다음 특히 반복당 지표 수를 늘리는 경우 폴러가 수집하는 지표 수를 극적으로 늘릴 수 있습니다.

MCH: - 엄청난! 그리고 언제?

MM: – 어제도 늘 그랬듯이.

MCH: – fping과 nmap의 두 버전을 비교했습니다.

다수의 호스트에서 nmap은 최대 4배 더 효과적일 것으로 예상되었습니다. nmap은 가용성과 응답 시간만 확인하므로 손실 계산을 트리거로 이동하고 가용성 확인 간격을 크게 줄였습니다. 우리는 nmap의 최적 호스트 수가 반복당 약 120개라는 것을 발견했습니다. Nmap을 사용하면 가용성 확인에 소요되는 CPU 비용을 10배로 줄이고 간격을 XNUMX초에서 XNUMX초로 줄일 수 있었습니다.

폴링 최적화

MM: “그런 다음 우리는 여론 조사를 시작했습니다. 우리는 주로 SNMP 감지 및 에이전트에 관심이 있었습니다. Zabbix에서는 폴링이 동기식으로 수행되며 시스템 효율성을 높이기 위해 특별한 조치가 취해졌습니다. 동기 모드에서는 호스트를 사용할 수 없으면 폴링 성능이 크게 저하됩니다. 전체 상태 시스템이 있고, 도달할 수 없는 호스트에서만 작동하는 소위 도달할 수 없는 폴러라는 특별한 프로세스가 있습니다.

이것은 시스템이 효과적으로 유지되기 위해 필요한 전환 시스템의 모든 복잡성인 상태 매트릭스를 보여주는 해설입니다. 게다가 동기식 폴링 자체도 매우 느립니다.

이것이 바로 수십 개의 프록시에 있는 수천 개의 폴러 스트림이 우리에게 필요한 양의 데이터를 수집할 수 없는 이유입니다. 비동기 구현은 스레드 수 문제를 해결했을 뿐만 아니라 사용할 수 없는 호스트의 상태 시스템을 크게 단순화했습니다. 왜냐하면 한 번의 폴링 반복에서 확인된 숫자에 대해 최대 대기 시간은 1회 시간 초과였기 때문입니다.

또한 SNMP 요청에 대한 폴링 시스템을 수정하고 개선했습니다. 사실 대부분의 사람들은 동시에 여러 SNMP 요청에 응답할 수 없습니다. 따라서 동일한 호스트의 SNMP 폴링이 비동기적으로 수행되는 경우 하이브리드 모드를 만들었습니다.

이는 전체 호스트 팩에 대해 수행됩니다. 1개의 SNMP 값을 폴링하는 것이 여전히 XNUMX회 제한 시간보다 훨씬 빠르기 때문에 이 모드는 궁극적으로 완전히 비동기식 모드보다 느리지 않습니다.

우리의 실험에 따르면 한 번의 반복에서 최적의 요청 수는 SNMP 폴링을 사용하여 약 8개입니다. 전체적으로 비동기 모드로의 전환을 통해 폴링 성능을 200배, 수백 배 향상할 수 있었습니다.

MCH: – 결과적인 폴링 최적화 결과, 모든 프록시를 제거할 수 있을 뿐만 아니라 많은 확인 간격을 줄일 수 있으며 로드를 공유하는 방법으로 프록시가 더 이상 필요하지 않음이 나타났습니다.

약 XNUMX개월 전

아키텍처를 변경하면 부하가 늘어납니다!

MM: - 음, 맥스, 이제 생산성을 높일 시간인가요? 강력한 서버와 좋은 엔지니어가 필요합니다.

MCH: - 알았어, 계획을 세워보자. 이제 초당 5메트릭이라는 한계점에서 벗어나야 할 때입니다.

업그레이드 후 아침

MCH: - 미샤, 우리는 스스로 업데이트했지만 아침에는 롤백했습니다... 우리가 달성한 속도가 어느 정도인지 추측해 보세요.

MM: – 최대 20개.

MCH: - 응, 25살이야! 불행히도 우리는 우리가 시작한 바로 그 곳에 있습니다.

MM: - 왜? 진단을 실행했습니까?

MCH: - 물론이지! 예를 들어 다음은 흥미로운 상단입니다.

MM: - 구경하자. 나는 우리가 엄청난 수의 폴링 스레드를 시도한 것을 확인했습니다.

그러나 동시에 시스템을 절반도 재활용할 수 없었습니다.

그리고 전반적인 성능은 초당 약 4개 메트릭으로 매우 작습니다.

다른 것이 있나요?

MCH: – 예, 폴러 중 하나의 추적:

MM: – 여기에서 폴링 프로세스가 "세마포어"를 기다리고 있음을 명확하게 볼 수 있습니다. 자물쇠는 다음과 같습니다.

MCH: - 불분명해요.

MM: – 보세요, 이것은 한 번에 하나만 작업할 수 있는 리소스를 여러 스레드가 사용하여 작업하려고 하는 상황과 유사합니다. 그렇다면 그들이 할 수 있는 일은 시간이 지남에 따라 이 리소스를 공유하는 것뿐입니다.

그리고 이러한 리소스로 작업하는 전체 성능은 하나의 코어 속도에 의해 제한됩니다.

이 문제를 해결하는 방법에는 두 가지가 있습니다.

머신의 하드웨어를 업그레이드하고 더 빠른 코어로 전환하세요.

또는 아키텍처를 변경하는 동시에 부하도 변경합니다.

MCH: – 그런데 테스트 머신에서는 전투 머신보다 더 적은 수의 코어를 사용하지만 코어당 주파수는 1,5배 더 빠릅니다!

MM: - 분명한? 서버 코드를 살펴봐야 합니다.

Zabbix 서버의 데이터 경로

MCH: – 이를 파악하기 위해 Zabbix 서버 내부에서 데이터가 전송되는 방식을 분석하기 시작했습니다.

멋진 사진이죠? 좀 더 명확하게 설명하기 위해 단계별로 살펴보겠습니다. 데이터 수집을 담당하는 스레드와 서비스가 있습니다.

수집된 측정항목은 소켓을 통해 전처리기 관리자로 전송되며, 여기에서 큐에 저장됩니다.

"전처리기 관리자"는 전처리 명령을 실행하고 동일한 소켓을 통해 다시 반환하는 작업자에게 데이터를 전송합니다.

그 후 전처리기 관리자는 이를 기록 캐시에 저장합니다.

여기에서 트리거 계산, 값 캐시 채우기, 가장 중요한 것은 기록 저장소에 메트릭 저장과 같은 많은 기능을 수행하는 기록 싱커에 의해 가져옵니다. 일반적으로 프로세스는 복잡하고 매우 혼란스럽습니다.

MM: – 우리가 가장 먼저 본 것은 대부분의 스레드가 소위 "구성 캐시"(모든 서버 구성이 저장되는 메모리 영역)를 놓고 경쟁한다는 것입니다. 데이터 수집을 담당하는 스레드는 특히 많은 차단을 수행합니다.

...구성에는 매개변수가 포함된 측정항목뿐만 아니라 폴러가 다음에 수행할 작업에 대한 정보를 가져오는 대기열도 저장되기 때문입니다. 폴러가 많고 하나가 구성을 차단하면 다른 폴러는 요청을 기다립니다.

폴러는 충돌해서는 안 됩니다.

따라서 우리가 가장 먼저 한 일은 대기열을 4개 부분으로 나누고 폴러가 안전한 조건에서 이러한 대기열을 동시에 차단할 수 있도록 하는 것입니다.

이로 인해 구성 캐시에 대한 경쟁이 사라지고 폴러 속도가 크게 향상되었습니다. 그러나 우리는 전처리기 관리자가 작업 대기열을 축적하기 시작했다는 사실을 발견했습니다.

전처리기 관리자는 우선순위를 정할 수 있어야 합니다.

실적이 부족한 경우에 이런 일이 일어났습니다. 그런 다음 그가 할 수 있는 일은 데이터 수집 프로세스의 요청을 축적하고 모든 메모리를 소비하고 충돌할 때까지 버퍼를 추가하는 것뿐이었습니다.

이 문제를 해결하기 위해 우리는 특별히 워커 전용으로 사용되는 두 번째 소켓을 추가했습니다.

따라서 전처리기 관리자는 작업의 우선순위를 정할 수 있는 기회를 가졌으며 버퍼가 커지면 제거 속도를 늦추어 작업자에게 이 버퍼를 사용할 수 있는 기회를 제공합니다.

그런 다음 우리는 속도 저하의 원인 중 하나가 근로자 자신이라는 것을 발견했습니다. 왜냐하면 그들은 업무에 전혀 중요하지 않은 자원을 놓고 경쟁하고 있었기 때문입니다. 우리는 이 문제를 버그 수정으로 문서화했으며 Zabbix의 새 버전에서는 이미 해결되었습니다.

소켓 수를 늘립니다. 결과를 얻습니다.

게다가 전처리기 관리자 자체가 하나의 스레드이기 때문에 병목 현상이 발생했습니다. 이는 코어 속도에 기반하여 초당 약 70미터의 최대 속도를 제공합니다.

따라서 우리는 XNUMX개의 소켓 세트와 함께 XNUMX개의 작업자를 만들었습니다.

이를 통해 속도를 약 130만 메트릭까지 높일 수 있었습니다.

성장의 비선형성은 히스토리 캐시에 대한 경쟁이 나타났다는 사실로 설명됩니다. 4명의 전처리기 관리자와 히스토리 싱커가 이를 놓고 경쟁했습니다. 이 시점에서 우리는 테스트 시스템에서 초당 약 130개의 메트릭을 수신했으며 이를 프로세서의 약 95%까지 활용했습니다.

약 2,5개월 전

snmp 커뮤니티 거부로 NVP가 XNUMX배 증가했습니다.

MM: – 맥스, 새 테스트카가 필요해! 우리는 더 이상 현재의 상황에 맞지 않습니다.

MCH: - 지금 가지고 있는 것은 무엇입니까?

MM: – 현재 – 130개의 NVP 및 즉시 사용 가능한 프로세서.

MCH: - 우와! 시원한! 잠깐만요, 두 가지 질문이 있습니다. 내 계산에 따르면 초당 약 15~20개의 메트릭이 필요합니다. 왜 더 필요한가요?

MM: “일을 끝내고 싶어요.” 나는 우리가 이 시스템에서 얼마나 많은 것을 짜낼 수 있는지 보고 싶습니다.

MCH: -하지만 ...

MM: "그러나 그것은 사업에 쓸모가 없습니다."

MCH: - 알았습니다. 두 번째 질문: 개발자의 도움 없이 우리가 지금 가지고 있는 것을 스스로 지원할 수 있습니까?

MM: - 아닌 것 같아요. 구성 캐시 작동 방식을 변경하는 것이 문제입니다. 이는 대부분의 스레드의 변경 사항에 영향을 미치며 유지 관리가 매우 어렵습니다. 아마도 그것을 유지하는 것은 매우 어려울 것입니다.

MCH: “그렇다면 우리에게는 어떤 대안이 필요합니다.”

MM: - 그런 선택지가 있습니다. 새로운 잠금 시스템을 포기하면서 빠른 코어로 전환할 수 있습니다. 우리는 여전히 60-80개 지표의 성능을 얻을 것입니다. 동시에 나머지 코드는 모두 그대로 둘 수 있습니다. Clickhouse 및 비동기 폴링이 작동합니다. 그리고 유지 관리가 쉬울 것입니다.

MCH: - 놀라운! 여기서 멈추는 것이 좋습니다.

서버 측을 최적화한 후 마침내 새로운 코드를 프로덕션에 출시할 수 있었습니다. 우리는 빠른 코어를 갖춘 머신으로 전환하고 코드 변경 횟수를 최소화하기 위해 일부 변경 사항을 포기했습니다. 또한 추가 잠금이 도입되므로 구성을 단순화하고 가능한 경우 데이터 항목의 매크로를 제거했습니다.

예를 들어, 문서와 예제에서 흔히 볼 수 있는 snmp-community 매크로를 포기하면 우리의 경우 NVP 속도를 약 1,5배 더 높일 수 있었습니다.

제작 이틀만에

사건 이력 팝업 제거

MCH: – Misha, 우리는 이틀 동안 시스템을 사용해 봤는데 모든 것이 작동합니다. 하지만 모든 것이 작동할 때만 가능합니다! 우리는 네트워크의 상당히 큰 부분을 이전하는 작업을 계획했고 무엇이 일어나고 무엇이 일어나지 않았는지 다시 직접 확인했습니다.

MM: - 그럴 리가 없어! 우리는 모든 것을 10번 확인했습니다. 서버는 완전한 네트워크 가용성이 발생하지 않는 경우에도 즉시 처리합니다.

MCH: - 예, 모든 것을 이해합니다: 서버, 데이터베이스, top, austat, 로그 - 모든 것이 빠릅니다... 하지만 웹 인터페이스를 보면 서버의 "선반에" 프로세서가 있고 다음과 같습니다.

MM: - 알았습니다. 웹을 살펴보자. 우리는 활성 사건이 많은 상황에서 대부분의 라이브 위젯이 매우 느리게 작동하기 시작한다는 것을 발견했습니다.

그 이유는 목록의 항목별로 사건이력 팝업이 생성되기 때문입니다. 따라서 우리는 이러한 창 생성을 포기하고(코드에서 5줄을 주석 처리함) 문제를 해결했습니다.

전혀 사용할 수 없는 경우에도 위젯의 로딩 시간이 몇 분에서 허용 가능한 10~15초로 단축되었으며, 시간을 클릭하면 기록을 계속 볼 수 있습니다.

퇴근 후. 2 달전

MCH: - 미샤, 떠날 거야? 우리는 얘기해야 해요.

MM: - 그럴 생각은 없었어요. 또 Zabbix와 관련된 일이 있나요?

MCH: - 아니, 진정해! 나는 단지 말하고 싶었습니다: 모든 것이 작동합니다. 감사합니다! 나는 맥주를 마신다.

Zabbix는 효율적입니다

Zabbix는 상당히 보편적이고 풍부한 시스템과 기능을 갖추고 있습니다. 기본적으로 소규모 설치에 사용할 수 있지만 요구 사항이 증가함에 따라 최적화해야 합니다. 대규모 측정항목 아카이브를 저장하려면 적합한 저장소를 사용하세요.

• Elasticsearch와의 통합 또는 기록을 텍스트 파일에 업로드하는 형태로 내장 도구를 사용할 수 있습니다(버전 XNUMX부터 사용 가능).
• Clickhouse와의 통합 및 경험을 활용할 수 있습니다.

메트릭 수집 속도를 획기적으로 높이려면 비동기 방식을 사용하여 메트릭을 수집하고 트랩퍼 인터페이스를 통해 Zabbix 서버로 전송합니다. 또는 패치를 사용하여 Zabbix 폴러를 비동기식으로 만들 수 있습니다.

Zabbix는 C로 작성되었으며 매우 효율적입니다. 여러 가지 아키텍처 병목 현상을 해결하면 성능을 더욱 향상시킬 수 있으며 경험상 단일 프로세서 시스템에서 100만 개 이상의 메트릭을 얻을 수 있습니다.

동일한 Zabbix 패치

MM: – 몇 가지 포인트를 추가하고 싶습니다. 전체 현재 보고서, 모든 테스트, 숫자는 우리가 사용하는 구성에 대해 제공됩니다. 이제 우리는 초당 약 20개의 측정항목을 가져오고 있습니다. 이것이 당신에게 효과가 있는지 이해하려는 경우 비교할 수 있습니다. 오늘 논의된 내용은 패치 형식으로 GitHub에 게시됩니다. github.com/miklert/zabbix

패치에는 다음이 포함됩니다:

• Clickhouse(Zabbix 서버와 프런트엔드 모두)와의 완전한 통합
• 전처리기 관리자로 문제를 해결합니다.
• 비동기 폴링.

패치는 lts를 포함한 모든 버전 4와 호환됩니다. 아마도 최소한의 변경만으로 버전 3.4에서 작동할 것입니다.

관심을 가져 주셔서 감사합니다.

질문

청중의 질문(이하 – A): – 안녕하세요! 이것이 패치가 아니라 Zabbix의 정상적인 동작이 되도록 Zabbix 팀 또는 그들과 집중적으로 상호 작용할 계획이 있습니까?

MM: – 예, 일부 변경 사항을 확실히 커밋하겠습니다. 어떤 일이 일어날 것이고, 패치에 어떤 일이 남을 것입니다.

A : – 훌륭한 보고서를 보내주셔서 진심으로 감사드립니다! 패치를 적용한 후에도 Zabbix의 지원은 계속 유지되며 더 높은 버전으로 계속 업데이트하는 방법을 알려주십시오. 패치 후 Zabbix를 4.2, 5.0으로 업데이트할 수 있습니까?

MM: – 지원에 대해서는 아무 말도 할 수 없습니다. 내가 Zabbix 기술 지원 담당자라면 아마도 아니라고 대답할 것입니다. 왜냐하면 이것은 다른 사람의 코드이기 때문입니다. 4.2 코드베이스에 대한 우리의 입장은 "우리는 시간이 지나면서 다음 버전에서 업데이트할 것입니다."입니다. 따라서 한동안 업데이트된 버전에 대한 패치를 게시할 예정입니다. 보고서에서 이미 말했듯이 버전 변경 횟수는 여전히 매우 적습니다. 3.4에서 4로 전환하는 데 약 15분 정도 걸린 것 같습니다. 뭔가 변경되었지만 그다지 중요하지는 않습니다.

A : – 그러면 패치를 지원할 계획이며 프로덕션 환경에 안전하게 설치하고 향후 어떤 방식으로든 업데이트를 받을 수 있습니까?

MM: – 강력히 추천합니다. 이것은 우리에게 많은 문제를 해결합니다.

MCH: – 다시 한 번 아키텍처와 블로킹이나 큐와 관련되지 않은 변경 사항은 모듈식이며 별도의 모듈에 있다는 사실에 주목하고 싶습니다. 사소한 변경이라도 매우 쉽게 유지 관리할 수 있습니다.

MM: – 세부 사항에 관심이 있으시면 "Clickhouse"는 소위 역사 라이브러리를 사용합니다. 이는 묶여 있지 않습니다. 이는 Elastics 지원의 복사본입니다. 즉, 구성 가능합니다. 폴링은 폴러만 변경합니다. 우리는 이것이 오랫동안 효과가 있을 것이라고 믿습니다.

A : - 정말 감사합니다. 변경 사항에 대한 문서가 있습니까?

MM: – 문서는 패치입니다. 확실히 Clickhouse가 도입되고 새로운 유형의 폴러가 도입되면서 새로운 구성 옵션이 등장하게 되었습니다. 마지막 슬라이드의 링크에는 사용 방법에 대한 간단한 설명이 나와 있습니다.

fping을 nmap으로 대체하는 방법

A : – 최종적으로 이를 어떻게 구현하셨나요? 구체적인 예를 들어주실 수 있나요? 스트래퍼와 외부 스크립트가 있나요? 그렇게 많은 수의 호스트를 그렇게 빨리 확인하게 된 이유는 무엇입니까? 이 호스트를 어떻게 채굴합니까? 어떻게든 nmap에 공급하고, 어딘가에서 가져오고, 넣고, 뭔가를 실행해야 합니까?..

MM: - 시원한. 매우 정확한 질문입니다! 요점은 이것이다. 우리는 패킷 수(1)를 나타내는 ICMP 검사를 위해 라이브러리(ICMP ping, Zabbix의 일부)를 수정했으며 코드는 nmap을 사용하려고 시도합니다. 즉, 이것은 Pinger의 내부 작업이 된 Zabbix의 내부 작업입니다. 따라서 동기화나 트랩퍼 사용이 필요하지 않습니다. 이는 시스템을 그대로 유지하고 두 데이터베이스 시스템의 동기화를 처리할 필요가 없도록 의도적으로 수행되었습니다. 확인할 내용, 폴러를 통한 업로드, 업로드가 중단되었습니까?.. 이는 훨씬 간단합니다.

A : – 프록시에서도 작동합니까?

MM: – 네, 하지만 확인하지 않았습니다. 폴링 코드는 Zabbix와 서버 모두 동일합니다. 작동해야합니다. 다시 한 번 강조하겠습니다. 시스템 성능은 프록시가 필요하지 않을 정도입니다.

MCH: – 질문에 대한 정답은 "그런 시스템에 프록시가 왜 필요한가요?"입니다. NAT 때문이거나 일종의 느린 채널을 통한 모니터링 때문입니다.

A : – 그리고 내가 올바르게 이해한다면 Zabbix를 알레르기로 사용합니다. 아니면 그래픽(아카이브 레이어가 있는 곳)을 Grafana와 같은 다른 시스템으로 옮겼습니까? 아니면 이 기능을 사용하지 않으시나요?

MM: – 다시 한 번 강조하겠습니다. 우리는 완전한 통합을 달성했습니다. Clickhouse에 이력을 쏟아 붓고 있지만 동시에 PHP 프런트엔드도 변경했습니다. Php 프런트엔드는 Clickhouse로 이동하여 거기에서 모든 그래픽을 수행합니다. 동시에, 솔직히 말해서 동일한 Zabbix 데이터에서 동일한 Clickhouse의 다른 그래픽 디스플레이 시스템에 데이터를 구축하는 부분이 있습니다.

MCH: - <그라판>에도 그렇고.

자원 할당에 대한 결정은 어떻게 이루어졌습니까?

A : – 내부 주방을 조금 공유해 보세요. 제품의 심각한 처리를 위해 자원을 할당해야 한다는 결정은 어떻게 내려졌습니까? 이는 일반적으로 특정 위험입니다. 그리고 새 버전을 지원할 예정이라는 맥락에서 이 결정이 관리 관점에서 어떻게 정당화되는지 알려주십시오.

MM: – 아무래도 우리는 역사 드라마를 잘 전달하지 못한 것 같다. 우리는 뭔가를 해야 하는 상황에 처해 있었고 본질적으로 두 개의 병렬 팀과 함께 진행했습니다.

• 하나는 새로운 방법을 사용하여 모니터링 시스템을 출시하는 것이었습니다. 즉, 서비스형 모니터링, 표준 오픈 소스 솔루션 세트를 결합한 다음 새로운 모니터링 시스템과 함께 작동하기 위해 비즈니스 프로세스를 변경하려고 시도하는 것이었습니다.
• 동시에 (자신에 대해) 이 작업을 수행하는 열정적인 프로그래머가 있었습니다. 그가 이겼습니다.

A : – 그리고 팀의 규모는 어느 정도인가요?

MCH: - 그녀가 당신 앞에 있어요.

A : – 그럼 언제나 그렇듯이 열정적인 사람이 필요한가요?

MM: - 열정이 뭔지 모르겠어요.

A : -이 경우에는 분명히 당신입니다. 정말 고마워요. 당신은 정말 대단해요.

MM: 고마워.

Zabbix 패치 정보

A : – 프록시를 사용하는 시스템(예: 일부 분산 시스템)의 경우 폴러, 프록시 및 부분적으로 Zabbix 자체의 전처리기를 조정하고 패치하는 것이 가능합니까? 그리고 그들의 상호작용은? 여러 프록시가 있는 시스템의 기존 개발을 최적화할 수 있습니까?

MM: – Zabbix 서버는 프록시를 사용하여 조립된다는 것을 알고 있습니다(코드가 컴파일되어 획득됩니다). 우리는 이것을 프로덕션 환경에서 테스트하지 않았습니다. 이에 대해서는 잘 모르겠지만 프록시에서는 전처리기 관리자가 사용되지 않는 것 같습니다. 프록시의 임무는 Zabbix에서 일련의 메트릭을 가져와 병합(구성, 로컬 데이터베이스도 기록)하고 Zabbix 서버에 다시 제공하는 것입니다. 그런 다음 서버 자체는 이를 수신할 때 전처리를 수행합니다.

프록시에 대한 관심은 이해할 수 있습니다. 확인해보겠습니다. 이것은 흥미로운 주제입니다.

A : – 아이디어는 다음과 같습니다. 폴러를 패치할 수 있으면 프록시에서 패치하고 서버와의 상호 작용을 패치하고 서버에서만 이러한 목적으로 전처리기를 조정할 수 있습니다.

MM: - 내 생각엔 그게 더 간단한 것 같아. 코드를 가져와 패치를 적용한 다음 필요한 방식으로 구성합니다. 즉, 프록시 서버(예: ODBC 사용)를 수집하고 패치된 코드를 시스템 전체에 배포합니다. 필요한 경우 - 프록시를 수집하고, 필요한 경우 - 서버를 수집합니다.

A : – 프록시 전송을 서버에 추가로 패치할 필요는 없을 것 같은데요?

MCH: - 아니요, 표준입니다.

MM: – 사실 아이디어 중 하나가 들리지 않았습니다. 우리는 폭발적인 아이디어와 변화의 양, 지원 용이성 사이에서 항상 균형을 유지해 왔습니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com