Get a bundle of support files from your Azure IoT Edge for remote diagnostics

Azure IoT Edge makes it possible to run extensive logic within your factory, building, vehicle, etc. while it’s connected to the cloud.

This way, we can monitor the underlying sensors and protocols and measure what’s happening on the Edge. We are even capable of making predictions, both on the Edge and in the Cloud, of what is going to happen based on the current measurements and the data received over the last second, minute, hour, etc.

On a meta-level, Azure IoT Edge also comes with features for monitoring the edge device itself. Think about monitoring metrics and logging.

These features are mostly centralized around the edge modules and runtime. Due to the edge logic being sand-boxed, this is fine.

Still, we want to be able to go beyond the logic we deployed.

It would be nice if we would be able to break out of that sandbox and get some information about the Docker/Moby environment, IoT Edge runtime daemon, network, etc.:

This is actually offered!

Azure IoT Edge offers a so-called ‘support bundle’.

It is just a bundle of files with eg. logs, taken from various sources on the edge device and it is made available so you can support your edge device.

It contains:

• Module logs
• IoT Edge security manager logs
• Container engine logs
• ‘iotedge check‘ JSON output
• Other useful debug information

It’s even possible to retrieve these files ‘over-the-air’. This makes remote diagnostics possible for all your Azure IoT Edge devices!

Let’s take a closer look at this.

Azure IoT DeviceClient SDK demonstration, the basics

The cloud gateway of Azure IoT offers multiple protocols to connect to:

• MQTT
• AMQP
• HTTPS

Programming all D2C and C2D communication yourself is pretty hard. Microsoft has made it easy to communicate by providing SDKs, both for device communication and IoT Hub manipulation.

In this blog, we dive into what is offered by the Device SDKs.

Towards zero-touch IoT Edge with edgeAgent direct methods

Update: 27-9-2021 The method GetLogs is now called GetModuleLogs. It’s not experimental anymore.

The holy grail of IoT Edge compute is zero-touch configuration and monitoring.

If we look at the life cycle of an edge device, these are the phases where the device is rolled out to production:

The only time when we want to have a person near that edge device is during the initial deployment (Plan, Register), during decommission (Retire) and during physical changes or while repairing the device.

To make zero-touch possible we first need to have a secure cloud connection that supports both sending telemetry to the cloud and retrieving commands from the cloud. And that is supported by Azure IoT Edge by default.

But still, we also need a second communication channel to log-in remotely in a secure way. This is typically done by hand to look at local settings, to check logging, to check connections, or to make repairs to eg. the operating system or the Azure IoT Edge runtime. This could be done using SSH and/or a Remore Desktop connection (RDP). Because this is typically an outbound connection, this is usually provided using a ‘jump box’ or a VPN connection so the connection is set up in a more secure way.

As said, this is done by hand… so far for zero-touch.

Now, if we look at what tasks are performed on the IoT Edge device using an SSH connection:

• Checking the log of running modules
• Restarting modules if their performance is not thusted or to force picking up settings
• Checking the cloud connectivity

What if exactly these three tasks could be performed from the cloud? What if these task could automated?

Let’s check this out.

Inter-module messaging without IoT Edge routing

Azure IoT supports cloud-to-device messaging with Direct Methods. This is an important tool when you want to control your devices real-time or if you want to execute logic on the device real-time.

In the past I have written about Direct Methods a couple of times. like this blog. I then wrote about IoT Edge supporting Direct Methods too. To be more specific, Modules in an IoT Edge support Direct Methods.

But my colleague Heindirk pointed me at a little gem unknown to me.

The same logic used to communicate from Azure cloud to a module can also be used to communicate from one module to another module without IoT Edge routes!

This makes several new IoT strategies possible!

Let’s check out this gem.

Direct methods support in the IoT Hub Connected Service

The Visual Studio 2017 Connected Service for Azure IoT Hub has received an update a couple of months ago.

This update had some visual updates and now supports a Singleton pattern for the Device client too.

But it also included support for both Device twins and  Direct Methods. The latter feature looks a lot like the Commands method but there are some fundamental changes.

Yes, both solutions (Command and Direct Method) can execute code on a remote IoT Hub client. But the remote method just passes a message to the client. The Direct method can pass a message in a certain context. It calls a specific method (a client can have multiple methods registered) and passes the JSON parameter.

If you execute a Command, it feels like fire-and-forget. There is no descriptive response. But the caller of a Direct Method can wait until a response is accepted and a JSON value is returned.

Let’s check out Direct Methods.