Sidecars

Security Data Lake Sidecar is a lightweight configuration management system for log collectors. It provides a centralized framework to deploy, configure, and manage collectors such as Winlogbeat, Filebeat, and NXLog across multiple hosts. This simplifies log collection and ensures consistent configurations in distributed environments.

Sidecar architecture

The Security Data Lake node serves as the central hub for managing log collector configurations. The Sidecar daemon periodically retrieves the latest configurations for each target using the REST API. On its first run, or whenever a configuration change is detected, Sidecar generates the necessary backend configuration files and restarts the affected log collectors. All collector configurations are centrally managed through the Security Data Lake web interface, ensuring consistency and simplified administration.

Sidecar can run as a service (Windows host) or as a daemon (Linux host) on supported, message-producing devices.

Installing Sidecar

To install Sidecar and complete the necessary configurations, follow these steps:

1. Set up the sidecar in Security Data Lake

Take the following steps to create and configure a sidecar:

1.1 Set up an input

Before installing Sidecar, create a new Beats input in order to receive data from the Beats collector, and configure it to receive Sidecar logs on port 5044.

1.2 Create an API token

Select the user icon on the upper-right side of the screen and click Edit profile.
Select Edit tokens on the upper-right side of the screen.
Enter the token details and select Create Token.

Save the API server token in a safe yet accessible location in case you need to retrieve it.

1.3 Download Sidecar

You can find .deb, .rpm, .msi, .exe, .arm, .tar and .gz packages in our package repository. To download the appropriate package, refer to the Bitdefender Sidecar releases page.

2. Prepare your local environment

Note

All the Bitdefender Sidecar installer URLs in this section are provided as examples, with a <version> placeholder instead of the actual version. When installing Bitdefender Sidecar, always copy the appropriate installer URL for your installation method from the Bitdefender Sidecar releases page and update the commands accordingly.

Windows

You can install Bitdefender Sidecar on Windows either interactively or in silent mode.

Interactive installation

Run the installer:

bitdefender_sidecar_installer_<version>.exe

Follow the steps of the installation wizard:
- Provide your Security Data Lake server URL, for example: https://sdl-<tenant-id>.datainsights.gravityzone.bitdefender.com/api
- Enter a name for your Sidecar instance.
- Provide the Security Data Lake server API token that you created in Step 1.2 above.

After installation, you can edit the configuration file located at:

C:\Program Files\Bitdefender\sidecar\sidecar.yml

Most configuration parameters use default values. The only parameters that must be configured manually are server_url and server_api_token.

Silent Installation

To run the installer in silent mode, use the following command:

bitdefender_sidecar_installer_<version>.exe /S -SERVERURL=https://sdl-<tenant-id>.datainsights.gravityzone.bitdefender.com/api -APITOKEN=<your_api_token>

The Windows installer also supports additional options in silent mode, such as:

-TAGS=["example","IIS"] -NODENAME=mynodename -NODEID=1234 -SENDSTATUS=false -TLSSKIPVERIFY=true -UPDATEINTERVAL=10s

Adding a Winlogbeat collector configuration

Follow these steps to add a Winlogbeat collector configuration to your Sidecar and begin ingesting Windows event logs.

In Security Data Lake, go to System > Sidecars, and identify your Windows device.
Select your Windows sidecar or click Manage sidecar.
In Collectors Administration, select winlogbeat and click Assign Configurations.
Select an existing configuration or create a new one and click Save. For more information on configuring collectors, refer to Sidecar collectors.
To begin collecting data, open the Process dropdown menu and select Start.
To view the status of the sidecar, select the Overview tab.

Once started, your Security Data Lake instance will begin receiving Windows event logs from the configured machine.

Linux - Set up the host machine

Take the following steps on the remote machine from where you want to collect log data to prepare it for sending data to Security Data Lake

Install the Sidecar repository and package.

Run the following commands to install the repository configuration and the Sidecar package:

wget https://download.bitdefender.com/business/data-insights/sidecar/<version>/bitdefender-sidecar_<version>.deb
sudo dpkg -i bitdefender-sidecar_<version>.deb

Edit the configuration file.
Open the configuration file and specify the required parameters. Most settings have default values, but you must manually configure server_url and server_api_token.
```
sudo vi /etc/bitdefender/sidecar/sidecar.yml
```

Activate Sidecar as a system service.

Install and start Sidecar as a service using the commands below, depending on your operating system version:

sudo vi /etc/bitdefender/sidecar/sidecar.yml

sudo bitdefender-sidecar -service install

# Ubuntu 14.04 with Upstart
sudo start bitdefender-sidecar

# Ubuntu 16.04 and later with systemd
sudo systemctl enable bitdefender-sidecar
sudo systemctl start bitdefender-sidecar

Install the Sidecar repository and package

Run the following commands to install the repository configuration and the Sidecar package:

sudo rpm -Uvh https://download.bitdefender.com/business/data-insights/sidecar/<version>/bitdefender-sidecar-<version>.rpm
sudo yum install bitdefender-sidecar

Edit the configuration file.
Open the configuration file and set the required parameters. Most options include default values, but you must manually configure server_url and server_api_token.
```
vi /etc/bitdefender/sidecar/sidecar.yml
```

Activate Sidecar as a system service.

Install and start Sidecar as a service using the following commands:

sudo bitdefender-sidecar -service install
sudo systemctl enable bitdefender-sidecar
sudo systemctl start bitdefender-sidecar

Install the Sidecar repository and package.

Run the following commands to install the repository configuration and the Sidecar package:

sudo rpm -Uvh https://download.bitdefender.com/business/data-insights/sidecar/<version>/bitdefender-sidecar-<version>.rpm
sudo mv /etc/yum.repos.d/* /etc/zypp/repos.d/
sudo zypper up
sudo zypper install bitdefender-sidecar

When prompted, enter:

Continue? y
Do you want to reject the key, or trust always? [r/a/?] (r): a

Edit the configuration file.
Open the configuration file and set the required parameters. Most options have default values, but you must manually configure server_url and server_api_token.
```
sudo vi /etc/bitdefender/sidecar/sidecar.yml
```

Activate Sidecar as a system service.

Install and start Sidecar as a service using the following command:

sudo bitdefender-sidecar -service install
sudo systemctl enable bitdefender-sidecar
sudo systemctl start bitdefender-sidecar

Once Bitdefender Sidecar is installed, the next step is to install the Sidecar collectors. Collectors are the agents responsible for gathering log data from your system and forwarding it to Security Data Lake. Examples include Filebeat, Winlogbeat, and NXLog.

You can install one or more collectors depending on your environment and data sources. After installation, Sidecar will automatically detect the available collectors and manage their configurations through the Security Data Lake web interface.

`sidecar.yml` configuration reference

Below is a list of parameters used in the sidecar.yml configuration file for your reference:

Parameter	Description
`server_url`	Specifies the base URL for the Security Data Lake REST API. The path must include `/api/`. Example: `https://sdl-tenant-url/api/`
`server_api_token`	API token used for authenticating with the Security Data Lake REST API. This parameter is required. Example: `1jq26cssvc6rj4qac4bt9oeeh0p4vt5u5kal9jocl1g9mdi4og3n`
`node_id`	Unique identifier for the Sidecar instance. Can be a file URI or a literal string. Example file path: `file:/etc/bitdefender/sidecar/node-id` Example ID string: `6033137e-d56b-47fc-9762-cd699c11a5a9` Default: Windows: `file:C:\\Program Files\\Bitdefender\\sidecar\\node-id` Linux: `file:/etc/bitdefender/sidecar/node-id`
`node_name`	Display name for the Sidecar instance in the web interface. Defaults to the system hostname if not set.
`update_interval`	Specifies how often (in seconds) the Sidecar fetches updated configurations from the server. Default: `10` Sidecars that regularly update are marked as active. To configure the inactivity threshold, go to System > Configuration > Sidecars System in the web interface.
`tls_skip_verify`	Determines whether TLS certificate validation is skipped for HTTPS connections. Default: `false`
`send_status`	Controls whether the Sidecar reports detailed status, including collector states, metrics, and log listings. Disable this option to reduce load on the server. Default: `true`
`list_log_files`	Defines directories that will be listed on the host status page. Can include one or multiple paths. Example: `/var/log` Default: `[]` (empty list)
`cache_path`	Directory used by Sidecar to store local cache data. Default: Windows: `C:\\Program Files\\Bitdefender\\sidecar\\cache` Linux: `/var/cache/bitdefender-sidecar`
`collector_configuration_directory`	Directory where generated collector configuration files are stored. Default: Windows: `C:\\Program Files\\Bitdefender\\sidecar\\generated` Linux: `/var/lib/bitdefender-sidecar/generated`
`log_path`	Directory where the Sidecar writes its own log files. Default: Windows: `C:\\Program Files\\Bitdefender\\sidecar\\logs` Linux: `/var/log/bitdefender-sidecar`
`log_rotate_max_file_size`	Maximum size of a log file before rotation occurs, in MiB. Default: `10MiB`
`log_rotate_keep_files`	Number of old rotated log files to retain. Example: `log_rotate_keep_files: 10`
`collector_validation_timeout`	Maximum interval to wait for the config validation command, in minutes. Example: `collector_validation_timeout: "1m"`
`windows_drive_range`	Range of Windows drives that are checked for disk usage. If a drive's usage exceeds 75%, it will be reported in the sidecar's status report to the Security Data Lake server. To disable disk scanning, set the value to `""`. Example: `windows_drive_range: "CDEFGHIJKLMNOPQRSTUVWXYZ"`
`collector_binaries_accesslist`	Specifies which collector executables the Sidecar is allowed to run. Leave empty to disable this restriction. Default: Windows: `C:\\Program Files\\Bitdefender\\sidecar\\filebeat.exeC:\\Program Files\\Bitdefender\\sidecar\\winlogbeat.exeC:\\Program Files\\Filebeat\\filebeat.exeC:\\Program Files\\Packetbeat\\packetbeat.exeC:\\Program Files\\Metricbeat\\metricbeat.exeC:\\Program Files\\Heartbeat\\heartbeat.exeC:\\Program Files\\Auditbeat\\auditbeat.exeC:\\Program Files (x86)\\nxlog\\nxlog.exeC:\\Program Files\\nxlog\\nxlog.exe` Linux: `/usr/bin/filebeat usr/bin/packetbeat` `/usr/bin/metricbeat` `/usr/bin/heartbeat` `/usr/bin/auditbeat` `/usr/bin/journalbeat` `/usr/share/filebeat/bin/filebeat` `/usr/share/packetbeat/bin/packetbeat` `/usr/share/metricbeat/bin/metricbeat` `/usr/share/heartbeat/bin/heartbeat` `/usr/share/auditbeat/bin/auditbeat` `/usr/share/journalbeat/bin/journalbeat` `/usr/bin/nxlog` `/opt/nxlog/bin/nxlog`
`tags`	Defines a list of configuration tags. The Sidecar retrieves and merges all server configurations that match these tags. Default: `[]` (empty list)

Bitdefender Sidecar releases

Bitdefender Sidecar 1.5.6

Release date

2026.07.10

Download links

Installation method	Download link
Windows .exe	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender_sidecar_installer_1.5.6-1.exe
Windows .msi	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender-sidecar-1.5.6-1.msi
ARM64 DEB	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender-sidecar_1.5.6-1_arm64.deb
x86_x64 RPM	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender-sidecar-1.5.6-1.x86_64.rpm
aarch64 RPM	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender-sidecar-1.5.6-1.aarch64.rpm
Binary	https://download.bitdefender.com/business/data-insights/sidecar/1.5.6/bitdefender-sidecar-1.5.6.tar.gz

Sidecar collectors

A collector is a lightweight agent installed on a host system that gathers and forwards log data to Security Data Lake. It is responsible for collecting logs from local files, system logs, or applications, then sending them securely to a Security Data Lake server or input endpoint for central analysis.

Collectors are typically managed through Sidecar, which allows administrators to configure, deploy, and monitor multiple collectors from a single interface. This setup helps ensure consistent log collection across different servers or environments and reduces the need for manual configuration on each host.

There are two types of collectors:

Default collectors (using ready-to-use configurations)
Manually installed collectors

Default collectors

Several default collector configurations are included with Bitdefender Sidecar. These ready-to-use configurations are automatically assigned after installation and immediately begin collecting data such as event logs and audit framework information. The following collectors are currently available:

Operating System	Collectors
Linux x86/x86_64	Filebeat, Auditbeat
Windows x86/x86_64	Filebeat, Winlogbeat

To view the collectors that will be running by default, follow these steps:

Go to System > Sidecars.
Select the Configuration tab.

Editing default collectors

You can modify any Sidecar configuration to suit your needs. However, it is not advisable to modify the default collector configurations directly. If you need to modify a default collector configuration, click its More button and select Clone to create a copy of the configuration, which you can then use as the default. This ensures that the original configuration is preserved on the server and can be restored in case an issue arises.

For added convenience, you can define variables, which you can reuse when creating or editing collector configurations. This eliminates the need to manually enter the same value multiple times. For more information on variables, refer to Managing sidecars (Create and edit variables section).

If you remove a configuration's default tag under Configuration Assignment Tags, the configuration will no longer be automatically applied to the Sidecar.

Collector configuration window with default tag

Custom collectors

Security Data Lake provides default collector configurations for Filebeat, Winlogbeat, and Auditbeat; however, you can install and configure additional collectors to use with your Sidecar.

The following section demonstrates how to install NXLog as an example, but you can install and integrate other collectors as needed.

Because Sidecar allows you to define your own collector backends, you can also deploy tools such as Sysmon, auditd, or Packetbeat for specific data collection requirements.

Installing NXLog

On Ubuntu

To install NXLog on Ubuntu systems, follow these steps:

Download and install the NXLog package.
Stop any running NXLog instances and remove the default system service configuration.
Because Sidecar manages the NXLog service (including starting and stopping it), you must disable the existing NXLog service before Sidecar can take control:
```
sudo systemctl stop nxlog
sudo update-rc.d -f nxlog remove
sudo gpasswd -a nxlog adm
sudo chown -R nxlog.nxlog /var/spool/nxlog
```

These steps ensure that Sidecar has full control over the NXLog service and can manage its lifecycle correctly.

On CentOS

To install NXLog on Red Hat–based systems, follow these steps:

Download and install the NXLog package.
Stop all running instances of NXLog and unconfigure the default system service.
Because Sidecar manages the NXLog service (including starting and stopping it), you must disable the existing NXLog service before Sidecar can take control.
```
sudo service nxlog stop
sudo chkconfig --del nxlog
sudo gpasswd -a nxlog root
sudo chown -R nxlog.nxlog /var/spool/nxlog
```

On Windows

To install NXLog on Windows systems, follow these steps:

Download and install the NXLog package.
Deactivate the system service.

Only the NXLog binaries are required for use with Sidecar. Run the following command:

"C:\Program Files\nxlog\nxlog" -u

Tip

When using PowerShell, prefix the command with &.

Ingest application data

Application data can be received through various methods, depending on the technology stack and logging framework in use. To illustrate how a configuration might work in practice, this article demonstrates how to configure a Ruby on Rails application to send logs to Security Data Lake.

Ruby on Rails

Integrating Ruby on rails with Security Data Lake involves configuring your application to send structured log data using Lograge and the GELF gem.

Log all requests and logger calls

The recommended approach for sending structured information (such as HTTP return codes, controller names, and actions) about every request, as well as explicit Rails.logger calls, is to use Lograge with GELF output.

Lograge consolidates each request into a single structured log entry (instead of multiple lines generated by the default Rails logger) and supports Security Data Lake output starting from version 0.2.0.

To set up Lograge and GELF to send request and log data to Security Data Lake, follow these steps:

Add Lograge and the GELF gem to your Gemfile:
```
gem "gelf"
gem "lograge"
```

Configure both in your Rails application. We recommend adding this configuration in config/environments/production.rb:

config.lograge.enabled = true
config.lograge.formatter = Lograge::Formatters::Graylog2.new
config.logger = GELF::Logger.new(
  "datainsights.example.org",
  12201,
  "WAN",
  { host: "hostname-of-this-app", facility: "heroku" }
)

This configuration ensures that both request logs and explicit logger calls (for example, Rails.logger.error "Something went wrong") are sent to Security Data Lake.

Log Only Explicit Logger Calls

If you want to log only explicit logger calls rather than all requests, configure only the GELF logger:

Add the GELF gem to your Gemfile:
```
gem "gelf"
```

Configure the GELF logger in your Rails application. We recommend adding this configuration in config/environments/production.rb:

config.logger = GELF::Logger.new(
  "datainsights.example.org",
  12201,
  "WAN",
  { host: "hostname-of-this-app", facility: "heroku" }
)

Note

This setup will send only the messages explicitly written through Rails.logger to Security Data Lake.

Heroku

By default, Heroku injects its own logger (rails_log_stdout), which overrides custom logger configurations. To enable custom logging with GELF on Heroku, create a dummy file to make Heroku detect a pre-existing logger:

$ touch vendor/plugins/rails_log_stdout/heroku_fix

This workaround prevents Heroku from replacing your custom logger, allowing Rails to forward logs to Security Data Lake via GELF.

Ingest from files

Log files come in many different formats, which can make them difficult to parse and normalize.

For this reason, Security Data Lake does not collect log files directly. Instead, it relies on a variety of collectors and agents that are purpose-built for gathering logs from different systems and applications.

Collectors can be:

Configured and managed through existing configuration management tools in your environment.
Centrally managed and monitored through Sidecar (after it has been installed and configured).
Set up manually, if preferred, for standalone deployments.

Additionally, any program that supports the GELF or Syslog protocols can be used to send logs to Security Data Lake.

One of the most effective and widely recommended collectors for both Windows and Linux systems is Filebeat. Filebeat is designed to read log files and forward them to a central destination. To send log data to Security Data Lake, configure Filebeat to use the Logstash output, which connects to a Beats input in Security Data Lake.

Example Filebeat configuration for Linux

fields_under_root: true
fields.collector_node_id: ${sidecar.nodeName}
fields.gl2_source_collector: ${sidecar.nodeId}

filebeat.inputs:
  - type: filestream
    id: var-log
    paths:
      - /var/log/*.log

output.logstash:
  hosts: ["<forwarder_ip>:5044"]

path:
  data: /var/lib/bitdefender-sidecar/collectors/filebeat/data
  logs: /var/lib/bitdefender-sidecar/collectors/filebeat/log

Example Filebeat configuration for Windows

fields_under_root: true
fields.collector_node_id: ${sidecar.nodeName}
fields.gl2_source_collector: ${sidecar.nodeId}

output.logstash:
  hosts: ["<forwarder_ip>:5044"]

path:
  data: C:\Program Files\Bitdefender\sidecar\cache\filebeat\data
  logs: C:\Program Files\Bitdefender\sidecar\logs

tags:
  - windows

filebeat.inputs:
  - type: filestream
    id: c-log-log
    paths:
      - C:\logs\log.log

Ingest Windows event logs

Some log collection agents can send Windows event logs using Syslog, while others rely on proprietary transport protocols. Security Data Lake supports both approaches — it can receive data from agents that transmit logs via Syslog, as well as those that use the Graylog Extended Log Format (GELF) protocol.

A notable example is NXLog Community Edition, which can read Windows event logs locally and forward them to Security Data Lake over GELF, providing a simple and reliable integration method.

However, the recommended approach for collecting Windows event logs is to use Winlogbeat. This remains the most reliable and widely adopted method for ingesting Windows event data into Security Data Lake.

You can configure collectors manually, using any configuration management tool available in your environment. Alternatively, you can use Sidecar to centrally configure and control collectors. Manual installation and configuration are also supported if preferred.

To ingest messages into Security Data Lake, you must create an input that matches the type of collector sending the data. The input defines how Security Data Lake receives and processes incoming log messages.

For example:

When using NXLog, configure a GELF input.
When using Winlogbeat, configure a Beats input.

Below is an example Winlogbeat configuration that minimizes noise while still providing comprehensive and useful event information:

fields_under_root: true
fields.collector_node_id: ${sidecar.nodeName}
fields.gl2_source_collector: ${sidecar.nodeId}

output.logstash:
  hosts: ["<forwarder_ip>:5044"]

winlogbeat.event_logs:
  - name: Application
    level: critical, error, warning
    ignore_older: 48h
  - name: Security
    processors:
        - drop_event.when.not.or:
            - equals.event_id: 129
            - equals.event_id: 141
            - equals.event_id: 1102
            - equals.event_id: 4648
            - equals.event_id: 4657
            - equals.event_id: 4688
            - equals.event_id: 4697
            - equals.event_id: 4698
            - equals.event_id: 4720
            - equals.event_id: 4738
            - equals.event_id: 4767
            - equals.event_id: 4728
            - equals.event_id: 4732
            - equals.event_id: 4634
            - equals.event_id: 4735
            - equals.event_id: 4740
            - equals.event_id: 4756
    level: critical, error, warning, information
    ignore_older: 48h
  - name: System
    processors:
        - drop_event.when.not.or:
            - equals.event_id: 129
            - equals.event_id: 1022
            - equals.event_id: 1033
            - equals.event_id: 1034
            - equals.event_id: 4624
            - equals.event_id: 4625
            - equals.event_id: 4633
            - equals.event_id: 4719
            - equals.event_id: 4738
            - equals.event_id: 7000
            - equals.event_id: 7022
            - equals.event_id: 7024
            - equals.event_id: 7031
            - equals.event_id: 7034-7036
            - equals.event_id: 7040
            - equals.event_id: 7045
    level: critical, error, warning
    ignore_older: 48h

Managing sidecars

You can manage and monitor your Sidecar instances from System > Configurations > Sidecars.

Once a sidecar is installed and running, it appears on this page along with its current status. Each Sidecar instance reports its health and configuration details back to Security Data Lake, allowing you to verify that collectors are connected and functioning correctly.

Note

Obsolete or disconnected sidecars are automatically removed from the list after 14 days of inactivity. You can adjust this default retention period from the Sidecars page.

To view detailed information about a specific sidecar, click its entry under Node details. This opens a dedicated status page showing configuration parameters, active collectors, and other runtime information reported by that sidecar.

Failure tracking

In large deployments with many sidecars, identifying the cause of individual collector failures can be time-consuming. To simplify troubleshooting, Security Data Lake includes a Failure Tracking page in the Sidecars interface.

This searchable and sortable page lists each collector along with its name, status, error message, and detailed (verbose) error message, allowing administrators to quickly identify and address issues across multiple sidecars.

Create and edit variables

For added convenience, you can define variables, which you can reuse when creating or editing collector configurations. This eliminates the need to manually enter the same value multiple times. For example, you can define a ${user.forwarder_host} variable whose value is the IP address of the Forwarder deployed in your network, and then use the variable across multiple configurations.

To create a configuration variable, follow these steps:

Select Edit for a configuration.
Click the Variables tab in the Collector Configuration Reference section of the configuration page and select Create variable.
In the dialog box, enter a Name and (optional) Description, as well as a value for the variable (such as the forwarder IP address mentioned in the example above) in the Content field.
When you are done, click Save.
You can then use the variable (for example, ${user.forwarder_host}) in other configuration files instead of manually entering the value every time.

Securing communication

To secure the communication between the collector and Security Data Lake, enable TLS in your input configuration. For example, when configuring a Beats input, select Enable TLS. Security Data Lake will then generate a self-signed certificate for the input, ensuring encrypted data transfer between the collector and the Security Data Lake server.

Assigning tags

You can use tags to control how collector configurations are assigned to hosts. Tags determine which configurations each endpoint receives.

For example, you can create a configuration to collect Apache access logs and assign it the tag apache. Any Sidecar instance running on a web server with the same apache tag will automatically fetch and apply this configuration, allowing it to collect and forward web access logs to Security Data Lake.

This is the relevant section of a typical Sidecar configuration YAML file found on an endpoint:

# A list of tags to assign to this Sidecar. Collector configuration matching any of these tags will automatically be
# applied to the Sidecar.
# Example:
# tags:
# - apache-logs
# - dns-logs

Once a system tag is applied to an endpoint, it automatically begins collecting logs and forwarding them to Security Data Lake.

This feature simplifies configuration management by automatically assigning collector configurations to new clients whose YAML files include the corresponding tags.

Tags can be defined on any endpoint, such as Windows Servers, Windows Workstations, or Linux systems, and can be used across different collectors including Winlogbeat, Filebeat, Metricbeat, and NXLog.

Sidecar also supports assigning multiple collector configurations to the same endpoint. For instance, a Windows client could have configurations for both winlogbeat and sysmon tags applied simultaneously.

Tip

You can also use snippets to include additional collector configuration details that may not be easily defined through the system interface.

Snippets can contain entire configurations (such as an NXLog setup) or extend existing input and output definitions.

All snippets are directly included in the generated collector configuration, regardless of whether their inputs or outputs are already defined.

Troubleshooting

Sidecar writes its log files to the directory specified in the log_path configuration parameter. Each backend (collector) has its own log file where you can check for issues such as file permission errors or log transmission problems.

The sidecar itself writes to a file named sidecar.log, which contains general operational messages. Errors such as failed connection to the Security Data Lake API are typically recorded in this file.

You can also start the sidecar in the foreground with debug output enabled to monitor its activity in real time:

bitdefender-sidecar -debug

This command is useful for troubleshooting connection issues, configuration errors, or collector startup problems.

Uninstalling

The process of uninstalling a sidecar differs based on the operating system where it was installed.

Linux

On Linux systems, you can simply uninstall the package using your package manager. For example:

sudo apt-get remove bitdefender-sidecar

sudo yum remove bitdefender-sidecar

Windows

On Windows systems, stop and uninstall the Sidecar service by running the following commands:

"C:\Program Files\Bitdefender\bitdefender-sidecar.exe" -service stop 
"C:\Program Files\Bitdefender\bitdefender-sidecar.exe" -service uninstall

Note

When using PowerShell, prefix each command with &.

After running these commands, you can safely remove the sidecar directory if it is no longer needed.

In this section:

Sidecars

Sidecar architecture

Installing Sidecar

1. Set up the sidecar in Security Data Lake

1.1 Set up an input

1.2 Create an API token

1.3 Download Sidecar

2. Prepare your local environment

Note

Windows

Interactive installation

Silent Installation

Adding a Winlogbeat collector configuration

Linux - Set up the host machine

sidecar.yml configuration reference

Bitdefender Sidecar releases

Bitdefender Sidecar 1.5.6

Release date

Download links

Sidecar collectors

Default collectors

Editing default collectors

Custom collectors

Installing NXLog

On Ubuntu

On CentOS

On Windows

Tip

Ingest application data

Log all requests and logger calls

Log Only Explicit Logger Calls

Note

Heroku

Ingest from files

Ingest Windows event logs

Managing sidecars

Note

Failure tracking

Create and edit variables

Securing communication

Assigning tags

Tip

Troubleshooting

Uninstalling

Linux

Windows

Note

Search results

`sidecar.yml` configuration reference