MSactivator™ Manager Guide

This will give you access to the manager dashboard, that allows you to monitor and manage the entities configured in your MSactivator™ installation.

This dashboard represents the "Ops" part of the "DevOps" approach, see the GUI Overview for more details.

Login as an manager, you can directly start monitoring and managing your system.

Access to the developer dashboard, to design business processes, write workflows, or use visual workflows and develop microservices in the MSactivator™.

Configure your remote Git repositories to do code versioning management, share you code with your team, publish your code and contribute to the community.

This dashboard represents the "Dev" part of the "DevOps" approach, see the GUI Overview for more details.

Login as a developer, you can easily access and work on the design of your automation processes.

The swimlanes are matching the 3 layers of integration and automation: BPM, Workflows and Microservices

The term "Managed Entity" encompasses manageable entities such as network elements (routers, switches, load balancer,etc.), security elements such as firewalls, UTM, etc. but also virtual infrastructure and cloud management layers such as Openstack, AWS, VMWare or even container management platforms such as Rancher, K8,…​

Microservices can be used to manage a wide variety of services on numerous types of entities, such as network equipment, virtualization infrastructure managers, or even Linux servers.

Microservices is the abstraction layer between the specificities of the managed entities and the genericity required for a true multi-vendor management system.

Microservices will let you define your managed services in a fine-grained and modular manner and provide all the required functions to create, read, update, delete and import these services in a production environment.

The MSactivator™ configuration engine runs on PHP Smarty and allows some scripting to add logic to the generation of the configuration.

Deployment settings are the logical entities that will bind together the configurations and the managed entities.

Monitoring profiles are the logical entities that will let you define your KPI to monitor and bind these to the monitored entities.

The workflow layer addresses domain-specific scenarios which can be highly technically scripted, appealing to DevOps and SecOps engineers.

The BPM layer offers a visual workflow editor to make MSactivator™ a strong SOAR contender for business process design which appeals to realities and is not enshrined in vendor-specific boundaries. Maximum security remediation policies can be applied as engineers creatively imagine a process applied to all domains involved (security, routing, switching, cloud hosting, etc.).

The 10 terms that define the tree of the MSactivator™ navigation:

This graph is very convenient, as it represents a lot of data in a small area. Firstly, it is made up of three concentric circles: - The outer circle represents physical entities. - The middle circle represents public entities. - The inner circle represents private entities.

To further illustrate this, a legend is provided on the dashboard to explain each circle purpose:

Finally, the number in the center of the circles is the total number of managed entities associated with that customer. If you click on any of those status graphs, you then see a pop-up table containing the same details but in a matrix like so:

On the administrator dashboard, there are a number of filter, sort, and search options available to help you organize and view your data.

By default the manager dashboard displays the status of the managed entities and the workflow instance but this view can be customized to let you decide the important data that you want to display.

To customize your dashboard, click on the cog icon on the top right of the dashboard. This will open a screen where you can control the settings of your dashboard.

Use the opacity slider to see the result of your changes through the setting screen.

You can add as many component as you need, each component will be added one after the other, on the same line if there is enough space or on the line below.

The custom layout will be persisted and available for the user on any device he uses to connect (browser, tablet, phone,…​).

To see the list of managed entities, click on the "Integration" link in the left menu

On that screen, you can use the list view toggle button to switch to a compacted view of the managed entities list. You can also adjust the amount of entities displayed on each page

Finally, on this screen you can also perform a simple search of the managed entity you are looking for by its name.

To see the list of microservices, click on the link "Infrastructure" in the left menu.

You can view the list of deployment settings by clicking on the tab "Deployment Settings".

This screen will let you build your deployment settings by selecting microservice .

You will also be able to select the Managed Entities you wish to apply you configuration service on.

To see the list of workflows select the "Automation" link in the left menu.

By default, if you are connected as a manager or an administrator you will see the list of Workflows that are associated to the subtenant you are managing

If you select a subtenant, the list will be filtered by the selected subtenant’s workflows and you will see the process execution status of the workflow instances.

To see the workflow instance for a subtenant, you can click on the Workflow name

From this screen you can start using the existing instances or create a new instance for the current Workflow.

To see the list of Business Processes select the "Automation" link in the left menu

You can select a BPM by clicking on a name in the list and start working on your BPM.

This is where you can develop new workflows for your application. In MSactivator™, workflows can be written in either PHP or Python. A workflow is a series of tasks that you can develop to carry out any set of complex tasks that you wish to automate via our orchestration engine.

This is where you can develop new microservices for your application. In MSactivator™, a microservice is a way to wrap commands (Create/Read/Update/Delete/Import) into a service, that can be invoked with a workflow or even from outside MSactivator™ via our REST API.

The microservices are typically used for managing the configuration of managed entities in an abstracted, vendor-neutral way.

This is where you can develop new adaptors for your application, or import existing ones. The adaptors are used to connect to managed entities from MSactivator™, regardless of the network protocols supported by the entity in question. If an adaptor is not already available for your entity vendor in the library, a new one can be developed.

On the developer Dashboard, in the "Settings" menu, you can configure your remote repository where your library code is versioned.

Select the "Tenants" section in the "Admin" menu and click on the "+ Create Tenant" button to create a new tenant.

The "Tenant Prefix" is a three letters, unique identifier for the tenant. It will be combined with the subtenant or the managed database identifier to build a short, comprehensive, unique identifier that you can use to filter application logs when troubleshooting or when you need to communicate with the support team.

Select the "Subtenants" section in the "Admin" menu and click on the "+ Create Subtenant" button to create a new subtenant.

Carefully select the tenant where the subtenant will be created as moving a subtenant to another tenant is not possible without database update.

Save the customer form and navigate to the new subtenant tenant (click on the subtenant name in the customer list).

ncroot is the only predefined user within the MSactivator™. It’s the user with the highest level of privilege.

In addition to the action available to the other users with lower privileges, ncroot can create the tenants, upload and activate the MSactivator™ product licenses, create administrator users.

Administrator users can only be managed by ncroot.

Administrators are associated with one or more tenants and have full access rights over these tenants.

A typical administrator job is to create the managers and privileged manager as well as the subtenant within its tenants.

Privileged managers are restricted to a single tenant.

Within their tenant, privileged managers have full access rights and can perform tasks such as subtenant management, device management, user and rights management.

Managers are restricted to a single tenant and, within this tenant, to a subset of subtenants.

By default, the managers have restricted, read-only access to the subtenant.

A manager may be used to provide self-care access to the MSactivator™ portal.

These are the fields available when creating a managed entity. Some are mandatory and this is made explicit by the * on the web form.

The information such as the serial number, firmware, memory …​ are retrieved dynamically by the adapter once the entity is activated.

By default there are 3 graphs that are displayed in the monitoring section of the overview screen:

In order to import the configuration from the actual managed entity into the MSactivator™ configuration database, you need to click on the link "Synchronize with Managed Entity".

This will call the CoreEngine and run the Import of each of the microservice.

The Import function may not always be implemented (this depends on the design of the microservice), therefore, the CoreEngine will simply skip these microservices.

Once the synchronization is done, the console will display the microservice instance, one by line, for each microservice.

In order to ensure that the configuration stored in the database is exactly reflecting the actual configuration of the managed entity, the microservice instances, specific to the current managed entity, are deleted from the database before the actual import can start.

You can create a new microservice instance by selecting a microservice on the left menu and clicking "+ Add Row" and providing the input parameters to configure.

The input parameters are defined in the microservice "Variable" section.

To update or delete a microservice instance, you need to select the row and click on "Edit" or "Remove".

Once you have updated your microservice, you can either click on "Discard Changes" or "Apply Changes".

"Discard Changes" will remove all the orders that where stacked and stored in memory.

"Apply Changes" will unstack all the orders and pass all the orders that were stacked to the CoreEngine configuration daemon. The configuration daemon will process the order, build the configuration and apply it to the managed entity.

You can configure and monitor your KPI with the monitoring profiles.

A monitoring profiles is a way to configure a set of SNMP based KPI, to configure threshold crossing based alarms and build graphs to display the KPI.

A monitoring profile has to be associated to one or more managed entity(ies) and a managed entity can also be associated to several monitoring profile(s).

You can create a monitoring profile by browsing to the "Infrastructure" menu and selecting the tab "Monitoring Profiles" and clicking "+ Create Monitoring profile".

A monitoring profile is made out of 2 parts: the SNMP polling and the graphical rendering. Although SNMP polling is mandatory to have the MSactivator™ poll for the KPI, the graphical rendering is optional.

By default the MSactivator™ will be using SNMP v2.

Starting with MSactivator™ v2.8.3 SNMPv3 is also supported.

In order to use SNMPv3 to monitor a managed entity you need to configure its variables with the SNMPv3 parameters.

For the polling, the mandatory variables are snmpv3_securityName, snmpv3_securityLevel, the others depends of snmpv3_securityLevel value, see below.

For receiving SNMP trap, the mandatory variables are snmpv3_securityName, snmpv3_securityLevel, snmpv3_securityEngineID, the others depends of snmpv3_securityLevel value, see below.

You also need to enable "SNMP Monitoring", use the SNMPv3 user for the community field.

The parameter values should match the SNMPv3 configuration that was set in your actual device.

For instance on a Linux Centos7:

To verify that SNMP v3 monitoring is working properly you can check that the sysuptime graph is plotting data.

You can also monitor specific KPI based on the OID of your vendor.

The MSactivator™ can collect, index and store events received from the managed entities. Once indexed, the logs are fully searchable from the user interface.

The diagram below shows the syslog processing steps from the device to Elasticsearch.

To view and search the logs you can either access the global log and alarm view by clicking on the bell icon at the screen top right or by browsing to a specific managed entity and selecting the tab "Logs"

You can use the workflow "Deploy Dashboard" to deploy the dashboards packaged in the MSactivator™.

Use the Kibana URL from the workflow instance to browse to the Kibana dashboard

The alarm management module is based on the detection of events which internal (VNOC), SNMP thresholds, or sylogs sent by the managed devices and collected by the MSactivator™. Alarm management is designed to provide email notifications to customers or managers or administrator

The detection of events relies on rules configured at the super administrator level.

Rule management is available for the super administrator (ncroot). The rules are defined globally and can be modified by the operation team.

The infrastructure management team can modify the setting of the notifications on a per-event and/or per-subtenant basis. The rules are executed on a periodic basis (the period frequency can be configured) and alarms are generated whenever a rule matches.

The Alarm management screen is available by clicking on the bell icon on the top right of the screen.

Alarm Rule can be created from the Manage Alarms tab, as show in the below screen shot. Alarm Name should be Unique across the MSactivator™ and it should not contain space.

Alarm creation contains Four sections below

As soon as an event is detected to be an alarm, a notification badge will appear at the top right of the screen showing the number of new alarm that require an user action (acknowledgement)

You have the possibility to edit an alarm, add a comment and acknowledge the alarm.

You can test the triggering of a process execution with the simple workflow "Security Event Detection" included in the mini-lab.

This workflow will execute a process to display the raw log that cause the alarm.

To trigger an event you can, for instance, stop one of the Linux container which will raise a IPDOWN event.

A new instance of the workflow should be created

For alarms to be notified as email, we need the Docker host to be properly configured as a SMTP server or relay.

An alarm severity can be tuned by choosing the severity of the alarm when editing the alarm rule.

By default the alarm severity is the same as the severity of the source event but by selecting the severity, you can decide that an event with a high severity level should raise an alarm with a low severity level (or the other way around).

Example: it is possible to have an alarm rule to detect the VNOC event IPDOWN and configure the rule to have the highest level (Emergency) and an other alarm rule to detect the event IPUP with a lower severity (Informational)

This is very useful if SNMP traps are configured to be sent as you may not want to have all the SNMP traps detected with the same severity level.

With version 2.8.0, it is possible to execute bulk operations on the microservices.

Bulk operations allow you to select multiple instance to delete or update or create multiple instances.

Microservice bulk operation usually requires that some variables are configured to allow "Primary Composite Key". This is done by setting the parameter "Primary Composite Key" to true in the advanced parameter tab of the variable.

On the topology view you can right-click on a managed entity icon and add categories to the managed entity.

This is useful to organize your infrastructure elements.

Use the "Filter By" action to filter your topology view and only display the elements you are interested in.

If you right-click anyway on the topology canvas, a contextual menu will pop-up and from there you have the possibility to trigger the execution of a workflow or a BPM.

This is a useful shortcut when you need to run some automated processes based a visual display of your infrastructure.

The L3 SNMP mode relies on SNMP request to the managed entities to build the topology graph.

The VLAN mode provides a layer 2 view of your infrastructure.

To generate this view you need first to create a new instance of the topology workflow and select "VLAN" for the topology type. Once this is done you will see the layer 2 topology in the topology screen of the infrastructure.

When you load or refresh the topology, the topology workflow will either create a new instance or update the last one that was created. It will loop through each managed entity of the subtenant and import the vlan information based on the microservice implementation of the IMPORT function.

For example, with a linux based switch, the regex :\svlan_(?<object_id>\w+):\s\S+\s\S+\s\S+\s+\S+\s\S+\s\S+\s(?<state>\w+) will be applied to the result of the CLI command ip a:

and the result of the import will be 3 vlans, 100, 200 and default.

For non-linux managed entities the process to export the vlan information will be different but a similar result will be stored in the database and used by the workflow to build the data structure to represent the topology.

The code to build the topology node information will resemble to

The topology workflow is located under /opt/fmc_repository/OpenMSA_WF/ in the container msa_dev, it’s a git repository so you also need to make sure that it is up to date with git status and update your local repository with git pull origin master to get the latest updates.

Under /opt/fmc_repository/Process, there is a symlink to the git repo: Topology → ../OpenMSA_WF/Topology

You can add your own remote to your fork of the openmsa repository or work with the default one. Either way, you need to create a working branch that you will use later to initiate a pull request.

With the MSactivator™, edit the topology workflow, edit the variable view_type and, in the "Advanced" section add my_topology to the values for the drop-down list.

Save the workflow and use git status to see your change

you can add and commit these files.

Go to /opt/fmc_repository/OpenMSA_WF/Topology/Topology_Types

You can reuse any of these files to create your own script, we will use Template.php which is an "empty" implementation.

Add a new commit for this initial file

Now you are ready to start implementing and testing your new topology.

On the workflow screen, create a new instance with your new topology view. At that point the implementation will be specific to your use case.

Whenever you create a new instance of the process, a dedicated log file is created in the API container, under /opt/jboss/wildfly/standalone/log/process-<INSTANCE_ID>.log. The workflow instance ID (39 in the screenshot below) is the one displayed at the top left corner of each instance.

You can monitor the log for debugging purpose: docker-compose exec msa-api tail -F /opt/jboss/wildfly/standalone/log/process-39.log (where 39 is the workflow instance ID

Use the custom functions logToFile and debug_dump to output your debugging information in the log file.

With the code provided in Template.php you will get topology similar to this, without any links.

Use the action on the top right to create a new instance of the workflow, select the actions available on an instance to call the processes available for this workflow.

The list of workflow instances can be filtered by the status of the execution of their processes:

The status of a process and how a process can end with one of the possible statuses is defined by the process, in the tasks.

For each instance, a toolbar is available when you hover your mouse over it.

Each icon will give you some information about the instance:

The history will let you audit the process past executions and access all their the details.

The BPM engine will start executing the BPM tasks one by one and the status of the current workflow process execution will be updated live in the view "LATEST EXECUTION RESULT".

Click "Show Tasks" to see the detail of the process execution.

With the execution breakpoints the execution of a BPM can be paused until the user manually resume the execution

It can be used to execute complex BPM with several part and allow for manual validation of each intermediate steps.

When a BPM execution is paused, the instance will be listed with an empty execution end date.

The execution of a BPM can be cancelled any time by clicking on the "Terminate BPM" button at the top right of a BPM execution screen.

The execution of a BPM can be scheduled to run once at a predetermined date or in a recurring way for a predefined duration. The list of scheduled executions is available and any scheduled execution can be canceled