또 다른 모니터링 시스템

모뎀 16개, 이동통신사 4개 = 발신 속도 933.45Mbit/s

소개

안녕하세요! 이 기사는 우리가 스스로 새로운 모니터링 시스템을 작성하는 방법에 관한 것입니다. 고주파수 동기 메트릭을 얻는 능력과 매우 낮은 리소스 소비량에서 기존의 것과 다릅니다. 폴링 속도는 0.1나노초의 메트릭 간 동기화 정확도로 10밀리초에 도달할 수 있습니다. 모든 바이너리 파일은 6MB를 차지합니다.

프로젝트에 대한

우리는 다소 구체적인 제품을 가지고 있습니다. 우리는 데이터 전송 채널의 처리량과 내결함성을 요약하기 위한 포괄적인 솔루션을 생산합니다. 이는 여러 채널이 있는 경우입니다. Operator1(40Mbit/s) + Operator2(30Mbit/s)+ 다른 것(5Mbit/s)이라고 가정하면 결과는 하나의 안정적이고 빠른 채널이며 속도는 다음과 같습니다. 이는 (40+ 30+5)x0.92=75×0.92=69Mbit/s입니다.

이러한 솔루션은 한 채널의 용량이 부족한 경우에 필요합니다. 예를 들어 교통, 비디오 감시 시스템 및 실시간 비디오 스트리밍, 라이브 TV 방송 및 라디오 방송, 통신 사업자 중 Big XNUMX의 대표만 있고 하나의 모뎀/채널 속도가 충분하지 않은 교외 시설 .
이러한 각 영역에 대해 우리는 별도의 장치 라인을 생산하지만 소프트웨어 부분은 거의 동일하며 고품질 모니터링 시스템이 주요 모듈 중 하나이므로 올바른 구현이 없으면 제품이 불가능합니다.

수년에 걸쳐 우리는 다단계, 빠른 크로스 플랫폼 및 경량 모니터링 시스템을 만들었습니다. 이것이 우리가 존경하는 커뮤니티와 공유하고 싶은 것입니다.

문제 성명

모니터링 시스템은 근본적으로 다른 두 가지 클래스, 즉 실시간 측정항목과 기타 모든 클래스의 측정항목을 제공합니다. 모니터링 시스템의 요구 사항은 다음과 같습니다.

1. 실시간 지표를 고주파 동기식으로 획득하고 지연 없이 통신 관리 시스템에서 전송합니다.
   다양한 메트릭의 고주파수 및 동기화는 중요할 뿐만 아니라 데이터 전송 채널의 엔트로피를 분석하는 데 필수적입니다. 하나의 데이터 전송 채널에서 평균 지연이 30밀리초인 경우, 단 5밀리초의 나머지 메트릭 간의 동기화 오류로 인해 결과 채널의 속도가 약 1% 저하됩니다. 4개 채널에서 타이밍을 30밀리초씩 잘못 맞추면 속도 저하가 쉽게 0.5%로 떨어질 수 있습니다. 또한 채널의 엔트로피는 매우 빠르게 변하므로 500밀리초마다 한 번 미만으로 측정하면 약간의 지연이 있는 빠른 채널에서 빠른 속도 저하가 발생합니다. 물론 이러한 정확도는 모든 측정항목에 필요하지 않으며 모든 조건에 필요한 것은 아닙니다. 채널의 지연이 1밀리초이고 우리가 작업하는 경우 2밀리초의 오류는 거의 눈에 띄지 않습니다. 또한 생명 유지 시스템 지표의 경우 XNUMX초의 충분한 폴링 및 동기화 속도를 가지고 있지만 모니터링 시스템 자체는 초고속 폴링 속도 및 초정밀 지표 동기화로 작동할 수 있어야 합니다.
2. 최소한의 리소스 소비 및 단일 스택.
   최종 장치는 도로 상황을 분석하거나 사람의 생체 인식 기록을 수행할 수 있는 강력한 온보드 컴플렉스일 수도 있고, 특수부대 군인이 방탄복 안에 착용하여 영상을 전송하는 손바닥 크기의 단일 보드 컴퓨터일 수도 있습니다. 열악한 통신 상황에서 실시간으로. 이렇게 다양한 아키텍처와 컴퓨팅 성능에도 불구하고 우리는 동일한 소프트웨어 스택을 갖고 싶습니다.
3. 우산 건축
   측정항목은 최종 장치에서 수집 및 집계되어야 하며 로컬에 저장되고 실시간 및 소급적으로 시각화되어야 합니다. 연결이 있는 경우 중앙 모니터링 시스템으로 데이터를 전송합니다. 연결이 없으면 전송 대기열이 누적되어야 하며 RAM을 소비해서는 안 됩니다.
4. 많은 모니터링 시스템이 필요하지 않기 때문에 고객의 모니터링 시스템에 통합하기 위한 API입니다. 고객은 모든 장치 및 네트워크의 데이터를 단일 모니터링으로 수집해야 합니다.

어떻게 된 거예요

이미 인상적인 장문의 내용에 부담을 주지 않기 위해 모든 모니터링 시스템에 대한 예와 측정값을 제시하지는 않겠습니다. 이는 다른 기사로 이어집니다. 1밀리초 미만의 오류로 두 개의 메트릭을 동시에 가져올 수 있고 64MB RAM이 있는 ARM 아키텍처와 86MB RAM이 있는 x64_32 아키텍처 모두에서 동일하게 효과적으로 작동하는 모니터링 시스템을 찾을 수 없었다고 말씀드리겠습니다. GB RAM. 그러므로 우리는 이 모든 것을 할 수 있는 우리 자신의 것을 작성하기로 결정했습니다. 우리가 얻은 것은 다음과 같습니다.

다양한 네트워크 토폴로지에 대한 세 채널의 처리량 요약

일부 주요 지표의 시각화

구조

우리는 장치와 데이터 센터 모두에서 Golang을 주요 프로그래밍 언어로 사용합니다. 멀티태스킹 구현과 각 서비스에 대해 하나의 정적으로 링크된 실행 바이너리 파일을 얻을 수 있는 기능을 통해 생활이 크게 단순화되었습니다. 결과적으로 우리는 최종 장치에 서비스를 배포하기 위한 리소스, 방법 및 트래픽, 개발 시간 및 코드 디버깅을 크게 절약했습니다.

시스템은 고전적인 모듈식 원리에 따라 구현되며 여러 하위 시스템을 포함합니다.

1. 측정항목 등록.
   각 측정항목은 자체 스레드로 제공되며 여러 채널에서 동기화됩니다. 우리는 최대 10나노초의 동기화 정확도를 달성할 수 있었습니다.
2. 측정항목 저장
   우리는 시계열을 위한 자체 스토리지를 작성하거나 이미 사용 가능한 것을 사용하는 것 중에서 선택하고 있었습니다. 데이터베이스는 후속 시각화 대상인 회고적 데이터에 필요합니다. 즉, 0.5밀리초마다 채널의 지연에 대한 데이터나 전송 네트워크의 오류 판독값에 대한 데이터는 포함되지 않지만 각 인터페이스에는 500밀리초마다 속도가 있습니다. 크로스 플랫폼에 대한 높은 요구 사항과 낮은 리소스 소비 외에도 처리할 수 있는 것이 매우 중요합니다. 데이터가 저장되는 곳입니다. 이로 인해 엄청난 컴퓨팅 리소스가 절약됩니다. 우리는 2016년부터 이 프로젝트에서 Tarantool DBMS를 사용해 왔으며 지금까지 이를 대체할 제품이 보이지 않습니다. 최적의 리소스 소비와 적절한 기술 지원 이상의 유연성을 제공합니다. Tarantool은 GIS 모듈도 구현합니다. 물론 PostGIS만큼 강력하지는 않지만 일부 위치 관련 측정 항목(전송 관련)을 저장하는 작업에는 충분합니다.
3. 측정항목 시각화
   여기에서는 모든 것이 비교적 간단합니다. 우리는 창고에서 데이터를 가져와 실시간으로 또는 소급하여 표시합니다.
4. 중앙 모니터링 시스템과 데이터 동기화.
   중앙 모니터링 시스템은 모든 장치로부터 데이터를 수신하여 지정된 기록과 함께 저장하고 API를 통해 고객의 모니터링 시스템으로 보냅니다. "헤드"가 돌아다니며 데이터를 수집하는 기존 모니터링 시스템과 달리 우리는 반대 체계를 사용합니다. 연결이 있을 때 장치 자체에서 데이터를 보냅니다. 이는 장치를 사용할 수 없는 기간 동안 장치에서 데이터를 수신할 수 있고 장치를 사용할 수 없는 동안 채널과 리소스를 로드할 수 없기 때문에 매우 중요한 점입니다. Influx 모니터링 서버를 중앙 모니터링 시스템으로 사용합니다. 아날로그와 달리 회고적 데이터를 가져올 수 있습니다.(즉, 메트릭이 수신된 순간과 다른 타임스탬프가 있음) 수집된 메트릭은 Grafana에 의해 시각화되고 파일로 수정됩니다. 이 표준 스택도 거의 모든 고객 모니터링 시스템과 미리 만들어진 API 통합을 갖추고 있기 때문에 선택되었습니다.
5. 중앙 장치 관리 시스템과 데이터 동기화.
   장치 관리 시스템은 Zero Touch Provisioning(펌웨어 업데이트, 구성 등)을 구현하며, 모니터링 시스템과 달리 장치별 문제만 수신합니다. 이는 온보드 하드웨어 감시 서비스의 작동과 생명 유지 시스템의 모든 지표(CPU 및 SSD 온도, CPU 로드, 여유 공간 및 디스크의 SMART 상태)에 대한 트리거입니다. 하위 시스템 스토리지도 Tarantool을 기반으로 구축되었습니다. 이를 통해 수천 개의 장치에 걸쳐 시계열을 집계하는 데 상당한 속도가 제공되고, 이러한 장치와 데이터를 동기화하는 문제도 완전히 해결됩니다. Tarantool은 탁월한 대기열 및 보장된 배송 시스템을 갖추고 있습니다. 우리는 이 중요한 기능을 즉시 사용할 수 있게 되었습니다. 훌륭합니다!

네트워크 관리 시스템

다음 단계

지금까지 우리의 가장 약한 연결고리는 중앙 모니터링 시스템입니다. 이는 표준 스택에서 99.9% 구현되며 다음과 같은 여러 가지 단점이 있습니다.

1. InfluxDB는 전원이 끊기면 데이터를 잃습니다. 일반적으로 고객은 장치에서 나오는 모든 것을 즉시 수집하며 데이터베이스 자체에는 5분보다 오래된 데이터가 포함되어 있지 않지만 앞으로는 이것이 문제가 될 수 있습니다.
2. Grafana는 데이터 집계 및 디스플레이 동기화와 관련하여 여러 가지 문제를 안고 있습니다. 가장 일반적인 문제는 데이터베이스에 2:00:00부터 시작하여 00초 간격의 시계열이 포함되어 있고 Grafana가 +1초부터 집계 데이터를 표시하기 시작하는 경우입니다. 결과적으로 사용자는 춤추는 그래프를 보게 됩니다.
3. 타사 모니터링 시스템과의 API 통합을 위한 코드의 양이 너무 많습니다. 훨씬 더 컴팩트하게 만들 수 있으며 물론 Go에서 다시 작성할 수도 있습니다.

여러분 모두 Grafana가 어떻게 생겼는지 완벽하게 보셨고, 제가 없어도 문제점을 아실 것이라 생각하므로, 사진을 너무 많이 올리지는 않겠습니다.

결론

나는 의도적으로 기술적 세부 사항을 설명하지 않고 이 시스템의 기본 설계만 설명했습니다. 첫째, 시스템을 기술적으로 완전히 설명하려면 다른 기사가 필요합니다. 둘째, 모든 사람이 이에 관심을 갖는 것은 아닙니다. 알고 싶은 기술적인 세부 사항을 댓글로 적어주세요.

이 기사의 범위를 벗어나는 질문이 있는 경우 a.rodin @ qedr.com으로 저에게 편지를 보내주십시오.

출처 : habr.com