In The Spotlight: Data from the device to the database.
The Edge. The border, boundary, or transition point of your data. Data precariously hanging just outside your DCIM monitoring solution with a slew of diverse inputs.
In previous blogs, we covered the importance of how you bring this data in from the wild – utilizing industry standards augmented with normalization to achieve a resilient and standard format. How does that data get from this process and into the system? For OpenData, this is beautifully simple. At the collector, the data is encapsulated into discrete packages, encrypted, and sent upstream to the core application. From there, it is unwrapped and stored in the database. This sets off a series of additional events like data aggregation, but we will cover that another day.
How is this different from any other data journey? The route is always outgoing from the collector. The collector instigates an outgoing connection to the core application. This means the collector can live behind a firewall, collecting device data at a remote location, wrapping it up and securing it, and sending it on its way – without opening security holes. A single outgoing connection is needed (port 4803 by default, but that can be changed). If you have multiple remote locations, you do not need to add incoming exceptions to each firewall to collect data from remote devices. Place a collector instance at each site to get the site device data and report it upstream using an outgoing connection (if you don’t run VPN across all sites)
If you do subnet monitoring within the site (You are doing that for security, right?), this can simplify your model for how monitored data gets across your network. And of course, troubleshooting device traffic is much easier when the collector is local to the device and data does not span multiple routers, switches, and a VPN.
Responsiveness is critical in DCIM. To that end, alarms, while fully visible within the core application, are defined at the collector level. This means that when the collector gets data for a device, it can determine if the data meets an alarm condition immediately. For example, if the load on a UPS exceeds a limit or a temperature sensor crosses a threshold – the collector does not wait for the next data transmission. Instead, the collector immediately sends the alarm state and data upstream so that OpenData can rapidly respond to the alarm in dashboards, EPMS displays, and trigger active notification and escalation.
The Edge can be irregular, unpredictable, and challenging. As a result, responsiveness hinges not only on how well data is handled in this environment but also on the journey it takes to arrive in your system.
We can help you manage and master your Edge Data Center. Reach out to us at sales@modius.com to let us show you how to live on the Edge with authority!
