Cortex XDR collector

Verify data collection

Service components

Once the collector has been launched, it is important to check if the ingestion is performed in a proper way. To do so, go to the collector’s logs console.

This service has the following components:

Setup is common for every service, so its output is displayed in this section.

On the other hand, Pullers are specific to each Service, so their outputs are shown in their corresponding sections below.

Setup output

A successful run has the following output messages for the setup module:

Restart the persistence

Some services in this collector use persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:

1. Edit the configuration file.

2. Change the value of the start_date parameter to a different one.

3. Save the changes.

4. Restart the collector.

The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.

Verify data collection

Puller output

A successful initial run has the following output messages for the puller module:

After a successful collector’s execution (this is, no error logs were found), you should be able to see the following log message:

Restart the persistence

This service makes use of persistence. You can check how to restart it above.

Verify data collection

Puller output

A successful initial run has the following output messages for the puller module:

After a successful collector’s execution (this is, no error logs were found), you should be able to see the following log message:

Restart the persistence

This service makes use of persistence. You can check how to restart it above.

Devo categorization and destination

All events of this service are ingested into table edr.cortex_xdr.audit_management

Verify data collection

Puller output

A successful initial run has the following output messages for the puller module:

After a successful collector’s execution (this is, no error logs were found), you should be able to see the following log message:

Restart the persistence

This service makes use of persistence. You can check how to restart it above.

Devo categorization and destination

All events of this service are ingested into table edr.cortex_xdr.all_alert

Verify data collection

Puller output

A successful initial run has the following output messages for the puller module:

After a successful collector’s execution (this is, no error logs were found), you should be able to see the following log message:

Restart the persistence

This service makes use of persistence. You can check how to restart it above.

The initialization module is in charge of setup and running the input (pulling logic) and output (delivering logic) services and validating the given configuration.

The initialization module is in charge of setup and running the input (pulling logic) and output (delivering logic) services and validating the given configuration.

A successful run has the following output messages for the initializer module, including all services together:

The event delivery module is in charge of receiving the events from the internal queues where all events are injected by the pullers and delivering them using the selected compatible delivery method.

A successful run has the following output messages for the initializer module:

Sender statistics

Each service displays its own performance statistics that allow checking how many events have been delivered to Devo by type:

To check the memory usage of this collector, look for the following log records in the collector which are displayed every 5 minutes by default, always after running the memory-free process.

• The used memory is displayed by running processes and the sum of both values will give the total used memory for the collector.

• The global pressure of the available memory is displayed in the global value.

• Al metrics (Global, RSS, VMS) include the value before freeing and after: previous -> after freeing memory

Sometimes it is necessary to activate the debug mode of the collector's logging. This debug mode increases the verbosity of the log and allows you to print execution traces that are very helpful in resolving incidents or detecting bottlenecks in heavy download processes.

• To enable this option you just need to edit the configuration file and change the debug_status parameter from false to true and restart the collector.

• To disable this option, you just need to update the configuration file and change the debug_status parameter from true to false and restart the collector.

For more information, visit the configuration and parameterization section corresponding to the chosen deployment mode.

This collector has different security layers that detect both an invalid configuration and abnormal operation. This table will help you detect and resolve the common errors for the current services.