Create meaningful metadata to enrich customer device information delivered as a micro-service. Expose out this new metadata and allow consumption through exiting and new applications. The combination of the business importance and technical role of the device gives us a better understanding of the device's Place in Network.
Evaluate running features on customer equipment and weight the importance of devices based on running features. An SME walk of global feature data to determine "important" features was performed. Feature information is fed from Mimir for all devices for a company key. Devices are then weighted and ranked based on their operating system type and significant features. Categories of "low", "medium", "high", and "critical" are used to equate importance to the device. This information is available via a RESTful API.
Create on-the-fly supervised Random Forest models from extracted configurations. Categorize devices based on user specified roles from configuration and feature information by predicting against the training data. A RESTful API exposes the categorization predictions for devices and company keys.
NCEs help train data models with supervised learning. By aligning devices with a particular role type, we can build a profile of configuration factors and ratios that are common across devices. We use a 80/20 split to build the model and then test the devices excluded from the training data to determine their role. The output of the model is delivered with a CSV file of prediction and feature extraction information, histogram of device classification, feature importance breakdown, clustering visualizations of roles, and a decision tree breakdown of how the algorithm determined which feature correlated to particular roles. When running an individual model, information for the customer is stored in the Role in Network API and can be then consumed from other applications and tools.Feature Extraction
A "design intent" approach was used to develop an algorithm that looks at the configured state of a device to profile the functional role. By using how the device was configured, not only can we determine with features are in use by the device, but also the responsibility of the device. The algorithm defines service and configuration boundaries of devices and helps us cluster elements and features into role categories.
The Profile of the device is built off the following characteristics:
A single device's role can be predicted using the global model, or an industry specific model. A breakdown of classification results based on all role types contained in the model are displayed. This data is only displayed on-screen and is not saved to the Role in Network API.Predicting all Devices for a Customer
Applying the prediction to all devices for a customer works in a similar fashion. The engineer can select to use the global model, or an industry specific model. After the model has run, a classification report is generated, along with a CSV file of predictions and features, feature importance breakdown, and role classification histogram. By default, this data is not stored automatically in the Role in Network API. The engineer can validate that the classification of devices is good, and can click the publish link to save the results to the API.Publishing results to the Role in Network API
This option is abstracted from the training and running phase to allow an engineer to test a customer against multiple models before storing information in the API. Upon validation that the classification was successful, clicking the publish link will remove any previous entries for a customer and replace the data with the predicted classification results.
How am I Spending My Time?
Configuration changes are associated with topics for aggregation. Configuration terms that are seen frequently together will gravitate towards the same topic. We can use this topic information to associate configuration snippets with other common configuration items and categorize the function of the bundle of configuration changes.
How am I Spending My Time? - Named Topics
Using the "Topic Mapper", we can associate keyword bundles discovered from the configuration topics and associate our own topic name. This is useful for trending configuration bundles that are frequently seen together, and categorizing the changes as a particular function or task.
What is a Topic? - Topic Keywords
Topics are derived from the frequency of terms showing up in a configuration snippet. The collection of these terms often associated with each other creates the topic. Some terms are more descriptive of the topic, and are assigned a higher "weight". This chart and table displays how particulary important a term was in defining the topic.
Recent Changes - Device Drilldown
These tables provide the last known change information detected in the environment, and devices that have changes over the selected time period. The graph link provides a relation overlay of the configurtation items that were removed (red) or added (green) and the parent objects to which the changes were seen. The DeviceId link will navigate to a deep dive for the device, where you can view the individual changes that were seen for the device and a frequency indicator of how rare the terms in the config snippets are when compared to the entire change database.