Skip to content

Alert Configuration Overview

Sophos Linux Sensor (SLS) lets users decide which data they need to best serve their workflows. As such, we support custom formatting of Alerts through Alert Templates.

Default alert formatting

By default, Alerts are UTF-8 encoded JSON strings that are newline-delimited. Alerts will arrive one at a time no matter what type of output destination (stdout, webhook, etc.).

Default limits

It's important to note that some log ingestion systems like Splunk, ELK, and syslog have default limits on the number of bytes that a single log entry can contain. In some cases, truncated alerts can lead to Alerts appearing on multiple lines or not parsing correctly as valid JSON.

It's possible to ingest a smaller Alert by turning off certain Alert information or ingesting only a portion of the Alert to work around these limits. You can do this by setting the configuration of features like process lineage or cloud metadata to "off," by the post-processing of Alerts written to a blob storage bucket with a cloud function, or using Alert Templates to alert the Alert format from within SLS itself.


Alerts contain a metadata field with information about the node SLS was running on, such as the hostname and OS.

In many cloud environments, this field can be optionally enriched with instance metadata from the instance's local metadata service. These services are local HTTP servers that return information about the running instance. For more information about these services see the AWS, GCP, and Azure documentation.

To configure the cloud metadata feature, either run the sensor with the CLOUD_META environment variable or set the cloud_meta key in the runtimedetections.yaml config file based on your platform:

To enable could metadata for AWS cloud_meta can be set to auto, ec2, or ec2_with_tags. ec2_with_tags will also retrieve the ec2 tags for the instance running the sensor but requires the instance to have ec2:DescribeTags

To enable cloud metadata for GCP cloud_meta can be set to autogcp, or gcp_with_labels. gcp_with_labels will also retrieve the compute instance labels but requires an instance to have a role with the compute.instances.get permission.

To enable cloud metadata for Azure cloud_meta can be set to azure.  Azure will automatically gather instance tags and requires no additional permissions.

If you are running the sensor in VMWare vSphere, cloud_meta can be set to vmware and the sensor will retrieve the vm uuid and submit it in the metadata as node_uuid

Process lineage

Alerts contain a lineage field with the full process lineage of the process that triggered the Alert going back to the process that launched that process.

In many cases, the process lineage will terminate with an init process or system like systemd or dockerd. This can be useful for creating fine-grained allowlists and blocklists.

While process lineage details provide useful context, they can considerably increase the size of an Alert. To turn it off, set the RUNTIMEDETECTIONS_PROCESS_LINEAGE_IN_ALERT environment variable to false or add process_lineage_in_alert: false to the runtimedetections-rules.yaml config file.

Removing Process Lineage

While process lineage details provide useful context, they can considerably increase the size of an Alert. If process lineage is not wanted in standard JSON Alerts, it can be disabled by setting the RUNTIMEDETECTIONS_PROCESS_LINEAGE_IN_ALERT environment variable to false, nor by adding process_lineage_in_alert: false to your runtimedetections-rules.yaml config file.

Back to top