모니터링 IoT 장치의 신뢰성, 효율성 및 보안을 유지하려면 관찰 가능성이 필수적입니다. 제대로 수행되면 IoT 시스템에 대한 실시간 개요를 제공할 뿐만 아니라 과거 문제를 해결하는 데 필요한 데이터에 대한 액세스도 보장합니다. 그러나 수천 개의 다양한 IoT 장치에 직면했을 때 이러한 목표를 달성하는 데는 많은 어려움이 따릅니다.

모니터링해야 할까요, 아니면 관찰해야 할까요?

먼저, "모니터링"과 "관찰 가능성"이라는 단어가 차이점에도 불구하고 같은 의미로 사용되는 경우가 많기 때문에 IoT 모니터링 및 관찰 가능성의 용어를 수정해 보겠습니다.

좀 더 확립된 역사를 가진 용어인 모니터링부터 시작해 보겠습니다. 모니터링의 핵심은 시스템의 상태와 성능에 대한 통찰력을 제공하는 것입니다.

이는 관련 지표를 수집하고 분석하는 것부터 시작됩니다. 분석은 일반적으로 대시보드를 통해 제공됩니다. 그러나 합리적인 모니터링 스택은 시각적 표현을 넘어 실시간으로 지표를 평가하고 사용자에게 예외 사항이나 문제를 경고해야 합니다.

그러나 모니터링에 대한 전통적인 접근 방식에는 문제가 있습니다. 즉, 무엇을 찾아야 하는지 알아야 한다는 것입니다. 새로운 문제가 발생하면 이 방법이 부족할 수 있습니다.

소위 알려지지 않은 미지의 항목을 처리하는 데 도움이 될 수 있으므로 관찰 가능성이 중요한 역할을 합니다. 간단히 말해서, 출력을 통해서만 내부 작동에 대한 질문에 대답할 수 있을 때 시스템을 관찰할 수 있습니다. 소프트웨어의 일반적인 출력에는 로그, 메트릭 및 추적이 포함됩니다.

관찰 가능성이 좋은 시스템은 문제 해결이 더 쉬울 뿐만 아니라 훨씬 더 광범위한 문제를 감지할 수 있습니다. 이는 시스템에 대한 더 나은 통찰력을 갖게 되므로 실제로 무슨 일이 일어나고 있는지에 대한 질문에 대한 답변을 더 쉽게 얻을 수 있기 때문입니다.

시스템에 수많은 장치와 모듈이 포함되는 IoT 환경에서는 관찰 가능성이 특히 중요합니다. 문제를 일으킬 수 있는 모든 잠재적인 상태 조합을 예상하려는 시도는 이 규모에서는 불가능하지는 않더라도 비실용적입니다.

필수 지표 및 모니터링 접근 방식

추적할 가치가 있는 데이터와 이 작업에 도움이 되도록 설계된 특정 도구를 살펴보겠습니다.

우리는 데이터를 얻고 있나요?

사물 인터넷이 사물보다 데이터에 더 중점을 두는 경우가 많다는 것은 누구나 아는 사실입니다. 그렇기 때문에 장치의 데이터 전송을 감시하는 것이 중요합니다. 견고한 IoT 플랫폼은 메시지 빈도, 전송되는 데이터 양과 같은 지표를 면밀히 관찰해야 합니다.

그러나 수천 대의 장치 트래픽을 수동으로 관찰하는 것은 분명히 현명한 행동이 아닙니다. 이 경우 자동 경고의 필요성은 의심할 여지가 없습니다.. 경고를 받아야 하는 최소한의 경우는 장치가 데이터를 보내지 않지만 데이터를 보낼 것으로 예상되는 경우입니다.

그러나 IoT 장치는 인터넷 연결이 불안정한 지역과 같이 예측할 수 없는 환경에서 작동하는 경우가 많다는 점을 명심하세요. 따라서 데이터 전송의 짧은 간격이 항상 장치에 문제가 있음을 나타내는 것은 아닙니다.

또한 중요한 데이터가 손실되지 않도록 장치나 에지 게이트웨이에서 메시지를 버퍼링하는 것이 일반적인 관행입니다. 요점은 임계값을 너무 민감하게 만들지 않도록 매우 주의해야 한다는 것입니다. 그렇지 않으면 필연적으로 경고 피로를 초래하는 네트워크의 모든 문제에 대해 경고를 받게 되며 경고는 그 잠재력을 잃게 됩니다.

일반 장치 상태 정보

장치 상태 모니터링에는 다양한 주요 측정항목 추적이 포함됩니다. CPU, 메모리 소비, 네트워크 트래픽을 생각해 볼 수 있습니다. 이러한 지표에 액세스하면 성능 문제를 식별하고 소프트웨어 버그를 감지하거나 심지어는 외부 공격 공개.

이러한 측정항목을 노출하는 방법에는 여러 가지가 있습니다. 그러나 엔지니어링 커뮤니티는 현재 다음의 기능에 매료되어 있습니다. 오픈 텔레메트리.

주요 판매 포인트 중 하나는 공급업체에 구애받지 않는 접근 방식입니다. 즉, 다음 중에서 선택할 수 있습니다. 수많은 관측성 백엔드 저장 및 다음 분석을 위해. 이로 인해 이를 사용하기 위한 모든 종류의 도구가 만들어졌습니다.

따라서 어떤 언어나 시스템을 사용하든 문제가 해결됩니다. 이는 특히 모든 장치가 고유한 소프트웨어를 실행할 수 있는 IoT의 세계에서 매우 편리합니다.

OpenTelemetry는 메트릭, 로그, 추적이라는 세 가지 주요 신호 유형을 지원합니다. 이 섹션에 설명된 대부분의 경우 장치는 현재 메모리 소비와 같은 여러 관련 측정항목을 노출하기만 하면 됩니다.

그런 다음 이러한 측정항목을 클라우드로 전송하여 시각화하고 알림을 설정하는 등의 작업을 수행해야 합니다. 이 경로는 IoT 장치에서 지표를 수집하는 데 도움이 될 수 있는 OpenTelemetry Collector 또는 Telegraf와 같은 프로젝트의 IoT 사용 사례를 위해 이미 준비되어 있습니다.

기타 도메인별 신호

데이터 전송 및 리소스 활용의 일반적인 특성 외에도 일부 도메인별 값을 추적해야 할 수도 있습니다. 여기에는 애플리케이션별 콘텐츠가 포함된 로그, 추적 또는 간단한 메시지 전송이 포함될 수 있습니다.

로그와 추적 모두 OpenTelemetry 에코시스템을 다시 한 번 신뢰할 수 있습니다. 이를 통해 추가 노력 없이 Grafana Loki/Tempo 또는 Elastic Observability 스택과 같은 선호하는 백엔드를 사용하여 로그 및 추적을 분석할 수 있습니다! 반면에 메시징은 모든 합리적인 IoT 플랫폼의 핵심 기능입니다. 즉, 이러한 접근 방식은 대부분의 시나리오에서 구현하기가 쉽지 않습니다.

로그의 단순성

예를 들어 자율 수확 기계를 생각해 보십시오. 활동을 추적하고 싶을 수도 있습니다. 이를 수행하는 간단한 방법은 활동이 시작될 때 일부 추가 메타데이터를 사용하여 로그를 보내는 것입니다.

활동이 완료되거나 기타 관련 이벤트에 대해서도 동일한 작업을 수행할 수 있습니다. 기본적으로 각 로그 레코드는 여러 필수 속성이 있는 구조화된 이벤트일 뿐입니다. 다음은 수확기가 도킹 시퀀스를 시작할 때 전송되는 로그의 예입니다.

타임스탬프 및 본문과 같은 기본 필드 외에도 메시지에는 이벤트를 더 자세히 설명하는 추가 속성이 포함될 수 있습니다. 이러한 추가 비트는 버그를 찾을 때 유용할 수 있습니다. 따라서 중요한 정보를 모두 포함했는지 확인하세요.

추적을 통한 심층적인 상황별 통찰력

좀 더 자세한 통찰력을 원한다면 추적을 사용할 수도 있습니다. 추적은 시스템의 하나의 논리적 작업에 해당하며 해당 범위에 의해 암시적으로 정의됩니다. 범위는 해당 작업의 단일 작업 단위를 나타냅니다. 이는 시작 및 종료 시간, 속성, 선택적으로 상위 범위로 정의됩니다.

상위 참조 덕분에 추적은 특정 작업과 해당 서브루틴을 설명하는 방향성 그래프를 형성합니다. 또한 범위에는 특정 시점에 발생한 이벤트를 설명하는 여러 범위 이벤트가 포함될 수 있습니다.

추적은 일반적으로 분산 시스템 모니터링과 연관되어 있지만 IoT 장치에서 추적을 사용하면 현장에서 일어나는 일에 대한 큰 그림을 이해하는 데 도움이 될 수도 있습니다. 자율 수확기가 어떻게 도킹 스테이션으로 돌아가는지 궁금하다고 가정해 보겠습니다.

도킹이 최상위 루트 범위에 해당하는 아래 그림을 참조하세요. 먼저 수확기는 도킹 스테이션을 찾아야 하므로 API를 호출합니다. 이 작업은 하나의 하위 범위에 해당합니다. 스팬 이벤트의 예로는 수확자가 밭을 떠난 시점을 들 수 있습니다. 모든 추적 장비를 함께 사용하면 장치 작동의 전체 그림을 볼 수 있습니다.

간단한 메시지로 기본으로 돌아가기

특정 시나리오에서는 OpenTelemetry 신호를 사용하는 것보다 간단하고 구조화된 메시지를 보내는 것이 더 실용적일 수 있습니다. 자율 수확기의 예로 돌아가서 아마도 그 위치를 추적하고 싶을 것입니다.

실시간으로 위치를 시각화하려는 경우 OpenTelemetry는 현재 의미상 이 시나리오에 맞는 신호를 실제로 지원하지 않습니다. 가장 가까운 일치 항목은 이벤트 API일 가능성이 높습니다. 이 API는 아직 실험 단계에 있습니다(이 기사를 작성하는 1년 2024분기 기준). 대신 다음 JSON 메시지를 보내는 것을 고려해 보세요.

이상적으로는 사용 중인 IoT 플랫폼이 이러한 메시지를 구문 분석하여 선택한 적절한 데이터베이스에 수집할 수 있어야 합니다. 여기에서 필요에 따라 데이터를 자유롭게 분석하고 시각화할 수 있습니다.

단순성을 보여주기 위해 Spotflow IoT 플랫폼을 사용하여 이 예를 다시 만들었습니다. 우리는 위치와 속도가 포함된 메시지를 플랫폼에 주기적으로 보내는 장치를 설정합니다. 그런 다음 데이터 스트림을 내장된 Grafana 송신 싱크로 라우팅했습니다. 그리고 그게 다야! 이제 플랫폼은 모든 메시지를 수집하여 Grafana에서 쿼리할 수 있는 시계열 데이터베이스에 넣습니다.

또한 이는 Grafana Geomap 시각화의 훌륭한 사용 사례입니다. 이를 통해 장치의 위치를 ​​쉽게 표시할 수 있습니다. Grafana를 사용하여 장치에서 수신된 데이터를 시각화한 아래 이미지를 참조하세요.

주요 요점

그리고 그게 다야! 이제 관측 가능성 스택을 설정하고 IoT 장치 모니터링을 시작할 준비가 되었습니다. 우리는 이 기사가 IoT 관찰 가능성의 세계에서 출발점이 되기를 바랍니다. 다음 핵심 아이디어를 기억하세요.

• 데이터 전송 모니터링: 장치의 데이터 전송을 면밀히 감시하고 중단을 즉시 발견할 수 있도록 경고를 준비하십시오.
• 장치 상태 지표 추적: 원활한 작동을 보장하기 위해 장치 상태와 관련된 측정항목을 표시합니다.
• 로그, 추적 및 구조화된 메시지를 통해 애플리케이션별 데이터 전송: 귀하의 도메인과 장치의 작동을 고려하고 향후 디버깅 및 실시간 모니터링에 필요할 수 있는 모든 데이터를 보냅니다.
• OpenTelemetry 생태계 살펴보기: 관찰 가능성 백엔드에 대한 다양한 옵션을 제공하고 다양한 장치 런타임을 제공하는 관찰 가능성 표준이 되므로 IoT에서 OpenTelemetry 생태계 사용을 고려해보세요.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://www.iotforall.com/a-practical-guide-to-monitoring-observability-of-iot-devices