As we continue to improve our network management system, we identified some ways to improve our MonitoringAgent application.
The MonitoringAgent performs a simple but important task in the FileCatalyst product family: tracking product alarms. The MonitoringAgent says, “Tell me the state of my FileCatalyst products (also referred to as agents), and let me know what is going wrong.”
MonitoringAgent Communication Improvements In 2.8
The first improvement we made for v2.8 of FileCatalyst Direct was flipping the direction of the MonitoringAgent communication protocol. Since its original release in v2.5, it was the responsibility of the MonitoringAgent to know where each product on the network was installed. Everything from product discovery to communication was made from the center and extended outwards. While offering a simple design from a software engineering viewpoint, we ran into issues with this in deployment scenario.
Every product (primarily FileCatalyst Servers and HotFolders) had to open up an additional listener port to handle management commands from the MonitoringAgent. If you are working on an internal LAN, this doesn’t present much of an issue. However, across a WAN and under real customer environments, the need to open up multiple ports meant too much work for our clients: dealing with reluctant system & network administrators, playing around with corporate firewalls, NAT port forwarding, and a few other issues. This gets compounded the larger the deployment, especially with regard to HotFolders which normally do not require open socket listeners. 100 clients need to send you data? That’s potentially 100 clients who have to mess around with port settings.
By switching the protocol around, only the MonitoringAgent needs to open up a socket listener port. Services are instead required to “dial in” to a central MonitoringAgent; HotFolders go back to not having open server ports.
Reversing the protocol also presents the option of auto-provisioning new products on the network: new products simply need to connect into the MonitoringAgent, and alarms/status can be immediately routed.
Additional MonitoringAgent tweaks:
Since the MonitoringAgent doesn’t present a GUI to users, Remote Server Admin was enhanced to serve as a configuration console for the MonitoringAgent. Views are now available to list all currently managed products on the network, in addition to being able to set configuration options formerly available only in a text-base configuration file.
Scalability was also addressed in the MonitoringAgent. The old logic responsible for agent polling was updated to allowing multiple services to be polled concurrently rather than a sequential walk-through of products. This allows not only more products to be managed, but also dramatically reduces the time required between polling cycles. The result is a refresh that feels much more natural when scanning for alarms via the GUI.
There you have it! If you’re already using MonitoringAgent, we hope you’ll benefit from the recent changes. If you’re not using it or were previously unaware of the MonitoringAgent, your representative would be happy to provide further information.