적용 대상:
IoT Edge 1.5
중요합니다
IoT Edge 1.5 LTS는 지원되는 릴리스입니다. IoT Edge 1.4 LTS는 2024년 11월 12일부터 수명이 종료됩니다. 이전 릴리스에 있는 경우 IoT Edge 업데이트를 참조하세요.
이 문서에서는 관찰 가능성 차원( 측정 및 모니터링 및문제 해결)을 모두 구현하기 위한 개념과 기술에 대해 알아봅니다. 다음 항목에 대해 알아봅니다.
- 모니터링할 서비스 성능 지표 정의
- 메트릭을 사용하여 서비스 성능 지표 측정
- Azure Monitor 통합 문서를 사용하여 메트릭 모니터링 및 문제 검색
- 큐레이팅된 통합 문서를 사용하여 기본 문제 해결
- 분산 추적 및 상관 관계 로그를 사용하여 고급 문제 해결
- 필요에 따라 Azure에 샘플 시나리오를 배포하여 학습한 내용을 연습합니다.
시나리오
추상적인 고려 사항을 넘어서기 위해 센서에서 Azure IoT로 해양 표면 온도를 수집하는 실제 시나리오를 사용해 보겠습니다.
라니냐
라니냐 서비스는 태평양의 표면 온도를 측정하여 라니냐 겨울을 예측합니다. 바다의 부표에는 표면 온도 데이터를 Azure Cloud로 보내는 IoT Edge 디바이스가 있습니다. 각 IoT Edge 디바이스의 사용자 지정 모듈은 원격 분석 데이터를 클라우드로 보내기 전에 전처리합니다. 클라우드에서 백 엔드 Azure Functions는 데이터를 처리하고 Azure Blob Storage에 저장합니다. ML 유추 워크플로, 의사 결정 시스템 및 다른 UI와 같은 서비스의 클라이언트는 Azure Blob Storage에서 온도 데이터를 사용하여 메시지를 가져올 수 있습니다.
측정 및 모니터링
비즈니스 가치에 중점을 두고 La Niña 서비스를 위한 측정 및 모니터링 솔루션을 빌드해 보겠습니다.
무엇을 측정하고 모니터링하나요?
무엇을 모니터링할 것인지 파악하려면 서비스가 실제로 하는 일과 서비스 클라이언트가 시스템에서 기대하는 것을 파악해야 합니다. 이 시나리오에서는 일반적인 La Niña 서비스 소비자에 대한 기대치를 다음 요인으로 분류할 수 있습니다.
- 커버리지. 대부분의 설치된 부표에서 데이터가 옵니다.
- 최신 데이터. 부표에서 오는 데이터는 최신 데이터이며 관련성이 높습니다.
- 처리량. 온도 데이터는 큰 시간 지연 없이 부표에서 전달됩니다.
- 정확성. 손실된 메시지(오류)의 비율이 낮습니다.
이러한 요인과 관련하여 만족한다는 것은 서비스가 클라이언트의 기대에 따라 작동한다는 것을 의미합니다.
다음 단계는 이러한 요인의 값을 측정하는 계측기를 정의하는 것입니다. 이 작업은 다음 SLI(서비스 수준 표시기)를 통해 수행됩니다.
| 서비스 수준 지표 | 요소 |
|---|---|
| 전체 디바이스 중 온라인 디바이스의 비율 | 범위 |
| 보고하는 디바이스 중 자주 보고하는 디바이스의 비율 | 최신 데이터, 처리량 |
| 전체 디바이스 중 메시지를 성공적으로 전송하는 디바이스의 비율 | 정확성 |
| 전체 디바이스 중 메시지를 빠르게 전송하는 디바이스의 비율 | 처리량 |
위의 단계를 마쳤으면 각 지표에서 슬라이딩 배율을 적용하고 고객이 "만족"한다는 것의 의미를 나타내는 정확한 임계값을 정의할 수 있습니다. 이 시나리오에서는 공식 SLO(서비스 수준 목표)를 사용하여 다음 표에 나와 있는 샘플 임계값을 선택합니다.
| 서비스 수준 목표 | 요소 |
|---|---|
| 디바이스의 90%가 관찰 간격 동안 10분 이내에(온라인) 메트릭을 보고했습니다. | 범위 |
| 온라인 디바이스의 95%가 관찰 간격 동안 온도를 분당 10번 보냅니다. | 최신 데이터, 처리량 |
| 온라인 디바이스의 99%가 관찰 간격 동안 메시지를 성공적으로 보내며 오류는 5% 미만입니다. | 정확성 |
| 온라인 디바이스의 95%가 관찰 간격 동안 메시지의 90번째 백분위수를 50ms 이내에 전달합니다. | 처리량 |
SLO 정의는 지표 값을 측정하는 방법도 설명해야 합니다.
- 관찰 간격: 24시간. SLO 진술은 지난 24시간 동안 참입니다. 즉, SLI가 중단되고 해당 SLO에 영향을 미치는 경우, SLI가 수정된 후 SLO가 다시 정상으로 간주되기까지 24시간이 소요됩니다.
- 측정 빈도: 5분. 5분마다 측정하여 SLI 값을 평가합니다.
- 측정 대상: IoT 디바이스와 클라우드 간의 상호 작용, 더 이상의 온도 데이터 사용은 이 문서의 범위를 벗어납니다.
측정 방법
이제 서비스가 기대한 대로 작동하는지 확인하려면 무엇을 측정하고 어떤 임계값을 사용해야 하는지 명확해졌습니다.
메트릭을 통해 정의한 것과 같은 서비스 수준 지표를 측정하는 것이 일반적인 방법입니다. 이 유형의 가시성 데이터는 값이 상대적으로 작다고 간주됩니다. 다양한 시스템 구성 요소에 의해 생성되며 대시보드, 워크북 및 경고를 통해 모니터링할 중앙 관찰 백엔드 시스템에 수집됩니다.
La Niña 서비스를 구성하는 구성 요소는 다음과 같습니다.
IoT Edge 디바이스Temperature Sensor에는 일부 온도 값을 생성하고 원격 분석 메시지를 사용하여 이를 업스트림으로 전송하는 사용자 지정 모듈(C#)이 있습니다. 이 메시지는 다른 사용자 지정 모듈 Filter(C#)로 라우팅됩니다. 이 모듈은 수신된 온도를 임계값 범위(섭씨 0-100도)와 대조하여 확인합니다. 온도가 범위 내에 있는 경우 FilterModule은 원격 분석 메시지를 클라우드로 보냅니다.
클라우드에서 메시지는 백 엔드에 의해 처리됩니다. 백 엔드는 2개의 Azure Functions와 스토리지 계정 체인으로 구성됩니다. Azure .NET Function은 IoT Hub 이벤트 엔드포인트에서 원격 분석 메시지를 선택하고, 처리하고, Azure Java Function으로 보냅니다. Java 함수는 메시지를 스토리지 계정 Blob 컨테이너에 저장합니다.
IoT Hub 디바이스는 시스템 모듈 edgeHub 및 edgeAgent가 함께 제공됩니다. 이러한 모듈은 Prometheus 엔드포인트를 통해 기본 제공 메트릭 목록을 노출합니다. 이러한 메트릭은 IoT Edge 디바이스에서 실행되는 메트릭 수집기 모듈에 수집되고 Azure Monitor Log Analytics 서비스로 푸시됩니다. 시스템 모듈 외에도, 비즈니스 관련 메트릭을 사용하여 Temperature Sensor 및 Filter 모듈을 계측할 수 있습니다. 그러나 우리가 정의한 서비스 수준 지표는 기본 제공 메트릭으로만 측정할 수 있습니다. 따라서 지금은 다른 것을 구현할 필요가 없습니다.
이 시나리오에서는 10개의 부표가 있습니다. 문제 탐지 및 후속 문제 해결 조치를 시연할 수 있도록 부표 중 하나는 의도적으로 오작동하도록 설정되었습니다.
모니터링 방법
Azure Monitor 통합 문서를 사용하여 SLO(서비스 수준 목표) 및 해당 SLI(서비스 수준 지표)를 모니터링할 것입니다. 이 시나리오 배포에는 IoT Hub에 할당된 La Nina SLO/SLI 통합 문서가 포함되어 있습니다.
최상의 사용자 환경을 달성하기 위해 통합 문서는 한눈에 보기 ->스캔 ->커밋 개념을 따르도록 설계되었습니다.
한눈에 보기
이 수준에서는 전체 그림을 한눈에 볼 수 있습니다. 데이터가 집계되어 플릿 수준에서 표시됩니다.
우리가 볼 수있는 것에서, 서비스는 기대에 따라 작동하지 않습니다. 데이터 신선도 SLO가 위반되었습니다. 서비스 클라이언트에서 기대하는 것은 95%인데 디바이스의 90%만이 데이터를 자주 보냅니다.
모든 SLO 및 임계값은 통합 문서 설정 탭에서 구성할 수 있습니다.
검색
위반된 SLO를 클릭하면 스캔 수준으로 드릴다운하고 디바이스가 집계된 SLI 값에 어떻게 기여하는지 확인할 수 있습니다.
원격 분석 데이터를 클라우드로 "드물게" 보내는 단일 디바이스(10개 중)가 있습니다. SLO 정의에서 "자주"는 분당 최소 10회를 의미한다고 했습니다. 이 디바이스의 빈도는 이 임계값보다 훨씬 낮습니다.
커밋
문제가 있는 디바이스를 클릭하여 커밋 수준으로 드릴다운합니다. 이것은 IoT Hub 모니터링 제품과 함께 기본적으로 제공되는 큐레이팅된 통합 문서 디바이스 세부 정보입니다. La Nina SLO/SLI 통합 문서는 이것을 재사용하여 특정 디바이스 성능에 대한 세부 정보를 가져옵니다.
문제 해결
측정 및 모니터링을 통해 시스템 동작을 관찰 및 예측하고, 정의된 기대치와 비교하고, 궁극적으로 기존 문제 또는 잠재적 문제를 탐지할 수 있습니다. 반면 문제 해결을 통해 문제의 원인을 식별하고 찾을 수 있습니다.
기본 문제 해결
커밋 수준 워크북은 장치 상태에 대한 자세한 정보를 제공합니다. 여기에는 모듈 및 디바이스 수준의 리소스 소비, 메시지 대기 시간, 빈도, QLen 등이 포함됩니다. 대부분의 경우 이 정보는 문제의 근본 원인을 찾는 데 도움이 될 수 있습니다.
이 시나리오에서는 문제 디바이스의 모든 매개 변수가 정상으로 표시되며 디바이스가 예상보다 덜 자주 메시지를 보내는 이유가 명확하지 않습니다. 디바이스 수준 통합 문서의 메시징 탭에서도 이를 확인합니다.
Temperature Sensor(tempSensor) 모듈은 120개의 원격 분석 메시지를 생성했지만, 그 중 49개만이 업스트림으로 클라우드에 전송되었습니다.
먼저 모듈에서 생성된 로그를 확인합니다 Filter .
실시간 문제 해결을 선택한 다음, 모듈을 Filter 선택합니다.
모듈 로그를 분석해도 문제가 표시되지는 않습니다. 모듈은 메시지를 수신하며 오류가 없습니다. 모두 정상인 것 같습니다.
상세한 문제 해결
두 가지 관찰성 도구는 추적 및 로그와 같은 심층적인 문제 해결 용도 로 사용됩니다. 이 시나리오에서 추적은 해양 표면 온도가 있는 원격 분석 메시지가 센서에서 클라우드의 스토리지로 이동하는 방법, 호출되는 내용 및 매개 변수를 보여 줍니다. 로그는 이 프로세스 중에 각 시스템 구성 요소 내에서 발생하는 작업을 보여 줍니다. 추적 및 로그의 진정한 힘은 상관 관계가 있을 때 발휘됩니다. 이 설정을 사용하면 특정 원격 분석 메시지를 처리하는 동안 IoT 디바이스의 모듈 또는 백 엔드 함수와 같은 특정 시스템 구성 요소의 로그를 읽을 수 있습니다.
La Niña 서비스는 OpenTelemetry를 사용하여 Azure Monitor에서 추적 및 로그를 생성하고 수집합니다.
IoT Edge 모듈은 Temperature SensorFilter OTLP(OpenTelemetry Protocol)를 사용하여 로그 및 추적 데이터를 동일한 에지 디바이스에서 실행되는 OpenTelemetryCollector 모듈로 내보냅니다. 그런 다음, 모듈은 OpenTelemetryCollector 로그 및 추적을 Azure Monitor Application Insights로 내보냅니다.
Azure .NET 함수는 Azure Monitor Open Telemetry 직접 내보내기를 사용하여 Application Insights에 추적 데이터를 보냅니다. 또한 구성된 ILogger 인스턴스를 사용하여 상관 관계가 있는 로그를 Application Insights에 직접 보냅니다.
Java 백 엔드 함수는 OpenTelemetry 자동 계측 Java 에이전트를 사용하여 추적 데이터 및 상관 관계가 있는 로그를 생성하고 Application Insights 인스턴스로 내보냅니다.
기본적으로 La Niña 서비스의 디바이스에 있는 IoT Edge 모듈은 추적 데이터를 생성하도록 설정되지 않으며 로깅 수준은 로 Information깅 수준으로 설정됩니다. 추적 데이터의 양은 비율 기반 샘플러에 의해 제어됩니다. 샘플러가 지정된 활동이 추적에 포함될 확률 로 설정됩니다. 기본적으로 확률은 0입니다. 이 설정을 사용하면 필요하지 않은 경우 디바이스가 Azure Monitor에 자세한 관찰 데이터로 넘쳐나지 않습니다.
모듈의 InformationFilter 수준 로그를 분석한 후 문제의 원인을 찾기 위해 자세히 알아봐야 합니다.
Temperature Sensor 및 Filter 모듈 쌍의 속성을 업데이트하고, loggingLevel를 Debug로 늘리며, traceSampleRatio를 0에서 1로 변경합니다.
이러한 변경을 수행한 후 다음 모듈을 Temperature SensorFilter 다시 시작합니다.
몇 분 후에 추적 및 자세한 로그가 문제 디바이스에서 Azure Monitor에 도착합니다. 디바이스의 센서에서 클라우드의 스토리지로의 전체 엔드 투 엔드 메시지 흐름은 Application Insights에서 애플리케이션 맵 을 사용하여 모니터링할 수 있습니다.
이 맵에서 추적 항목의 세부사항으로 들어갈 수 있습니다. 일부 추적은 정상으로 보이고 흐름의 모든 단계를 포함하지만 일부는 짧으므로 모듈 이후에 Filter 아무 일도 발생하지 않습니다.
이러한 짧은 추적 중 하나를 분석하여 Filter 모듈에서 어떤 일이 발생했으며 메시지를 클라우드로 전달하지 않은 이유를 알아보세요.
로그는 추적과 상관 관계가 있으므로 TraceId 모듈의 이 실행 인스턴스에 대한 로그를 검색하려면 SpanId와 Filter를 지정하여 로그 쿼리할 수 있습니다.
로그에 따르면 모듈은 온도가 70.465도인 메시지를 받았습니다. 그러나 이 디바이스에 설정된 필터링 임계값은 30~70입니다. 따라서 메시지가 임계값을 통과하지 못했습니다. 이 디바이스가 잘못 설정되었습니다. 이 구성은 통합 문서를 사용하여 La Niña 서비스 성능을 모니터링하는 동안 발견된 문제의 원인입니다.
모듈 쌍의 Filter 속성을 업데이트하여 이 디바이스의 모듈 구성을 수정합니다. 다음으로 loggingLevel을 Information으로 축소하고, traceSampleRatio을 0으로 설정하십시오.
이러한 변경을 수행한 후 모듈을 다시 시작합니다. 몇 분 후에 디바이스가 Azure Monitor에 새 메트릭 값을 보고합니다. 통합 문서 차트는 다음과 같은 업데이트를 반영합니다.
문제가 있는 디바이스의 메시지 빈도가 정상으로 돌아갑니다. 구성된 관찰 간격 동안 아무 일도 발생하지 않으면 전체 SLO 값이 다시 녹색으로 바뀝니다.
샘플 사용해 보기
이 시점에서 시나리오 샘플을 Azure에 배포하여 단계를 수행하고 고유한 사용 사례를 시도할 수 있습니다.
이 솔루션을 배포하려면 다음이 필요합니다.
- PowerShell을 참조하십시오.
- Azure CLI
- 활성 구독이 있는 Azure 계정. 체험 계정 만들기
IoT Elms 리포지토리를 복제합니다.
git clone https://github.com/Azure-Samples/iotedge-logging-and-monitoring-solution.gitPowerShell 콘솔을 열고
deploy-e2e-tutorial.ps1스크립트를 실행합니다../Scripts/deploy-e2e-tutorial.ps1
다음 단계
이 문서에서는 모니터링 및 문제 해결을 위한 엔드 투 엔드 관찰 기능으로 솔루션을 설정합니다. 이러한 IoT 시스템 솔루션의 일반적인 과제는 디바이스에서 클라우드로 관찰성 데이터를 보내는 것입니다. 이 시나리오의 디바이스는 온라인 상태이고 Azure Monitor에 안정적인 연결을 가질 것으로 예상되지만 항상 그런 것은 아닙니다.
디바이스가 일반적으로 오프라인 상태이거나 클라우드의 관찰 가능성 백 엔드에 대한 연결이 제한되거나 제한된 경우 시나리오를 처리하는 권장 사항 및 기술에 대해서는 IoT Edge를 사용한 분산 추적 과 같은 후속 문서로 이동하세요.