The orchestration of observability data is a cornerstone of modern IT infrastructure management. When organizations leverage SolarWinds for network and application monitoring, the data resides within the SolarWinds Information Service (SWIS), a sophisticated data access layer designed for the Orion product family. This layer provides a hybrid architecture, blending object-oriented and relational features through a proprietary language known as SolarWinds Query Language (SWQL). While SolarWinds provides a robust interface for monitoring, many engineering teams seek the advanced visualization, alerting, and dashboarding capabilities offered by Grafana. Establishing a connection between these two ecosystems requires a nuanced understanding of data source plugins, API endpoints, and the underlying SQL structures. Achieving this integration can be approached through three primary methodologies: utilizing the official SolarWinds data source plugin, configuring the Infinity plugin to interface with the SWIS REST API, or connecting directly to the Microsoft SQL database via the MS SQL data source. Each method carries specific architectural implications regarding security, performance, and maintenance complexity.
The SolarWinds Data Source Plugin Architecture
The SolarWinds data source plugin for Grafana serves as a specialized connector designed to facilitate the retrieval of metrics directly from the SolarWinds ecosystem. This plugin is currently classified under a public preview status within the Grafana Labs release life cycle. Because it is in a preview phase, users must remain cognizant of potential stability fluctuations and the specific support parameters defined by Grafana Labs.
The acquisition and deployment of this plugin follow a specific enterprise workflow. Unlike community-driven, open-source plugins, this particular data source is a paid entitlement developed by a marketplace partner. The procurement process requires users to initiate contact with Grafana Labs, where a customized discussion regarding organizational needs occurs, followed by payment processing through Grafana Labs. Once the entitlement is secured, the plugin is delivered in two distinct formats based on the deployment model: a cloud-compatible version for Grafana Cloud users or a signed version for on-premise installations.
Installation procedures vary significantly depending on the hosting environment of the Grafana instance. For local or on-premise installations, the most efficient method is utilizing the command-line interface tool.
- Execute the installation command via the terminal:
grafana-cli plugins install Solarwinds
This command automatically targets the default plugin directory, which is typically located at /var/lib/grafana/plugins. If a manual installation is required, the user must download the appropriate .zip file corresponding to their specific system architecture and manually extract the contents into the Grafana plugins subdirectory.
A critical technical hurdle during manual installation involves the verification of plugin signatures. If a user attempts to install an unsigned or community-contributed plugin, such as the etichy/grafana-swis-datasource found on GitHub, Grafana's security protocols may refuse to load the plugin. To mitigate this, administrators may need to modify the custom.ini configuration file to allow specific unsigned plugins to load. Furthermore, if the data/plugins directory is absent in newer Grafana versions, the administrator is responsible for manually creating the directory structure to accommodate the new files.
Implementing the Infinity Plugin for SWIS API Connectivity
For environments where the official SolarWinds plugin is not utilized, or where the existing plugin exhibits incompatibilities—such as reported issues with Grafana version 9—the Infinity plugin offers a highly flexible alternative. The Infinity plugin allows for the consumption of various data formats, including JSON, by interfacing directly with the SolarWinds Information Service (SWIS) REST API. This method bypasses the need for direct database access, which is often discouraged in high-security environments due to the risks associated with querying the Orion database directly.
The configuration of the Infinity data source requires precise attention to authentication and network routing. The process begins with the creation of a new Infinity data source within the Grafana interface, assigning it a descriptive identifier such as "SolarWinds."
The configuration workflow is as follows:
- Navigate to the Authentication tab within the data source settings.
- Select Basic Authentication as the primary method.
- Input a username and password for a SolarWinds account that possesses sufficient access to the web console. It is important to note that this account does not require elevated administrative permissions; the permissions applied to the account within the SolarWinds web interface will inherently govern the data visibility within Grafana.
- Define the Allowed Hosts by entering the URL, IP address, or DNS name of the SolarWinds server.
- Navigate to the URL, Headers, and Params tab to specify the target endpoint.
- Construct the URL to include the specific port used by the SWIS REST API. For SolarWaries versions released after 2023, the standard port is
17774. For legacy versions, the port may be17778. The final URL should follow the pattern:YOURSERVER:17774/.../Query. - Access the Network tab and enable the "Skip TLS Verify" option. This is a vital step because SolarWinds installations frequently utilize self-signed certificates for their API endpoints, which would otherwise cause the connection to fail during the SSL handshake.
Once the data source is established, individual dashboard panels must be configured to parse the incoming JSON payload. The following settings are recommended for optimal performance and feature availability:
- Set the Data Source to the newly created "SolarWinds" Infinity source.
- Set the Type to
JSON. - Set the Parser to
Backend. Utilizing the backend parser is a critical architectural decision, as it enables the creation of Grafana alerts and allows for the utilization of enterprise query caching, significantly reducing the load on the SolarWinds API. - Set the HTTP method to
GET. - Within the Headers, Request params, and URL Query Param section, add a new URL Query Param.
- Set the Key to
query. - Set the Value to a valid SWQL (SolarWinds Query Language) statement.
- Under the Parsing options, locate the Rows/Root box and input the regular expression
$.*. This ensures that the backend parser correctly identifies and flattens the incoming fields for visualization.
This method allows for the recreation of complex SolarWinds views, such as the "Node Details" view, by leveraging the structured data returned by the SWIS API.
Direct Microsoft SQL Integration and Cloud Connectivity
The third methodology involves treating the SolarWinds Orion database as a standard Microsoft SQL data source. While this approach provides direct access to the underlying relational data, it requires a deep understanding of the SolarWinds database schema and the tables involved in metric collection. This method is often preferred by administrators who are already proficient in T-SQL and require the ability to perform complex joins that might be cumbersome in SWQL.
For organizations utilizing Grafana Cloud, connecting to an externally hosted SolarWinds instance requires the deployment of the Grafana Private Data Source Connect (PDC) Agent. The PDC Agent acts as a secure bridge, allowing Grafana Cloud to communicate with a private network without the need for complex VPN or firewall configurations.
The deployment and configuration steps for SQL-based integration are:
- Deploy the Grafana PDC Agent directly on the SolarWinds server or a machine within the same network segment.
- Configure the MS SQL Data Source within Grafana.
- Ensure the PDC connection is explicitly added at the bottom of the data source configuration to facilitate the secure tunnel.
- Execute T-SQL queries against the Orion database to extract specific metrics.
This approach is highly effective for visualizing high-level metrics such as Network Availability Percentage (npm) or Application Availability Percentage (sam). Advanced dashboards can even incorporate geographic visualizations using geomaps to display network device response times, utilizing thresholds that can be dynamically adjusted within the SQL query itself.
Comparison of Integration Methodologies
The following table delineates the technical characteristics and operational requirements of the three primary integration strategies discussed.
| Feature | SolarWinds Plugin (Official) | Infinity Plugin (SWIS API) | MS SQL Data Source |
|---|---|---|---|
| Deployment Type | Paid/Entitlement | Open Source/Community | Standard SQL Driver |
| Complexity | Low (after procurement) | Moderate (requires SWQL) | High (requires SQL expertise) |
| Security Profile | High (Signed/Official) | High (API-based) | Moderate (Direct DB access) |
| Primary Protocol | Proprietary/Plugin | REST API (HTTP/HTTPS) | TDS (Tabular Data Stream) |
| Key Advantage | Native Integration | Flexible/No DB access needed | Deep relational querying |
| Primary Risk | Cost/Subscription | Configuration complexity | Security/Database load |
Technical Analysis of Data Observability
The integration of SolarWinds and Grafana represents a convergence of two distinct philosophies of observability. SolarWinds operates as a specialized, vertically integrated monitoring solution, focusing on the collection and processing of telemetry through the SWIS layer. Grafana, conversely, operates as a horizontally integrated visualization layer, designed to aggregate disparate data streams into a unified pane of glass.
The transition from SWIS-based querying to SQL-based querying involves a fundamental shift in the abstraction layer. When using the SWIS API via the Infinity plugin, the user is interacting with an object-oriented representation of the network. This abstraction simplifies the complexity of the underlying relational schema but limits the user to the objects and properties exposed by the SolarWinds Information Service. In contrast, direct MS SQL integration provides unfiltered access to the raw relational data, enabling the extraction of granular timestamps and historical trends that might be abstracted away by the API. However, this power comes with the responsibility of managing query impact on the production database.
Furthermore, the implementation of the backend parser in the Infinity plugin highlights an emerging trend in DevOps-oriented observability: the movement of computational logic from the client-side (browser) to the server-side (Grafana backend). By utilizing the backend parser, administrators can leverage enterprise features such as query caching. This caching mechanism is vital when dealing with SolarWinds environments, as it prevents the "thundering herd" problem, where multiple dashboard users simultaneously trigger heavy SWQL or SQL queries, potentially degrading the performance of the SolarWinds Orion services.
Ultimately, the success of a SolarWinds-Grafana implementation depends on the alignment of the chosen methodology with the organization's security posture, technical expertise, and performance requirements. Whether through the streamlined experience of an official plugin, the flexible API-driven approach of the Infinity plugin, or the deep-dive capability of direct SQL connection, the goal remains the same: transforming raw telemetry into actionable, real-time intelligence.