사라진 스쿠터를 돌려주다, 혹은 IoT 모니터링을 하는 한 사람의 이야기

XNUMX년 전 우리는 홍보 프로젝트의 파일럿 버전을 시작했습니다. 전기 스쿠터의 분산형 임대.

처음에 이 프로젝트는 Road-To-Barcelona라고 불렸고 나중에는 Road-To-Berlin(따라서 스크린샷에서는 R2B)이 되었으며 결국에는 xRide라고 불렸습니다.

프로젝트의 주요 아이디어는 다음과 같습니다. 중앙 집중식 자동차 또는 스쿠터 렌탈 서비스(킥스쿠터/스쿠터가 아닌 스쿠터, 일명 전기 오토바이에 대해 이야기하고 있음)를 갖는 대신 분산형 렌탈을 위한 플랫폼을 만들고 싶었습니다. 우리가 겪은 어려움에 대해 이미 예전에 썼어.

처음에 이 프로젝트는 자동차에 중점을 두었지만 마감일, 제조업체와의 매우 긴 커뮤니케이션 및 수많은 안전 제한으로 인해 전기 스쿠터가 파일럿으로 선택되었습니다.

사용자는 휴대폰에 iOS 또는 Android 애플리케이션을 설치하고 좋아하는 스쿠터에 접근한 후 휴대폰과 스쿠터가 PXNUMXP 연결을 설정하고 ETH가 교환되며 사용자는 다음을 통해 스쿠터를 켜서 라이딩을 시작할 수 있습니다. 전화기. 여행이 끝나면 휴대폰으로 사용자 지갑에서 이더리움을 이용해 여행비를 결제하는 것도 가능했다.

스쿠터 외에도 사용자는 애플리케이션에서 현재 배터리가 부족한 경우 사용자가 직접 교체할 수 있는 '스마트 충전기'를 보았습니다.

이는 일반적으로 작년 XNUMX월 독일 본(Bonn)과 베를린(Berlin) 두 도시에서 시작된 우리의 파일럿의 모습입니다.

그러던 어느 날, 이른 아침 본에서 우리 지원팀(스쿠터 작동 상태를 유지하기 위해 현장에 있음)에게 경고가 왔습니다. 스쿠터 중 하나가 흔적도 없이 사라졌습니다.

그것을 찾아서 반환하는 방법은 무엇입니까?

이 기사에서는 이에 대해 이야기하겠지만 먼저 우리가 자체 IoT 플랫폼을 구축한 방법과 이를 모니터링한 방법에 대해 설명하겠습니다.

모니터링 대상과 이유: 스쿠터, 인프라, 충전?

그렇다면 우리 프로젝트에서 무엇을 모니터링하고 싶었나요?

우선, 이것은 스쿠터 자체입니다. 전기 스쿠터 자체는 상당히 비싸므로 충분한 준비 없이는 그러한 프로젝트를 시작할 수 없습니다. 가능하다면 스쿠터에 대해 가능한 한 많은 정보(위치, 충전 수준)를 수집하고 싶습니다. , 등.

또한 데이터베이스, 서비스 및 작동에 필요한 모든 것 등 자체 IT 인프라의 상태를 모니터링하고 싶습니다. 또한, '스마트 충전기'가 고장나거나 배터리가 부족할 경우를 대비해 상태를 모니터링해야 했습니다.

스쿠터

우리 스쿠터는 무엇이었고 우리는 그것에 대해 무엇을 알고 싶었습니까?

가장 먼저이자 가장 중요한 것은 GPS 좌표입니다. 덕분에 우리는 GPS 좌표 덕분에 GPS 좌표가 어디에 있고 어디로 이동하는지 이해할 수 있습니다.

다음은 배터리 충전입니다. 덕분에 스쿠터 충전이 끝났음을 확인하고 주서기를 보내거나 적어도 사용자에게 경고할 수 있습니다.

물론 하드웨어 구성 요소에 무슨 일이 일어나고 있는지 확인하는 것도 필요합니다.

• 블루투스는 작동하나요?
• GPS 모듈 자체가 작동합니까?
  • 또한 GPS가 잘못된 좌표를 전송하여 정체될 수 있다는 문제도 있었는데, 이는 스쿠터에 대한 추가 확인을 통해서만 확인할 수 있었습니다.
    문제를 해결하기 위해 가능한 한 빨리 지원팀에 알립니다.

마지막으로 OS 및 프로세서, 네트워크 및 디스크 로드부터 시작하여 우리에게 보다 구체적인 자체 모듈 검사로 끝나는 소프트웨어 검사(졸로 콤, 열쇠망토).

하드웨어

우리의 “철” 부분은 무엇이었나요?

가능한 가장 짧은 시간과 신속한 프로토타이핑의 필요성을 고려하여 구성 요소 구현 및 선택을 위한 가장 쉬운 옵션인 Raspberry Pi를 선택했습니다.
Rpi 자체 외에도 우리는 맞춤형 보드(최종 솔루션의 조립 프로세스 속도를 높이기 위해 중국에서 직접 개발하고 주문한 보드)와 구성 요소 세트(스쿠터 켜기/끄기용), 배터리 충전 리더기, 모뎀, 안테나. 이 모든 것은 특별한 "xRide 상자"에 콤팩트하게 포장되어 있습니다.

또한 전체 상자는 스쿠터의 메인 배터리에 의해 전원이 공급되는 추가 보조 배터리에 의해 전원이 공급된다는 점에 유의해야 합니다.

이를 통해 시동 키를 "끄기" 위치로 돌리면 메인 배터리가 즉시 꺼지기 때문에 여행이 끝난 후에도 모니터링을 사용하고 스쿠터를 켤 수 있습니다.

도커? 일반 리눅스? 및 배포

모니터링으로 돌아가서 Raspberry - 우리는 무엇을 가지고 있습니까?

물리적 장치에 구성 요소를 배포, 업데이트 및 전달하는 프로세스의 속도를 높이기 위해 가장 먼저 사용하고 싶었던 것 중 하나는 Docker였습니다.

불행히도 RPi의 Docker는 작동하지만 특히 에너지 소비 측면에서 많은 오버헤드가 있다는 것이 금방 분명해졌습니다.

"네이티브" OS를 사용한 차이는 그다지 강력하지는 않지만 너무 빨리 충전이 손실될 가능성을 경계하기에는 충분했습니다.

두 번째 이유는 Go/C/C++로 작성되지 않은 시스템의 유일한 구성 요소인 Node.js(sic!)의 파트너 라이브러리 중 하나였습니다.

라이브러리 작성자는 "기본" 언어로 작업 버전을 제공할 시간이 없었습니다.

노드 자체가 저성능 장치를 위한 가장 우아한 솔루션이 아닐 뿐만 아니라 라이브러리 자체도 리소스를 많이 소모했습니다.

우리는 원하더라도 Docker를 사용하는 것이 우리에게 너무 많은 오버헤드가 될 것이라는 것을 깨달았습니다. 기본 OS를 선호하고 그 아래에서 직접 작업하도록 선택되었습니다.

OS

결과적으로 우리는 다시 OS로 가장 간단한 옵션을 선택하고 Raspbian(Pi용 Debian 빌드)을 사용했습니다.

우리는 모든 소프트웨어를 Go로 작성했으므로 시스템의 주요 하드웨어 에이전트 모듈도 Go로 작성했습니다.

GPS, Bluetooth 작업, 충전 금액 읽기, 스쿠터 켜기 등을 담당하는 사람은 바로 그 사람입니다.

배포

에이전트/애플리케이션 자체에 대한 업데이트와 OS/펌웨어 자체에 대한 업데이트 모두(에이전트의 새 버전에는 커널 업데이트가 필요할 수 있으므로) 장치에 업데이트(OTA)를 제공하기 위한 메커니즘을 구현해야 한다는 의문이 즉시 제기되었습니다. 또는 시스템 구성 요소, 라이브러리 등).

시장에 대한 오랜 분석 끝에 장치에 업데이트를 제공하는 솔루션이 상당히 많다는 것이 밝혀졌습니다.

swupd/SWUpdate/OSTree와 같은 비교적 단순하고 주로 업데이트/이중 부팅 지향 유틸리티부터 Mender 및 Balena와 같은 본격적인 플랫폼까지.

우선 우리는 엔드투엔드 솔루션에 관심이 있다고 판단하여 즉시 플랫폼을 선택하게 되었습니다.

그 자체 발레나 실제로 balenaEngine 내부에서 동일한 Docker를 사용한다는 사실로 인해 제외되었습니다.

하지만 그럼에도 불구하고 우리는 결국 그들의 제품을 계속 사용하게 되었다는 점에 주목합니다. 발레 나 에쳐 SD 카드의 플래시 펌웨어용 - 이를 위한 간단하고 매우 편리한 유틸리티입니다.

따라서 결국 선택은 떨어졌습니다 멘더. Mender는 펌웨어 조립, 전달 및 설치를 위한 완벽한 플랫폼입니다.

전반적으로 플랫폼은 훌륭해 보이지만 멘더 빌더를 사용하여 올바른 버전의 펌웨어를 빌드하는 데만 약 XNUMX주일 반이 걸렸습니다.
그리고 우리가 그 사용법의 복잡성에 더 많이 몰두할수록 그것을 완전히 배포하려면 우리가 가진 것보다 훨씬 더 많은 시간이 필요하다는 것이 더욱 분명해졌습니다.

아쉽게도 마감 기한이 촉박하여 Mender 사용을 포기하고 더 간단한 것을 선택해야 했습니다.

책임감있는

우리 상황에서 가장 간단한 해결책은 Ansible을 사용하는 것이었습니다. 시작하는 데는 몇 권의 플레이북이면 충분했습니다.

그들의 본질은 우리가 SSH를 통해 호스트(CI 서버)에서 라스베리에 연결하고 업데이트를 배포했다는 것입니다.

처음에는 모든 것이 간단했습니다. 장치와 동일한 네트워크에 있어야했고 쏟아지는 것은 Wi-Fi를 통해 이루어졌습니다.

사무실에는 동일한 네트워크에 연결된 테스트 라즈베리가 XNUMX개 있었고, 각 장치에는 Ansible Inventory에도 지정된 고정 IP 주소가 있었습니다.

모니터링 에이전트를 최종 장치에 전달한 것은 Ansible이었습니다.

3G / LTE

안타깝게도 이 Ansible 사용 사례는 실제 스쿠터가 출시되기 전의 개발 모드에서만 작동할 수 있었습니다.

아시다시피 스쿠터는 하나의 Wi-Fi 라우터에 연결되어 있지 않고 네트워크를 통해 지속적으로 업데이트를 기다리고 있기 때문입니다.

실제로 스쿠터는 모바일 3G/LTE 외에는 어떤 연결도 할 수 없습니다(그리고 항상 그런 것은 아닙니다).

이로 인해 연결 속도가 느리고 통신이 불안정해지는 등 많은 문제와 제한 사항이 즉시 발생합니다.

하지만 가장 중요한 것은 3G/LTE 네트워크에서는 네트워크에 할당된 고정 IP에만 의존할 수 없다는 점입니다.

이는 일부 SIM 카드 제공업체에 의해 부분적으로 해결되었으며 고정 IP 주소가 있는 IoT 장치용으로 설계된 특수 SIM 카드도 있습니다. 하지만 우리는 그러한 SIM 카드에 접근할 수 없었고 IP 주소도 사용할 수 없었습니다.

물론 Consul과 같은 곳에서 일종의 IP 주소 등록(일명 서비스 검색)을 수행하는 아이디어도 있었지만 테스트에서 IP 주소가 너무 자주 변경되어 큰 불안정성을 초래할 수 있었기 때문에 이러한 아이디어를 포기해야 했습니다.

이러한 이유로 메트릭 전달에 가장 편리한 사용은 필요한 메트릭을 위해 장치로 이동하는 풀 모델을 사용하는 것이 아니라 장치에서 서버로 직접 메트릭을 전달하는 푸시 모델을 사용하는 것입니다.

VPN

이 문제에 대한 해결책으로 우리는 VPN을 선택했습니다. 와이어 가드.

시스템 시작 시 클라이언트(스쿠터)가 VPN 서버에 연결되어 연결할 수 있었습니다. 이 터널은 업데이트를 전달하는 데 사용되었습니다.

이론적으로는 동일한 터널을 모니터링에 사용할 수 있지만 이러한 연결은 단순한 푸시보다 더 복잡하고 안정성이 낮습니다.

클라우드 리소스

마지막으로, 우리는 Kubernetes를 사용하기 때문에 클라우드 서비스와 데이터베이스를 모니터링해야 합니다. 이상적으로는 클러스터에 모니터링을 배포하는 것이 최대한 간단합니다. 이상적으로는 키, 배포를 위해 대부분의 경우 사용합니다. 물론 클라우드를 모니터링하려면 스쿠터 자체와 동일한 솔루션을 사용해야 합니다.

주어진

휴, 설명이 정리된 것 같습니다. 마지막으로 필요한 목록을 만들어 보겠습니다.

• 개발 프로세스 중에 이미 모니터링이 필요하므로 빠른 솔루션
• 볼륨/수량 – 많은 측정항목 필요
• 로그 수집이 필요합니다
• 신뢰성 - 데이터는 출시 성공에 매우 중요합니다.
• 풀 모델을 사용할 수 없습니다. 푸시가 필요합니다.
• 하드웨어뿐만 아니라 클라우드까지 통합적인 모니터링이 필요합니다

최종 이미지는 다음과 같았습니다

스택 선택

그래서 우리는 모니터링 스택을 선택하는 문제에 직면했습니다.

우선, 우리는 우리의 모든 요구 사항을 동시에 충족하면서도 동시에 우리의 필요에 맞게 사용할 수 있을 만큼 유연하게 사용할 수 있는 가장 완벽한 올인원 솔루션을 찾고 있었습니다. 그럼에도 불구하고 우리는 하드웨어, 아키텍처, 기한 등으로 인해 많은 제약을 받았습니다.

다음과 같은 본격적인 시스템을 시작으로 매우 다양한 모니터링 솔루션이 있습니다. 나기 오스, 아이싱 또는 자밥 스 차량 관리를 위한 기성 솔루션으로 마무리됩니다.

처음에는 후자가 우리에게 이상적인 솔루션처럼 보였지만 일부는 완전한 모니터링이 없었고 다른 일부는 무료 버전의 기능이 심각하게 제한되었으며 다른 일부는 단순히 "원하는 것"을 충족하지 못하거나 시나리오에 적합할 만큼 유연하지 않았습니다. 일부는 단순히 구식입니다.

여러 유사한 솔루션을 분석한 후 우리는 유사한 스택을 직접 조립하는 것이 더 쉽고 빠르다는 결론에 빠르게 도달했습니다. 예, 완전히 준비된 차량 관리 플랫폼을 배포하는 것보다 조금 더 복잡하지만 타협할 필요는 없습니다.

거의 확실하게, 엄청난 양의 솔루션 중에는 이미 우리에게 딱 맞는 기성 솔루션이 있지만, 우리의 경우에는 특정 스택을 자체적으로 조립하고 "스스로" 맞춤화하는 것보다 훨씬 더 빨랐습니다. 기성품 테스트.

이 모든 것을 통해 우리는 전체 모니터링 플랫폼을 직접 조립하려고 노력하지 않고 유연하게 구성할 수 있는 기능만 갖춘 가장 기능적인 "기성품" 스택을 찾고 있었습니다.

(B)엘크?

실제로 고려된 첫 번째 솔루션은 잘 알려진 ELK 스택이었습니다.
사실 모든 것이 Beats에서 시작되기 때문에 BELK라고 불러야 합니다. - https://www.elastic.co/what-is/elk-stack

물론 ELK는 모니터링 분야에서 가장 유명하고 강력한 솔루션 중 하나이며 로그 수집 및 처리 분야에서는 더욱 그렇습니다.

우리는 ELK를 사용하여 로그를 수집하고 Prometheus에서 얻은 측정항목을 장기간 저장하려고 했습니다.

시각화를 위해 Grafan을 사용할 수 있습니다.

실제로 새로운 ELK 스택은 메트릭을 독립적으로 수집할 수 있으며(metricbeat), Kibana에서도 이를 표시할 수 있습니다.

그러나 여전히 ELK는 초기에 로그에서 성장했으며 지금까지 측정항목의 기능에는 여러 가지 심각한 단점이 있습니다.

• 프로메테우스에 비해 현저히 느림
• Prometheus보다 훨씬 적은 수의 장소에 통합됩니다.
• 알림을 설정하기가 어렵습니다.
• 측정항목은 많은 공간을 차지합니다.
• Kiban에서 메트릭으로 대시보드를 설정하는 것은 Grafan보다 훨씬 더 복잡합니다.

일반적으로 ELK의 메트릭은 무겁고 아직 다른 솔루션만큼 편리하지 않습니다. 현재는 Prometheus보다 TSDB, Victoria Metrics, Cortex 등이 훨씬 더 많습니다. 물론, 당장이라도 본격적인 올인원 솔루션이 나왔으면 좋겠지만, 메트릭비트의 경우 타협점이 너무 많았습니다.

그리고 ELK 스택 자체에는 여러 가지 어려운 순간이 있습니다.

• 무겁고, 꽤 많은 양의 데이터를 수집하면 때로는 매우 무거워지기도 합니다.
• "요리하는 방법"을 알아야 합니다. 크기를 조정해야 하지만 이는 쉬운 일이 아닙니다.
• 제거된 무료 버전 - 무료 버전에는 일반적인 경고가 없으며 선택 시 인증이 없었습니다.

최근에는 마지막 점이 더 좋아졌고 게다가 오픈 소스 X-pack의 출력 (인증 포함) 가격 모델 자체가 변경되기 시작했습니다.

하지만 이 솔루션을 배포하려고 할 당시에는 경고가 전혀 발생하지 않았습니다.
아마도 ElastAlert나 다른 커뮤니티 솔루션을 사용하여 무언가를 구축하려고 시도할 수도 있었지만 여전히 다른 대안을 고려하기로 결정했습니다.

로키 - 그라파나 - 프로메테우스

현재 좋은 해결책은 메트릭 제공자로서 Prometheus, 로그용 Loki, 시각화를 위해 동일한 Grafana를 사용하여 순전히 Prometheus를 기반으로 모니터링 스택을 구축하는 것입니다.

안타깝게도 프로젝트 판매 파일럿 시작 당시(19년 0.3월~0.4월) Loki는 아직 베타 버전 XNUMX~XNUMX에 있었고, 개발 시작 당시에는 생산 솔루션으로 간주할 수 없었습니다. 조금도.

아직 심각한 프로젝트에서 Loki를 실제로 사용한 경험은 없지만 Promtail(로그 수집 에이전트)은 Kubernetes의 베어 메탈과 포드 모두에 훌륭하게 작동한다고 말할 수 있습니다.

진드기

아마도 ELK 스택에 대한 가장 가치 있는(유일한?) 모든 기능을 갖춘 대안은 이제 TICK 스택(Telegraf, InfluxDB, Chronograf, Kapacitor)이라고만 부를 수 있습니다.

아래의 모든 구성 요소를 더 자세히 설명하겠지만 일반적인 아이디어는 다음과 같습니다.

• Telegraf - 메트릭 수집 에이전트
• InfluxDB - 메트릭 데이터베이스
• Kapacitor - 경고를 위한 실시간 메트릭 프로세서
• Chronograf - 시각화를 위한 웹 패널

InfluxDB, Kapacitor 및 Chronograf의 경우 배포에 사용한 공식 helm 차트가 있습니다.

Influx 2.0(베타)의 최신 버전에서는 Kapacitor와 Chronograf가 InfluxDB의 일부가 되었으며 더 이상 별도로 존재하지 않는다는 점에 유의해야 합니다.

텔레그라프

텔레그라프 상태 머신에서 메트릭을 수집하기 위한 매우 가벼운 에이전트입니다.

그는 다음과 같은 엄청난 양의 모든 것을 모니터링할 수 있습니다. Nginx에 에
서버 minecraft.

여기에는 여러 가지 멋진 장점이 있습니다.

• 빠르고 가벼움(Go로 작성됨)
  • 최소한의 리소스를 소비합니다.
• 기본적으로 측정항목 푸시
• 필요한 모든 지표를 수집합니다.
  • 설정이 없는 시스템 측정항목
  • 센서의 정보와 같은 하드웨어 측정항목
  • 자신만의 측정항목을 추가하는 것은 매우 쉽습니다.
• 즉시 사용할 수 있는 다양한 플러그인
• 로그를 수집합니다.

푸시 메트릭이 필요했기 때문에 다른 모든 이점은 즐거운 추가 이상의 것이었습니다.

로그를 로깅하기 위해 별도의 유틸리티를 연결할 필요가 없기 때문에 에이전트 자체에서 로그를 수집하는 것도 매우 편리합니다.

Influx는 다음을 사용하면 로그 작업에 가장 편리한 경험을 제공합니다. syslog.

Telegraf는 ICK 스택의 나머지 부분을 사용하지 않더라도 일반적으로 메트릭을 수집하는 데 훌륭한 에이전트입니다.

거의 모든 곳에서 메트릭을 작성할 수 있기 때문에 많은 사람들이 편의를 위해 ELK 및 기타 다양한 시계열 데이터베이스와 교차합니다.

인플럭스DB

InfluxDB는 TICK 스택의 주요 핵심, 즉 메트릭을 위한 시계열 데이터베이스입니다.
Influx는 메트릭 외에도 로그를 저장할 수도 있지만 본질적으로 로그는 동일한 메트릭이지만 일반적인 숫자 표시기 대신 주요 기능은 로그 텍스트 줄로 수행됩니다.

InfluxDB도 Go로 작성되었으며 (가장 강력하지는 않은) 클러스터의 ELK에 비해 훨씬 빠르게 실행되는 것 같습니다.

Influx의 멋진 장점 중 하나는 우리가 매우 적극적으로 사용했던 데이터 쿼리를 위한 매우 편리하고 풍부한 API입니다.

단점 - $$$ 또는 확장?

TICK 스택에는 우리가 발견한 단 하나의 단점이 있습니다. 사랑스러운. 더 나아가.

무료 버전에는 없지만 유료 버전에는 무엇이 있나요?

우리가 이해할 수 있는 한, TICK 스택의 유료 버전과 무료 버전의 유일한 차이점은 확장 기능입니다.

즉, 다음에서만 고가용성 클러스터를 키울 수 있습니다. 엔터프라이즈 버전.

본격적인 HA를 원한다면 비용을 지불하거나 목발을 사용해야 합니다. 몇 가지 커뮤니티 솔루션이 있습니다. 예를 들어 influxdb-ha 유능한 솔루션처럼 보이지만 생산에는 적합하지 않다고 쓰여 있습니다.
유입구 - NATS를 통해 데이터를 펌핑하는 간단한 솔루션(확장도 필요하지만 해결 가능)

안타깝지만 둘 다 버려진 것 같습니다. 새로운 커밋이 없습니다. 문제는 Influx 2.0의 새 버전이 곧 출시될 예정이라고 가정합니다. 이 버전에서는 많은 것이 달라질 것입니다. 아직 규모를 조정하고 있습니다).

공식적으로 무료 버전이 있습니다 계전기 - 사실 이는 원시적인 HA이지만 밸런싱을 통해서만,
모든 데이터는 로드 밸런서 뒤의 모든 InfluxDB 인스턴스에 기록되기 때문입니다.
그 사람이 좀 갖고 있어 단점 포인트 덮어쓰기와 관련된 잠재적인 문제 및 미리 메트릭에 대한 기반을 생성해야 하는 필요성 등
(InfluxDB의 일반적인 작업 중에 자동으로 발생합니다).

또한 샤딩은 지원되지 않습니다, 이는 필요하지 않을 수도 있는 중복 측정항목(처리 및 저장 모두)에 대한 추가 오버헤드를 의미하지만 이를 분리할 수 있는 방법은 없습니다.

빅토리아 메트릭스?

결과적으로 우리는 유료 확장 이외의 모든 부분에서 TICK 스택에 완전히 만족했음에도 불구하고 나머지 T_CK 구성 요소는 남겨두고 InfluxDB 데이터베이스를 대체할 수 있는 무료 솔루션이 있는지 알아보기로 결정했습니다.

시계열 데이터베이스는 많지만 가장 유망한 데이터베이스는 Victoria Metrics입니다. 여기에는 여러 가지 장점이 있습니다.

• 적어도 결과에 따르면 빠르고 쉽습니다. 벤치마크
• 현재 좋은 리뷰가 있는 클러스터 버전이 있습니다.
  • 그녀는 조각을 낼 수 있다
• InfluxDB 프로토콜 지원

우리는 Victoria를 기반으로 완전히 사용자 정의 스택을 구축할 의도가 없었으며 주요 희망은 이를 InfluxDB의 드롭인 대체품으로 사용할 수 있다는 것이었습니다.

불행하게도 InfluxDB 프로토콜이 지원된다는 사실에도 불구하고 이는 측정항목 기록에만 작동합니다. Prometheus API만 "외부"에서 사용할 수 있으므로 Chronograf를 설정할 수 없습니다.

또한 지표에는 숫자 값만 지원됩니다(맞춤 지표에는 문자열 값을 사용했습니다. 이에 대한 자세한 내용은 섹션에서 확인하세요). 관리자 패널).

분명히 같은 이유로 VM은 Influx처럼 로그를 저장할 수 없습니다.

또한, 최적의 솔루션을 모색할 당시에는 Victoria Metrics가 아직 그다지 인기가 없었으며, 문서가 훨씬 적고 기능도 약했다는 점에 유의해야 합니다.
(클러스터 버전과 샤딩에 대한 자세한 설명은 기억나지 않습니다.)

베이스 선택

결과적으로 파일럿에서는 여전히 단일 InfluxDB 노드로 제한하기로 결정했습니다.

이 선택에는 몇 가지 주요 이유가 있었습니다.

• 우리는 TICK 스택의 전체 기능이 정말 마음에 들었습니다.
• 우리는 이미 이를 배포했으며 훌륭하게 작동했습니다.
• 기한이 얼마 남지 않았고 다른 옵션을 테스트할 시간도 얼마 남지 않았습니다.
• 우리는 이렇게 무거운 짐을 기대하지 않았습니다

파일럿의 첫 번째 단계에는 스쿠터가 많지 않았으며 개발 중 테스트에서는 성능 문제가 발견되지 않았습니다.

따라서 우리는 이 프로젝트의 경우 확장할 필요 없이 하나의 Influx 노드로 충분하다고 결정했습니다(마지막 결론 참조).

우리는 스택과 베이스를 결정했습니다. 이제 TICK 스택의 나머지 구성 요소에 대해 알아보겠습니다.

커패시터

Kapacitor는 실시간으로 데이터베이스에 입력되는 지표를 모니터링하고 규칙에 따라 다양한 작업을 수행할 수 있는 서비스인 TICK 스택의 일부입니다.

일반적으로 잠재적인 이상 징후 추적 및 기계 학습을 위한 도구로 자리잡고 있지만(이러한 기능이 수요가 있는지는 잘 모르겠습니다) 가장 널리 사용되는 사례는 경고입니다.

이것이 우리가 알림에 사용한 방법입니다. 특정 스쿠터가 오프라인 상태가 되면 Slack 알림을 설정했으며 스마트 충전기와 중요한 인프라 구성 요소에 대해서도 동일한 작업을 수행했습니다.

이를 통해 문제에 신속하게 대응할 수 있을 뿐만 아니라 모든 것이 정상으로 돌아왔다는 알림을 받을 수 있었습니다.

간단한 예: "박스"에 전원을 공급하는 추가 배터리가 고장났거나 어떤 이유로 전원이 부족합니다. 새 배터리를 설치하기만 하면 잠시 후 스쿠터의 기능이 복원되었다는 알림을 받게 됩니다.

Influx 2.0에서는 Kapacitor가 DB의 일부가 되었습니다.

크로노 그래프

모니터링을 위한 다양한 UI 솔루션을 보아왔지만 기능과 UX 측면에서 Chronograf와 비교할 수 있는 것은 없다고 말할 수 있습니다.

이상하게도 우리는 Grafan을 웹 인터페이스로 사용하여 TICK 스택을 사용하기 시작했습니다.
기능에 대해서는 설명하지 않겠습니다. 모든 사람이 무엇이든 설정할 수 있는 광범위한 가능성을 알고 있습니다.

그러나 Grafana는 여전히 완전히 보편적인 도구인 반면 Chronograf는 주로 Influx와 함께 사용하도록 설계되었습니다.

그리고 물론, 덕분에 Chronograf는 훨씬 더 영리하고 편리한 기능을 감당할 수 있습니다.

아마도 Chronograf 작업의 가장 큰 편리함은 Explore를 통해 InfluxDB의 내부를 볼 수 있다는 것입니다.

Grafana에는 거의 동일한 기능이 있는 것처럼 보이지만 실제로 Chronograf에서 대시보드 설정은 몇 번의 마우스 클릭만으로(동시에 시각화를 보면서) 수행할 수 있습니다. 반면 Grafana에서는 조만간 JSON 구성을 편집하려면(물론 Chronograf를 사용하면 직접 구성한 대시를 업로드하고 필요한 경우 JSON으로 편집할 수 있지만 UI에서 대시를 생성한 후에는 건드릴 필요가 없었습니다).

Kibana는 대시보드 및 제어 기능을 생성할 수 있는 훨씬 더 풍부한 기능을 갖추고 있지만 이러한 작업을 위한 UX는 매우 복잡합니다.

편리한 대시보드를 만들려면 충분한 이해가 필요합니다. Chronograf 대시보드의 기능은 적지만 이를 만들고 사용자 정의하는 것이 훨씬 간단합니다.

쾌적한 시각적 스타일을 제외하면 대시보드 자체는 실제로 Grafana 또는 Kibana의 대시보드와 다르지 않습니다.

쿼리 창은 다음과 같습니다.

무엇보다도 InfluxDB 데이터베이스의 필드 유형을 알면 크로노그래프 자체가 쿼리를 작성하거나 평균과 같은 올바른 집계 함수를 선택하는 데 자동으로 도움이 될 수 있다는 점에 유의하는 것이 중요합니다.

물론 Chronograf는 로그를 보는 데 최대한 편리합니다. 다음과 같습니다:

기본적으로 Influx 로그는 syslog를 사용하도록 맞춤화되어 있으므로 중요한 매개변수인 심각도를 갖습니다.

상단의 그래프는 특히 유용합니다. 그래프에서 발생하는 오류를 확인할 수 있으며 심각도가 높을 경우 색상이 즉시 명확하게 표시됩니다.

몇 번 우리는 이런 방식으로 중요한 버그를 잡아냈는데, 지난 주 로그를 보고 빨간 스파이크를 보았습니다.

물론 이상적으로는 이러한 오류에 대한 경고를 설정하는 것입니다. 왜냐하면 우리는 이미 이에 대한 모든 것을 갖추고 있기 때문입니다.

우리는 이 기능을 한동안 켰지만 파일럿을 준비하는 과정에서 꽤 많은 오류(LTE 네트워크를 사용할 수 없는 것과 같은 시스템 오류 포함)가 발생하여 Slack 채널에도 "스팸"이 발생하는 것으로 나타났습니다. 아무런 문제도 일으키지 않고 아주 큰 혜택을 줍니다.

올바른 해결 방법은 이러한 유형의 오류 대부분을 처리하고 심각도를 조정한 다음 경고를 활성화하는 것입니다.

이렇게 하면 새롭거나 중요한 오류만 Slack에 게시됩니다. 마감 기한이 촉박했기 때문에 그러한 설정을 위한 시간이 충분하지 않았습니다.

인증

Chronograf가 인증으로 OAuth 및 OIDC를 지원한다는 점도 언급할 가치가 있습니다.

이는 서버에 쉽게 연결하고 본격적인 SSO를 생성할 수 있으므로 매우 편리합니다.

우리의 경우 서버는 열쇠망토 — 모니터링에 연결하는 데 사용되었지만 스쿠터와 백엔드에 대한 요청을 인증하는 데에도 동일한 서버가 사용되었습니다.

"관리자"

제가 설명할 마지막 구성 요소는 Vue에서 자체 작성한 "관리자 패널"입니다.
기본적으로 이는 자체 데이터베이스의 스쿠터 정보, 마이크로서비스 및 InfluxDB의 측정 데이터를 동시에 표시하는 독립형 서비스입니다.

또한 긴급 재부팅이나 지원팀을 위한 원격 잠금 해제 등 많은 관리 기능이 이곳으로 옮겨졌습니다.

지도도 있었어요. 저는 이미 Chronograf 대신 Grafana로 시작했다고 언급했습니다. 왜냐하면 Grafana 지도는 스쿠터의 좌표를 볼 수 있는 플러그인 형태로 제공되기 때문입니다. 불행하게도 Grafana용 지도 위젯의 기능은 매우 제한되어 있으므로 현재 좌표를 볼 수 있을 뿐만 아니라 스쿠터가 이동한 경로, 지도의 데이터 필터링 등이 가능합니다(간단한 대시보드에서는 구성할 수 없었던 모든 기능).

이미 언급한 Influx의 장점 중 하나는 자신만의 측정항목을 쉽게 생성할 수 있다는 것입니다.
이를 통해 매우 다양한 시나리오에 사용할 수 있습니다.

배터리 충전, 잠금 상태, 센서 성능, 블루투스, GPS 및 기타 여러 상태 점검 등 유용한 정보를 모두 기록하려고 했습니다.
우리는 이 모든 것을 관리자 패널에 표시했습니다.

물론 우리에게 가장 중요한 기준은 스쿠터의 작동 상태였습니다. 실제로 Influx는 이를 자체적으로 확인하고 노드 섹션에 "녹색 표시등"으로 표시합니다.

이는 함수에 의해 수행됩니다. 데드 맨 — 우리는 이를 사용하여 상자의 성능을 이해하고 동일한 경고를 Slack에 보냈습니다.

그건 그렇고, 우리는 The Simpsons의 캐릭터 이름을 따서 스쿠터 이름을 지정했습니다. 서로 구별하는 것이 매우 편리했습니다.

그리고 일반적으로 이 방법이 더 재미있었습니다. "얘들아, 스미더스가 죽었어!" 같은 말이 끊임없이 들려왔다.

문자열 측정항목

InfluxDB를 사용하면 Victoria Metrics의 경우처럼 숫자 값만 저장할 수 있는 것이 아닙니다.

이것은 그다지 중요하지 않은 것 같습니다. 결국 로그 외에도 모든 측정항목은 숫자 형식으로 저장될 수 있습니다(알려진 상태에 대한 매핑을 추가하기만 하면 됩니다(일종의 열거형)).

우리의 경우 문자열 메트릭이 매우 유용한 시나리오가 하나 이상 있었습니다.
우연히 우리의 "스마트 충전기" 공급업체가 제XNUMX자였기 때문에 우리는 이러한 충전기가 제공할 수 있는 개발 프로세스와 정보를 통제할 수 없었습니다.

결과적으로 과금 API는 이상적이지는 않았지만, 가장 큰 문제는 우리가 그 상태를 항상 이해할 수 없다는 점이었습니다.

이것이 Influx가 구출된 곳입니다. 우리는 변경 없이 InfluxDB 데이터베이스 필드에 제공된 문자열 상태를 간단히 작성했습니다.

한동안 관리자 패널에 표시되는 정보에 따라 "온라인" 및 "오프라인"과 같은 값만 표시되고 알림이 Slack으로 전송되었습니다. 그런데 어느 순간 거기에도 '연결이 끊어졌다' 같은 가치관이 나타나기 시작했다.

나중에 밝혀진 바와 같이, 이 상태는 충전기가 특정 횟수의 시도 후에도 서버와 연결을 설정할 수 없는 경우 연결이 끊어진 후 한 번 전송되었습니다.

따라서 고정된 값 세트만 사용한 경우 펌웨어에서 이러한 변경 사항이 적시에 표시되지 않을 수 있습니다.

그리고 일반적으로 문자열 메트릭은 훨씬 더 많은 사용 가능성을 제공하므로 실제로 모든 정보를 기록할 수 있습니다. 물론 이 도구도 주의 깊게 사용해야 합니다.

일반적인 측정 항목 외에도 InfluxDB에 GPS 위치 정보도 기록했습니다. 이는 관리자 패널에서 스쿠터 위치를 모니터링하는 데 매우 유용했습니다.
사실 우리는 필요한 순간에 어떤 스쿠터가 어디에 있는지 항상 알고 있었습니다.

이는 우리가 스쿠터를 찾을 때 매우 유용했습니다(마지막 결론 참조).

인프라 모니터링

스쿠터 자체 외에도 전체(다소 광범위한) 인프라를 모니터링해야 했습니다.

매우 일반적인 아키텍처는 다음과 같습니다.

순수 모니터링 스택을 강조표시하면 다음과 같습니다.

우리가 클라우드에서 확인하고 싶은 것은 다음과 같습니다.

• 데이터 베이스
• 열쇠망토
• 마이크로서비스

우리의 모든 클라우드 서비스는 Kubernetes에 있으므로 해당 상태에 대한 정보를 수집하는 것이 좋습니다.

다행스럽게도 Telegraf는 즉시 사용 가능하며 Kubernetes 클러스터 상태에 대한 수많은 지표를 수집할 수 있으며 Chronograf는 이를 위한 아름다운 대시보드를 즉시 제공합니다.

우리는 주로 포드의 성능과 메모리 소비를 모니터링했습니다. 넘어지면 Slack에서 경고합니다.

Kubernetes에서 Pod를 추적하는 방법에는 DaemonSet과 Sidecar라는 두 가지 방법이 있습니다.
두 방법 모두 자세히 설명되어 있습니다. 이 블로그 게시물에서.

Telegraf Sidecar를 사용했으며 측정항목 외에도 Pod 로그를 수집했습니다.

우리의 경우에는 로그를 수정해야 했습니다. Telegraf가 Docker API에서 로그를 가져올 수 있다는 사실에도 불구하고 우리는 최종 장치에 균일한 로그 컬렉션을 갖고 싶었고 이를 위해 컨테이너용 syslog를 구성했습니다. 아마도 이 솔루션은 아름답지는 않았지만 작업에 대한 불만은 없었고 Chronograf에서는 로그가 잘 표시되었습니다.

모니터 모니터링???

결국 모니터링 시스템 모니터링에 대한 오래된 문제가 발생했지만 다행스럽게도 안타깝게도 이에 대한 시간이 충분하지 않았습니다.

Telegraf는 자체 메트릭을 쉽게 보내거나 동일한 Influx 또는 다른 곳으로 보내기 위해 InfluxDB 데이터베이스에서 메트릭을 수집할 수 있습니다.

조사 결과

파일럿 결과에서 어떤 결론을 얻었습니까?

모니터링은 어떻게 할 수 있나요?

우선, TICK 스택은 우리의 기대를 완전히 충족시켰고 우리가 처음에 기대했던 것보다 훨씬 더 많은 기회를 제공했습니다.

우리에게 필요한 모든 기능이 존재했습니다. 우리가 한 모든 일은 문제 없이 작동했습니다.

Производительность

무료 버전의 TICK 스택의 주요 문제점은 확장 기능이 부족하다는 것입니다. 이것은 우리에게 문제가 되지 않았습니다.

정확한 하중 데이터/수치를 수집하지는 않았지만, 한 번에 약 30대의 스쿠터로부터 데이터를 수집했습니다.

그들 각각은 10개 이상의 지표를 수집했습니다. 동시에 기기의 로그가 수집되었습니다. 데이터 수집 및 전송은 XNUMX초마다 이루어졌습니다.

일주일 반 동안의 파일럿 이후, 대부분의 "어린 시절의 상처"가 수정되고 가장 중요한 문제가 이미 해결되었을 때 서버로 데이터를 전송하는 빈도를 줄여야 했다는 점에 유의하는 것이 중요합니다. 30 초. LTE SIM 카드의 트래픽이 빠르게 사라지기 시작했기 때문에 이는 필요해졌습니다.

트래픽의 대부분은 로그에 의해 소비되었으며, 지표 자체는 10초 간격으로도 실제로 낭비되지 않았습니다.

결과적으로 지속적인 수집 없이도 특정 문제가 이미 명백했기 때문에 일정 시간이 지난 후 장치의 로그 수집을 완전히 비활성화했습니다.

어떤 경우에는 여전히 로그 보기가 필요한 경우 VPN을 통해 WireGuard를 통해 연결했습니다.

또한 우리가 가지고 있던 각각의 개별 환경은 서로 분리되어 있었고 위에서 설명한 로드는 프로덕션 환경에만 관련이 있다는 점을 덧붙일 것입니다.

개발 환경에서는 10초마다 계속 데이터를 수집하는 별도의 InfluxDB 인스턴스를 생성했는데 성능 문제는 발생하지 않았습니다.

TICK - 중소 규모 프로젝트에 이상적

이 정보를 바탕으로 TICK 스택은 상대적으로 작은 프로젝트나 HighLoad가 전혀 예상되지 않는 프로젝트에 이상적이라는 결론을 내릴 수 있습니다.

수천 개의 포드나 수백 개의 머신이 없다면 하나의 InfluxDB 인스턴스라도 로드를 잘 처리할 수 있습니다.

어떤 경우에는 기본 고가용성 솔루션인 Influx Relay에 만족하실 수도 있습니다.

물론 "수직적" 확장을 설정하고 단순히 다양한 유형의 메트릭에 대해 다양한 서버를 할당하는 것을 누구도 막지 못합니다.

모니터링 서비스의 예상 로드가 확실하지 않거나 매우 "무거운" 아키텍처를 갖게 될 것이 확실하다면 TICK 스택의 무료 버전을 사용하지 않는 것이 좋습니다.

물론 간단한 해결책은 구매하는 것입니다. InfluxDB 엔터프라이즈 -하지만 여기서는 미묘함에 익숙하지 않기 때문에 어떻게 든 논평 할 수 없습니다. 게다가 가격이 매우 비싸고 중소기업에는 적합하지 않습니다.

이런 경우 오늘은 Victoria Metrics를 통해 지표를 수집하고 Loki를 사용하여 로그를 수집하는 방법을 살펴보는 것이 좋습니다.

사실, Loki/Grafana는 기성품 TICK보다 훨씬 덜 편리하지만(더 큰 다양성으로 인해) 무료라는 점을 다시 한 번 말씀드립니다.

중요한 일이야: 여기에 설명된 모든 정보는 Influx 1.8이 곧 출시될 예정인 Influx 2.0 버전과 관련이 있습니다.

전투 상황에서 시도해 볼 기회가 없었고 개선에 대한 결론을 내리기는 어렵지만 인터페이스는 확실히 훨씬 좋아졌고 아키텍처는 단순화되었습니다(kapacitor 및 chronograf 없음).
템플릿이 나타났습니다("킬러 기능" - Fortnite에서 플레이어를 추적하고 좋아하는 플레이어가 게임에서 승리하면 알림을 받을 수 있습니다.). 그러나 불행하게도 현재 버전 2에는 첫 번째 버전을 선택한 핵심 사항이 없습니다. 즉, 로그 수집이 없습니다.

이 기능은 Influx 2.0에도 나타날 예정이지만 대략적인 마감 기한은 물론이고 마감 기한도 찾을 수 없습니다.

IoT 플랫폼을 만들지 않는 방법 (지금)

결국 파일럿을 시작한 후 우리 표준에 적합한 대안이 없는 상황에서 우리는 본격적인 IoT 스택을 직접 조립했습니다.

그러나 최근에는 베타 버전으로 제공됩니다. 오픈발레나 — 우리가 프로젝트를 시작할 때 그녀가 거기에 없었다는 것은 유감입니다.

우리는 최종 결과와 우리가 직접 조립한 Ansible + TICK + WireGuard 기반 플랫폼에 완전히 만족합니다. 하지만 오늘은 IoT 플랫폼을 직접 구축하기 전에 Balena를 자세히 살펴보는 것이 좋습니다.

왜냐하면 궁극적으로 우리가 했던 일의 대부분을 수행할 수 있고 OpenBalena는 무료이며 오픈 소스이기 때문입니다.

업데이트를 보내는 방법을 이미 알고 있을 뿐만 아니라 IoT 환경에서 사용할 수 있도록 VPN이 이미 내장되어 맞춤화되어 있습니다.

그리고 최근에는 심지어 하드웨어, 생태계에 쉽게 연결됩니다.

저기, 사라진 스쿠터는 어쩌고?

그래서 스쿠터 "랄프"는 흔적도 없이 사라졌습니다.

우리는 즉시 InfluxDB의 GPS 측정 데이터가 포함된 "관리자 패널"의 지도를 보기 위해 달려갔습니다.

모니터링 데이터 덕분에 우리는 스쿠터가 어제 21시쯤 주차장을 떠나 어떤 지역으로 00분 정도 운전한 뒤 오전 5시까지 독일의 어떤 집 옆에 주차되어 있다는 것을 쉽게 알아냈습니다.

오전 5시 이후에는 모니터링 데이터가 수신되지 않았습니다. 이는 추가 배터리가 완전히 방전되었거나 공격자가 마침내 스쿠터에서 스마트 하드웨어를 제거하는 방법을 알아냈다는 의미입니다.
그럼에도 불구하고 경찰은 여전히 ​​스쿠터가 있는 주소로 출동했습니다. 스쿠터는 거기에 없었습니다.

그런데 집주인도 어젯밤에 실제로 이 스쿠터를 타고 사무실에서 집으로 돌아왔기 때문에 이에 놀랐습니다.

결과적으로 지원 직원 중 한 명이 아침 일찍 도착하여 스쿠터를 픽업했고, 추가 배터리가 완전히 방전된 것을 확인하고 (도보로) 주차장으로 가져갔습니다. 그리고 추가 배터리도 습기로 인해 고장이 났습니다.

우리는 스쿠터를 우리 자신에게서 훔쳤습니다. 그건 그렇고, 경찰 사건의 문제를 누가 어떻게 해결했는지는 모르겠지만 모니터링은 완벽하게 작동했습니다 ...

출처 : habr.com