Sonar Architecture
Raptor Sep 1 2022 at 12:00 AM
The purpose of this document is to describe the general architecture of the Sonar offering, and to outline the various software and hardware requirements for it’s provisioning. This document will also describe the services and how to set up for Sonar.
The interfacing layers depict that of the Raptor service such as cloud, drivers, gateways, and devices, all of which are functioning together on separate levels.
Figure 1 - Layers & Communication methods
Services
As per the architectural diagrams of the Raptor environment and interaction of the different levels and services it shows that a failure could occur at any specific level and not just the top level. This means that many issues can be resolved by monitoring and perhaps simply rebooting a lower-level service. A single V-Raptor™ can handle numerous edge devices (Edge Raptor™, Micro Raptor™, bulk devices – directly, etc) by maintaining a logical and stable link of inter-communicating services. This means that rebooting or interfering with the top level (Edge Raptor) would result in all levels below not functioning as expected (even if it may only be temporary). Therefore, it is better to work through the other levels of services to pinpoint the failure and reboot a single low-level service which will not compromise other large aspects of a given project.
How to setup Sonar
The Sonar application (backend API) needs to be activated on the relevant production tenant if users wish to make use of this feature. It is not activated by default. The process to activate Sonar in its entirety is as follows:
Activate Commander™ feature flag
This is done via the Commander™ Portal (UI). This can only be done by a user with the correct user rights and credentials. To find the feature flag, go to the Client Management portal and enable the correct Feature Flag in the client’s Environment settings.
Figure 2 - Enable Sonar via Commander™
Once the feature is activated and the tenant updated, the logs within rancher will show the success/failure of this activation as shown in Figure 18, below.
Figure 3 - Sonar Enabled Successfully via Rancher
Management service setup
There are two configuration files that require changes and must be restarted once completed for the changes to be applied.
Management service options
File | ./Data/Config/ManagementServiceOptions.json |
NuGet Package | N/A |
Program.cs Stub | N/A |
Required By | Management Service |
This is used to set the type of Commander™ API interface that will be used by the service. The only current valid option is “rest”.
Changes to this file will require a restart of the service.
{
"ManagementServiceOptions": {
"InterfaceType": "rest"
}
}
File | Description |
Interface Type | Selects the type of Commander™ API interface used by the service. The only current valid option is “rest” |
Management REST options
File | ./Data/Config/ManagementRestOptions.json |
NuGet Package | N/A |
Program.cs Stub | N/A |
Required By | Management Service |
This is used to set the options for the REST Commander™ API interface that will be used by the service. These options are used when the Interface value of Management Service Options is set to rest
.
To communicate with the Commander™ API, the REST interface requires a Commander™ Username and Password that will be used to retrieve a bearer token from the Commander™ Identity service which will be used to authenticate the REST requests. No specific roles are required for this user (member), basic roles.
{
"ManagementRestOptions": {
"CommanderApiUrl": "https://iotnxtinternal.commander.io/_apis/sonar",
"CommanderUsername": "[email protected]",
"CommanderPassword": "yourpassword",
"AsyncTimeout": 20000,
"LogMessages": false
}
}
Property | Description |
CommanderApiUrl | The URL to the Commander™ API service |
CommanderUserName | The authenticating Commander™ Username |
CommanderPassword | The authenticating Commander™ User’s Password |
AsyncTimeout | The default asynchronous timeout. Defaults to 20,000ms (20 seconds) |
CommanderUserName | Whether to log out all messages sent and received from the Commander™ API. Defaults to false |