Connector for SolarWinds
This section of the documentation contains technical specifications about the connector that is implemented to link vFire Core and the SolarWinds systems listed below, including:
- The name of the .NET assembly file
- Connection methodology
- The resource and link types that can be discovered on the application
- The attributes of each resource and link types that can be imported into the vFire Core Configuration Management Database (CMDB)
SolarWinds Systems
- Server & Application Monitor
- Virtualization Manager
- Network Performance Monitor
For compatibility and version support details, refer to the vFire Connector Matrix.
Use Case Scenario
|
Purpose |
An organization uses SolarWinds to discover and maintain resources present in its organization networks. SolarWinds is also used to raise alerts about adverse events that occur on the supervised networks. |
|
Role |
The role of this connector is to expose the resources and their relationships in order to allow for population and ongoing consistency checks of the vFire Core CMDB. The connector also possesses an Event Management capability which allows for SolarWinds alerts to be integrated as calls or requests. |
Connector Description
The table below provides a description of the SolarWinds connector.
|
Information fields |
Name |
|---|---|
|
Connector |
SolarWinds -> vFire Core |
|
Third-party application |
SolarWinds |
|
Assembly |
Alemba.Connector.SolarWinds.Connector.dll |
|
Connector class |
Alemba.Connector.SolarWinds.Connector |
|
Configuration file |
Alemba.Connector.SolarWinds.icnf |
|
Connection methodology |
API |
Connection Parameters
The table below provides a description of the SolarWinds connection parameters.
|
Parameters |
Description |
|---|---|
|
URL |
URL of the SolarWinds JSON. Either the IP address or server name is acceptable.
|
|
Login ID |
Login ID for the server where SolarWinds is installed |
|
Password |
Password for that Login ID |
Customization
This connector permits extensions to the schema through customization of the configuration file. The possible customizations are listed below. However, the customizations are not limited to these:
- New resource types
- New resource properties
- New link types
Connector Diagnostics
The connector has the facility to trace information. The data can be obtained through Polling tracing or Application tracing.
Licensing
Contact Sales for more information.
Resource Types
This section lists the resource types and their attributes that the connector has to discover on SolarWinds systems. The connector then imports the resource types it has discovered into the vFire Core CMDB.
The resource types available for mappings are:
- Nodes
- Virtual Clusters
- Data Centers
Node Attributes
|
Attribute |
Data Type |
Is Multi Valued |
|---|---|---|
|
Node ID |
Int |
False |
|
Object Sub type |
string |
False |
|
IP Address |
string |
False |
|
Display Name |
string |
False |
|
Last Synced |
dateTime |
False |
|
Caption |
string |
False |
|
Description |
string |
False |
|
Node Description |
profile |
False |
|
DNS |
string |
False |
|
System Name |
string |
False |
|
Vendor |
string |
False |
|
Location |
string |
False |
|
Status |
profile |
False |
|
IOS Version |
string |
False |
|
Last Boot |
dateTime |
False |
|
Machine Type |
string |
False |
|
Node Category |
profile |
False |
|
Manufacturer |
string |
False |
|
Model |
string |
False |
|
Number of VMs |
int |
False |
Virtual Cluster Attributes
|
Attribute |
Data Type |
Is Multi Valued |
|---|---|---|
|
Cluster ID |
int |
False |
|
Name |
string |
False |
|
DRS Behaviour |
string |
False |
|
HA Status |
bool |
False |
|
Datacenter ID |
int |
False |
|
Datacenter Name |
string |
False |
Data Center Attributes
|
Attribute |
Data Type |
Is Multi Valued |
|---|---|---|
|
Datacenter ID |
int |
False |
|
Name |
string |
False |
|
vCenter ID |
int |
False |
|
vCenter Name |
string |
False |
Link Types
Nodes are the only SolarWinds link types that are exposed by the connector by default.
|
Link Type |
Resource Type A |
Resource Type B |
|---|---|---|
|
Node - Node |
Node |
Node |
Event Management
This section provides information about the Event Management capability of the SolarWinds connector.
Functionality Overview
The purpose of this functionality is to:
- Automatically transpose alerts generated by SolarWinds into vFire Core calls or requests.
- Maintain the consistency of the information held in the item created in vFire Core.
Event Management Operation
The operation of this functionality relies on the connector monitoring the SolarWinds alerts in order to detect any new alerts. When such event occurs, the Integration Platform automatically compares the attributes of the new alert against some user-defined criteria. In case criteria are met, the platform proceeds with the creation of a call/problem or a request depending on the user settings.
From a practical point of view, SolarWinds alert attributes can be mapped to vFire Core fields. This mapping is used when creating a new call or request.
As the alert is updated, the connector ensures that these modifications are properly transmitted to the related vFire Core item. The current behavior of vFire Core, upon receipt of such updates and notifications, depends on the Event Mapping settings that are configured in vFire Core.
Eventually, physical actions on the network will be taken to fix the issue and the SolarWinds alert will be marked as Inactive or will disappear from its queue. This fact will also be transmitted to the relevant vFire Core item and the final result (Call Updated, Call Closed and so on) will again depend on the Event Mapping settings in vFire Core.
Specific Use Case
The following use case describes the scenario where an organization sets up integration between vFire Core and SolarWinds. In this scenario, vFire Core is responsible for Service Desk and Change operations and SolarWinds is responsible for issuing alerts.
|
Use case scenario |
Action |
Event Management transaction |
|---|---|---|
|
SolarWinds sends an alert to vFire Core |
vFire Core logs a call with this information and automatically forwards the call to the Incident Management group. The analyst takes over the call and clicks the Acknowledge Event button. |
vFire Core sends an Acknowledgement transaction to SolarWinds |
Event Management and Transactions
The use case scenario in the previous section, and more generally the Event Management operation of the connector, rely on a particular communication protocol between the two systems. This protocol is composed of different transactions that are detailed below.
The transactions and their descriptions are listed below.
|
Event Management transactions |
Description |
|
Receive |
An alert is sent from an external system to vFire Core. vFire Core receives this alert. |
|
Acknowledge |
vFire Core sends a transaction to an external system with a formal statement acknowledging that their alert has been received. This is different from a transactional acknowledge/not acknowledge (ack/nack) note sent between systems. |
|
Notify |
Occurs when there is a call or request within vFire Core logged due to an alert sent from an external system: Notification is initiated from an external system and is sent to vFire Core as a NOTIFY event. It is either added as a note or ignored, depending on the settings in the Event Mapping screen. |
|
Update |
Occurs when there is a call or request within vFire Core logged due to an alert sent from an external system: From the external system, an UPDATE message is sent to vFire Core any time an alert related to a call in vFire Core is modified. Either the vFire Core call/request is physically closed, a note added, or it is ignored, depending on the settings in the Event Mapping screen. |
|
Resolve |
Occurs when the alert has been resolved in the external system and a Resolve transaction is sent to vFire Core. Either the vFire Core call/request is physically closed, a note is added, or it is ignored, depending on the settings in the Event Mapping screen. |
|
Delete |
Occurs when the alert is no longer valid on the external system. It also informs vFire Core through a transaction. Either the vFire Core call/request is physically closed, a note is added, or it is ignored, depending on the settings in the Event Mapping screen. |
Business Rules
The table below defines some business rules that specifically apply to the SolarWinds integration.
|
Transaction |
Rules |
|
Receive |
The Receive transaction leads to a new call being logged, a new problem being created or a request being initiated depending on Integration Platform settings. |
|
A reliable unique ID is stored against any specific call created to ensure proper management of the subsequent communications |
|
|
Any possible data in relation with the time or date of the alert is made available to vFire Core. This allows for possible back-dating of any call or problem logged in vFire Core after it receives a Receive message from the SolarWinds system. |
There are no business rules for the other transaction types.
Setting up the Event Management Functionality
Check the following items when setting up the Event Management functionality of the connector for SolarWinds:
- Ensure that the Event Management checkbox is selected in the Integration Platform settings window.
- Ensure that the connector for SolarWinds is installed and the check boxes in the Events and Visible columns are selected in the Integration Connectors window.
- Ensure that a SolarWinds source is defined in the Integration Source window.
- Ensure that a SolarWinds Event mapping is defined in the Event screen. This mapping should at least specify the action to be performed (log call/create request) when a notification is carried over, as well as the template to be used for this action.
Starting the Event Management Functionality
If the Event Management checkbox in the Integration Platform administration screen is selected, the Event Management functionality starts running as soon as a proper Event mapping is completed and saved. When starting, the connector immediately connects to the SolarWinds system and logs a call/request for every alert that is present and fulfills the criteria that are implemented in the Event mapping. This can lead to a large number of calls/requests being created when activating the Event Management functionality.
One solution to avoid this behavior is to include in the Event criteria setting an item based on the Triggered Date Time attribute. For example, you could plan to “go live” with Event management on a precise date and, as a consequence, specify that the value of Triggered Date Time has to be after this date before any action can be triggered in vFire Core.
SolarWinds Alert Attributes
The table below lists all the SolarWinds alert attributes that are exposed by the connector.
|
Attribute |
Data Type |
Is Multi Valued |
|---|---|---|
|
Source Local ID |
string |
False |
|
Alert ID |
int |
False |
| Alert Object ID | int | False |
|
Alert Name |
string |
False |
|
Alert Note |
string |
False |
|
Alert Severity |
int |
False |
|
Triggering Object ID |
string |
False |
|
Triggering Object Name |
string |
False |
|
Triggering Object Type |
string |
False |
|
Related Node ID |
int |
False |
|
Related Node Name |
string |
False |
|
Related Node Status |
string |
False |
|
Triggered Date Time |
dateTime |
False |
|
Triggered Count |
int |
False |
|
Description |
string |
False |
|
Category |
string |
False |
|
Alert Message |
string |
False |
|
Application Name |
string |
False |
|
Application Status |
string |
False |
|
Component Name |
string |
False |
|
Component Status |
string |
False |
|
Component Type |
string |
False |