After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
Configure the logging levels for daemons
You can adjust logging levels for each daemon running in to help debug or troubleshoot issues.
daemons
The following daemons in work to control collection and scheduling tasks in the background independently from the web interface:
Daemon | Description |
---|---|
Action daemon | Responsible for launching actions by putting into effect the appropriate app on the specified asset.
The following key actions are logged by this daemon:
|
Cluster daemon | Responsible for communicating with cluster nodes. Available only in clustered environments. |
Decide daemon | Responsible for operating on incoming data.
The following key actions are logged by this daemon:
|
Ingest daemon | Responsible for ingesting data into the product.
The following key actions are logged by this daemon:
|
Proxy daemon | Responsible for communicating with Splunk mobile apps to register devices and send notifications to mobile users. This daemon is available only when the mobile app feature is enabled. |
Watchdog daemon | Responsible for tracking the status of other daemons and adding or removing them in the system startup list.
The following key actions are logged by the watchdog daemon:
|
Workflow daemon | Responsible for managing approval requests to action reviewers and asset owners.
The following key actions are logged by the workflow daemon:
|
Configure the logging level for each daemon
Adjust the logging levels as needed to assist Support with troubleshooting any issues you might experience.
- From the main menu, select Administration.
- Select System Health > Debugging.
- Select a logging level for each daemon you want to change. The log levels determine the message types that are written to each daemon's corresponding log file. The Debug level is the most verbose level of logging and is useful for troubleshooting.
- (Optional) Click Download Logs to download a copy of the current log files for manual investigation or a submission to support.
A zippedTAR
archive of the logs is downloaded to<PHANTOM_HOME>/var/log/phantom
. - Click Save Changes.
At the operating system level, log files are in <PHANTOM_HOME>/var/log/phantom
. Adjust logging levels only at the direction of Support.
Configure the logging format
You can configure the logging format for JSON or plaintext. Configure the format through the CLI as the root user. For example:
[phantom@phantom]# phenv set_preference —logging-format <format>
For NRI, you don't need to run the command as root user.
The valid formats are plain
and json
.
Take note of the following items:
- Running the command restarts Splunk SOAR (on-prem).
- If you are using clusters, you need to run the command on each node.
- You can reconfigure the plaintext format at any time.
Example plaintext log structure
See the following sample of a common log format:
Oct 5 22:55:18 localhost DECIDED[7177]: TID:7422 : WARNING: DECIDED : rules_engine.cpp : 1503 : DECIDED_CMD_PROCESS_CONTAINERS : All rules FAILED t
This table summarizes the structure of the example log message.
Log message content | Description |
---|---|
Oct 5 22:55:18 | Timestamp of when the log message was generated. |
localhost | Name of the host where the log message was generated. |
DECIDED[7177]: | Name of the component and process ID (PID) generating the message. |
TID:7422: | Threat ID (TID) of the message. |
WARNING: | Log level or class of the message. |
DECIDED: | Functional component that generated the log message. |
rules_engine.cpp: | Source file applicable to the log message. |
1503: | Line number in the source file that caused this log message to be generated. |
DECIDED_CMD_PROCESS_CONTAINERS: All rules FAILED to process the container: 2964. Error: Playbook 'local/test11 (version: 1, id: 711)' cannot be executed since it is: NOT ACTIVE, ENABLED and VALID | The log message. |
Monitor logs using an external SIEM
You can use an external SIEM such as Splunk Enterprise to monitor the status of your instance using the log files from . Monitor errors in actions execution through the ingestion of the actiond.log file, and you can find platform information in the watchdogd.log file.
These files are constantly updated by the components of the platform. Use a service to monitor the log file regularly, or copy and forward the log files on a regular basis.
Rotate your logs when they get too large
The logs in <PHANTOM_HOME>/var/log/phantom
are automatically rotated when they reach 50MB in size.
- keeps a running archive of the last 10 rotated logs.
- The oldest log is deleted when a new log is rotated in.
- You can configure log rotation settings for your organization's IT requirements by modifying the phantom_logrotate.conf file. By default, the configuration file is located in
<PHANTOM_HOME>/etc/logrotate.d/phantom_logrotate.conf
. A copy of that file is included later in this topic. - Any updates to this configuration will be automatically applied the next time 's scheduled logrotate job runs.
phantom_logrotate.conf
# On NRI all logs are owned by the same user and we do # not use rsyslogd as that would require root to configure. # A special logging case for NRI is spawn logs. since spawn # cannot use syslog, watchdog sets up a pipe (spawn_pipe) # that spawns can use to log which is then sent to spawn.log # Since on NRI we use copytruncate for all logs, we don't # need to exclude wsgi and supervisord. So we use # copytruncate for all logs. # create will use the same user/group as the original file # when user/group are not specified. __PHANTOM_VAR__/log/phantom/*.log { copytruncate rotate 10 size 50M start 1 create 0660 } # Splunk Audit logs __PHANTOM_VAR__/log/phantom/audit.log { copytruncate maxage 1 rotate 10 size 50M start 1 create 0660 } # Rotate NGINX logs in NRI the same as they were for # priv installs __PHANTOM_VAR__/log/nginx/*.log { daily rotate 10 missingok notifempty compress delaycompress create 0660 sharedscripts postrotate /bin/kill -USR1 `cat __PHANTOM_VAR__/run/nginx.pid 2>/dev/null` 2>/dev/null || true endscript } # Rotate PGBouncer logs in NRI the same as they were for # priv installs __PHANTOM_VAR__/log/pgbouncer/*.log { weekly rotate 5 missingok notifempty compress create 0660 sharedscripts nodateext } include __PHANTOM_HOME__/usr/local/logrotate.conf }
View ingested container statistics using Ingestion Status | Create and download or upload a diagnostic file |
This documentation applies to the following versions of Splunk® SOAR (On-premises): 5.4.0, 5.5.0, 6.0.0, 6.0.1, 6.0.2, 6.1.0, 6.1.1, 6.2.0, 6.2.1, 6.2.2, 6.3.0
Feedback submitted, thanks!