A Logging Stack for the Internet of Things
LogDNA sponsored this post.
As with any production system, logs from Internet of Things (IoT) systems are crucial to optimization, debugging, forensics, and other critical tasks for keeping those systems up and running without impacting users. Log data drives every aspect of the observability stack and many (if not all) alerting, monitoring, and metrics functions. Let’s explore the specific needs and solutions for an IoT logging stack.
What Is IoT?
We all hear the buzzword (buzz-initialism?) IoT thrown around in modern tech conferences and blogs. But what is it and why is it important? The Internet of Things is a catchall term for interconnected networks of small computing devices that share data seamlessly. Often, these devices aren’t full-fledged systems with full-size processors, onboard memory, motherboards, and connected hard disks. Rather, they’re commonly smaller systems with a different processing system. For example, you might be using microcontrollers — which are integrated circuits that have a processor and onboard memory where you can use the pins purely for input and output. Examples of microcontrollers are the Arduino Uno or a Flora.
For most do-it-yourself IoT projects, you are more likely to work with System on a Chip (SoC) architectures. These systems utilize a single chip that combines the CPU, the onboard memory, and all other peripherals that do not need a motherboard to function. The most common example of SoC is the well-known Raspberry Pi.
While IoT has been a hobbyist’s playground for a while, there are quite a few companies working in the space, and the industry as a whole has taken off and grown exponentially. From smart TVs to wearable devices, IoT is prevalent and here to stay. However, there are some concerns about IoT networks that we all need to address.
Security
The privacy and security of data flowing through an IoT network is probably the most important concern that people have about IoT, and there’s a lot of information out there on what these issues are. First, firmware updates are necessary to ensure that IoT devices are secure. However, rolling out firmware updates and ensuring that they get applied consistently is difficult. Second, too many consumer networks are not secure enough. Most consumer modems and routers sacrifice strong security for ease of use. Third, a lot of IoT devices are sending unencrypted data over less-than-secure connections, from networks run on those insecure modems to Bluetooth broadcast over a wide area or NFC broadcast over a small area. Finally, the sheer amount of personal data that these devices generate is both impressive and worrying when taking into account the prior concerns.
Distributed Systems and Connectivity
By definition, IoT systems are distributed, networked systems. Whether they are connected to the Internet or only to other devices that are part of that specific IoT system, devices rely on connectivity to function as expected. The concerns around any distributed system apply, from handling asynchronous communication and concurrency errors, to the possibility of single-device failures affecting the entire network. Connectivity for some of these devices can also be spotty, such as when a consumer takes a smartwatch out on a run without their phone at hand. While the data can be reconciled later when the device reconnects to a network, there can still be errors in the data or the device’s memory may get too full before it can reconnect, causing data loss. While these issues may seem small, they get a lot more worrying when you consider that some of these use cases may include data people rely on – from heart rate to detect abnormalities, to sensors that detect the road ahead in a smart car.
How Does Logging in IoT Work, and Why Is It so Important?
Since IoT is all about gathering and transmitting data, it stands to reason that logging is just as crucial to the overall space.
Typical Logs
Just like with a server, the devices that make up an IoT system generate logs. From a hardware perspective, the states of the onboard memory, the microcontroller, and any sensors are all described by logs. That data can tell you anything from whether the system is functioning as expected, to whether your next update needs to trim down memory usage to avoid overwhelming the onboard memory. From a software perspective, the microcontroller logs details about how data flows through the application. Then you have network logs. Knowing how the data flows in and out of the device is crucial for something as interconnected as IoT systems.
Log Location
The biggest part of logging in IoT is understanding where to store the generated data. Unlike servers, the devices do not have enough onboard memory to store logs for any useful period of time. In addition, the log data itself is sometimes part of the use of the device, as the analyzed data may be used in providing further services to customers with the device itself. That analysis is often done in centralized data centers rather than on the edge at that device. Finally, since IoT systems are by definition distributed, the aggregated data from multiple devices is necessary for troubleshooting issues with the overall system.
As a result, a centralized log management system is key to working with and understanding IoT systems from an operational perspective. While logs can be stored on the device itself for a short period of time, those logs are of no use to the developer, operations engineer, or security engineer while they are inaccessible or isolated.
Use Case Example
Imagine you are a DevOps engineer responsible for a small IoT network of smartwatches. An automated rollout of a firmware update catches your attention as you start getting reports of customers’ watches not getting past a loading screen while the first batch of updates rolls out. The first place you would normally turn to for information is your logs. Your team had decided to store logs on each device, sending back batches to the central server once a day. Unfortunately, because the devices are stuck when they attempt to update, the devices cannot connect to a network to upload those logs from those updates. You will have to manually work backward through customer reports, testing data, and other information to discover what, exactly, bricked the devices. You shut down the update and begin the process of trying to understand what happened, all while another team is upset that a feature isn’t available, or security is upset that customer data is still vulnerable to a recently released vulnerability that the update was to solve.
Rewind that scenario. Now you have a centralized log management system and a requirement that devices are connected to the Internet when they are updating. You start getting reports of the first devices stuck on the loading screen, and you are able to dig into the logs on those devices while you pause the rollout. You discover that a recent change to the automated firmware update process accidentally skips a step, and a quick patch of that system sends the completed update out to the first batch. You can see immediately that the update works, and you are able to continue the rollout with minimal fuss.
In Conclusion
Now, we might be a bit biased considering we’re a centralized log management provider. However, IoT systems really do better with some sort of centralized location for logs, whether you use the data for typical basic debugging, postmortem forensics, security auditing, network tracing, or data analytics for end users. Most IoT devices do not have the computing power to drive analysis at the edge, and even if they do, you lose out on the deeper analytics that come from having multiple devices dumping logs to one location. Logs are a crucial part of successful IoT systems, and having a concrete plan on how to store and use those logs is the difference between true success and failure.
If you’d like to learn more about how LogDNA thinks about IoT and logging register for our upcoming webinar on May 6, at 11:00 am PT.
Feature image via Pixabay.