How do I know if my integration is functioning?
One of the things you will need to know is that integrations you have configured are working correctly and sending telemetry to the Samurai platform.
Integration Health
You can easily get an overview of which of your Integrations are not healthy by viewing the Telemetry Dashboard or Telemetry Monitoring. This gives you a concise overview of any integrations which are unhealthy - or in other words, Integrations where the Samurai platform has not seen events over specific time periods:
The fact that an Integration is unhealthy doesn’t necessarily mean that there is a fault. For example, your integration may send telemetry intermittently - is this case we highlight this in the Info field.
Telemetry Monitoring Notifications
Samurai will send email notifications to registered application users if no events are seen for an integration over 24hrs. You can opt-in to receive notifications by submitting a ticket in the Samurai MDR portal or during MDR onboarding.
Managing Integration Health
There are a few factors which could result in telemetry not being properly ingested. This article takes you through the main factors which could impact whether an integration is working or not, who is responsible for them, and how to address them.
In order for a log source to be ingested into the platform, the following main areas need to be functioning properly:
- Platform is available: We are responsible for making sure that the Samurai platform is available.
- Log source configuration: Often the first place to check is that the log source is correctly configured to send logs. If your log source uses a Cloud Collector, you will also need to check that the Cloud Collector is functioning and healthy. Make sure that you have followed all of the configuration steps outlined in the configuration guide for the Integration.
- Connectivity: Any log sources using Local Collectors are dependent on internet connectivity between your premises and the Samurai platform. Check that your internet connection is available and that firewalls are configured to allow traffic. The Local Collector article also provides a detailed explanation of all of the ports that a Local Collector needs to have open in order to function correctly.
- Local Collector: If your log source uses a Local Collector, you will need to ensure that the Local Collector is available. You will also need to ensure that the virtualization platform that hosts the Local Collector is healthy. For more information see the section on Local Collectors below.
- Cloud Collector: If your log source uses a Cloud Collector, the health of your integration is also dependent on the Cloud Collector being operational. If your cloud collector monitors a cloud storage account, ensure that your integrated sources are sending and storing data to the storage account. If your log source is correctly configured but it remains unhealthy, it is our responsibility to ensure the Cloud Collector is operational for you.
Local Collectors
If your integration is utilizing a Local Collector, firstly make sure it’s running as expected. If there is a problem with your Local Collector you should receive an email notification of status change. Login to the Samurai MDR portal and check the Collector Health. This is a status that is shown in the Collector navigation item in the application (Offline, Unavailable, Healthy, Not-Healthy, Provisioning).
When you drill down into a Local Collector in the Samurai MDR portal, you are provided a view which shows you the health of the Collector, together with all of the Integrations that are configured to use that Collector:
For integrations that utilize a Cloud Collector you can jump directly to checking the Integration status.
Integration Status
Once you have confirmed that the Local Collector is Healthy (communicating with Samurai), check the Integration status. From the Collectors menu (applicable to both Local Collectors and Cloud Collector) you can view associated integrations to view their state of health. Alternatively, navigate to the Integrations page. Refer to Integrations for further steps.
In both cases you will see a column called ‘Last Event Seen’. This column provides a timestamp (in the format [yyyy:mm:dd], [hh:mm:ss]) represented in Universal Time Coordinated (UTC) of the last received event.
Within the current version of Samurai we monitor for ‘Last Event Seen’ within specific timeframes that relate directly to the Status - a table below outlines the time periods and related status.
| Status | Description |
|---|---|
| Not Available | No events seen over 24 hrs |
| Not-Healthy | No events seen between 12-24 hrs |
| Healthy | Events seen within the last 12 hrs |
If for some reason, the Integration is not healthy or not available (e.g. not Green), then run through the Integration guide for your specific device and confirm there are no other controls blocking the traffic to the Local Collector or Cloud / Native Collector.
If your Integration is of type Local or Cloud and is not healthy or not available, then review the integration configuration to ensure it is correct and also ensure you followed the appropriate Integration guide for your device.
If you still have issues and please raise a ticket via the Samurai MDR portal
Querying the detail
If you would like to go into more detail about the events from your log sources, you can make use of Advanced Query to analyze the events stored in the data lake. This will help you to answer questions like:
Is my log source generating logs intermittently? By querying your log source over a period of time, the graphical representation of events will quickly show you time periods when your log source was not generating logs:
When did my log source last generate an event and what was that event? You can easily find the last time when a log source generated an event. This will be the same as the “Last Event Seen” field for the Integration. For instance, the following query shows the last log generated in the last 7 days:
Is my log source configured to generate correctly formatted logs? Sometimes a configuration error on your log source might result in your log source generating incorrectly formatted logs. By examining the raw log content you can check that your logs are correctly formatted. This will assist in correcting any configuration errors which may have resulted in incorrectly formatted logs being sent.
Is my log source sending the logs I need? By checking the types of events generated, you can verify that you have configured the log source to send the logs you require, and that it is generating them. For instance, in this example, we are verifying that a device is generating DNS logs as expected:
