The two platforms can be connected through the Sycope API and the Nagios plugin mechanism. A custom Nagios plugin can query Sycope for selected network information, evaluate the returned data and present the result as a standard Nagios service state.
This allows network conditions identified through flow analysis to become part of the monitoring processes already used by NOC and infrastructure teams, while detailed traffic analysis remains available in Sycope.
Table of Contents
From Sycope data to a Nagios service check
Nagios active checks are performed by plugins executed on a defined schedule. The plugin checks the required condition and returns both a status code and descriptive output to the Nagios monitoring engine.
A Sycope integration can use this mechanism to query the Sycope API for network information relevant to a monitored host or service.
The public Sycope integration library provides methods for running NQL queries over a defined time range and retrieving the resulting records. Larger result sets can also be retrieved using pagination.
A custom Nagios plugin can use these results to evaluate a defined network condition and translate it into the Nagios state model.
For example, a check could determine whether a monitored system is experiencing increased network latency, whether unexpected communication has appeared or whether a selected type of Sycope security event has occurred within a defined time window.
Nagios continues to manage the service state, notification and escalation workflow, while Sycope provides the network data on which the check is based.
Complementary capabilities, clearly divided
Sycope and Nagios remain independent monitoring platforms and provide different perspectives on the environment.
Nagios provides:
- Host and service availability monitoring
- Scheduled active checks
- Passive check processing
- Plugin-based extensibility
- Service states and thresholds
- Notifications and escalation
- Established infrastructure monitoring workflows
Sycope provides:
- Flow-based network analysis
- Host-to-host communication visibility
- Network performance analysis
- Network anomaly and threat detection
- Historical network communication data
- Application and protocol context
- NQL-based search and analysis
Nagios determines the operational state of monitored hosts and services through checks. Sycope provides information about the network communication associated with those systems.
The integration allows selected network conditions to participate in the same monitoring workflow without attempting to reproduce Sycope’s full analytical environment inside Nagios.
Adding network context to infrastructure monitoring
Infrastructure monitoring can identify that a host or service is unavailable or performing outside an expected range. Flow data can provide additional information about the network behavior surrounding the same system.
Network performance checks
A custom Nagios plugin can use Sycope data to evaluate network conditions associated with a monitored host or service.
For example, an NQL query can select relevant performance information for a defined system and time range. The plugin can then compare the returned value with thresholds defined for the Nagios service.
If the value remains within the expected range, the check can return OK. Higher values can be mapped to WARNING or CRITICAL according to the monitoring policy.
This allows selected network performance indicators to be included in the Nagios service view while retaining the detailed underlying data in Sycope.
Verification of network communication
Sycope can provide information about communication involving a particular IP address, service or group of systems.
A Nagios check can use this information to verify whether expected communication is taking place or whether an unexpected connection pattern has appeared.
This can be useful for systems with clearly defined network roles, where the presence or absence of particular communication provides additional information about operational health.
Security conditions in the NOC workflow
Selected security information from Sycope can also be used as the basis for Nagios service checks.
A plugin can query for a defined class of network event or condition within a recent time window and change the Nagios service state when matching data is returned.
This provides a way to expose selected security signals to teams that work primarily in Nagios without turning Nagios into the system responsible for network threat analysis.
The detailed event and communication history remain available in Sycope for further investigation.
Monitoring across existing Nagios hosts
Because the integration can use an IP address or other host information as part of the NQL query, the same plugin concept can be applied to multiple systems already defined in Nagios.
The check logic can therefore be standardized while the host-specific parameter determines which Sycope data should be evaluated.
This allows organizations to add a network perspective to selected Nagios hosts without creating a separate monitoring workflow for every system.
A custom integration based on standard extension mechanisms
The public Sycope repository does not currently contain a dedicated Nagios template.
Instead, it provides a shared Python API library for integrations with third-party systems that do not have dedicated templates. The library includes methods for executing NQL queries, defining time ranges and retrieving query results.
Nagios is designed to support custom plugins and does not require them to use a specific internal implementation. A plugin needs to perform the required check, return an appropriate status code and provide output that Nagios can display.
This makes it possible to build a lightweight integration around the specific Sycope information required by the monitoring environment rather than deploying a separate proprietary connector.
How the integration works
The integration can be organized around four main components.
NQL query in Sycope
The required network condition is first defined as an NQL query.
The query can select the data source, monitored host, time range and filtering conditions relevant to the Nagios service check.
The Sycope API library provides a run_query method for executing the NQL pipeline and methods for retrieving the resulting data.
Custom Nagios plugin
A plugin or script uses the Sycope API to execute the query and process the returned result.
The plugin contains the logic required to determine whether the current condition should be considered normal or should result in a warning or critical state.
This can be based on a numeric threshold, the number of matching records or the presence of a specific network condition.
Nagios service state
The plugin converts the result into the standard Nagios return codes.
Nagios plugins use return codes to indicate states such as OK, WARNING, CRITICAL and UNKNOWN, together with textual output describing the check result.
Nagios then processes the result in the same way as other active service checks.
Notification and further investigation
If the state changes according to the configured Nagios logic, the existing notification and escalation workflow can be used.
The service output can identify the condition detected through Sycope and provide enough context for the receiving team to understand why the state changed.
When deeper analysis is required, the engineer continues the investigation in Sycope using the underlying flow data, historical communication and analytical context.
Active and passive integration models
The plugin-based active check is the most direct way to connect Nagios with the Sycope API, but Nagios also supports passive checks.
With passive checks, an external application performs the monitoring operation and submits the resulting host or service state to Nagios for processing. Once received, passive check results can participate in the same notification and monitoring mechanisms as active checks.
A custom Sycope integration could therefore also operate independently of the Nagios scheduler, periodically evaluating Sycope data and submitting a result when required.
The appropriate model depends on the monitoring architecture. Active checks are suitable when Nagios should initiate the query on its regular schedule, while passive checks can be used when the integration process should control when results are submitted.
From network condition to Nagios alert
Consider a critical application server already monitored in Nagios.
Traditional checks confirm that the server is running and that the application port is available. A separate Sycope-based service check evaluates network performance for communication involving the same host.
Nagios periodically runs the custom plugin. The plugin queries Sycope using NQL for the defined time window and evaluates the returned network metric.
When the network condition exceeds the configured threshold, the plugin returns a WARNING or CRITICAL result.
Nagios displays the problem alongside the server’s other infrastructure checks and uses the existing notification and escalation workflow to inform the responsible team.
The engineer can then continue the investigation in Sycope, where historical traffic and communication data provide the additional context required to determine the cause of the network condition.
The integration therefore adds selected network evidence to Nagios while preserving the role of each platform in the monitoring process.
Sycope and Nagios integration
A custom Sycope–Nagios integration allows selected network, performance and security conditions to be presented as standard Nagios service checks.
Nagios retains the existing host and service monitoring workflow, while Sycope provides the network data and historical context used to extend that monitoring beyond traditional infrastructure checks.
To discuss adding Sycope network checks to your Nagios environment, contact our team.
