Defining the Roadmap is a fundamental part of our strategic approach. It involves gathering proposals, prioritizing ideas, and setting objectives as the starting point for the cycle of development and continuous improvement of WOCU-Monitoring.
Our commitment includes constant interaction with our clients and users to work towards a common goal: making WOCU-Monitoring the trusted, flexible, and unparalleled all-in-one tool for immediate and unforeseen network problem resolution.
1. Expand Monitoring Catalog
Cloud Monitoring: Load, bottlenecks, availability, and performance.
Public clouds (Amazon, Azure, Google Cloud, Oracle, etc.), private, or hybrid.
Container monitoring and their orchestration systems (OpenShift, Docker, Kubernetes, etc.)
2. Passive Monitoring based on volatile services
Enhance the efficiency of passive monitoring in WOCU-Monitoring, as a new paradigm for monitoring in Cloud, IoT, etc., environments.
Necessary also to improve classical monitoring of receiving traps, syslog events, and applications.
We intend to implement a specific module for SNMP traps and another for events from IDSs (Snort/bleeding-edge/Suricata).
3. Complex Architectures with Shinken
Now that Shinken is already integrated as a part of WOCU-Monitoring, we want to continue working on certain complex architectures not yet supported at the base level.
These architectures include the so-called Multi-broker (capable of scaling the broker daemon and having multiple ones for the same instance of Shinken) and Single-arbiter (capable of having the configuration of several monitoring realms managed by a single Import-tool and a single arbiter daemon of Shinken).
Also, the possibility of implementing federation in LMD to further abstract the Multi-realms layer.
4. Infrastructure Dashboard (map) of WOCU-Monitoring
Given the increasing complexity of WOCU-Monitoring architectures, there was a need to visualize the deployed infrastructure map, down to the detail of the executed services and their status. We’re talking about visualizing the volume of Realms, their architecture, installed packs, executed processes, etc. To achieve this, specific endpoints need to be implemented, which will then be consumed either by custom panels or by external tools like Grafana.
5. Efficiency in SNMP queries (SNMP Booster)
It’s no secret that the most used protocol for device monitoring is SNMP. In fact, the vast majority of developed packs use this protocol. Calling these binaries from a Monitoring Pack incurs an overhead. Not only do we have to invoke the script interpreter used (usually Python), but it also has to make a system call to execute the binary, wait for its response, and pipe the result back into the script.
We intend to modify the core library of WOCU-Monitoring so that queries don’t leave the Python script scope using extensions or bindings written in C, which are much closer to the machine language than Python. Tests have already been performed on specific packs, and the performance improvement is more than notable. We must make it the default and transparent option for the execution of SNMP queries by any developed pack supported by WOCU-Monitoring.
6. Deployments of WOCU-Monitoring in the cloud
Just as delving into cloud monitoring is interesting, it’s equally important to adapt to new deployment methods to provide monitoring services from our own cloud or the client’s.
This involves adapting the software and architecture to be served in containers and allowing some elasticity based on the resources used or connectivity needs. Additionally, many clients don’t require a full installation of WOCU-Monitoring on their premises but opt for the installation of agents that communicate with the contracted service. In this regard, work must also be done to support WOCU-Monitoring on architectures other than Intel to install on cheap machines like Raspberry Pi (ARM architecture). Complementarily, we need to work on the high availability of all WOCU-Monitoring components, including the monitoring console (aggregator).
7. Device Configuration Management (backups)
Platform for network automations, mainly configuration backup management, manufacturer-agnostic, and with a REST API for integrations.
Professionalize development for deployment in product environments.
Continuous support for new manufacturers. Options: Gesconf, eNMS, Solarwinds.
It would also be very positive to implement network topology discovery and its graphical representation.
8. Complete Modeling of the Configuration Module
Adding devices to be monitored by WOCU-Monitoring can be done in different ways, the main one being through Import Tasks. It’s also possible to graphically edit these assets to modify their attributes, assign packs, contacts to notify, etc. But there are certain finer configurations that currently can only be done from an administration panel outside the main interface or even by editing configuration files.
With this year’s main objective being to allow the tool to be installed and managed by other channels with less knowledge of the tool, efforts must be made to integrate possible configurations (device groups, macros, notification periods, etc.) within the main interface.
9. Support for IPv6 Device Monitoring
Although the adoption of IPv6 as the standard for device identification in the network is slow, the lack of IPv4 addresses and the improvements that this new protocol brings in terms of security and auto-configuration suggest an acceleration in the coming years.
As a monitoring tool that focuses on IP device supervision, we cannot lag behind and must begin to support this protocol. The proposal is to modify the basic query libraries of WOCU-Monitoring such as SNMP and the most used Monitoring Packs in a first phase, to later modify the Shinken core and be able to perform checks against these IP addresses. Subsequent phases are beyond the scope of this Roadmap but will include the installation of WOCU-Monitoring itself using IPv6 addresses.
10. Advanced Inventory Management and Cross-Referencing with Vulnerabilities
Equip WOCU-Monitoring with greater capabilities to manage an inventory based on installed applications with their corresponding versions, to cross-reference that information with known vulnerable applications and generate alerts accordingly. This functionality may include the installation of agents on operating systems, and the development of specific Monitoring Packs or Security Reports.
