Share data from Splunk SOAR (On-premises)
Opt in or opt out of sharing Usage Data
You can change data sharing settings anytime using either the user interface or the command line interface.
Use the Splunk SOAR (On-premises) interface
Modify general Usage Data share settings in the graphical user interface following these steps:
- From the main menu, select Administration.
- Expand the Product Settings drop-down list.
- Select Data Sharing.
- Adjust Usage Data category toggles to the On (opt in) or Off (opt out) position.
Use the command line interface
Modify Rum and FullStory Usage Data share settings using the command line interface and the following management commands:
For Splunk RUM telemetry:
phenv set_preference --rum [{yes,no}]
Use yes to opt in, no to opt out.
For FullStory telemetry:
phenv python -m manage fullstory
How data is collected
Splunk SOAR (On-premises) uses several technologies running in the background to collect usage data.
- Splunk Web Analytics (swa.js)
- Splunk Real User Monitoring (RUM)
- FullStory
Usage Data Telemetry
A Splunk SOAR (On-premises) background task runs at a specified system time to collect telemetry data which is transmitted to Splunk's products-telemetry server.
Each time a user logs in some system settings and license metrics are collected.
FullStory is used to collect experiential user journey information from the Visual Playbook Editor with user personally identifiable information redacted. In the Splunk SOAR (On-premises) interface, FullStory data collection can either be managed from the graphical interface by switching the main Telemetry Usage Data toggle on or off, or alternatively, by discrete command using the command line interface, as described earlier in this article.
For information about the Visual Playbook Editor see Use playbooks to automate analyst workflows in Splunk SOAR (On-premises) in Build Playbooks with the Playbook Editor.
RUM Telemetry
Splunk Real User Monitoring (RUM) connects to a non-PCI-compliant system.
RUM is designed to collect and send information like console errors, JavaScript errors, and page load performance metrics without user-provided values, such as username or email, or any URI or URL parameters that personally identify individual users. See What is Splunk RUM? for more information.
How data is stored
Splunk's retention time frames for Usage Data are described here and those for Splunk Rum are described here. For more information about Splunk's data collection and privacy practices see the Splunk Privacy Policy and learn how Splunk Protects.
Telemetry impacts on performance
Collecting telemetry data minimally affects database performance and the loading of the Splunk SOAR (On-premises) UI.
General Usage Data
Splunk SOAR (On-premises) telemetry collects the following basic usage information:
Name | Description | Example |
---|---|---|
Items in this section apply to all telemetry objects | ||
app.session.soar.*
automation.*
automation.summary.*
orchestration.*
| Either:
And:
Splunk SOAR sends the deploymentID with every event. This change adds either companyID or stackID and licenseNumber, licenseIssueDate, licenseExpirationDate, and licenseInstance wherever deploymentID is currently logged. |
Or
|
app.session. objects | ||
app.session.soar.apiTime
| Reports roundtrip time consumption for each API request. |
|
app.session.soar.error
| Reports uncaught errors of front-end Splunk SOAR scripts. |
|
app.session.soar.license
| Reports license status, limits, and usage information. Sent once per session.
|
|
app.session.soar.pageview
| Reports which pages are visited by users. |
|
app.session.soar.
systemSettings
systemSettings
| Reports the feature on/off settings and product version.
|
|
app.session.session_start
| Reports the browser and OS, along with their versions. |
|
app.session.phantom.viewTime
| Reports time spent on a specific page. Only tracked for specific pages. |
|
app.session.soar.vpe
| Reports:
CAUTION: The classic playbook editor will be deprecated soon, in 2024. For information on converting your playbooks, see Convert classic playbooks to modern playbooks.
|
|
app.session.soar.vpeTime
| Reports the time in milliseconds it took for the VPE to load in the browser. |
|
automation.summary objects | ||
automation.summary.app_summary
| A summary of apps installed on the system.
|
|
automation.summary.
case_summary
| A summary of opened and closed cases in the last 24 hours.
|
|
automation.summary.
ingestion_status
| Ingestion status and events ingested per Splunk SOAR deployment.
|
|
automation.summary.
playbook_names
| A summary of playbooks names and whether or not a playbook is custom.
|
|
automation.summary.
playbook_runs.by_trigger
| Counts of playbook runs by trigger, either adhoc or by automation, aggregated over the last day. Emitted once daily. |
|
automation.summary.
publish_telemetry_time_taken
| Start time, end time, and a the calculated total time of the telemetry publish job.
|
|
automation.summary.
workbook_summary
| A summary of opened and closed workbooks.
|
|
orchestration. objects | ||
orchestration.summary.
action_runs.by_trigger
| Counts of action runs by trigger, either adhoc or by automation, aggregated over the last day. Emitted once daily. adhoc: Counts of adhoc action runs by status
automated: Counts of automated action runs by status all: Counts of both adhoc and automated playbook runs by status cloudWorksEnvironment: The environment in which the Splunk SOAR cloud stack is deployed; development (dev), staging (stg), or live (lve). missionControlDeploymentID: A nullable field identifying the Splunk Mission Control instance paired to the Splunk SOAR instance soarDeploymentID: Uniquely identifies the Splunk SOAR stack that emitted the metric |
|