Understanding Edge Processor

What you will learn

This module introduces Edge Processor and outlines the problems it solves. By the end of this
module, you will be able to accomplish the following:
Define Edge Processor
Identify use cases for Edge Processor
Explain how Edge Processor works

What is Edge Processor?

Edge Processor is a managed service within Splunk Cloud Platform used to process data at the
edge of your network. Edge Processor allows you to manage data-in-motion before it gets to its
destination.

Do you want to reduce the index size?

Do you want to redact something?
Do you want to direct processed data in particular ways?
You often look to accomplish these objectives with third-party solutions. Now, with Edge
Processor, you can:
• drop unnecessary data
• mask sensitive fields
• normalize and enrich payloads
• route data to self-managed Splunk indexers, Splunk Cloud indexers, or even data lakes
such as Amazon S3
• transform your data before it is indexed
Edge Processor can handle all of these use cases within the boundaries of your network
environments.
You may have already deployed Splunk Heavy Forwarders in your environment. You may also
have heard of Splunk Ingest Actions to meet similar use cases. And now you are wondering why
you would ever introduce another similar component in your environment.

Each forwarder deployment is independent, so the collection process is opaque. Different inputs
are setup in different places. Edge Processor provides a centralized cloud control plane from
which all of your nodes can be centrally configured and monitored. Additionally, SPL2 pipelines
are easier to interpret than many layered .conf files.

Edge Processor also allows you to do the following:

• Horizontally scale and load balance fleet-wide by adding more Edge Processor instances.
These node binary and pipeline designs are auto-updated.

• SPL2 provides consistent pipeline authoring experience.

Edge Processor helps you control overall operational cost more effectively. The Edge Processor
service is provided as an integral part of Splunk Cloud at no additional cost. All you need is to
supply your own Edge Processor hosts.

How does Edge Processor work?

The Edge Processor solution consists of three parts:

• Edge Processor service

• Edge Processor node(s)

• Pipelines composed with SPL2, the next-generation of the Splunk Processing Language

Combined, you can enable data processing at the edge of your network. Flip the cards below to
learn more about each:

Edge Processor service

Splunk hosts the Edge Processor service as part of the Splunk Cloud Platform. The Edge
Processor service provides a cloud control plane that lets you deploy configurations, monitor
the status of your Edge Processors, and gain visibility into the amount of data that is moving
through your network.

Edge Processor node(s)

You install Edge Processors on self-managed hosts. Edge Processors provide a data plane that
lets you reduce and sanitize your data before sending it outside of your network.

Pipeline

In the Edge Processor service, you create pipelines to specify what data to process, how to
process it, and what destination to send the processed data to. Then, you apply pipelines to
your Edge Processors to configure them to start processing data according to those instructions.

The following diagram provides an overview of how these components work together:

Using the Splunk Cloud Platform

You access your Edge Processor service through the Splunk Cloud Platform. The Splunk Cloud
Platform, or SCP, is a cloud-native environment that hosts a variety of Splunk cloud application
services. Unlike the classic Splunk Cloud stacks, the SCP is a multi-tenant environment where all
service binaries are centrally managed but independently deployed based on subscriptions. A
tenant is the namespace for a customer entity where Splunk cloud services are subscribed and
available. The tenants are isolated from each other in cells, so the security and resources for
each tenant is protected. It is the SCP resource container that defines what activities the
members of a tenant are allowed to perform.

Using Edge Processor instances

The path your data takes remains the same as before – it moves from sources to destinations.
The only change is the additional Edge Processor instances that sit between your Splunk input
agents and the storage destinations. Edge Processor currently supports Splunk forwarders, HEC
inputs, and Syslog.
Input agents forward the data to the Edge Processor instances. Each instance acts as an
additional data processing engine. Edge Processor pipelines expressed in SPL2 are the actual
instructions that refine the data. Any source with no applicable pipeline is sent to its default
destination. Edge Processors can be configured to drop or route by default.

Edge Processor can run as a standalone instance or as a collection of nodes; however, a host can
only support one Edge Processor instance.

Forwarders can be configured to send data to Edge Processor in the same way that they are
configured to send data to indexers, using outputs.conf.

Using the Edge Processor service

So, how does an Edge Processor instance in your network know which version of executables
and pipelines to use?

When you get the installation script from the Edge Processor service, it installs a data processing
engine along with a Splunk instance management tool called "Supervisor". Supervisor allocates
needed resources on the host and communicates to the Edge Processor Service at a set interval
using the same secure channel used in Splunk Assist called "Teleport". Supervisor maintains the
connection to the Edge Processor service, reports its heartbeats, and monitors any updates on
its runtime and pipelines. When Splunk releases new features for Edge Processor, Supervisor
detects these changes and automatically updates its executables.

Edge Processor regional availability

Your Edge Processor tenant must be paired with your Splunk Cloud stack in the same region. As
of July 2024, the Edge Processor Service is available in the following regions:

• US (Oregon, Virginia)

• UK (London)

• Europe (Dublin, Frankfurt, Paris)

• Asia Pacific (Singapore, Sydney, Tokyo)

• Canada (Central)

Other regions will be online soon.

Splunk Cloud Platform Service Description

Available regions and region differences

Getting started with Edge Processor

What You Will Learn

This module guides you through the initial configuration of your Edge Processor service and
provides an overview of its menu. By the end of this module, you will be able to accomplish the
following:

• Configure Splunk Cloud Stack for Edge Processor

• Manage permissions for Edge Processor Service

• Manage Edge Processor users

• Enable communications between the Edge Processor and Splunk Cloud Stack

• Navigate Edge Processor Service menu options

Accessing the Edge Processor service

You access your Edge Processor tenant through the Console Service page. If you're familiar with
AWS, the Splunk Cloud Console is similar to the AWS Console in that it provides a single point-
of-entry for SCS services.

To access, navigate to: https://console.scs.splunk.com(opens in a new tab)

Let's break this URL down:

• scs.splunk is the service domain

• console represents the current application ID

When you navigate to the URL, you will be prompted to enter your tenant ID.
Let's say you work for Awesome Company (I hear they're hiring!) and your Splunk Cloud Stack
URL is the following:

https://awesomeco.splunk.com

In this example, awesomeco is your stack ID. It's also your tenant ID. After signing in to the
Splunk Cloud Console, you will be routed to a URL similar to the following:

https://console.scs.splunk.com/awesomeco

Your tenant and the Splunk Cloud Platform communicate via a dedicated bridge called, wait for
it... scpbridge. It allows Splunk Cloud users to access Splunk Cloud services. If you already have
an account in the Cloud stack and the proper role-capabilities, your identity is carried forward to
all SCS experiences. Your Console page displays all the applications available to you. By default,
any user with the sc_admin role is given the tenant.admins and tenant.users access permissions
and admin privilege in the Edge Processor service.

The screenshot below shows the landing page presented to you when you first access the
Splunk Cloud Platform application.

Click Launch to start the SCP and access your Edge Processor.

Configuring initial settings

You will need to configure some initial setting when you first activate your Edge Processor
Service:

• Create a role and service account that will allow your tenant to access SCP indexes

• Connect your tenant to your SCP deployment

• Enable communication between your SCP deployment and Edge Processor

We'll address these as we proceed, but first...

Considering user accounts

Who in your Splunk Cloud stack should have access to the service and with what capabilities?

Who should be able to update the scpbridge connection?

Which indexes in the paired Cloud stack should be available in SCP?

Answering these questions will help you determine the additional roles you need to create and
manage. If you want to have more users in the cloud-stack working with the Edge Processor
service, further planning is advised.

There are three different Splunk user-roles you will want to consider:

• Edge Processor Service administrators

• scpbridge service account: This account is used to expose the indexes in your cloud-
stack

• Edge Processor users: These are the optional users who can add Edge Processor
instances and build and apply data pipelines but can't modify the scpbridge connection
settings

Their privileges in SCP are associated with their Splunk role capabilities.

Flip the following cards to learn more about each role:

Edge Processor Service Administrators: A user with the tenant.admins SCS role

Service Account: This account is used to expose the indexes in your cloud-stack to the SCP

Edge Processor users: These are the optional users who can add Edge Processor instances and
build and apply data pipelines but can't modify the scpbridge connection settings.

The Edge Processor Service Administrator is you. You are the tenant administrator because you
have the sc_admin role in the cloud stack. But if you want to assign someone as a backup
tenant-administrator without granting the full sc_admin role, allowing
the admin_all_object and edit_edge_processor capabilities will do. With these capabilities, the
users can access and update the scpbridge connection details.
Creating a Service Account

To create a service account, you need a Splunk role. You may use the existing role but
dedicating a new role is recommended.

Log into your Splunk Cloud-stack as a user with the sc_admin role.

Clone the user role

On the user role, under the Actions column, select the Edit dropdown and then select Clone.

Log into your Splunk Cloud-stack as a user with the sc_admin role.

Navigate to Settings > Roles.

Clone the user role.

After entering a Name, proceed to Capabilities.

After selecting Capabilities, proceed to Indexes, and determine which indexes you want to
expose.
Click Clone to create the new role.

Navigate to Settings > Users and select New User.

Give the user a descriptive name, such as scp_svc_acct.

Require password change on first login

When you create the service account with this role, be sure to deselect the check box for
"Require password change on first login".
Confirm the settings and click Save.

Creating Edge Processor users

The Edge Processor user-role is optional. It's not needed in an environment where only a few
users will use and manage the Edge Processor service. In a large deployment where there are
different groups responsible for managing destinations and applying pipelines on different Edge
Processor instances, having a bit more granular permissions would be useful.

Note that when you remove the admin_all_object capability and keep only
the edit_edge_processor capability, the users in this role can only work with pipeline-related
menus. They will not have the ability to modify the bridge connection settings.

Configuring the default connection

When you access any Edge Processor menu for the first time, it reminds you to run the first-time
setup. If you get the prompt to do so, configure the accompanied connection and destination
forms.

To set up the initial connection to your stack, click the "Settings" icon, and then select System
connections. You will be routed to a page similar to the following:
Click New Platform Connection and fill in the form.

Connection name
The name scpbridge is already set to signify the paired default connection.
Hostname
Enter the hostname of your Splunk Cloud stack.
Service account username
Enter the username for the service account that you prepared in the previous topic.
If and when the connection is successful, you will get a pop-up notification. If you receive an
error notification, double check your URL and your credentials or go back and verify your service
account was created correctly. Your system connections page will now display
your scpbridge connection.

Select Datasets from the sidebar to navigate to the Datasets dashboard.

Any indexes that this account is allowed to access will be listed here.

Configuring forwarder credentials

To secure data going to your Cloud stack from any Edge Processor instances, you must use the
same forwarder credential package from your stack.

To configure, first download the universal-forwarder-credentials package and save it locally.

In your Cloud Stack, navigate to Apps > Universal Forwarder.

On the Universal Forwarder landing page, click the Download Universal Forwarder
Credentials button.

Meanwhile, back in your tenant, navigate to the Data management dashboard and click on
the Set up Edge Processors button. This will route you to the First-time setup page where you
can upload your UF credentials:
During the first-time setup, you add this credentials package to
the default_splunk_cloud_destination. Upload the splunkclouduf.spl file, then click Save at the
bottom of the page.

You only need to do this once. As you deploy your Edge Processor instances later, they will
automatically get this package. When you update the package in the future, the Supervisor
process running on every Edge Processor instance will automatically pick up this change and
update itself as well. This is one of the key benefits of having the Splunk Cloud Service centrally
manage a fleet of Edge Processor instances.

This completes the initial setup tasks.

Securing Splunk Cloud Platform

Define roles on the Splunk platform with capabilities

https://docs.splunk.com/Documentation/SplunkCloud/latest/Security/Rolesandcapabilities

Define roles on the Splunk platform with capabilities

There are two versions of this topic: one for Splunk Cloud Platform and the other for Splunk
Enterprise. This is the Splunk Cloud Platform version of the topic. To change to the Splunk
Enterprise version, select "Splunk Enterprise" from the "Product" drop-down list box in this topic.

When you perform user management on the Splunk platform, you can assign one or more roles
to the user as part of that process. Each role contains a set of capabilities. These capabilities
define what users who hold a certain role can do on the Splunk platform.

Users can only access the Splunk platform and use capabilities through roles that you assign to
them. For example, if a user receives the edit_tokens_settings capability through a role, that user
can modify the Token Authentication scheme on the Splunk platform instance. If they receive
the admin_all_objects capability through another role, they can modify nearly any object on the
instance.

Capabilities are always additive in nature. You cannot take away the ability to do something by
adding a capability. If you don't want users who hold a role to perform a certain function on
your Splunk platform instance, then do not assign that role a capability that lets a user perform
that function.

Similarly, users who hold multiple roles can access any capabilities that are assigned to those
roles. If you do not want a certain user to have access to all the capabilities that a role provides,
do not assign that role to that user.

In nearly all cases, capabilities whose names begin with edit_ give users the ability to perform
create, read, update, and delete operations for the feature with which they associate. For
example, the edit_udp capability grants you the ability to create, read, update, and delete UDP
network inputs - even if you do not have access to edit other types of inputs. Exercise caution
when assigning edit_ capabilities.

Add, edit, and remove capabilities from roles

You can add, edit, or remove capabilities from new, existing, and default roles. These actions
change the kind of access that the role provides. For example, you might give a role the
capability to add inputs or edit saved searches.

To add or change the capabilities of a role, choose one of the following methods:

• To add or change the capabilities of a role in Splunk Web, see Create and manage roles
with Splunk Web.

• To create roles and assign capabilities by editing the authorize.conf configuration file in
Splunk Enterprise, see Add and edit roles with authorize.conf.

• To learn more about roles and how they work, see About configuring role-based user
access.

Splunk is in the process of retiring the use of the "admin" user and role for external customers.
The "admin" account and role are holdovers from the early days of the Splunk Cloud Platform
service, and as Splunk continues to evolve its capabilities in Splunk Cloud Platform, the account
and role are no longer relevant for these customers.

Splunk platform capabilities

This table shows the capabilities that you can add to any role, and whether or not the
capabilities are assigned by default to the user, power, admin or sc_admin roles.

For the most up-to-date list of capabilities that are assigned to a role, see the Imported
Capabilities text box on the Create a role page in Splunk Web.

Because capabilities change frequently from release to release, not every capability that is
available to the Splunk platform appears in this list. Apps and add-ons can add their own
capabilities which also do not appear here. See the documentation for the app or add-on that
you use to potentially get information on app- and add-on-specific capabilities.
Capability name What it lets you do User Power Admin Sc_admin

accelerate_datamodel Enable or disable acceleration for data models. Set acceleration to true to enable X X
automatic acceleration of this data model. Additional space is required depending on
the number of events, fields, and distinct field values in the data. See the Knowledge
Manager Manual for more information.

accelerate_search Lets the user enable or disable acceleration for reports. The user must also have the X X X X
schedule_search capability assigned. Works for searches that use transforming
commands. See the Knowledge Manager Manual for more information.

acs_* Capabilities required to run operations against Admin Config Service (ACS) API X X
endpoints. See Manage ACS API access with capabilities in the Admin Config Service
Manual.

admin_all_objects Lets the user access and modify any object in the system regardless of any restrictions X X
set in the objects. For example user objects, search jobs, reports, and knowledge objects.
Lets the user bypass any ACL restrictions, much the way root access in a *nix
environment does.

change_authentication Lets the user change authentication settings and reload authentication. See the Securing X X
Splunk Enterprise Manual for more about authentication.

change_own_password Lets the user change their own password. X X X X

delete_by_keyword Lets the user use the "delete" operator. The "delete" command marks all of the events
returned by the search as deleted. This masks the data from showing up in search results
but does not actually delete the raw data on disk. See the Search Manual for more
information.

delete_messages Lets a user delete system messages that appear in the UI navigation bar. X X X

dispatch_rest_to_indexers Lets a user dispatch the REST search command to indexers. X

edit_bookmarks_mc Lets a user add bookmark URLs within the Monitoring Console. The URLs redirect X
administrators to Monitoring Console instances in other Splunk deployments.

edit_deployment_client Lets the user change deployment client settings. See the Managing Indexers and X
Clusters of Indexers Manual for more about the deployment client.

edit_deployment_server Lets the user change deployment server settings. User can change or create remote X
inputs that are pushed to the forwarders and other deployment clients. See the
Managing Indexers and Clusters of Indexers manual for more about the deployment
server.

edit_dist_peer Lets the user add and edit peers for distributed search. See the Managing Indexers and X
Clusters of Indexers Manual for more information.

edit_edge_processor Users with this capability can create, update, delete, and view all resources in the Edge X
Processor service. Resources include source types, pipelines, Edge Processors, and
destinations.
edit_encryption_key_provider Lets the user view and edit key provider properties when they use Server-Side X
Encryption (SSE) for a remote storage volume.

edit_field_filter Lets a user create, edit, or delete field filters by using Splunk Web or the Splunk platform X X
REST API authorization/fieldfilters and authorization/fieldfilters/{name} endpoints
to update field filters. See Protect PII, PHI, and other sensitive data with field filters.

edit_forwarders Lets the user change forwarder settings, including settings for SSL, backoff schemes, etc. X
Also used by TCP and Syslog output admin handlers.

edit_global_banner Lets administrators display a persistent banner message to all users. X X

•
• Non-dismissible, and viewable by all users on all product pages.

• Customize text and background color, with ability to also include a

hyperlink.

edit_health Lets a user enable/disable health reporting, set health status alerts, and set indicator X
thresholds for a feature in the splunkd health status tree through the server/health-
config/ endpoint.

edit_health_subset Lets a user disable or enable health reporting for a feature in the "health_subset" view of X
the health status tree. Actions are performed through the server/health-
config/{feature_name} endpoint.

edit_httpauths Lets the user edit and end user sessions through the httpauth-tokens endpoint. X

edit_indexer_cluster Lets the user edit indexer clusters. See the Managing Indexers and Clusters of Indexers X
Manual for more about indexers.

edit_indexerdiscovery Lets the user edit settings for indexer discovery, including settings X
for master_uri, pass4SymmKey, and so on. Used by Indexer Discovery admin handlers.

edit_ingest_processor Users with this capability can create, update, delete, and view all resources in the Ingest X
Processor solution. Resources include pipelines, and destinations.

edit_input_defaults Lets the user use the server settings endpoint to change default hostnames for input X X
data.

edit_ip_allow_list Lets the user edit ip allow lists for their deployment. See configure IP allow lists using X X
Splunk Web.

edit_local_apps Lets the user edit actions for application management. Applies only when you set X
the enable_install_apps setting to "true" in authorize.conf.

edit_log_alert_event Lets a user log an event when an alert condition is met. Also lets the user select the "Log X X X
an event" option for an alert action in Splunk Web.

edit_limits_conf Lets a user view and edit limits.conf settings using the Configure limits UI in Splunk Web. X X
edit_metric_schema Lets the user set up log-to-metrics transformations, which can convert single log events X
into multiple metric data points.

edit_metrics_rollup Lets the user create and edit metrics rollup policies, which set rules for the aggregation X
and summarization of metrics on a specific metric index.

edit_monitor Lets the user add inputs and edit settings for monitoring files. Also used by X
the standard inputs endpoint and the one-shot input endpoint.

The The sc_admin role does not receive the edit_monitor capability because Splunk
Cloud Platform cannot directly monitor files and directories.

edit_modinput_journald Lets the user add and edit journald inputs. This input is not available on Windows. X

edit_own_objects X X X X

edit_roles Lets the user edit roles and change user/role mappings. Used by both X
the user and role endpoint.

edit_roles_grantable Lets the user edit roles and change user/role mappings for a limited set of roles. Can X X
assign any role to other users. To limit this ability, configure grantableRoles in
authorize.conf. For example: grantableRoles = role1;role2;role3

edit_scripted Lets the user create and edit scripted inputs. X

edit_search_concurrency_all Lets a user edit settings related to maximum concurrency of searches. X

edit_search_concurrency_scheduled Lets a user edit settings related to concurrency of scheduled searches.

edit_search_head_clustering Lets the user edit search head clustering settings. X X

edit_search_schedule_priority Lets the user assign a search a higher-than-normal schedule priority. For information X X
about the search scheduler, see the Knowledge Manager Manual.

edit_search_schedule_window Lets the user assign schedule windows to scheduled reports. Requires the X X X X
schedule_search capability. For more about the search scheduler, see the Knowledge
Manager Manual.

edit_search_scheduler Lets the user enable and disable the search scheduler. See the Knowledge Manager X X
Manual.

edit_search_server Lets the user edit general distributed search settings like timeouts, heartbeats, and deny X
lists.

edit_server Lets the user edit general server settings like server name, log levels, etc. X

edit_server_crl Lets the user edit general server settings like server name, log levels, etc. Inherits the X
ability to read general server and introspection settings.
edit_sourcetypes Lets the user edit sourcetypes. See the Knowledge Manager manual for more X X X
information about sourcetypes.

edit_splunktcp Lets the user change settings for receiving TCP inputs from another Splunk instance. X

edit_splunktcp_ssl Lets the user view or edit any SSL-specific settings for Splunk TCP input. X

edit_splunktcp_token Lets the user edit the Splunktcp token. X

edit_storage_passwords Lets the user make HTTP POST and DELETE calls to the /storage/passwords endpoint, X X
which stores or deletes secrets. Users must hold the 'list_storage_passwords' role to
retrieve secrets.

edit_tcp Lets the user change settings for receiving general TCP inputs. X

edit_tcp_token Lets the user change TCP tokens. This is an admin capability and should only be X
assigned to system administrators.

edit_telemetry_settings Opt in or out of product instrumentation. See Share data in Splunk Enterprise in X
the Admin Manual.

edit_token_http Lets the user create, edit, display, and remove settings for HTTP token input. Also X
enables the HTTP Event Collector feature.

edit_tokens_all Lets the user issue tokens to all users. X

edit_tokens_own Lets the user issue tokens to themself. X

edit_tokens_settings Lets the user manage token settings. X

edit_udp Lets the user change settings for UDP inputs. X

edit_user Lets the user create, edit, or remove users. A role with the edit_user capability can assign X X
any role to other users. To limit this ability, configure grantableRoles in authorize.conf.
For example: grantableRoles = role1;role2;role3. Also lets a user manage certificates for
distributed search.

edit_view_html Lets the user create, edit, or modify HTML-based views. X

edit_web_settings Lets the user change settings for web.conf through the system settings endpoint. X

edit_webhook_allow_list Lets the user edit the webhook allow list, which determines the URL endpoints to which X X
a webhook alert action is authorized to send HTTP POST requests. See Configure
webhook allow list in Splunk Web.

edit_workload_pools Lets the user create and edit workload pools through the workloads/pools endpoint. X
edit_workload_rules Lets the user create and edit workload rules through the workloads/rules endpoint. X

embed_report Lets the user embed reports and disable embedding for embedded reports. X X

export_results_is_visible Lets the user display or hide the Export Results button in Splunk Web. The default value X X X X
is to display the button.

fsh_manage Lets the user view, create, and edit federated provider and federated index definitions X X
through Splunk Web. Federated providers and federated indexes are required for
federated search.

fsh_search Lets the user run federated searches. X X

get_diag Lets the user get a remote diag from a Splunk instance using X
the /streams/diag endpoint.

get_metadata Lets the user use the "metadata" search processor. X X X X

get_typeahead Lets the user use typeahead in the endpoint and the typeahead search field. X X X X

indexes_edit Lets the user change index settings. X X

input_file Lets the user add a file as an input through inputcsv (except for dispatch=t mode) and X X X X
inputlookup.

install_apps Lets the user install, uninstall, create, and make updates to apps. Applies only when you X
configure the enable_install_apps setting to "true" in authorize.conf.

license_edit Lets the user edit the license. X

license_read Lets the user access license attributes and related information.

license_tab Lets the user access and change the license. This attribute is deprecated. X

license_view_warnings Lets the user see a warning message when they are exceeding data limits or reaching X
the expiration date of their license. These warnings appear on the system banner.

list_accelerate_search Lets the user view accelerated reports. User cannot accelerate reports. X

list_all_apps Lets a user list all configuration settings for the configuration endpoints. This capability X X X X
prevents unauthorized access to configuration endpoints.

list_all_roles Lets a user list all roles and the capabilities that are assigned to those roles. For full X
access to listing users, roles, and capabilities, the user must also have or assign the
'list_all_users' capability.
 If you log into your Splunk Cloud Platform instance as the sc_admin or ps_admin user,
you might see additional users that are associated with these capabilities when you view
them in the Users settings page in Splunk Web.

list_all_users Lets a user list all users by accessing the /services/authentication/users REST endpoint. X
For full access to listing users, roles, and capabilities, the user must also have or assign
the 'list_all_roles' capability.

If you log into your Splunk Cloud Platform instance as the sc_admin or ps_admin user,
you might see additional users that are associated with these capabilities when you view
them in the Users settings page in Splunk Web.

list_deployment_client Lets the user view deployment client settings. X

list_deployment_server View deployment server settings. X

list_field_filter Lets a user view field filters by using Splunk Web or the Splunk platform REST X X X
API authorization/fieldfilters and authorization/fieldfilters/{name} endpoints.
See Protect PII, PHI, and other sensitive data with field filters.

list_forwarders Lets a user list and view settings for data forwarding. Can be used by TCP and Syslog X
output admin handlers.

list_health_subset Lets a user monitor the health of Splunk Enterprise features (such as search scheduler) X
through REST endpoints.

list_httpauths Lets the user view user sessions through the httpauth-tokens endpoint. X X

list_indexer_cluster Lets the user view the list of indexer clusters as well as indexer cluster objects such as X
buckets, peers, etc.

list_indexerdiscovery Lets the user view settings for indexer discovery. Also used by indexer discovery X
handlers.

list_inputs Lets the user view lists of various inputs, including input from files, TCP, UDP, scripts, etc. X X X X

list_introspection Lets the user read introspection settings and statistics for indexers, search, processors, X X
queues, etc.

list_metrics_catalog Lets the user query for lists of metrics catalog information such as metric names, X X X
dimensions, and dimension values.

list_search_head_clustering Lets the user list and view search head clustering objects like artifacts, delegated jobs, X X
members, captain, etc.

list_search_scheduler Lets the user view lists of search scheduler jobs. X X

list_settings Lets the user list and view server and introspection settings such as the server name, log X X
levels, etc. You must have the list_settings capability to send emails from alerts.
list_storage_passwords Lets the user list and view the /storage/passwords endpoint, lets the user perform X X
GETs. The admin_all_objects capability must be added to the role for the user to perform
POSTs to the /storage/passwords endpoint.

list_tokens_all Lets the user view all tokens. X

list_tokens_own Lets the user view their own tokens. X X X

list_tokens_scs Lets a user retrieve a Splunk Cloud Platform Services (SCS) token for an SCS service with X X
which this Splunk Cloud deployment has been configured to communicate.

Customers do not use or assign this capability, rather, it might appear in various
configuration panes in Splunk Web.

list_workload_pools Lets a user list and view workload pool and workload status information from X
the workloads/rules endpoint.

list_workload_rules Lets a user list and view workload rule information from the workloads/rules endpoint. X

metric_alerts Lets a user create, update, enable, disable, and delete a streaming metric alert. X X

never_expire Lets a user account never expire. X

never_lockout Lets a user account never lock the user out. X

output_file Lets the user create file outputs, including outputcsv (except for dispatch=t mode) and X X X X
outputlookup.

pattern_detect Lets the user see and use the Patterns tab in the Search view. X X X X

request_remote_tok Lets the user obtain a remote authentication token, which lets the user perform some X X X X
distributed peer management and bundle replication and distribute searches to old 4.0.x
Splunk instances.

rest_access_server_endpoints Lets a user access any /services/server/* endpoints using the rest command. For X X X X
example, a role with the rest_access_server_endpoints capability can run the following
searches:

• |rest splunk_server=local /services/server/info

• |rest splunk_server=local /services/server/security

• |rest splunk_server=local /services/server/roles

• |rest splunk_server=local /services/server/introspection

rest_apps_management Lets the user edit settings for entries and categories in the python remote apps handler. X X
See restmap.conf for more information.
rest_apps_view Lets the user list and view various properties in the Python remote apps handler. X X X X
See restmap.conf for more information.

rest_properties_get Lets the user get information from the services/properties endpoint. X X X X

rest_properties_set Lets the user edit the services/properties endpoint. X X X X

restart_splunkd Lets the user restart Splunk Enterprise through the server control handler. X X

rtsearch Lets the user run real-time searches. X X X

run_collect Lets the user run the collect command. X X X

run_commands_ignoring_field_filter When field filters are in use, this capability lets users run searches across any indexes in X X X
the organization using certain restricted commands that return protected data. This
capability is required for roles to run the following commands that are restricted by
default: tstats, mstats, mpreview, walklex, and typeahead. These commands can return
sensitive index information to which roles that are restricted by field filters should not
have access. See Protect PII, PHI, and other sensitive data with field filters.

run_custom_commands Lets the user run custom search commands. For more information on custom search X X X
commands and how to create them, see Create custom search commands for apps in
Splunk Cloud Platform or Splunk Enterprise in the Splunk Developer Portal.

run_dump Lets the user run the dump search command. X X X

run_mcollect Lets the user run the mcollect and meventcollect commands. X X X

run_msearch Lets the user run the msearch command. X

run_walklex Lets the user run searches that include the walklex command, even if they have a role
that has search filters applied to it. By its nature, the walklex command bypasses role-
based search filters. Avoid giving this capability to roles that must have their search
functionality restricted. This capability is not assigned to any role by default.

run_sendalert Lets the user run the sendalert search command. X X X

schedule_rtsearch Lets the user schedule real-time saved searches. The schedule_search and rtsearch X X X X
capabilities must also be assigned to the role.

schedule_search Lets the user schedule saved searches, create and update alerts, review triggered alert X X X
information, and use the sendemail command.

search Lets the user run a search. See the Search Manual for more information. X X X X

search_process_config_refresh Lets the user use the "refresh search-process-config" CLI command to manually flush X X X
idle search processes.
select_workload_pools Lets a user assign a scheduled search or ad-hoc search to a workload pool. X

srchFilter Lets the user manage search filters. See the Search Manual for more information. X

srchIndexesAllowed Lets the user run search indexes. See the Search Manual for more information. X

srchIndexesDefault Lets the user set default search indexes. X

srchJobsQuota Lets the user set search job quotas. X

srchMaxTime Lets the user set the maximum time for a search. X

upload_lookup_files Lets the user upload files that can be used in conjunction with lookup definitions. Only X X X
affects lookup types that involve the upload of a file, such as CSV and geospatial
lookups.

upload_mmdb_files Lets the user upload .mmdb files that are used by the iplocation command to extract X X
location information from IP addresses.

use_file_operator Lets the user use the "file" search operator. The "file" search operator is deprecated. X

web_debug Lets the user debug Web files. X

Navigating the Edge Processor menu

When you first access your tenant, you will be presented with a screen similar to the one shown
above. This entry-point is your Data Management page, where you learn about "What's new"
features, access your system logs, and get links to the latest documentation.

Note the other items in the menu on the left:

• My workspace

• Shared workspaces

• Datasets

• Search

• Pipelines

• Edge Processors

o Source types

o Shared settings

• Destinations

Let's take a look at each of these.

Using My workspace and Shared workspaces

My workspace is your repository of modules and pipelines.

If you didn't complete it yet, you will learn more about modules in the SPL2 course. For the time
being, you need to know the following about modules:

• modules act as containers for your SPL2 statements

• modules provide a mechanism to group related logic into a reusable package

You'll learn more about pipelines in a subsequent course.

Shared workspaces are just that. Workspaces you create for collaboration and workspaces that
are shared with you can be found here.

Using Datasets

The Datasets dashboard provides an overview of the data available to you for use in your
modules and pipelines.

If you didn't complete it yet, you will learn more about datasets in the SPL2 course. For the time
being, you need to know the following:

• A dataset is a collection of data. You can read from it and write to it.

• A dataset may be data that you want to search or it may be the result of a search.

• Datasets may be derived from indexes, forwarder data, and S3 buckets, to name a few
examples.

Using Search
Similar to the Search app in Splunk Cloud or Enterprise, the Search dashboard allows you to
compose searches and pipelines in SPL2 using your available datasets. You can save your work
here as a module in your workspace. Note that Search is not important for creating Edge
Processor artifacts.

Pipelines
This is where you design, test and deploy your pipelines according to your data collection
strategy. You can build a pipeline from scratch, or by cloning a template.

You will learn more about pipelines in a subsequent course.

Edge Processors

This is where you add, monitor and manage all your Edge Processor instances.

Source types
Source types determine how inbound data is broken into distinct events before it goes through
a pipeline.

There are many source types supplied by the Edge Processor service but if you don’t see a
particular one that meets your needs, you can add a new one here.

This is the equivalent of Splunk Enterprise linebreaking.

Shared settings

In Shared settings, you can modify fleet-wide default settings such as receiver ports and
monitoring thresholds.

Destinations
In order to route data from an Edge Processor instance, you must define the storage locations
as destinations.

When you have configured the first-time setup, the default destination is added using
the scpbridge connection. This dedicated connection allows Splunk Cloud users to access Splunk
Cloud services through role-based controls set in the Splunk UI.

Use Edge Processors

First-time setup instructions for the Edge Processor solution

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/Firsttimesetup

First-time setup instructions for the Edge Processor solution

After you request access to the Edge Processor solution and the provisioning process is
completed, you receive a welcome email confirming that you now have access to a tenant in the
Splunk cloud environment. The tenant is your entry point to the Edge Processor service, where
you can perform actions such as configuring and deploying Edge Processors, creating data
processing pipelines, and more.

If you are the first user on the tenant, you need to complete a one-time setup procedure before
you can start using the Edge Processor service. During this setup procedure, you finish
connecting the tenant and your Splunk Cloud Platform deployment by providing the tenant with
credentials that allow it to read and write data to your Splunk Cloud Platform deployment. In
order for the Edge Processor solution to work, it must be able to store and retrieve Edge
Processor logs and metrics in designated indexes in the Splunk Cloud Platform deployment and
then display that data in the user interface of the Edge Processor service.
This one-time setup process is only required for newly provisioned tenants. Once this process is
completed, you don't need to go through it again.

Understanding the connection between your tenant and your Splunk Cloud Platform
deployment

When you first receive your tenant, it already has a partial connection to your Splunk Cloud
Platform deployment. This partial connection grants the tenant the following characteristics:

• The name of the tenant is the same as the name of the connected Splunk Cloud Platform
deployment. For example, if the name of your Splunk Cloud Platform deployment
is buttercupgames and you use the URL https://buttercupgames.splunkcloud.com to
access it, then the name of the tenant is also buttercupgames and you would use the
URL https://px.scs.splunk.com/buttercupgames to access the tenant.

• The tenant uses the connected Splunk Cloud Platform deployment as an identity
provider for managing user accounts and logins. As a result, the tenant accepts the same
login credentials as the Splunk Cloud Platform deployment.

If you configured Splunk Cloud Platform to use another service as the identity provider for
single sign-on (SSO), then use your SSO credentials when logging in to the tenant.

Splunk Cloud Platform users can access the tenant as long as the user account has the
admin_all_objects capability.

Be aware that the tenant does not start with the complete connection necessary for reading and
writing data to the Splunk Cloud Platform deployment. The first-time setup procedure finishes
connecting the tenant to the Splunk Cloud Platform deployment and allows the tenant to use
the deployment as a storage location for the logs and metrics generated by Edge Processors.

Prerequisite: Confirm that you can log in to your tenant

Before beginning the first-time setup procedure for the Edge Processor solution, confirm that
your Splunk Cloud Platform account has the required capabilities and that you can log in to the
tenant.

1. Log in to your Splunk Cloud Platform deployment as an administrator.

2. In the Settings menu, in the Users and authentication section, select Users.

3. In the row that lists your username, select Edit and then select View Capabilities.

4. Check if your account has the admin_all_objects capability. If your account doesn't have
that capability, assign it. See Define roles on the Splunk platform with capabilities in
the Securing Splunk Cloud Platform manual for more information.
 5. In the Settings menu, select Data Management experience. If you have activated Edge
Processor, then you will be redirected to your tenant. If you have not activated Edge
Processor, you will be redirected to the Splunk Adoption Hubs.

If you encounter authentication errors or cannot access the Edge Processor service despite
ensuring that your user account has the required capabilities, contact your Splunk representative
for assistance.

Step 1: Allow your tenant to access Splunk Cloud Platform indexes

To make the necessary indexes from your Splunk Cloud Platform deployment available to your
tenant, you must create a service account that can access those indexes and then configure the
tenant to connect to the Splunk Cloud Platform deployment using that account. Do the
following:

1. In Splunk Cloud Platform, create a role that can access the required indexes. See Create a
role for the service account.

2. Create a service account, which is a Splunk Cloud Platform account that uses the role you
created. See Create a service account.

3. In your tenant, configure a connection to your Splunk Cloud Platform deployment using
the service account. See Connect your tenant to your Splunk Cloud Platform deployment.

This connection grants your tenant the same permissions as the service account, allowing the
Edge Processor service to send data to your indexes.

Create a role for the service account

In Splunk Cloud Platform, create a role that grants access to the internal indexes.

1. Log in to your Splunk Cloud Platform deployment as an administrator.

2. To start creating the role for the service account, clone the default user role:

1. In the Settings menu, in the Users and authentication section, select Roles.

2. In the row that lists the default user role, select Edit, then Clone.

3. In the Name field, specify a name for the new role, such as scp_user.

4. If you have search head clustering (SHC) on your Splunk Cloud Platform deployment,
then you must add the list_search_head_clustering capability to the role. To do this,
select the 2. Capabilities tab and then select list_search_head_clustering.

5. On the 3. Indexes tab, select the Included check box for all the indexes that you want to
make available in your tenant. At minimum, you must make all internal indexes available.
Instead of specifying internal indexes individually, you can select the Included check box
in the _* (All internal indexes) row.
 6. To avoid concurrent search limitations, select the 5. Resources tab and do the following:

1. In the Role search job limit settings, change Standard search limit to 300.

2. In the User search job limit settings, change Standard search limit to 200.

3. In the Disk space limit settings, change Standard search limit to 10000.

7. To save your settings and finish creating the role, select Clone.

8. (Optional) If you've already completed this first-time setup process before, and you are
now updating these role settings, then you must refresh the connection to your Splunk
Cloud Platform deployment by doing the following steps in the Edge Processor service:

1. Select the Settings icon ( ) and then select System connections.

2. On the scpbridge connection, select the Refresh icon ( ).

Next, create a service account using this role.

Create a service account

In Splunk Cloud Platform, create an account that uses the role you created during the preceding
steps. This account is a service account to be used by the tenant and the Edge Processor service.

1. In the Settings menu, in the Users and authentication section, select Users.

2. Select New User.

3. In the Name field, specify a name for the service account, such as service_acct.

4. In the Set password and Confirm password fields, specify a password for the service
account.

5. In the Assign role area, do the following:

1. Add the role that you created during Create a role for the service account.

2. Remove the default user role.

6. Deselect the Require password change on first login check box.

7. To save your settings and finish creating the service account, select Save.

8. To confirm that the service account is valid, log out of your Splunk Cloud Platform
deployment and then log back in using the service account credentials.

On some systems, you might be prompted to reset the password even though you disabled that
requirement. If prompted, reset the password.
 9. After confirming that you can successfully log in to Splunk Cloud Platform using the
service account, log out of the service account.

10. (Optional) To prevent the service account from being locked out due to password expiry
and failed login attempts, review the password policies configured for your Splunk Cloud
Platform deployment and configure an expiration alert.
For more information, see Configure Splunk password policies in the Securing Splunk
Cloud Platform manual. If you are using another service as the identity provider, then
refer to the documentation for that service.

You now have a service account that your tenant can use to connect to your Splunk Cloud
Platform deployment.

Connect your tenant to your Splunk Cloud Platform deployment

1. In Splunk Cloud Platform, select Settings then select Data Management experience.

2. Log in using your Splunk Cloud Platform username and password.

If you configured Splunk Cloud Platform to use another service as the identity provider for SSO,
then use your SSO credentials when logging in to the tenant.

The browser redirects you to the Data management page in the Edge Processor service.

3. Select the Settings icon ( ) and then select System connections.

4. Select New, then Platform connection.

5. Complete the fields in the Connect to your data dialog box:

Field Description

Connection The name of the connection. The value scpbridge is provided and can't be changed.
name

Host name The URL for your Splunk Cloud Platform deployment. The https:// is assumed. For example, if your URL
is https://scpanalytics.splunkcloud.com you would specify scpanalytics.splunkcloud.com.

Management The default port number. Most Splunk Cloud Platform deployments use the 8089 port as the default port. If you
port changed the default port in your deployment, specify that port number.

Service account The name of the service account that you created during Create a service account. For example, service_acct.
username

Service account The password of the service account.

password
 6. Select Create connection.
A connection named scpbridge is created, and a Status: connected icon ( ) displays
beside the connection name. The tenant displays the following message:

7. Connection was created

The connection was successfully created.

8. (Optional) If you need to change the connection after it has been successfully created, do
the following:

1. On the System connections page, select the Edit icon ( ) on

the scpbridge connection.

2. Update your connection settings as needed and then select Apply.

The indexes from your Splunk Cloud Platform deployment are now available in the tenant. After
you complete the remaining steps in this first-time setup process, you can send data into these
indexes.

Step 2: Retrieve credentials to allow communications between the Edge Processor service
and Splunk Cloud Platform

The Edge Processor service must prove its identity using TLS certificates before Splunk Cloud
Platform allows the service to communicate with it. To allow the Edge Processor service to
securely communicate with your Splunk Cloud Platform deployment, you must retrieve the
universal forwarder credentials package from the Splunk Cloud Platform deployment and then
store that credentials package in the Edge Processor service. This credentials package contains
the necessary TLS certificates.

1. In Splunk Cloud Platform, select Apps, then Universal Forwarder.

2. Select Download Universal Forwarder Credentials. Note the location of the credentials
file. The credentials file is named splunkclouduf.spl.

3. Copy the file to a storage location of your choice.

During the next step, you upload this credentials package to the Edge Processor service.

Step 3: Complete the first-time setup process

Upload the Splunk Cloud Platform universal forwarder credentials package to the Edge
Processor service and finish setting up communication between the Edge Processor service and
your Splunk Cloud Platform deployment.

1. In the Edge Processor service, select Edge Processors.

The service redirects you to the First-time setup page.

 2. Complete the fields in the First-time setup page.

Field Description

Destination name default_splunk_cloud_destination

This is a preset destination name for your Splunk Cloud Platform deployment.

Universal forwarder Upload the universal forwarder credentials package that you downloaded during Step 2: Retrieve credentials to allow communications
credentials between the Edge Processor service and Splunk Cloud Platform.

3. Select Save.

Next steps

Now that you've finished setting up the indexes and connections required by the Edge
Processor solution, you can start using it to receive, transform, and route your data. For more
information on how to get started, see Quick start: Process and route data using Edge
Processors.

If you create additional indexes in your Splunk Cloud Platform deployment after completing
these first-time setup steps, you must refresh the connection between your tenant and the
Splunk Cloud Platform deployment in order to make those indexes available in the tenant. For
detailed instructions, see Make more indexes available to the tenant.

Sending data from Edge Processor

This module covers the following objectives:

• Configuring S2S destinations

• Configuring HEC destinations
• Configuring S3 destinations

Configuring Splunk Cloud destinations

In order to send data from an Edge Processor to a storage location, you must define the
location as a destination in the Edge Processor service. The steps to define a destination
vary depending on the type of storage. Some customers have more than one Splunk Cloud
stack. Is the destination the primary stack that has been paired to this tenant or another
cloud stack? Is it a Splunk Enterprise indexer that is managed in your own data center? Or
is the destination Amazon S3 buckets?
Understanding index destination precedence

Index destination precedence is similar to the order followed by a typical Splunk ingestion
pipeline set. Once the index name is set in the collection path, it persists until you override
it with one of the options along its path. The last place to override this value is at the
indexer's ruleset or the transforms.conf transformation. The following list outlines index
destination precedence from highest to lowest:

• Rulesets and transforms.conf transformation at the indexer

• Named $destination (Only for the paired destination)
• Pipeline statement (e.g: $pipeline = from $source | eval index="foo" | into
$destination)
• Forwarder inputs.conf setting
• Metadata in the HEC event payload
• Default index settings on the indexer
• Under the [http] stanza in inputs.conf and defaultDatabase &
lastChanceIndex settings in indexes.conf

Use Edge Processors

How the destination for Edge Processor works

How the destination for Edge Processor works

1. In order to send data from an Edge Processor to a storage location such as an index or
an Amazon S3 bucket, you must define the location as a destination in the Edge
Processor service. Each destination contains the connection information necessary for
allowing an Edge Processor to send data to a given location.

2. The steps for adding a destination to the Edge Processor service varies depending on
whether the destination is part of the Splunk Cloud Platform deployment that's
connected to your cloud tenant:

• When you connect your tenant to a Splunk Cloud Platform deployment as part of the
first-time setup of the Edge Processor solution, all the indexers and indexes that the
service account can access become available as destinations. For information about
working with destinations that are associated with this connection, see Send data from
Edge Processors to the Splunk Cloud Platform deployment connected to your tenant.

• For destinations that are not part of the connected deployment, such as Amazon S3
buckets or indexes from other Splunk platform deployments, you must use
the Destinations page in the Edge Processor service to add and configure them. See the
following pages for more information:

o Add or manage destinations

o Send data from Edge Processors to non-connected Splunk platform deployments

using S2S

o Send data from Edge Processors to non-connected Splunk platform deployments

using HEC

o Send data from Edge Processors to Amazon S3

3. You can confirm the destinations that are available by checking the Destinations page,
and view additional details about a given destination by selecting it on
the Destinations page.

What happens to my data if a destination becomes unavailable?

4. Edge Processors currently provide no data delivery guarantees. However, to help

prevent data loss, the Edge Processor instance holds data in a queue if it is unable to
send data to a destination or if it receives more data than it can send. If the queue fills
up before the destination is available again, then the Edge Processor back pressures the
data until it is ready to be sent to the destination and will continue to attempt to put
data in the queue unless the Edge Processor needs to restart or shut down. If the Edge
 Processor instance shuts down or restarts while data is being sent, data cannot be
written to a persistent queue which can cause data loss.

5. Queued data is stored on the hard drive of the Edge Processor host. By default, the
queue is configured to hold up to 10000 batches of events. Depending on which
receiver you use, each batch can contain various amounts of events ranging from 1 to
128 events. The amount of data contained and how quickly the queue fills up varies
depending on the rate at which the Edge Processor is receiving data.

6. If your pipeline uses either the branch or route command and one of the queues for
your destination is full, then data may be delivered more than once for the other healthy
destinations causing data duplication.

7. Once the destination is available again, the Edge Processor sends the queued events to
the destination. It might take some time for newer data to be processed by an Edge
Processor as the data in the queue is prioritized first. If you want to adjust the size of the
queue, see the solution instructions in An Edge Processor fails to send data, and logs a
"Dropping data because sending_queue is full" error.

Read the docs

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/DestinationsOvervi
ew

Use Edge Processors

SendingCloud
Splunk
Enterprise
data from
Platform
Edgeor
Processors
Splunk to
Sending data from Edge Processors to Splunk Cloud Platform or Splunk Enterprise
You can send data from Edge Processors to Splunk Enterprise or Splunk Cloud Platform. The steps
that you need to take in order to send data to a Splunk platform deployment varies depending on
these factors:

• Are you sending data to the Splunk Cloud Platform deployment that is connected to the
Edge Processor service?
• Do you want to send this data using the Splunk-to-Splunk (S2S) protocol or the HTTP
Event Collector (HEC)?
During the first-time setup process for the Edge Processor solution, the Edge Processor service is
connected to a Splunk Cloud Platform deployment. Due to this connection, the indexers associated
with this deployment are already available as data destinations for Edge Processor pipelines. You
can create a pipeline to send data to the connected Splunk Cloud Platform deployment using the
S2S protocol. For more information, see Send data from Edge Processors to the Splunk Cloud
Platform deployment connected to your tenant.
Before you can send data to a non-connected Splunk Cloud Platform or Splunk Enterprise
deployment, you must add the indexers from those deployments as destinations in the Edge
Processor service. When sending data to a non-connected Splunk platform deployment, you can
choose to use the S2S protocol or HEC:

S2S is the proprietary, TCP-based data transmission protocol used between Splunk
•
software. The S2S protocol typically sends data faster and more efficiently than HEC,
and does not require any additional configurations on the Splunk platform deployment.
To send data using S2S, add and use a Splunk platform S2S destination. See Send data
from Edge Processors to non-connected Splunk platform deployments using S2S for
more information.
• HEC is a mechanism that allows HTTP clients and logging agents to send data to the
Splunk platform over HTTP or HTTPS. If your Splunk platform deployment has HEC
turned on and valid HEC tokens configured, then you can choose to send data using
HEC. To do this, add and use a Splunk platform HEC destination. See Send data from
Edge Processors to non-connected Splunk platform deployments using HEC for more
information.
The protocol that you use to send the data affects how that data gets routed to an index. See the rest
of this topic for details.

How does an Edge Processor know which

index to send data to?
The specific index that the data from an Edge Processor gets routed to is determined by a
precedence order of configurations. See the following tables for details:

• Index precedence order when using S2S

• Index precedence order when using HEC

Edge Processors use the S2S protocol when sending data to the Splunk Cloud Platform deployment
that's connected to the tenant.

Index precedence order when using S2S

When you use the S2S protocol to send data from an Edge Processor to the Splunk platform, the
destination index is determined by the following precedence order of configurations:
Configuration Description

Data routing configurations in the Splunk platform If the deployment is configured to route events to different indexes based on field values, then the Edge Processor sends dat a to the index determined by these routing configurations.
deployment

For example, if the props.conf file specifies a transforms.conf stanza, and that stanza uses the REGEX and DEST_KEY properties to route data to different indexes based on extracted field values, then data from
the Edge Processor is routed according to these settings.

The SPL2 statement of the pipeline If the pipeline contains an eval command that sets the index field to a specific value, then the Edge Processor sends data to the specified index. For example, if you apply the following pipeline, then the Edge
Processor sends data to an index called AppLogEvents:
$pipeline = | from $source | eval index="AppLogEvents" | into $destination;

You can add this command by specifying a target index during pipeline creation or by selecting the Target index action when editing a pipeline. See Create pipelines for Edge Processors for more information.

The metadata in the event payload If the event contains metadata that specifies an index, then the Edge Processor sends the event to that index.
 The index in the event metadata can be set through various methods as the event travels from the original data source to the Edge Processor. For example:

• When you use a Splunk forwarder to send the event to the Edge Processor, the index value in the inputs.conf file specifies the index in the event metadata.

• When you use HEC to send the event to the Edge Processor, the index parameter in the HTTP request specifies the index in the event metadata.

None of the previously described configurations The Edge Processor sends data to the default index of the Splunk platform deployment, which is typically main. See Manage Splunk Cloud Platform indexes in the Splunk Cloud Platform Admin Manual for more
specify an index information.

If the destination index determined by this precedence order does not exist in the Splunk platform
deployment, then one of the following outcomes occur:

If the lastChanceIndex property is configured in the Splunk platform deployment,

•
then the data goes to the index specified by that property.
• If the lastChanceIndex property is not configured, then the data is dropped.
For more information about the lastChanceIndex property, see indexes.conf in the Splunk
Enterprise Admin Manual.

Index precedence order when using HEC

When you use HEC to send data from an Edge Processor to the Splunk platform, the destination
index is determined by the following precedence order of configurations:

Configuration Description

The SPL2 statement of the pipeline If the pipeline contains an eval command that sets the index field to a specific value, then the Edge Processor sends data to
the specified index. For example, if you apply the following pipeline, then the Edge Processor sends data to an index
called AppLogEvents:

$pipeline = | from $source | eval index="AppLogEvents" | into $destination;

You can add this command by specifying a target index during pipeline creation or by selecting the Target index action when
editing a pipeline. See Create pipelines for Edge Processors for more information.

The metadata in the event payload If the event contains metadata that specifies an index, then the Edge Processor sends the event to that index.

The index in the event metadata can be set through various methods as the event travels from the original data source to the
Edge Processor. For example:

• When you use a Splunk forwarder to send the event to the Edge Processor, the index value in the
inputs.conf file specifies the index in the event metadata.

• When you use HEC to send the event to the Edge Processor, the index parameter in the HTTP request
specifies the index in the event metadata.

The Default index configuration in a Splunk If the pipeline uses a Splunk platform HEC destination, and the Default index setting in the destination specifies an index
platform HEC destination name, then the Edge Processor sends data to that index.

The Default Index configuration in the HEC If the pipeline uses a Splunk platform HEC destination, and the Default Index setting in the HEC token specifies an index name,
token then the Edge Processor sends data to that index.

The Default Index configuration in the HEC If you're sending data to Splunk Enterprise using a Splunk platform HEC destination, and the Default Index setting in the HEC
shared settings of a Splunk Enterprise shared settings of the Splunk Enterprise deployment specifies an index name, then the Edge Processor sends data to that index.
deployment

None of the previously described The Edge Processor sends data to the default index of the Splunk platform deployment, which is typically main. See Manage
configurations specify an index Splunk Cloud Platform indexes in the Splunk Cloud Platform Admin Manual for more information.

If the destination index determined by this precedence order does not exist in the Splunk platform
deployment, then one of the following outcomes occur:
 • If the lastChanceIndex property is configured in the Splunk platform deployment,
then the data goes to the index specified by that property.
• If the lastChanceIndex property is not configured, then the data is dropped.
For more information about the lastChanceIndex property, see indexes.conf in the Splunk
Enterprise Admin Manual.

Read the docs

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/SplunkPlatformDest
ination

Adding a new destination

To route data from Edge Processor instances to Splunk Enterprise indexers or other Splunk
Cloud stacks that are not paired, you add and register them as new destinations. Once you
define the connection details, you can select them as a destination in the pipeline. These
destinations can be defined to receive data in one of two methods:

• Using the Splunk-to-Splunk (S2S) connection

• Using the HTTP Event Collector (HEC)

Remember Splunk Cloud stacks only receive encrypted data using TLS v1.2 or later. Senders and
receivers authorize each other with the keys provided in the Universal Forwarder Credentials
package.

Using S2S destinations

To add a destination, navigate to the Destinations dashboard, select New destination, then
select the type of destination. Click the hotspots below for information on creating a destination
using S2S.
Indexers

Enter the IP address or host name and the port number

Add another

Click the plus sign to add more indexers

TLS

TLS must be turned on for any Splunk Cloud destination

Before you decide to add a new Splunk destination, have the following information ready for
each indexer destination:

• The receiver IP address or host name

• The receiving port

• TLS private key and certificates

Edge Processor will load balance across the indexers entered here.
For hybrid solutions with self-managed components, data between those components is
encrypted only if you configure the connection to be encrypted. For other self-managed
indexers using TLS, you need to configure Edge Processor to forward using their TLS keys.

Splunk Enterprise

Select for self-managed destinations

Client private key

A decrypted key for the client certificate. Equivalent to the sslPassword attribute in outputs.conf.

Client private key

A decrypted key for the client certificate. Equivalent to the sslPassword attribute in outputs.conf.

CA certificates

Certificate authority certifications for indexers. Equivalent to the sslRootCAPath attribute

in server.conf.

Configure these indexers by providing the following details in separate PEM, Privacy Enhanced
Mail, files:

• A decrypted key for the client certificate

• The client certificate

• CA cert(s) for indexers

Securing Splunk Enterprise

How to prepare TLS certificates for use with the Splunk platform

How to prepare TLS certificates for use with the Splunk platform

• TLS certificates let you secure communication between Splunk Enterprise components
from end to end. After you get the certificates, you need to prepare them for use with
your deployment before you install them and configure your deployment to use them.

• As part of preparing TLS certificates for use, you must combine them with the private
keys that you either received or generated to create the certificates into a single
certificate file that the Splunk platform can use.

• All certificates and respective keys that you use on the Splunk platform must be
concatenated in this manner. A certificate or key alone does not work, even if you
configure it correctly. Regardless of the service or contact point you secure, they all must
use combined certificates files.
Create a single combined certificate file

• After you obtain certificates, several files are available depending on the method you
used to get them. You will combine these files into one file. You must combine the files
in the right order and the combined file must be in the correct format. If you don't
combine them correctly, your Splunk platform instance won't be able to use the file to
secure its communications with other instances.

• If you got the certificate by purchasing them from a certificate authority, you'll have the
following at a minimum:

• The private key file

• The server certificate file

• The certificate authority certificate file, which was used to create the server certificate

The certificate authority certificate is also known as the root certificate.

• If you got the certificate by creating a certificate signing request and submitting that
request to a CA, you will have the following:

• The private key file that you created and subsequently used to create the certificate
signing request

• The certificate signing request file

• The server certificate file that you downloaded from the certificate authority after
submitting your certificate signing request.

• The certificate authority certificate file that you downloaded from the certificate authority
after downloading the server certificate.

• If you created and signed a certificate yourself, you will have the following:

• The private key file that you used to create and sign the certificate authority certificate.

• The certificate authority certificate signing request file

• The root certificate file that you generated with the private key file and the certificate
authority certificate signing request file

• The private key file that you created to create and sign the server certificate

• The server certificate signing request file

• The server certificate file. You created this file using the private key and the server
certificate signing request file
 • Depending on the method you used, you must combine the server certificate, the private
key, and the public certificate, in that order, into a single file. The combined file must be
in privacy-enhanced mail (PEM) format.

*nix command Windows command

cat <server certificate file> <server private key file> type <server certificate file> <server private ke
<certificate authority certificate file> > <combined server <certificate authority certificate file> > <comb
certificate file> certificate file>

• After you create the combined certificate file, review it using a text editor. Its contents
must contain, in the following order:

• The server certificate

• The private key

• The certificate authority certificate

• Following is an example of a properly concatenated certificate. Each certificate and key

must include the "BEGIN" and "END" markers to be considered complete.

-----BEGIN CERTIFICATE-----

MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV

...

<Server Certificate>

...

8/PZr3EuXYk1c+N5hgIQys5a/HIn

-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,CFCECC7976725DE5

S+DPcQ0l2Z1bk71N3cBqr/nwEXPNDQ4uqtecCd3iGMV3B/WSOWAQxcWzhe9JnIsl

...

<Server Private Key – Passphrase protected>

 ...

-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----

MIICUTCCAboCCQCscBkn/xey1TANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV

...

<Certificate Authority Public Key>

...

8/PZr3EuXYk1c+N5hgIQys5a/HIn

-----END CERTIFICATE-----

How to configure a certificate chain

• To use multiple certificates, place any intermediate certificates after the server certificate
and before the root certificate. You can add as many intermediate certificates as you
need, in decreasing order of hierarchy, up to the root certificate.

• Concatenate multiple certificates in the following order:

[ server certificate]

[ intermediate certificate]

[ certificate authority certificate (if required) ]

• The following is an example of a certificate chain:

-----BEGIN CERTIFICATE-----

... (certificate for your server)...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

... (the intermediate certificate)...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

... (the root certificate for the CA)...

-----END CERTIFICATE-----

Valid certificate chains must contain the -----BEGIN CERTIFICATE---- and -----END CERTIFICATE-
---- certificate markers to be valid. Do not remove these markers from the certificate file.

• In another example, when you use Splunk forwarder to indexer certificates that contain a
Private Key, the completed certificate file might look like the following:

-----BEGIN CERTIFICATE-----

... (certificate for your server)...

-----END CERTIFICATE-----

-----BEGIN RSA PRIVATE KEY-----

...<Server Private Key – Passphrase protected>

-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----

... (certificate for your server)...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

... (the intermediate certificate)...

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

... (the certificate authority certificate)...

-----END CERTIFICATE-----

Next steps

• After you combine certificates into one file, you can then configure the Splunk platform
to use the certificates.

• See Configure Splunk indexing and forwarding to use TLS certificates for instructions on
configuring TLS certificates to secure communications between indexers and forwarders.

• See Configure TLS certificates for inter-Splunk communication for instructions on

configuring TLS certificates to secure communications between Splunk platform
instances.
 • See Configure TLS certificates for Splunk Web for instructions on configuring TLS
certificates to secure communications on Splunk Web.
https://docs.splunk.com/Documentation/Splunk/latest/Security/HowtoprepareyoursignedcertificatesforSplunk

Use Edge Processors

Obtain TLS certificates for data sources and Edge Processors

Obtain TLS certificates for data sources and Edge Processors

You can use mutually authenticated TLS (mTLS) to secure communications between data sources
and Edge Processors. When mTLS is active, the data source and the Edge Processor must prove
their identities by presenting valid TLS certificates before they can connect and communicate
with each other. To configure mTLS, you must provide client certificates that validate the identity
of the data source and server certificates that validate the identity of the Edge Processor.

The instructions on this page describe how to obtain the necessary TLS certificates. If you
already have certificates that you'd like to use, then proceed to the following pages for
information on how to configure your data source and Edge Processor to use the certificates:

• Get data from a forwarder into an Edge Processor

• Get data into an Edge Processor using HTTP Event Collector

• Get syslog data into an Edge Processor

The certificates that you use to configure mTLS between data sources and Edge Processors are
different from the certificates that you use to configure TLS or mTLS between Edge Processors
and Splunk indexers. If you are looking for instructions on configuring TLS or mTLS between
Edge Processors and indexers, see the "Obtaining TLS certificates" section in Send data from
Edge Processors to non-connected Splunk platform deployments using S2S or Send data from
Edge Processors to non-connected Splunk platform deployments using HEC.

Configuring mTLS between data sources and Edge Processors

Configuring mTLS involves the following high-level steps:

1. Get or generate the following certificates:

o A client certificate, private key, and CA certificate that the data source can use to
prove its identity.

o A server certificate, private key, and CA certificate that the Edge Processor can
use to prove its identity.

Typically, each certificate is stored in a separate Privacy Enhanced Mail (PEM) file. However, if the
data source is a Splunk forwarder, then you must concatenate the client certificate, private key,
and CA certificate in the listed order into the same PEM file. For more information, see How to
prepare TLS certificates for use with the Splunk platform in the Securing Splunk
Enterprise manual.

2. Configure your data source to use the client certificates.

3. Upload the server certificates to your Edge Processor.

The Edge Processor uses the same PEM files to prove its identity to all data sources where mTLS
is used. For example, if you turn on mTLS for both Splunk forwarders and HTTP Event Collector
(HEC) data sources, then the Edge Processor uses the same server-side PEM files when receiving
data from both types of data sources.

The steps that you must follow to obtain TLS certificates depend on the type of certificates you
intend to use. You have two options for obtaining these certificates:

• Create and sign the certificates yourself. This is the fastest and lowest cost method for
getting certificates, but it is less secure than getting signed certificates from a third party.
For instructions, see Generate and self-sign client and server certificates to secure
communications on this page.

• Get signed certificates from a third party. This option is the most secure method for
getting certificates, but it involves a third party and potentially a cost to obtain the
certificates. For instructions, see Obtain a certificate from a third-party on this page.

If you're working with a Splunk forwarder that has the sslVerifyServerCert property in the
outputs.conf file turned on, then you must use a certificate from a third party.

Generate and self-sign client and server certificates to secure communications

Follow these steps if you've chosen to create and sign your own certificates to secure
communications between data sources and Edge Processors.

Before creating a certificate authority (CA), you must choose a signing algorithm for the CA's
private key. Follow the set of instructions that match the signing algorithm that you'd like to use:

• RSA: Generate self-signed client and server certificates

• ECDSA: Generate self-signed client and server certificates

RSA: Generate self-signed client and server certificates

Follow these steps if you've chosen to create and sign your own certificates with the RSA signing
algorithm to secure communications between data sources and Edge Processors.

1. Open a command line interface, for example, a shell prompt, or a Terminal or PowerShell
window.

2. Create a new directory that you'd like to store your certificates on.
 3. Change to the new directory you created.

4. Create the Certificate Authority's certificate and keys.

1. Generate a private key for the CA.

2. openssl genrsa 2048 > ca_key.pem

3. Generate the self-signed CA certificate. Replace the text contained in the -

subj flag with the information relevant to you.
4. openssl req -new -x509 -nodes -days 825 -sha256 -subj "/C=<Country>/O=<Organization>/CN=<Common-Name>/emailAddress=<Email>" -key
ca_key.pem -out ca_cert.pem

5. Create the server certificate and keys.

1. Generate the private and public keys for your server. Replace the text contained in the -subj flag with the information relevant to you.

2. openssl req -newkey rsa:2048 -nodes -days 825 -sha256 -subj "/C=<Country>/O=<Organization>/CN=<Common-Name>/emailAddress=<Email>"
-keyout edge_server_key.pem -out edge_server_req.pem

3. Sign the server certificate using your self-signed root CA.

4. openssl x509 -req -days 825 -sha256 -set_serial 01 -extfile <(printf "subjectAltName=DNS:<FQDN_Edge_Processor_Instance>") -in
edge_server_req.pem -out edge_server_cert.pem -CA ca_cert.pem -CAkey ca_key.pem

5. Verify the server certificates.

6. openssl verify -CAfile ca_cert.pem edge_server_cert.pem

6. Create the client certificate and keys.

1. Generate the private key and certificate request. Replace the text contained in
the -subj flag with the information relevant to you.
2. openssl req -newkey rsa:2048 -nodes -days 825 -sha256 -subj "/C=<Country>/O=<Organization>/CN=<Common-Name>/emailAddress=<Email>" -keyout
data_source_client_key.pem -out data_source_client_req.pem

3. Sign the client certificate using your self-signed root CA.

4. openssl x509 -req -days 825 -sha256 -set_serial 01 -in data_source_client_req.pem -out data_source_client_cert.pem -CA ca_cert.pem -CAkey ca_key.pem

5. Verify the client certificates.

6. openssl verify -CAfile ca_cert.pem data_source_client_cert.pem

ECDSA: Generate self-signed client and server certificates

Follow these steps if you've chosen to create and sign your own certificates with the ECDSA
signing algorithm to secure communications between data sources and Edge Processors.

1. Open a command line interface, for example, a shell prompt, or a Terminal or PowerShell
window.

2. Create a new directory that you'd like to store your certificates on.

3. Change to the new directory you created.

4. Create the Certificate Authority's certificate and keys.

1. Generate an ECDSA private key for the CA.

 2. openssl ecparam -genkey -name prime256v1 -out ca_key.pem

3. Generate the self-signed CA certificate. Replace the text contained in the -

subj flag with the information relevant to you.
4. openssl req -x509 -new -SHA384 -nodes -days 825 -subj "/C=<Country>/O=<Organization>/CN=<Common-
Name>/emailAddress=<Email>" -key ca_key.pem -out ca_cert.pem

5. Create the server certificate and keys.

1. Generate the server key.

2. openssl ecparam -genkey -name prime256v1 -out edge_server_key.pem

3. Generate the private key and certificate request. Replace the text contained in
the -subj flag with the information relevant to you.
4. openssl req -new -SHA384 -key edge_server_key.pem -nodes -subj "/C=<Country>/O=<Organization>/CN=<Common-
Name>/emailAddress=<Email>" -out edge_server_req.pem

5. Sign the server certificate using your self-signed root CA.

6. openssl x509 -req -days 825 -set_serial 01 -extfile <(printf "subjectAltName=DNS:<FQDN_Edge_Processor_Instance>") -in
edge_server_req.pem -out edge_server_cert.pem -CA ca_cert.pem -CAkey ca_key.pem

7. Verify the server certificates.

8. openssl verify -CAfile ca_cert.pem edge_server_cert.pem

6. Create the client certificate and keys.

1. Generate the client key.

2. openssl ecparam -genkey -name prime256v1 -out data_source_client_key.pem

3. Generate the private key and certificate request. Replace the text contained in
the -subj flag with the information relevant to you.

4. openssl req -new -SHA384 -key data_source_client_key.pem -nodes -subj

"/C=<Country>/O=<Organization>/CN=<Common-
Name>/emailAddress=<Email>" -out data_source_client_req.pem

5. Sign the client certificate using your self-signed CA.

openssl x509 -req -SHA384 -days 825 -set_serial 01 -in data_source_client_req.pem -out
data_source_client_cert.pem -CA ca_cert.pem -CAkey ca_key.pem

6. Verify the client certificates.

7. openssl verify -CAfile ca_cert.pem data_source_client_cert.pem

Confirm that you have the required certificates

After generating and self-signing the certificates, you have the following files:
 File name Description

ca_cert.pem The CA certificate that will be uploaded to both the Edge Processor and the data
source

edge_server_cert.pem The server certificates that will be uploaded to an Edge Processor

edge_server_key.pem The private key associated with the server certificate

data_source_client_cert.pem The client certificates that will be uploaded to a data source

data_source_client_key.pem The private key associated with the client certificate

Obtain a certificate from a third party

If you want to use a signed third party certificate from a CA such as Let's Encrypt, Sectigo, or
Symantec, you can acquire the certificate directly from those CAs, and upload them to the Edge
Processor service.

You will need to ask the third party for the client certificates for the data sources, the server
certificates for the Edge Processors, and the CA certificate. If there is an intermediate certificate
from the third party, then add it to your server certificate:

cat edge_server_cert.pem intermediate.pem > edge_server_cert.pem

Create a combined certificate file for a Splunk forwarder

When preparing TLS certificates for proving the identity of a universal forwarder or a heavy
forwarder, you must combine the certificates into a single PEM file. For more information,
see How to prepare TLS certificates for use with the Splunk platform in the Securing Splunk
Enterprise manual.

Next steps

Configure your data source and Edge Processor to use the TLS certificates. See the following
pages:

• Get data from a forwarder into an Edge Processor.

• Get data into an Edge Processor using HTTP Event Collector

• Get syslog data into an Edge Processor

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/SecureForwarders
Using HEC destinations
Use HEC if and when S2S is not an option. To prepare the destination on the indexer-side,
take the following steps:

• Log into Splunk Cloud

• Navigate to Settings > Data inputs > HTTP Event Collector > New
Token
• Give the token a descriptive name.
• Do not check Enable indexer acknowledgement as it is not in use.
• Configure the Input Settings, but understand the ramifications of
setting the Selected item(s) list: if you set to accept only the data
destined to the allowed list, you will lose data if the indexer rejects the
authorization because of a misconfigured index name.
• Review and finish creating your token. Then copy the token value.

If you're using Splunk Enterprise, you will need to enable HEC in the Global Settings
dialog: Settings > Data inputs > HTTP Event Collector > Global Settings. Select Enabled
on the All tokens toggle.

Meanwhile, back at the SCP...

From the New destination dropdown on the Destinations landing page, select Splunk
Platform using HEC. You will be routed a to a page similar to the following:
HEC URI

As above with S2S, enter the IP address or hostname of the Splunk instance followed by the port
number. Note that Splunk Cloud uses a fixed URL: https://http-inputs.<stack_id>.splunkcloud.com:443

Default HEC token

Enter the token created in and copied from Splunk Cloud or Enterprise.

TLS

Check this box if the destination HEC listener is using TLS.

The same details you have configured in the indexer-side should be entered in this Edge
Processor Destination form.

The HEC data is sent to the /services/collector API endpoint. The /services/collector/raw or other
endpoints are not supported.

Getting Data In
SetSplunk
in up andWeb
use HTTP Event Collector
Set up and use HTTP Event Collector in Splunk Web
The HTTP Event Collector (HEC) lets you send data and application events to a Splunk deployment
over the HTTP and Secure HTTP (HTTPS) protocols. HEC uses a token-based authentication model.
You can generate a token and then configure a logging library or HTTP client with the token to send
data to HEC in a specific format. This process eliminates the need for a Splunk forwarder when you
send application events.
After you enable HEC, you can use HEC tokens in your app to send data to HEC. You do not need to
include Splunk credentials in your app or supported files to access the Splunk platform instance.

HEC functionality varies based on Splunk software type

HTTP Event Collector runs on Splunk Cloud Platform and Splunk Enterprise. How it works depends
on the type of Splunk platform instance you have.

HEC and Splunk Cloud Platform

You can enable HEC on a Splunk Cloud Platform deployment. The following caveats apply to using
HEC on a Splunk Cloud Platform instance:
 • If you need to use a configuration file to configure an HEC input, you must do this on a
heavy forwarder, then forward the data to Splunk Cloud Platform. This is because
Splunk Cloud Platform does not provide access to configuration files locally.
• You must file a ticket with Splunk Support to enable HEC for use with Amazon Web
Services (AWS) Kinesis Firehose. Standard HEC is enabled by default on all Splunk
Cloud Platform deployments and does not require a Splunk Support ticket.
• You cannot make changes to global settings. You can only make settings changes to
tokens that you create.
• You cannot forward data that HEC receives to another set of Splunk indexers as Splunk
Cloud Platform does not support forwarding output groups.
• The index that you choose to store events that HEC receives must already exist. You
cannot create a new index during the setup process.
• Indexer acknowledgment is only available for AWS Kinesis Firehose at this time.
• After you create tokens, you can monitor progress of the token as it is deployed across
your Splunk Cloud Platform instance.
For instructions on how to enable and manage HEC on Splunk Cloud Platform, see Configure HTTP
Event Collector on Splunk Cloud.

HEC and Splunk Enterprise

HEC offers full configurability and functionality on the Splunk Enterprise platform on-premises. It
offers the following additional benefits over HEC on Splunk Cloud Platform:

• HEC can accept events that you send to it over the HTTP protocol in addition to the
HTTPS protocol.
• HEC can forward events to another Splunk indexer with an optional forwarding output
group.
• You can use the deployment server to distribute HEC tokens across indexers in a
distributed deployment.
For instructions on how to enable and manage HEC on Splunk Enterprise, see Configure HTTP
Event Collector on Splunk Enterprise.

How the Splunk platform uses HTTP Event

Collector tokens to get data in
Tokens are entities that let logging agents and HTTP clients connect to the HEC input. Each token
has a unique value, which is a 128-bit number that is represented as a 32-character globally unique
identifier (GUID). Each character can be a number from 0-9 or a letter from a-f, and the token is
case insensitive. For example, the following is a valid HEC token: B5A79AAD-D822-46CC-80D1-
819F80D7BFB0 .

Agents and clients use a token to authenticate their connections to HEC. When the clients connect,
they present this token value. If HEC receives a valid token, it accepts the connection and the client
can deliver its payload of application events in either text or JavaScript Object Notation (JSON)
format.
HEC receives the events and Splunk Cloud Platform indexes them based on the configuration of the
token. HEC uses the source, source type, and index that was specified in the token. If a forwarding
output group configuration exists on a Splunk Enterprise instance, HEC forwards the data to
indexers in that output group.

Configure HTTP Event Collector on Splunk

Cloud Platform
HEC is enabled by default in Splunk Cloud Platform. You can create, modify, delete, enable, and
disable HEC tokens.

Enable HTTP Event Collector on Splunk Cloud Platform

HTTP Event Collector is enabled by default on Splunk Cloud Platform.

Create an Event Collector token on Splunk Cloud Platform

To use HEC, you must configure at least one token. Splunk Cloud Platform distributes the token
across the deployment. The token is not ready for use until distribution has completed.

1. Click Settings > Add Data.

2. Click monitor.
3. Click HTTP Event Collector.
4. In the Name field, enter a name for the token.
5. (Optional) In the Source name override field, enter a name for a source to be
assigned to events that this endpoint generates.
6. (Optional) In the Description field, enter a description for the input.
7. (Optional) If you want to enable indexer acknowledgment for this token, click
the Enable indexer acknowledgment checkbox.
8. Click Next.
9. (Optional) Make edits to source type and confirm the index where you want HEC
events to be stored. See Modify input settings.
10. Click Review.
11. Confirm that all settings for the endpoint are what you want.
12. If all settings are what you want, click Submit. Otherwise, click < to make
changes.
13. (Optional) Copy the token value that Splunk Web displays and paste it into
another document for reference later.
14. (Optional) Click Track deployment progress to see progress on how the token
has been deployed to the rest of the Splunk Cloud Platform deployment. When
you see a status of "Done", you can then use the token to send data to HEC.

Check Event Collector token distribution status on Splunk

Cloud Platform
You can check the distribution status of an HEC token from the HEC token page. When a
distribution is in progress, the page displays "Operation in progress" and a progress bar. Otherwise,
the page displays "Last deployment status."

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Click Operation in progress or Last deployment status.
4. View the status of the token distribution.
5. Click Close.

Modify an Event Collector token on Splunk Cloud Platform

You can make changes to an HEC token after you create it.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Locate the token that you want to change in the list.
4. In the Actions column for that token, click Edit. You can also click the link to the
token name.
5. (Optional) Edit the description of the token by entering updated text in
the Description field.
6. (Optional) Update the source value of the token by entering text in
the Source field.
7. (Optional) Choose a different source type by selecting it in the Source Type drop-
down list box.
1. Choose a category.
2. Select a source type in the pop-up menu that appears.
3. (Optional) You can also type in the name of the source type in the text
box at the top of the drop-down list box.
8. (Optional) Choose a different index by selecting it in the Available Indexes pane
of the Select Allowed Indexes control.
9. (Optional) Choose whether you want indexer acknowledgment enabled for the
token.
10. Click Save.
Delete an Event Collector token on Splunk Cloud Platform
You can delete an HEC token. Deleting an HEC token does not affect other HEC tokens, nor does it
disable the HEC endpoint.
You cannot undo this action. Clients that use this token to send data to your Splunk deployment can
no longer authenticate with the token. You must generate a new token and change the client
configuration to use the new value.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Locate the token that you want to delete in the list.
4. In the Actions column for that token, click Delete.
5. In the Delete Token dialog, click Delete.

Enable and disable Event Collector tokens in Splunk Cloud

Platform
You can enable or disable a token from within the HEC management page. Changing the active
status of one token does not change the status of other tokens.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. In the Actions column for a token, click the Enable link, if the token is not active,
or the Disable link, if the token is active. The token status toggles and the link
changes to Enable or Disable based on the changed token status.

Configure HTTP Event Collector on Splunk

Enterprise
You can enable HEC and create, modify, delete, enable, and disable HEC tokens in Splunk
Enterprise.

Enable HTTP Event Collector on Splunk Enterprise

Before you can use Event Collector to receive events through HTTP, you must enable it. For Splunk
Enterprise, enable HEC through the Global Settings dialog box.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Click Global Settings.
4. In the All Tokens toggle button, select Enabled.
5. (Optional) Choose a Default Source Type for all HEC tokens. You can also type in
the name of the source type in the text field above the drop-down list box before
choosing the source type.
6. (Optional) Choose a Default Index for all HEC tokens.
 7. (Optional) Choose a Default Output Group for all HEC tokens.
8. (Optional) To use a deployment server to handle configurations for HEC tokens,
click the Use Deployment Server check box.
9. (Optional) To have HEC listen and communicate over HTTPS rather than HTTP,
click the Enable SSL checkbox.
10. (Optional) Enter a number in the HTTP Port Number field for HEC to listen on.

Confirm that no firewall blocks the port number that you specified in the '''HTTP
Port Number''' field, either on the clients or the Splunk instance that hosts HEC.

11. Click Save.

Create an Event Collector token on Splunk Enterprise

To use HEC, you must configure at least one token.

1. Click Settings > Add Data.

2. Click monitor.
3. Click HTTP Event Collector.
4. In the Name field, enter a name for the token.
5. (Optional) In the Source name override field, enter a source name for events
that this input generates.
6. (Optional) In the Description field, enter a description for the input.
7. (Optional) In the Output Group field, select an existing forwarder output group.
8. (Optional) If you want to enable indexer acknowledgment for this token, click
the Enable indexer acknowledgment checkbox.
9. Click Next.
10. (Optional) Confirm the source type and the index for HEC events.
11. Click Review.
12. Confirm that all settings for the endpoint are what you want.
13. If all settings are what you want, click Submit. Otherwise, click < to make
changes.
14. (Optional) Copy the token value that Splunk Web displays and paste it into
another document for reference later.

Modify an Event Collector token on Splunk Enterprise

You can make changes to an HEC token after you have created it.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Locate the token that you want to change in the list.
4. In the Actions column for that token, click Edit. You can also click the link to the
token name.
5. (Optional) Edit the description of the token by entering updated text in
the Description field.
 6. (Optional) Update the source value of the token by entering text in
the Source field.
7. (Optional) Choose a different source type by selecting it in the Source Type drop-
down list box.
1. Choose a category.
2. Select a source type in the pop-up menu that appears.
3. (Optional) You can also type in the name of the source type in the text
box at the top of the drop-down.
8. (Optional) Choose a different index by selecting it in the Available Indexes pane
of the Select Allowed Indexes control.
9. (Optional) Choose a different output group from the Output Group drop-down
list box.
10. (Optional) Choose whether you want indexer acknowledgment enabled for the
token.
11. Click Save.

Delete an Event Collector token on Splunk Enterprise

You can delete an HEC token. Deleting an HEC token does not affect other HEC tokens, nor does it
disable HEC.
You cannot undo this action. Clients that use this token to send data to your Splunk deployment can
no longer authenticate with the token. You must generate a new token and change the client
configuration to use the new token.

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. Locate the token that you want to delete in the list.
4. In the Actions column for that token, click Delete.
5. In the Delete Token dialog box, click Delete.

Enable and disable Event Collector tokens on Splunk

Enterprise
You can enable or disable a single HEC token from within the HEC management page. Changing the
status of one token does not change the status of other tokens. To enable or disable all tokens, use
the Global Settings dialog. See Enable the HTTP Event Collector.
To toggle the active status of an HEC token:

1. Click Settings > Data Inputs.

2. Click HTTP Event Collector.
3. In the Actions column for that token, click the Enable link, if the token is not
active, or the Disable link, if the token is active. The token status toggles
immediately and the link changes to Enable or Disable based on the changed
token status.
Use output groups to specify groups of indexers on Splunk
Enterprise
To index large amounts of data, you will likely need multiple indexers. On Splunk Enterprise only,
you can specify groups of indexers to handle indexing your HTTP Event Collector data. These
groups are called output groups. You can use output groups to, for example, index only certain kinds
of data, or data from certain sources.
You configure output groups in the outputs.conf configuration file. Specifically, for HTTP Event
Collector, edit the outputs.conf file
at $SPLUNK_HOME/etc/apps/splunk_httpinput/local/ ( %SPLUNK_HOME%\etc\apps\splunk_httpi
nput\local\ on Microsoft Windows hosts). If either the local directory or the outputs.conf file
doesn't exist at this location, create it (or both).

HTTP Event Collector is not an app, but it stores its configuration in

the $SPLUNK_HOME/etc/apps/splunk_httpinput/ directory
( %SPLUNK_HOME%\etc\apps\splunk_httpinput\ on Windows) so that its configuration can be
easily deployed using built-in app deployment capabilities.

Send data to HTTP Event Collector

You must satisfy all of the following conditions when you send data to HEC:

• HEC must be enabled

• You must have at least one active HEC token available
• You must use an active token to authenticate into HEC
• You must format the data that goes to HEC in a certain way. See Format events for HTTP
Event Collector
There are several options for sending data to HTTP Event Collector:

• You can make an HTTP request using your favorite HTTP client and send your JSON-
encoded events.
• As a developer, you can use the Java, JavaScript ( node.js ), and .NET logging libraries in
your application to send data to HEC. These libraries are compatible with popular
logging frameworks. See Java, JavaScript (Node.js), and .NET on the Splunk Dev Portal.

Send data to HTTP Event Collector on Splunk Cloud

Platform
You must send data using a specific URI for HEC.
The standard form for the HEC URI in Splunk Cloud Platform free trials is as follows:
<protocol>://http-inputs-<host>.splunkcloud.com:<port>/<endpoint>
The standard form for the HEC URI in Splunk Cloud Platform is as follows:
<protocol>://http-inputs-<host>.splunkcloud.com:<port>/<endpoint>
The standard form for the HEC URI in Splunk Cloud Platform on Google Cloud is as follows:
<protocol>://http-inputs.<host>.splunkcloud.com:<port>/<endpoint>
The standard form for the HEC URI in Splunk Cloud Fedramp Moderate on AWS Govcloud is as
follows:
<protocol>://http-inputs.<host>.splunkcloudgc.com:<port>/<endpoint>

Where:

• <protocol> is either http or https

• You must add http-inputs- before the <host> on AWS.
• You must add http-inputs. before the <host> on GCP and AWS Govcloud.
• <host> is the Splunk Cloud Platform instance that runs HEC
• You must add the domain .splunkcloud.com after the <host>
• <port> is the HEC port number
o 8088 on Splunk Cloud Platform free trials
o 443 by default on Splunk Cloud Platform instances
• <endpoint> is the HEC endpoint you want to use. In many cases, you use
the /services/collector/event endpoint for JavaScript Object Notation (JSON)-
formatted events or the services/collector/raw endpoint for raw events

If you do not include these prefixes before your Splunk Cloud Platform hostname when you send
data, the data cannot reach HEC.

Send data to HTTP Event Collector on Splunk Enterprise

You send data to a specific Uniform Resource Indicator (URI) for HEC.
The standard form for the HEC URI in Splunk Enterprise is as follows:
<protocol>://<host>:<port>/<endpoint>
Where:

• <protocol> is either http or https

• <host> is the Splunk instance that runs HEC
• <port> is the HEC port number, which is 8088 by default, but you can change in the HEC
Global Settings
• <endpoint> is the HEC endpoint you want to use. In many cases, you use
the /services/collector/event endpoint for JavaScript Object Notation (JSON)-
formatted events or the services/collector/raw endpoint for raw events

Example of sending data to HEC with an HTTP request

The following example makes a HTTP POST request to the HEC on port 8088 and uses HTTPS for
transport. This example uses the curl command to generate the request, but you can use a
command line or other tool that better suits your needs.
You can configure the network port and HTTP protocol settings independently of settings for other
instances of HEC in your Splunk Enterprise or Splunk Cloud Platform deployment.
The following cURL command uses an example HTTP Event Collector token (B5A79AAD-D822-
46CC-80D1-819F80D7BFB0), and uses https://hec.example.com as the hostname. Replace these
values with your own before running this command.

JSON request and response

When you make a JSON request to send data to HEC, you must specify the "event" key in the
command.
The Authorization HTTP header for HEC requires the "Splunk" keyword before the HEC token.
curl https://hec.example.com:8088/services/collector/event -H "Authorization:
Splunk B5A79AAD-D822-46CC-80D1-819F80D7BFB0" -d '{"event": "hello world"}'
{"text": "Success", "code": 0}

More information on HEC

• For information about defining forwarding output groups, see Configure forwarders
with outputs.conf. You can also set up forwarding in Splunk Web, which generates a
default output group called default-autolb-group .
• For information on indexer acknowledgement, see HTTP Event Collector indexer
acknowledgment. Indexer acknowledgment in HTTP Event Collector is not the same
indexer acknowledgment capability described in indexer acknowledgment and indexer
clusters.
• For information about using HEC in Splunk Enterprise, see Set up and use HTTP Event
Collector in Splunk Web in the Splunk Enterprise Getting Data In manual.
• For information about using HEC in Splunk Cloud Platform, see Set up and use HTTP
Event Collector in Splunk Web in the Splunk Cloud Platform Getting Data In manual.
• For information about using HEC in the Edge Processor service, see Get data into an
Edge Processor using HTTP Event Collector in the Splunk Cloud Platform Use Edge
Processors manual.

More information on HEC for developers

• For developer content on using HTTP Event Collector, see HTTP Event Collector
Examples, as well as Introduction to Splunk HTTP Event Collector in the Splunk
Developer Portal.

Using Amazon S3 destinations

If you want to route data to Amazon S3 buckets from Edge Processor instances, you can add
them as destinations. Before you start, verify the bucket policies and user policies in Amazon S3
Console. These Amazon policies control access permissions of your Amazon S3 resources.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetBucketLocation"
],
"Resource": "<S3_bucket_ARN>/*"
}
]
}
S3 bucket policy

A bucket policy grants what actions are permitted for the authenticated account. These
permissions apply to all the specified objects in the bucket policy. Verify the S3 bucket policy
and tune it as necessary.

Also, turn off the “Object Lock” option if it is enabled on your S3 bucket.

The data in S3 lives forever by default unless they are explicitly removed. Plan and set the
correct life cycle policies for your S3 buckets before you define the destination in the Edge
Processor service.

To enlist an Amazon S3 bucket as an Edge Processor destination, select Amazon S3 under

the New destination dropdown. You will be routed to a page similar to the following:
Bucket name

The Amazon S3 bucket that you want to send data to with Object Lock turned off

Output data format

Currently the only supported output data format is the Splunk HTTP Event Collector schema in
newline delimited JSON format.

Authentication

You have two authentication options depending on where your Edge Processor instances will be
deployed.
1. For Edge Processors deployed outside of the Amazon EC2 environment, you must use an S3
access key and secret combination.

2. For Edge Processors running in Amazon EC2 regions, you may use either the access key and
secret combination or an AWS Identity and Access Management (IAM) role. However, using the
IAM role is recommended.

Advanced settings

Note that a single S3 object has a size limit of 5 GB in AWS. An attempt to upload an object
greater than this size may result in data loss. To minimize the number of objects in any one S3
partition, The Edge Processor flushes its buffer every 30 seconds or batches 4,096 events,
whichever comes first, as an S3 object. If necessary, you can adjust this batch count in the
"Advanced settings".

A schema for the S3 object partitioning is constructed using the values you enter in
"Amazon S3 object key name settings" along with auto-generated values by the Edge
Processor.

The current partition schema looks like this:

<bucketName>/<folderName>/<year>/<month>/<day>/<instanceID>/<filePrefix><UUID>.json

• The instance ID is the Edge Processor instance that is handling the data.
• The UUID is for the batched payload. It is automatically generated for each S3
object by the Edge Processor.
• If the data does not have a timestamp, the S3-partition defaults to the current
time.

For example, you have configured the following values for the object key names:

• Bucket name: foo

• Folder name: bar
• File prefix: baz-
{"event": "Hello, world!", "sourcetype": "foo", "host": "bar"}

When this "Hello, world!" payload enters and passes through an Edge Processor
pipeline without any other processing would have the S3 object partitioned like this:
S3://foo/bar/year=2023/month=08/day=21/instanceId=<EP_ID>/baz-<UUID>.json

Verifying destinations

To verify the destination connection, you must send data through an Edge Processor following
these steps:
 1. Deploy an Edge Processor instance.
2. Define a source-type.
3. Select a destination.
4. Optionally, create and apply a pipeline to the Edge Processor instance. The
default behavior of any Edge Processor can be set to send data to any
destination without a pipeline.
5. Send data to this Edge Processor instance.

To confirm that data is flowing to your destination, click the destination detail and review
the data-flow metrics. These metrics are not real-time so refresh the page to get the latest.
An additional confirmation is to search the data in the destination. For data sent to an S3
bucket, use the AWS-provided tools such as S3 bucket browser or AWS CLI.
Use Edge Processors
https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/AmazonS3Destination

Send data from Edge Processors to Amazon S3

Send data
Amazon S3from Edge Processors to
• To send data from an Edge Processor to an Amazon S3 bucket, you must first add an
Amazon S3 destination in the Edge Processor service. Depending on the environment that your
Edge Processor is installed in, you can configure the destination to use different authentication
methods to access your bucket:

• If any of the instances in your Edge Processor are not installed on Amazon EC2, then
you must authenticate the connection using the access key ID and secret access key of
an Identity and Access Management (IAM) user who can access the bucket.
• If all the instances of your Edge Processor are installed on Amazon EC2, then you can
choose to authenticate the connection using either an IAM role or an access key ID and
secret access key.
• You can then create a pipeline that uses that destination. When you apply that pipeline to
your Edge Processor, the Edge Processor starts sending data that it receives to your Amazon S3
bucket. In Amazon S3, the data from your Edge Processor is identified by an object key name that is
constructed using auto-generated values from the Edge Processor and some of the values that you
specify in the destination configuration.

How the Edge Processor constructs object key names

• When you send data from an Edge Processor to an Amazon S3 bucket, that data is identified
using an object key name with the following
format: <bucket_name>/<folder_name>/<year>/<month>/<day>/<instance_ID>/<file_prefix>-
<UUID>.<extension>

• When you create your Amazon S3 destination, you specify the bucket name, folder name,
file prefix, and file extension to be used in this object key name. The instance ID is taken from the ID
of the Edge Processor instance that handled the data, and the Edge Processor automatically
generates the date partitions and the UUID (universally unique identifier).
• For example, if you send data to Amazon S3 on October 31, 2022 using a destination that
has the following configurations:

• Bucket name: EdgeProcessor

• Folder name: FromUniversalForwarder
• File prefix: TestData
• Output data format: JSON (Splunk HTTP Event Collector schema)
• Compression type: Gzip
• Your data in Amazon S3 would be associated with an object key name like the following
example: EdgeProcessor/FromUniversalForwarder/year=2022/month=10/day=31/instanceId=72
c3a66d-b4f0-11ed-a3ec-0142ad120001/TestData-3ac12345-3b6f-12ed-78d6-
0242ec110002.json.gz .

Prerequisites
• Before you can send data to Amazon S3, the following requirements must be met:
• The Amazon S3 bucket that you want to send data to does not have Object Lock turned
on.

Object Lock cannot be turned off after it is turned on, so you might need to create a new
bucket. For more information,
see https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-
configure.html in the Amazon Simple Storage Service (S3) User Guide.

• You have the necessary credentials for accessing the bucket:

o If any of the instances in your Edge Processor are not installed on Amazon
EC2, then you must have the access key ID and secret access key for an IAM
user who can access the bucket.
o If all the instances of your Edge Processor are installed on EC2 and you
want to authenticate the connection to the bucket using your IAM role, then
you must grant your EC2 instances access to the bucket.
 See https://aws.amazon.com/premiumsupport/knowledge-center/ec2-
instance-access-s3-bucket in the AWS Knowledge Center.
• The IAM user or role that you plan to use has the following identity-based policy for
accessing the S3 bucket, where <S3_bucket_ARN> is replaced by the Amazon Resource
Name (ARN) of the bucket:
• {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Effect": "Allow",
• "Action": [
• "s3:PutObject",
• "s3:GetBucketLocation"
• ],
• "Resource": "<S3_bucket_ARN>/*"
• }
• ]
• }

• For more information about managing access to Amazon S3 resources,

see https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-
control.html in the Amazon Simple Storage Service (S3) User Guide.

Steps
1. In the Edge Processor service, select Destinations.
2. On the Destinations page, select New destination > Amazon S3.
3. Provide a name and description for your destination:
Field Description

Name A unique name for your destination.

Description (Optional) A description of your destination.

 4. Specify the object key name that you want to use to identify your data in the
Amazon S3 bucket. See How the Edge Processor constructs object key names for
more information.
Field Description

Bucket Name The name of the bucket that you want to send your data to.

•
Edge Processors use this bucket name as a prefix in the object key name.

Folder name (Optional) The name of a folder where you want to store your data in the bucket.
•
In the object key name, Edge Processors include this folder name after the bucket name and before a set of auto-generated timestamp
partitions.

File prefix (Optional) The file name that you want to use to identify your data.
•
In the object key name, Edge Processors include this file prefix after the auto-generated timestamp partitions and before an auto-
generated UUID value.

Output data Edge Processors only support the JSON (Splunk HTTP Event Collector schema) setting.
format
•
This setting causes your data to be stored as .json files in the Amazon S3 bucket. The contents of these .json files are formatted into the
event schema that's supported by the Splunk HTTP Event Collector. See Event metadata in the Splunk Cloud Platform Getting Data
In manual.

Compression The compression format for your data. Select one of the following options:
type

o Uncompressed: Your data is not compressed.

o Gzip: Compress your data using gzip. For JSON format, the Edge Processor uses file-level compression and changes the
resulting file extension to .json.gz.

5. Specify the AWS region and authentication method to allow this destination to
connect with your Amazon S3 bucket.
Field Description

Region The AWS region that your bucket is associated with.

Authentication The method for authenticating the connection between your Edge Processor and your Amazon S3
bucket.

•
If all of your Edge Processor instances are installed on Amazon EC2, then select Authenticate
using IAM role for Amazon EC2. Otherwise, select Authenticate using access key ID and
secret access key.

AWS access key ID The access key ID for your IAM user.
•
This field is available only when Authentication is set to Authenticate using access key ID
and secret access key.
AWS secret access The secret access key for your IAM user.
key
•
This field is available only when Authentication is set to Authenticate using access key ID
and secret access key.

6. (Optional) To adjust the maximum number of records that this destination sends
in each batch of output data, expand Advanced settings and enter your desired
maximum number of records in the Batch size field.

In most cases, the default Batch size value is sufficient. Be aware that the actual
size of each batch can vary depending on the rate at which the Edge Processor is
sending out data.

7. To finish adding the destination, select Add.

• You now have a destination that you can use to send data from an Edge Processor to an
Amazon S3 bucket.
• To start sending data from an Edge Processor to the Amazon S3 bucket specified in the
destination, create a pipeline that uses the destination you just added and then apply that pipeline
to your Edge Processor. For more information, see Create pipelines for Edge Processors and Apply
pipelines to Edge Processors.

AWS
AWS CLI Command Reference

https://awscli.amazonaws.com/v2/documentation/api/latest/index.html

Getting data into Edge Processor

This module guides you through the deployment and configuration of Edge
Processor nodes. By the end of this module, you will be able to accomplish the
following:

• Explain Edge Processor deployments

• Register Edge Processors
• Add Edge Processor instances
• Configure data sources

Deploying Edge Processor nodes

The Edge Processor clients (or the runtime-binaries) are installed in self-managed
environments. Deploying the Edge Processors into your existing environment requires
some planning as your collection strategy will dictate how you want to add and deploy
your Edge Processors. For production use, an Edge Processor instance must be running on
a dedicated host. It can be a single server instance or multiple nodes.
The real strength of deploying an Edge Processor in your environment is how easy it is to
scale and manage. If you need more computing resources to implement different collection
strategies, or to increase routing throughput, you can deploy multiple Edge Processor
instances as a cluster. The instances in this cluster topology share the same configurations.
Any changes you make to the parent group settings will get updated automatically on all
member-instances.
Note the following:

• The S2S traffic from the forwarder is load-balanced with the outputs.conf settings on
those forwards. This is a setting that you must apply on each forwarder.

• For HTTP Event Collector traffic going to the Edge Processor, you must provide your own
load balancing mechanism.

Client system requirements

Currently, you can only install Edge Processors on Linux servers that are on kernel version 4.9
and higher. At minimum, the host must be able to dedicate the following to the Edge Processor
runtime binaries:

• 2 x86-64 bit virtual CPUs

• 1 GB of RAM

• 20 GB of free disk space

If you plan to send to more than one destination, allocate an additional 5 GB of disk space per
destination.

Edge Processor uses port 1777 and port 8888 internally for its diagnostics and metrics.

Take a look at the following tabs for details on inbound and outbound traffic:

You must open the ports for S2S and HEC traffic.

Ports 9997 and 8088 are typically used, but you may use different ports. These are global
settings and apply to all Edge Processors.
Your network policy must allow all the ports used by your destinations.

Typically ports 443, 8088, 9997 and/or any other ports your destinations require. These are
configured per each destination.

Finally, Edge Processors must be able to communicate with Splunk Cloud services. Make
sure your firewall policy allows outbound calls to the following URLs
(replacing <tenant> with your cloud tenant ID):

• https://<tenant>.api.scs.splunk.com
• https://<tenant>.auth.scs.splunk.com
• https://auth.scs.splunk.com
• https://beam.scs.splunk.com

Considering other prerequisites

Depending on how you want to control default behaviors of your Edge Processor, the
following requirements should also be considered:

• When you install the Edge Processor client, you do not need
administrator level privileges on the Linux host. However, if you
want systemd to manage the underlying Edge Processor process, you
need the sudo privilege.
• Next, decide what to do with unprocessed data coming to the Edge
Processor. Unprocessed data refers to data that has no assigned
pipelines within the Edge Processor. You can specify either to drop, or to
route them to a default destination. If you want to route, then you must
have the destination created beforehand.
• Next, you need to decide how the Edge Processor receives its data – S2S
or HEC. Note, the inbound HEC input does not use authentication
currently. As noted earlier, the recommended practice is not to mix and
match the source-to-destination types because Edge Processor cannot
guarantee the connection flags to be propagated down to different
destinations.
 When Edge Processor receives parsed or unparsed UF data, it leaves it as
•
is. The implication is that this maintains the same TA-behavior in the
Splunk destinations. If you ingest HF data, the use of rulesets is the only
option to make further modifications at the indexing tier
• Use Edge Processors
Installation requirements for Edge
Processors
• Installation requirements for Edge Processors
Before installing an Edge Processor, make sure that the host that you're installing on meets the
following requirements. Meeting these requirements and addressing issues arising from the host
environment, including the hardware, operating system and network, is your responsibility.

• Hardware requirements
• Software requirements
• Network requirements

This is step 1 of 6 for using an Edge Processor to process data and route it to a destination. To see
an overview of all of the steps, see Quick start: Process and route data using Edge Processors.

Hardware requirements
The host machine where you want to install an Edge Processor must meet the following system
requirements.

Hardware Specifications

CPU 2 vCPUs

CPU x86 (64-bit)

architecture

Memory 2 GB, assuming that 1 GB from this amount is used to run the operating system.

Disk space 20 GB, assuming that the Edge Processor is configured to send data to 1 destination.

If the Edge Processor is configured to send data to multiple destinations, allocate an

additional 5 GB of disk space per destination.
 To prevent data loss, Edge Processors store queued data on the hard drive of the host as
needed.

To improve the performance of the Edge Processor, allocate resources beyond these minimum
requirements.

Software requirements
The host machine where you want to install an Edge Processor instance cannot already have
another Edge Processor instance installed on it. You must install each Edge Processor instance on a
different machine.
Additionally, the system clock of the host machine must be synchronized with a Network Time
Protocol (NTP) server. If the system time is incorrect, this can cause the Edge Processor installation
to fail due to prematurely expired security tokens. For information about how to synchronize the
system clock to an NTP server, refer to the documentation for your operating system.

Operating system support

You can only install Edge Processors on Linux servers that are on kernel version 4.9.x and higher.
The following Linux distributions are supported:

• Amazon Linux 2
• Debian 10 and 11
• Red Hat Enterprise Linux (RHEL) 8.0 and higher
• SUSE Linux Enterprise 15.0 and higher
• Ubuntu 20.04 LTS and 22.04 LTS

Network requirements
Configure your firewall settings and the ports on your host machines to allow your Edge Processors
to communicate with data sources, data destinations, the Edge Processor cloud service, and your
Splunk platform deployment.

• Firewall settings
• localhost ports
• Inbound ports
• Outbound ports

Firewall settings
The Edge Processors in your network must be able to communicate with the following external
resources:

• The Edge Processor service in the cloud

 •Any Splunk Cloud Platform deployments that are used as data destinations, including
the deployment that is paired with your cloud tenant
• Services that Splunk uses to monitor the health of the Edge Processor solution and
detect any unexpected disruptions in the service
Splunk collects information pertaining to the operational status of each Edge Processor. This
includes information such as the amount of data that is being sent through the Edge Processors, as
well as logs that track any events, warnings, or errors that have occurred.

This collected data only contains information pertaining to the operational status of the Edge
Processors. It does not contain any of the actual data that you are ingesting and processing through
Edge Processors.

To allow your Edge Processors to communicate with these external resources, make sure that your
firewall allows access to the following URLs:

External resource URLs

The Edge Processor service in the cloud Allow access to these URLs, where <tenant> is the name of your cloud tenant:

• https://<tenant>.api.scs.splunk.com
• https://<tenant>.auth.scs.splunk.com
• https://auth.scs.splunk.com
• https://beam.scs.splunk.com

The Splunk Cloud Platform deployment that is paired with your cloud For each deployment, allow access to the following URL, where
tenant, as well as any deployments that are used as data destinations <deployment_name> is the name of the Splunk Cloud Platform deployment:

*.<deployment_name>.splunkcloud.com

Services that Splunk uses to monitor the health of the Edge Processor Allow access to these URLs:
solution

• https://dataeng-data-cmp-prod.s3.us-east-1.amazonaws.com
• https://http-inputs-products-telemetry.splunkcloud.com
• https://telemetry-splkmobile.dataeng.splunk.com

localhost ports
Edge Processors use the following ports associated with localhost or IP address 127.0.0.1 to
support internal processes. Make sure that these ports are open for local loopback on the host
machines where you're installing your Edge Processors.
You don't need to expose these ports to external traffic.

Port Details

1777 Edge Processors use port 1777 to send logs to the edge_diagnostic tool.
 You can run the edge_diagnostic tool manually and locally on the host machine of the Edge Processor.
The tool compiles information from Edge Processor logs, but does not expose any information externally. For
more information, see Generate a diagnostic report for an Edge Processor instance.

8888 Edge Processors use port 8888 to send application health metrics to internal dashboards used by Splunk
Support.

Inbound ports
Edge Processors use inbound ports to listen for data from data sources. Make sure that these ports
are available and that your network policy allows them to be opened to incoming external traffic.
You can choose which port numbers to use for each supported type of inbound data. For more
information, see Configure shared Edge Processor settings.
By default, Edge Processors are configured to use the following inbound ports to receive data:

Port Type of data received

8088 Data that's transmitted through HTTP Event Collector (HEC)

9997 Data from Splunk forwarders

Edge Processors support the ingestion of syslog data, but do not have a default inbound port
configured for it. You must choose the port number for receiving syslog data. See Configure a port
for receiving syslog data.

Outbound ports
Edge Processors use outbound ports to communicate with other components in your Splunk
platform deployment and with external destinations. Make sure that these ports are available and
that your network policy allows them to be opened to outgoing external traffic.

Port Details

443 Edge Processors use port 443 to do the following:

• Connect instances to the Edge Processor service managed by Splunk.

• Send data to Amazon S3.

9997 By default, Edge Processors use port 9997 to do the following:

• Send internal logs to the Splunk Cloud Platform deployment that's connected to the tenant.
 • Send data to Splunk Enterprise and Splunk Cloud Platform.
If your Splunk platform deployments use ports other than 9997 to listen for incoming data, then
you must configure your Edge Processors to use those ports instead and make sure that those ports
are available.

• During the first-time setup process, you connect your tenant to a Splunk Cloud Platform
deployment. The listening ports used by the indexers in that deployment determine
which ports your Edge Processors use to send internal logs. For more information,
see First-time setup instructions for the Edge Processor solution.
• To configure the port that an Edge Processor uses to send data to Splunk Enterprise or
Splunk Cloud Platform, start by adding a Splunk platform destination that specifies the
correct port number. Then, use that destination in a pipeline and apply the pipeline to
your Edge Processor. See Send data from Edge Processors to non-connected Splunk
platform deployments using S2S and Send data from Edge Processors to non-connected
Splunk platform deployments using HEC for more information.
Use Edge Processors
Set up an Edge Processor
Set up an Edge Processor
The first step towards incorporating the Edge Processor solution into your existing Splunk
ecosystem is to configure and install an Edge Processor. An Edge Processor is a single server
instance or a group of multiple server instances that provide computing resources for processing
and routing data. You install Edge Processors in your own network so that you can reduce and
sanitize your data before sending it outside of your local network. See How the Edge Processor
solution works for more information about the Edge Processor architecture.
Setting up an Edge Processor involves completing the following tasks:

1. Adding an Edge Processor in your tenant. See Add an Edge Processor for more
information.
2. Installing an Edge Processor instance on a machine in your network. See Install
an Edge Processor instance for more information.
3. If necessary, adding more instances to the Edge Processor to provide more
computing resources. See Add more instances to an Edge Processor for more
information.

This is step 2 of 6 for using an Edge Processor to process data and route it to a destination. To see
an overview of all of the steps, see Quick start: Process and route data using Edge Processors.
Prerequisites
Make sure that the environment where you're installing the Edge Processor meets the system and
network requirements. See Installation requirements for Edge Processors.
Depending on how you want to configure your Edge Processor, the following requirements might
also apply:

• When installing the Edge Processor instance, you can choose to configure systemd on
your host machine to manage the underlying process of the Edge Processor instance as
a service. If you want to use this configuration, you must have super user permissions
on the host machine.
• To prevent unprocessed data from being dropped, you'll need to configure your Edge
Processor to use a default destination for storing unprocessed data. To do this, you
must first create a destination. See Add or manage destinations and Data pathway for
more information.
o If you plan to use a Splunk platform HEC destination as the default
destination, make sure that the Default source type setting in the
destination specifies an appropriate value. If the events routed to this
destination aren't already associated with a source type, then the Default
source type value is used.
• You can secure communications between your data source and your Edge Processor
using TLS or mutually authenticated TLS (mTLS). When TLS or mTLS is active, the data
source and the Edge Processor must prove their identities by presenting valid TLS
certificates before they can connect and communicate with each other.
o If you want to use mTLS, then you must have the following certificates in
Privacy Enhanced Mail (PEM) format:
▪ A client certificate, CA certificate, and private key that the data
source can use to prove its identity.

The instructions on this page focus on Edge Processor

configurations, and do not explain how to configure a data
source to use TLS certificates. For information about data
source configurations, see the Get data into Edge
Processors chapter.

▪ A server certificate, CA certificate, and private key that the Edge

Processor can use to prove its identity.
o If you want to use TLS, then you must have the following certificates in PEM
format:
▪ A server certificate, CA certificate, and private key that the Edge
Processor can use to prove its identity.
These certificates can be self-signed or they can be signed by a third-party. See Obtain
TLS certificates for data sources and Edge Processors for information on generating
client and server certificates.

Add an Edge Processor

In the Edge Processor service, add an Edge Processor and specify configuration settings that apply
to all instances of this Edge Processor.

1. In the Edge Processor service, navigate to the Edge Processors page and then
select New Edge Processor.
2. Enter a Name and a Description for the Edge Processor.
3. To prevent unprocessed data from being dropped, specify a default destination
that the Edge Processor can send the unprocessed data to. Select To a default
destination. Then, from the Default destination drop-down list, select the
destination you want to use.
4. To turn on receivers that allow your Edge Processor to receive data from specific
data inputs, select data inputs as necessary in the Receive data from these
inputs section.
5. If you want to use TLS or mTLS to secure communications between this Edge
Processor and the data sources that are sending data to it, then do the following:
1. Select your preferred type of connection protocol for your data inputs.
2. If you choose to use mTLS with your data input, upload PEM files
containing the certificates for proving the Edge Processor's identity in
the Server private key, Server certificate, and CA certificates fields.
3. If you choose to use TLS with your data input, upload PEM files
containing the certificates for proving the Edge Processor's identity in
the Server private key, and Server certificate fields.

The Edge Processor uses the same PEM files to prove its identity to all
data sources where TLS or mTLS is used. For example, if you select
both Splunk forwarders and HTTP Event Collector, then the Edge
Processor uses the same server-side PEM files when receiving data
from forwarders and HEC data sources.

6. Select Save.
The Edge Processor service creates an Edge Processor configuration with the settings that you
specified. Next, install an instance of this Edge Processor on a machine in your network.

Install an Edge Processor instance

After adding an Edge Processor in your tenant, you can install an instance associated with that Edge
Processor on a host machine in your network.
As an optional configuration during this installation procedure, you can configure systemd on your
host machine to manage the underlying process of the Edge Processor instance as a service.
Configuring systemd to manage the splunk-edge process allows systemd to start the process at
boot and automatically restart the process if it is terminated unexpectedly.
Choose the installation procedure that suits your needs:

• Install an instance without configuring systemd

• Install an instance and configure systemd
Install an instance without configuring systemd
Use the installation commands provided in the Edge Processor service to install an Edge Processor
instance.

1. In your cloud tenant, locate and copy the installation commands.

1. On the Edge Processors page, in the row that lists your Edge
Processor, select the Actions icon ( ) and then select Open.
2. In the panel that contains your Edge Processor details, select Manage
instances.
3. Select the Install/uninstall tab, and then expand the Step 1: Run
commands to install/uninstall instances section.
4. Select Install to view the commands for downloading and installing
an Edge Processor instance on a Linux machine, and then select Copy
to clipboard.

These commands contain sensitive information about your cloud

environment. Do not share these commands with anyone except your
Splunk representative or trusted members in your organization.

2. On the machine where you want to install the instance, open a command-line
interface in the directory where you want to install the Edge Processor instance
and then paste and run the commands.
The commands create a splunk-edge directory in your chosen installation
location.
3. To verify that the instance was installed successfully, return to your cloud tenant
and select the Instances tab in the Manage instances panel. Confirm that your
instance is listed and has the Healthy status. It may take up to 1 minute for the
status to change to Healthy. See Manage and uninstall Edge Processors for
information about instance statuses and what they mean.
You now have a single-instance Edge Processor that you can use to receive and process data. For
information about creating and applying pipelines for data processing, see Create pipelines for Edge
Processors.
If you want to scale out your Edge Processor to a group of multiple Edge Processor instances, see
the Add more instances to an Edge Processor section for information.

Install an instance and configure systemd

When configuring systemd to manage the splunk-edge process as a service, you must associate a
control group (cgroup) and a user to that service. The user must have read and write permissions
for the directory where you want to install the Edge Processor instance.

The following instructions ensure that the user has the necessary permissions by setting the home
directory of the user to the installation directory of the Edge Processor instance. However, if
desired, you can choose to use an existing cgroup and user or configure the user permissions
through another method.
1. On the machine where you want to install the instance, create a cgroup and a
user.
1. Create a cgroup by running the following command, where
<group_name> is the name of the cgroup:
sudo groupadd <group_name>

2. Create a user by running the following command, where

<install_location> is the directory where you want to install the Edge
Processor instance, <group_name> is the name of the cgroup, and
<username> is the name of the user.
3. sudo useradd -d <install_location>/splunk-edge -g `gre
p <group_name> /etc/group | awk -F ":" {'print $3'}` -
m -s /bin/bash <username>
4. (Optional) To confirm you've successfully created the cgroup and
user, run the following commands:
sudo grep <group_name> /etc/group
sudo grep <username> /etc/passwd
These commands return information about the cgroup and the user if
you have successfully created them.

2. In your cloud tenant, navigate to the panel that displays the installation
commands.
1. On the Edge Processors page, in the row that lists your Edge
Processor, select the Actions icon ( ) and then select Open.
2. In the panel that contains your Edge Processor details, select Manage
instances.
3. Select the Install/uninstall tab, and then expand the Step 1: Run
commands to install/uninstall instances section.
4. Select Install to view the commands for downloading and installing
an Edge Processor instance on a Linux machine, and then select Copy
to clipboard.

These commands contain sensitive information about your cloud

environment. Do not share these commands with anyone except your
Splunk representative or trusted members in your organization.

5. Open a text editor and paste the commands. Delete the following
command, which comes after the # Install the Edge Processor
instance comment:

nohup ./splunk-edge/bin/splunk-edge run >> ./splunk-ed

ge/var/log/install-splunk-edge.out 2>&1 </dev/null &

6. Copy the commands that remain.

3. On the machine where you want to install the instance, create and populate the
installation directory.
1. Log in as the user that you created during step 1.
 2. Open a command-line interface in the directory where you want to
install the Edge Processor instance.
3. Paste and run the commands that you copied during step 2f.
The commands create a splunk-edge directory in your chosen
installation location. In the steps that follow, <install_directory>
represents the fully qualified path to this splunk-edge directory. For
example, if you completed step 3c in the /opt/ directory, then
<install_directory> is /opt/splunk-edge.
4. Open the <install_directory>/etc/splunk-edge.service file and make sure that
the User and Group properties are set to the user and cgroup that you created
during step 1. Additionally, make sure that the ExecStart property is set as
follows:
ExecStart=<install_directory>/bin/splunk-edge run

5. To add the splunk-edge process to systemd and then finish installing the Edge
Processor instance, run the following commands:
6. sudo chown -R splunk: <install_directory>
7. sudo cp <install_directory>/etc/splunk-edge.service /etc/system
d/system
8. sudo systemctl daemon-reload
9. sudo systemctl enable splunk-edge
10. sudo systemctl start splunk-edge
When the installation is complete, the following message is returned:

splunk-edge.service - Splunk edge starter

Loaded: loaded (/etc/systemd/system/splunk-edge.service, en
abled)
Active: active (running)

11. To confirm that you've successfully added the splunk-edge process to systemd ,
run the following command:
sudo systemctl status splunk-edge.service
Review the status information that is returned and confirm that there are no
errors.

12. To verify that the instance is healthy, return to your cloud tenant and select
the Instances tab in the Manage instances panel. Confirm that your instance is
listed and has the Healthy status. It may take up to 1 minute for the status to
change to Healthy. See Manage and uninstall Edge Processors for information
about instance statuses and what they mean.
You now have a single-instance Edge Processor that you can use to receive and process data. For
information about creating and applying pipelines for data processing, see Create pipelines for Edge
Processors.
If you want to scale out your Edge Processor to a group of multiple Edge Processor instances, see
the Add more instances to an Edge Processor section for information.
Add more instances to an Edge Processor
To ensure that your Edge Processor has sufficient computing resources for your data processing
workload, you can scale out your Edge Processor into a group of multiple Edge Processor instances
as needed.
Be aware that there is a soft limit on the maximum number of Edge Processor instances that can be
supported. See Tested and recommended service limits (soft limits) in the Splunk Cloud Platform
Service Details for more information.
To scale out your Edge Processor by adding more instances, do the following:

1. Install an instance on another machine in your environment. See the Install an

Edge Processor instance section on this page.
2. If you have already configured data sources to send data to this Edge Processor,
then you must update their configurations to account for the added Edge
Processor instance:
Type of data Configuration instructions
source

Splunk In the outputs.conf file, update the server property to include the host and port information of your new instance. You
forwarders can get an outputs.conf stanza with the settings relevant to your Edge Processor by selecting the Configure data
sources action for your Edge Processor and then selecting Splunk forwarder from the drop-down list.

As a best practice, if you have many forwarders configured to send data to the same multi-instance Edge Processor,
use a DNS record to keep your outputs.conf settings up to date. Map all the Edge Processor instance hosts to a DNS
record, and then set the server property in your outputs.conf files to the IP address of that DNS record. When you
add or remove instances to your Edge Processor, you only need to update the DNS record instead of updating
multiple outputs.conf files. For more information about using a DNS to manage forwarder outputs, see Options for
configuring receiving targets for load balancing in the Splunk Cloud Platform Forwarding Data manual.

HTTP clients or If you want the HTTP client or logging agent to send data to multiple Edge Processor instances, you must set up a load
logging agents balancer to pass the HTTP request to all of the instances. Then, update the URI of the HTTP request so that the request is
using HTTP directed to the load balancer.
Event Collector
(HEC) Otherwise, if you want the HTTP client or logging agent to send data to the new Edge Processor instance only,
update the URI of the HTTP request so that the request is directed to the new instance. You can get HTTP request
examples with hostname and port values relevant to your instance by selecting the Configure data sources action
for your Edge Processor and then selecting HTTP Event Collector from the drop-down list.

You now have a group of Edge Processor instances that you can use to receive and process data. For
information about creating and applying pipelines for data processing, see Create pipelines for Edge
Processors.
https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/CreateNode
Adding an Edge Processor
To add an Edge Processor, click Edge Processors in the SCP menu and then click the New Edge
Processor button. The “Add an Edge Processor” panel will appear.
Name
The name given here represents the logical cluster group. It can have a single instance or a group of
instances.
Since you will have different options to deploy Edge Processors, it is a good practice to have a
naming convention. That way you can easily identify different Edge Processor clusters.
Default destination
This setting determines how to handle unprocessed data. Select either to forward or drop them.

Splunk forwarders send their internal logs destined to the _internal, _audit, and _introspection
indexes. To Edge Processor, these internal logs are unprocessed data. Pay special attention when
selecting the default destination. Normally you want to aggregate these internal logs to a single
destination.

If that destination is somewhere other than the paired Cloud stack, recommend selecting a “Splunk
platform S2S” destination.

If you are planning to aggregate unprocessed data to destinations other than the Splunk indexers,
then you must create separate pipelines to filter and route, because non-Splunk destinations only
work with the source type associated pipelines.

Receiver setttings
Edge Processors can receive data from Splunk forwarders and HTTP Event Collectors currently.
Select which type of connections you want the Edge Processor to use. If you want to secure
communication between this Edge Processor group and your data sources, select TLS. You must
provide a TLS package to both Edge Processor and your data source clients.

PEM files
Upload the following PEM files:
• A server private key
• A server certificate
• A CA certificate
The certificates can be self-signed or signed by a third-party. The TLS for outbound traffic is
configured in the Destinations menu.
Fill in the required fields and click Save.

Use Edge Processors

Data pathway

How the Edge Processor solution

works
The Edge Processor solution combines Splunk-managed cloud services, on-premises data
processing software, and the Search Processing Language, version 2 (SPL2) to support data
processing at the edge of your network. The Edge Processor solution consists of the following main
components:

Component Description Usage

Edge A data processing engine that allocates You install Edge Processors on machines in your local network. Edge Processors provide
Processor resources for processing and routing data an on-premises data plane that lets you reduce and sanitize your data before sending it
outside of your network.
Edge A cloud service that provides a centralized Splunk hosts the Edge Processor service as part of Splunk Cloud Platform. The Edge
Processor console for managing Edge Processors Processor service provides a cloud control plane that lets you deploy configurations,
service monitor the status of your Edge Processors, and gain visibility into the amount of data that
is moving through your network.

Pipeline A set of data processing instructions In the Edge Processor service, you create pipelines to specify what data to process, how to
written in SPL2, which is the data search process it, and what destination to send the processed data to. Then, you apply pipelines to
and preparation language used by Splunk your Edge Processors to configure them to start processing data according to those
software instructions.

By using the Edge Processor solution, you can process data in your own local network while also
managing and monitoring your data ingest ecosystem from a Splunk-managed cloud service.
The following diagram provides an overview of these elements:

• The components that comprise the Edge Processor solution, and whether each
component is hosted in the Splunk cloud environment or your local environment. See
the System architecture section on this page for more information.
• The path your data takes as it moves from source to destination through an Edge
Processor. See the Data pathway section on this page for more information.

System architecture
The primary components of the Edge Processor solution include the Edge Processor service, Edge
Processors, and SPL2 pipelines that support data processing.

Edge Processor service

The Edge Processor service is a cloud service hosted by Splunk. It is part of the data management
experience, which is a set of services that fulfill a variety of data ingest and processing use cases.
You can use the Edge Processor service to do the following:

• Configure and install Edge Processors on your local environment for on-location data
processing.
• Create and apply SPL2 pipelines that determine how each Edge Processor processes
and routes the data that it receives.
• Define source types to identify the kind of data that you want to process and determine
how Edge Processors break and merge that data into distinct events.
• Create connections to the destinations that you want your Edge Processors to send
processed data to.
You access the Edge Processor service by logging in to your tenant in the Splunk cloud
environment. Your tenant is connected with your Splunk Cloud Platform deployment, and uses it as
an identity provider for managing user accounts and logins. To log in and access the Edge Processor
service, use the same username and password as you would when logging in to your Splunk Cloud
Platform deployment.
The connection between the tenant and the Splunk Cloud Platform deployment also allows the Edge
Processor solution to use the deployment as a storage location for the logs and metrics that are
generated by Edge Processors. The Edge Processor service retrieves these logs and metrics from
the deployment and displays them in the user interface of the service.

These Edge Processor logs and metrics only contain information pertaining to the operational
status of a given Edge Processor. They do not contain any of the actual data that you are ingesting
and processing through Edge Processors. See the Edge Processors section that follows for more
details.

Edge Processors
An Edge Processor is a data processing engine that allocates resources for processing and routing
data. You can install an Edge Processor on a single server node in your network or on a cluster of
multiple server nodes. Multi-instance Edge Processors provide more powerful data processing
capabilities than single-instance Edge Processors. Be aware that multiple Edge Processor instances
cannot run on the same machine, so you must install each instance on a different machine.
Each Edge Processor instance is associated with a supervisor, which contacts the cloud service at
regular intervals to check for system updates, provide telemetry data, and confirm that the instance
is still connected to the service. When you use the Edge Processor service to change your Edge
Processor configurations or pipeline definitions, or when Splunk releases new features or bug fixes
for Edge Processors, the supervisor detects these changes and automatically updates the instance
as needed.
The supervisor sends the following information from the Edge Processor instance to the Edge
Processor service in the cloud:

• Configuration information. This includes details such as the following:

o The list of applied pipelines
 o The datasets that represent the selected data sources and destinations
o The names of the Splunk indexes that the Edge Processor sends internal
logs and metrics to
o The version of the Edge Processor software that the instance is running
• Heartbeats that indicate the status of the Edge Processor instance and confirm if the
instance is still connected to the service. These heartbeats include information such as
the following:
o Whether the instance is running or stopped
o How much CPU and memory the instance is consuming
o The version of the Edge Processor software that the instance is running
As an Edge Processor works to process data, it generates logs and metrics containing operational
information such as the amount of data that was processed and any events, warnings, or errors that
have occurred. The Edge Processor sends these logs and metrics to the Splunk Cloud Platform
deployment that is connected to the tenant.

The information that an Edge Processor instance and its supervisor sends to the cloud does not
contain any of the actual data that is being ingested and processed. The data that you send through
an Edge Processor only gets transmitted to the destinations that you choose in the Edge Processor
configuration settings and the applied pipelines.

Pipelines
A pipeline is a set of data processing instructions written in SPL2. When you create a pipeline, you
write a specialized SPL2 statement that specifies which data to process, how to process it, and
where to send the results. For example, you can create a pipeline that filters for syslog events and
sends them to a dedicated index in Splunk Cloud Platform. When you apply a pipeline to an Edge
Processor, the Edge Processor uses those instructions to process all the data that it receives from
data sources such as Splunk forwarders, HTTP clients, and logging agents.
The Edge Processor solution supports a subset of SPL2 commands and functions. Pipelines can
include only the commands and functions that are part of the EdgeProcessor profile. For
information about the specific SPL2 commands and functions that you can use to write pipelines for
Edge Processors, see Edge Processor pipeline syntax. For a summary of how
the EdgeProcessor profile supports different commands and functions compared to other SPL2
profiles, see the following pages in the SPL2 Search Reference:

• Compatibility Quick Reference for SPL2 commands

• Compatibility Quick Reference for SPL2 evaluation functions

Data pathway
Data moves through the Edge Processor solution as follows:

1. A tool, machine, or piece of software in your network generates data such as

event logs or traces.
 2. An agent, such as a Splunk forwarder, receives the data and then sends it to an
Edge Processor. Alternatively, the device or software that generated the data can
send it to an Edge Processor without using an agent.
3. The Edge Processor filters and transforms the data, and then sends the resulting
processed data to a destination such as an indexer then into a Splunk index.
By default, Edge Processors route processed data to destinations based on any pipelines you
applied. If there are no applicable pipelines, then unprocessed data is either dropped or routed to
the default destination specified in the configuration setting of the Edge Processor. For more
information about how data moves through an Edge Processor, see Partitions.
If you don't specify a default destination, then Edge Processors drop unprocessed data.

As the Edge Processor receives and processes data, it measures metrics indicating the volume of
data that was received, processed, and sent to a destination. These metrics are stored in
the _metrics index of the Splunk Cloud Platform deployment that is connected to your tenant. The
Edge Processor service surfaces the metrics in the dashboard, providing detailed overviews of the
amount of data that is moving through the system.

Partitions
Each Edge Processor instance merges the received data into an internal dataset before processing
and routing that data. A partition is a subset of data that is selected for processing by a pipeline.
Each pipeline that you apply to an Edge Processor creates a partition from the internal dataset. For
information about how to specify a partition when creating a pipeline, see Create pipeline for Edge
Processors.
The partitions that you create and the configuration of your Edge Processor determines how the
Edge Processor routes the received data and whether any data is dropped:

• The data that the Edge Processor receives is defined as processed or unprocessed based
on whether there is at least one partition for that data. For example, if your Edge
Processor receives Windows event logs and Linux audit logs, but you only applied a
pipeline for Windows event logs, then those Windows event logs are selected in a
partition and considered to be processed while the Linux audit logs are considered to
be unprocessed.
• Each pipeline creates a partition of the incoming data based on specified conditions, and
only processes data that meets those conditions. Any data that does not meet those
conditions is considered to be unprocessed.
• If you configure your pipeline to filter the processed data, the data that is filtered out
gets dropped.
• If you configure your Edge Processor to have a default destination, then the
unprocessed data goes to that default destination.
• If you do not set a default destination, then the unprocessed data is dropped.
The following is a diagram of the Edge Processor data pathway.
See also
For information about how to set up and use specific components of the Edge Processor solution,
see the following resources.

• Set up an Edge Processor

• Create pipelines for Edge Processors
• Using source types to break and merge data in Edge Processors
• How the destination for Edge Processor works
• View logs for the Edge Processor solution
• Use Edge Processors
Obtain TLS
sources
• andcertificates
Edge Processors
for data
Obtain TLS certificates for data sources and Edge Processors
You can use mutually authenticated TLS (mTLS) to secure communications between data sources
and Edge Processors. When mTLS is active, the data source and the Edge Processor must prove
their identities by presenting valid TLS certificates before they can connect and communicate with
each other. To configure mTLS, you must provide client certificates that validate the identity of the
data source and server certificates that validate the identity of the Edge Processor.
The instructions on this page describe how to obtain the necessary TLS certificates. If you already
have certificates that you'd like to use, then proceed to the following pages for information on how
to configure your data source and Edge Processor to use the certificates:

• Get data from a forwarder into an Edge Processor

• Get data into an Edge Processor using HTTP Event Collector
• Get syslog data into an Edge Processor
The certificates that you use to configure mTLS between data sources and Edge Processors are
different from the certificates that you use to configure TLS or mTLS between Edge Processors and
Splunk indexers. If you are looking for instructions on configuring TLS or mTLS between Edge
Processors and indexers, see the "Obtaining TLS certificates" section in Send data from Edge
Processors to non-connected Splunk platform deployments using S2S or Send data from Edge
Processors to non-connected Splunk platform deployments using HEC.

Configuring mTLS between data sources and

Edge Processors
Configuring mTLS involves the following high-level steps:

1. Get or generate the following certificates:

o A client certificate, private key, and CA certificate that the data source
can use to prove its identity.
o A server certificate, private key, and CA certificate that the Edge
Processor can use to prove its identity.
Typically, each certificate is stored in a separate Privacy Enhanced Mail (PEM)
file. However, if the data source is a Splunk forwarder, then you must concatenate
the client certificate, private key, and CA certificate in the listed order into the
same PEM file. For more information, see How to prepare TLS certificates for use
with the Splunk platform in the Securing Splunk Enterprise manual.

2. Configure your data source to use the client certificates.

3. Upload the server certificates to your Edge Processor.

The Edge Processor uses the same PEM files to prove its identity to all data
sources where mTLS is used. For example, if you turn on mTLS for both Splunk
forwarders and HTTP Event Collector (HEC) data sources, then the Edge
Processor uses the same server-side PEM files when receiving data from both
types of data sources.

The steps that you must follow to obtain TLS certificates depend on the type of certificates you
intend to use. You have two options for obtaining these certificates:

• Create and sign the certificates yourself. This is the fastest and lowest cost method
for getting certificates, but it is less secure than getting signed certificates from a third
party. For instructions, see Generate and self-sign client and server certificates to
secure communications on this page.
• Get signed certificates from a third party. This option is the most secure method for
getting certificates, but it involves a third party and potentially a cost to obtain the
certificates. For instructions, see Obtain a certificate from a third-party on this page.

If you're working with a Splunk forwarder that has the sslVerifyServerCert property in the
outputs.conf file turned on, then you must use a certificate from a third party.

Generate and self-sign client and server

certificates to secure communications
Follow these steps if you've chosen to create and sign your own certificates to secure
communications between data sources and Edge Processors.
Before creating a certificate authority (CA), you must choose a signing algorithm for the CA's
private key. Follow the set of instructions that match the signing algorithm that you'd like to use:

• RSA: Generate self-signed client and server certificates

• ECDSA: Generate self-signed client and server certificates

RSA: Generate self-signed client and server certificates

Follow these steps if you've chosen to create and sign your own certificates with the RSA signing
algorithm to secure communications between data sources and Edge Processors.

1. Open a command line interface, for example, a shell prompt, or a Terminal or

PowerShell window.
2. Create a new directory that you'd like to store your certificates on.
3. Change to the new directory you created.
4. Create the Certificate Authority's certificate and keys.
1. Generate a private key for the CA.
2. openssl genrsa 2048 > ca_key.pem
3. Generate the self-signed CA certificate. Replace the text contained in
the -subj flag with the information relevant to you.
4. openssl req -new -x509 -nodes -days 825 -sha256 -subj
"/C=<Country>/O=<Organization>/CN=<Common-Name>/emailA
ddress=<Email>" -key ca_key.pem -out ca_cert.pem
5. Create the server certificate and keys.
1. Generate the private and public keys for your server. Replace the text
contained in the -subj flag with the information relevant to you.
2. openssl req -newkey rsa:2048 -nodes -days 825 -sha256
-subj "/C=<Country>/O=<Organization>/CN=<Common-Name>/
emailAddress=<Email>" -keyout edge_server_key.pem -out
edge_server_req.pem
3. Sign the server certificate using your self-signed root CA.
4. openssl x509 -req -days 825 -sha256 -set_serial 01 -ex
tfile <(printf "subjectAltName=DNS:<FQDN_Edge_Processo
r_Instance>") -in edge_server_req.pem -out edge_server
_cert.pem -CA ca_cert.pem -CAkey ca_key.pem
5. Verify the server certificates.
6. openssl verify -CAfile ca_cert.pem edge_server_cert.pe
m
6. Create the client certificate and keys.
1. Generate the private key and certificate request. Replace the text
contained in the -subj flag with the information relevant to you.
2. openssl req -newkey rsa:2048 -nodes -days 825 -sha256
-subj "/C=<Country>/O=<Organization>/CN=<Common-Name>/
emailAddress=<Email>" -keyout data_source_client_key.p
em -out data_source_client_req.pem
 3. Sign the client certificate using your self-signed root CA.
4. openssl x509 -req -days 825 -sha256 -set_serial 01 -in
data_source_client_req.pem -out data_source_client_cer
t.pem -CA ca_cert.pem -CAkey ca_key.pem
5. Verify the client certificates.
6. openssl verify -CAfile ca_cert.pem data_source_client_
cert.pem

ECDSA: Generate self-signed client and server certificates

Follow these steps if you've chosen to create and sign your own certificates with the ECDSA signing
algorithm to secure communications between data sources and Edge Processors.

1. Open a command line interface, for example, a shell prompt, or a Terminal or

PowerShell window.
2. Create a new directory that you'd like to store your certificates on.
3. Change to the new directory you created.
4. Create the Certificate Authority's certificate and keys.
1. Generate an ECDSA private key for the CA.
2. openssl ecparam -genkey -name prime256v1 -out ca_key.p
em
3. Generate the self-signed CA certificate. Replace the text contained in
the -subj flag with the information relevant to you.
4. openssl req -x509 -new -SHA384 -nodes -days 825 -subj
"/C=<Country>/O=<Organization>/CN=<Common-Name>/emailA
ddress=<Email>" -key ca_key.pem -out ca_cert.pem
5. Create the server certificate and keys.
1. Generate the server key.
2. openssl ecparam -genkey -name prime256v1 -out edge_ser
ver_key.pem
3. Generate the private key and certificate request. Replace the text
contained in the -subj flag with the information relevant to you.
4. openssl req -new -SHA384 -key edge_server_key.pem -nod
es -subj "/C=<Country>/O=<Organization>/CN=<Common-Nam
e>/emailAddress=<Email>" -out edge_server_req.pem
5. Sign the server certificate using your self-signed root CA.
6. openssl x509 -req -days 825 -set_serial 01 -extfile <(
printf "subjectAltName=DNS:<FQDN_Edge_Processor_Instan
ce>") -in edge_server_req.pem -out edge_server_cert.pe
m -CA ca_cert.pem -CAkey ca_key.pem
7. Verify the server certificates.
8. openssl verify -CAfile ca_cert.pem edge_server_cert.pe
m
6. Create the client certificate and keys.
1. Generate the client key.
2. openssl ecparam -genkey -name prime256v1 -out data_sou
rce_client_key.pem
 3. Generate the private key and certificate request. Replace the text
contained in the -subj flag with the information relevant to you.
4. openssl req -new -SHA384 -key data_source_client_key.p
em -nodes -subj "/C=<Country>/O=<Organization>/CN=<Com
mon-Name>/emailAddress=<Email>" -out data_source_clien
t_req.pem
5. Sign the client certificate using your self-signed CA.
openssl x509 -req -SHA384 -days 825 -set_serial 01 -in
data_source_client_req.pem -out data_source_client_cer
t.pem -CA ca_cert.pem -CAkey ca_key.pem

6. Verify the client certificates.

7. openssl verify -CAfile ca_cert.pem data_source_client_
cert.pem

Confirm that you have the required certificates

After generating and self-signing the certificates, you have the following files:

File name Description

ca_cert.pem The CA certificate that will be uploaded to both the Edge Processor and the data

edge_server_cert.pem The server certificates that will be uploaded to an Edge Processor

edge_server_key.pem The private key associated with the server certificate

data_source_client_cert.pem The client certificates that will be uploaded to a data source

data_source_client_key.pem The private key associated with the client certificate

Obtain a certificate from a third party

If you want to use a signed third party certificate from a CA such as Let's Encrypt, Sectigo, or
Symantec, you can acquire the certificate directly from those CAs, and upload them to the Edge
Processor service.
You will need to ask the third party for the client certificates for the data sources, the server
certificates for the Edge Processors, and the CA certificate. If there is an intermediate certificate
from the third party, then add it to your server certificate:
cat edge_server_cert.pem intermediate.pem > edge_server_cert.pem

Create a combined certificate file for a

Splunk forwarder
When preparing TLS certificates for proving the identity of a universal forwarder or a heavy
forwarder, you must combine the certificates into a single PEM file. For more information, see How
to prepare TLS certificates for use with the Splunk platform in the Securing Splunk
Enterprise manual.

Next steps
Configure your data source and Edge Processor to use the TLS certificates. See the following pages:

• Get data from a forwarder into an Edge Processor.

• Get data into an Edge Processor using HTTP Event Collector
• Get syslog data into an Edge Processor

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/SecureForwarders

Installing an Edge Processor client

When you click “Save”, the UI presents a client installation script that you can run on a
Linux host. This tailored script includes a connection token for initial client bootstrapping.
This is good for many additional installations, but will expire. Adding additional nodes later
will require you to revisit this page for a new token.
DO NOT share this script if you are adding an instance to another Edge Processor cluster.
The connection token in the script is tailored for this specific group but it can also be used
to communicate with the SCS service APIs.
Once the client has bootstrapped and is running, the Supervisor maintains a separate identity token
automatically.
The script performs the following:

1. Downloads the latest Supervisor package from Splunk Cloud Service and validates
its authenticity.
2. Extracts the package into the directory called splunk-edge in your current working
directory.
3. Saves the SCS environment information and the authentication token.
4. Contacts the SCS tenant for the latest runtime package.
5. Installs the latest Edge Processor runtime and other support processes.
Do not interrupt the script. Let the installation finish, after which you will be presented
with a screen similar to the following in SCP:

If you navigate to the Edge Processors landing page, you will see your new instance and its
health status:
When the "Instance health" status turns to green , you are good to continue.
Running Edge Processors under systemd
The installation script configures your Edge Processor client to run in the user session.
Optionally, you may configure the splunk-edge process as a service and
have systemd manage the underlying process. By doing so, systemd can start the process at
boot time or automatically restart it if it is terminated unexpectedly.
For this purpose, the installation script provides a unit file template called splunk-
edge.service. You can find this file in the etc sub-directory.
Before you can use the unit file, you need to prepare the host. The template file is hard-
coded to use "splunk" as the user and the group. The user running the service must have
read and write permissions to the installation directory and have the associated control
group, or cgroup, provisioned.
Scaling and working with service limits and constraints
You now have a single Edge Processor instance running in the logical group.
By default, the instance health warning is set to trigger when either of the CPU or memory
resource usage crosses 80%. This profiling is based on a 30-second interval.
An occasional high usage may be OK but if it is in a warning state for a prolonged time,
consider adding more nodes to the Edge Processor.
Each Splunk Cloud tenant permits up to 50 Edge Processor instances, deployed across up to
10 clusters or 100TB/day total traffic running through all deployed instances.
Clustering Edge Processor nodes
If you decide to scale out your Edge Processor, select the Actions icon associated with the
current Edge Processor name – shown as three vertical dots.

Instance options
Open the instance options by clicking the three vertically stacked dots.
Manage instances
Select 'Manage instances'
Select Manage instances > Install/uninstall.
You will be presented with an installation script similar to the one above. Execute the script
in the new instance, configure the systemd unit file if it's used, and wait for the instance to
reach a healthy state. If you are using systemd to manage the splunk-edge process, be sure
to configure the account and the cgroup settings in the new instance first as you have
learned in the previous topic. You might need to update your data sources after installing.
You will learn about this next.
Again, these settings apply globally to all instances in this group. You have set these details
while adding the name for this logical group. If you have turned on the TLS option for
inbound forwarder data, all forwarders should be configured to use the same client
certificates.
If the new nodes are set to receive data from Splunk forwarders, click the “View updated
stanzas” button, after all Edge Processor instances are in healthy state. This generates
updated stanzas that you can copy and paste into the outputs.conf file of each forwarder.
The forwarders will handle the load balance across the identified instances in the “server”
attribute. Depending on your Edge Processor configurations, you might have to check, and
additionally update other .conf files on the forwarders.
Configuring data sources

If you are adding a new Edge Processor instance at a later time, select the Actions icon and
select “Configure data sources”. A panel overlay will slide in providing you with the details
required to configure the new data source. There are three options:
• Splunk forwarder
• HTTP event collector
• Syslog
To distribute HTTP Event Collector data across the instances in this cluster, remember, you
need to use a network or an application load balancer.
When configuring your input agents to send data sources to this Edge Processor group, a
good practice is to use a DNS record to map all the Edge Processor instances. This way
when you add or remove instances from this group, you only need to update the DNS
record.
Checking Edge Processor configurations
To confirm that data is flowing through your Edge Processor, restart your forwarders.
On the Edge Processors page, select the Actions menu for your instance and select “Open”.
You will be routed to a page detailing the data path this group is configured to follow. The
“Received data” tab lists the sourcetypes it has seen in the last 30 minutes, but you can use
the search-range dropdown to select a different time-frame. The pipeline tab shows the
outbound data rate per pipeline and unprocessed data. The panel on the right displays the
current configurations and the inbound and outbound data metrics.
Remember these panels are not real time displays. To get updated metrics, refresh the
page.
If the Edge Processor view doesn’t show the inbound and outbound data, or no internal
logs from the forwarders have indexed in your default destination, check the logs in the
Edge Processor client.
When you have run the installation script, it creates a sub-directory named splunk-
edge under your working directory where you have executed the script.
Under the var/log sub-directories, there are two logs of interest:
• supervisor.log: contains the management-plane logs between this instance and the
Splunk Cloud Service tenant, such as heartbeat check, package updates, etc.
• edge.log: contains the data-plane processor logs and metrics, such as receiver,
processor, exporter, etc.
Under a successful configuration, these events should be indexed in the _internal index of
your cloud stack. You can also install the UF on the Edge Processor instances and forward
these internal logs to your own indexers, just in case the connection to the cloud is lost or
the instance processes restart and are in an errored state.
Splunk Cloud Platform Service Description
Service limits and constraints

Platform service limits (hard limits)

You can use this list as guidance to ensure the best Splunk Cloud Platform experience. You
are unable to exceed these hard service limits.
Category Service component Limitation Additional information

Email Maximum number of 50 This is a hard limit of the Splunk Cloud Platform email
notifications email recipients relay service. Use an email distribution list to increase
the number of email recipients.

Email Maximum email 40 MB This is a hard limit of the Splunk Cloud Platform email
notifications attachment size relay service.

IT Service Event Analytics / 100 You can configure up to 100 Correlation Searches.
Intelligence Correlation Searches

IT Service Event Analytics / Notable 100 You can configure up to 100 Notable Event Aggregation
Intelligence Event Aggregation Policies with 50/50 division between time-based and
Policies non-time-based NEAPs.
IT Service Service Insights / Service 1000 Services per Service You can configure up to 1000 Services per Service
Intelligence Templates Template (having 5 KPIs Template if the Service Template is configured with the
and 40 Entities) 5 KPIs and 40 Entities.

600 Services per Service You can configure up to 600 Services per Service
Template (having 10 KPIs Template if the Service Template is configured with the
and 75 Entities) 10 KPIs and 75 Entities.

300 Services per Service You can configure up to 300 Services per Service
Template (having 10 KPIs Template if the Service Template is configured with the
and 150 Entities) 10 KPIs and 150 Entities.

Other Splunk Cloud Platform ID A minimum of 4 This naming standard applies to all regions.
characters and a
maximum of 22
characters. The ID must
start with a letter. Any
lowercase letter from the
alphabet, any number
from 0 to 9, and the
hyphen character are
allowed. All other ASCII
characters are not
allowed.

Search CSV lookup 5 GB Larger CSV lookups will not replicate across a Search
Head Cluster and will be quarantined on the Search
Head it was generated. We recommend using KV store
for lookups larger than 1 GB.

Search Knowledge Bundle 3 GB This is the hard limit of the maximum Knowledge
replication size Bundle replication size. If the Knowledge Bundle
exceeds this service limit, the search tier will not push
the bundle to the indexer tier. Searches on the indexer
tier will instead use the previously pushed bundle,
which will be within the size limit.

Search Search concurrency per 38 When you add these Premium Apps subscriptions to
Premium Solution listed Splunk Cloud Platform, additional search processes are
below: available for each Premium App. These search
• Splunk App for processes are exclusive to the Premium Solution
Microsoft subscription.
Exchange
• Splunk App for
VMware

Security IP allow list address rules 230 This is the hard limit per IP allow list group. For
per allow list group in example, the service limit for collecting data is separate
Splunk Cloud Platform from sending search queries. Customers specify the IP
deployment in AWS address or IP address range that is permitted to access
regions Splunk Cloud Platform and those from which Splunk
Cloud Platform can collect data (forwarders and HEC)
and send search queries. These are generically referred
to as IP allow list rules. These rules can be configured
to use CIDR blocks to maximize the IP allow list
coverage. For more information, see IP allow list
behavior and IP subnet limits.

Security IP allow list address rules 200 This is the hard limit per IP feature allow list. For
per feature allow list in example, the IP allow list service limit for collecting
Splunk Cloud Platform data is separate from sending search queries.
deployment in Google Customers specify the IP address or IP address range
Cloud regions that is permitted to access Splunk Cloud Platform and
those from which Splunk Cloud Platform can collect
 data (forwarders and HEC) and send search queries.
These are generically referred to as IP allow list rules.
These rules can be configured to use CIDR blocks to
maximize the IP allow list coverage. For more
information, see IP allow list behavior and IP subnet
limits.

Security IP allow list address rules 230 This is the hard limit per IP allow list group. For
per allow list group in example, the service limit for collecting data is separate
Splunk Cloud Platform from sending search queries. Customers specify the IP
deployment in Azure address or IP address range that is permitted to access
regions Splunk Cloud Platform and those from which Splunk
Cloud Platform can collect data (forwarders and HEC)
and send search queries. These are generically referred
to as IP allow list rules. These rules can be configured
to use CIDR blocks to maximize the IP allow list
coverage. For more information, see IP allow list
behavior and IP subnet limits.

Tested and recommended service limits (soft limits)

You can use this list as guidance to ensure the best Splunk Cloud Platform experience. If
you exceed these soft service limits and have a degraded experience, Splunk may
recommend you reduce to below the tested or recommended limit as part of service
remediation.
Category Service component Limitation Additional information

Apps Splunkbase and private apps 250 This is the maximum tested limit for the self-service
Splunkbase and private app management. If you exceed this
soft service limit, you may experience issues with performing
self-service app management.

Data Ingress Active indexes 1000 for Victoria Experience This is the maximum tested limit for the number of active
indexes per Splunk Cloud Platform environment. If you exceed
this soft service limit, you may experience issues.
700 for Classic Experience

Data Collection HEC maximum content length 1 MB There is a recommended limit to the HEC payload size in
size limit Splunk Cloud Platform to ensure data balance and ingestion
fidelity. A HEC request can have one or more Splunk events
batched into it but the payload size should be no larger than
this limit. If you exceed this limit, you may experience
performance issues related to data balance and ingestion
fidelity.

Data Egress Dynamic Data Self-Storage No limit to the amount of data Dynamic Data Self-Storage is designed to export 1 TB of data
export of aged data per index that can be exported from per hour.
from Splunk Cloud Platform your indexes to your Amazon
to Amazon S3 or Google Cloud S3 or Google Cloud Storage
Storage account in the same region.

Data Egress Search results via UI or REST Recommend no more than For optimal performance, no single query, or all queries in
API 10% of ingested data aggregate over the day from the UI or REST API, should return
full results of more than 10% of ingested daily volume. To
route data to multiple locations, consider solutions like Ingest
Actions, Ingest Processor, or the Edge Processor solution.

Data Egress Search results to Splunk User No limit Data as a result of search queries to feed into Splunk User
Behavior Analytics (UBA) Behavior Analytics (UBA).

Edge Processor Total traffic through an Edge 100TB/day This is the maximum total amount of traffic running through
solution Processor network all deployed instances of Edge Processors for each Splunk
Cloud Platform environment.

Edge Processor Number of Edge Processors 50 instances This is the maximum total number of Edge Processor
solution instances instances. As a reminder, an Edge Processor can be made up of
1 or multiple Edge Processor instances.
Edge Processor Number of applied pipelines 100 pipelines This is the maximum total number of applied pipelines per
solution per Edge Processor Edge Processor. Pipelines with longer SPL2 configurations
may reduce this maximum limit.

Enterprise Correlation Searches 400 for Victoria experience This was the limit tested for Enterprise Security on Splunk
Security Cloud Platform. Note that there are different service limits for
the Victoria and Classic experiences. A correlation search is a
600 for Classic experience type of scheduled search. Correlation searches are a part of
Enterprise Security, and are used to generate notable events or
execute other adaptive response actions. If your use case
exceeds the tested limit and is deemed to be causing
performance issues, the remediation is to change the
configured limit to no more than the tested limit.
See Correlation search overview for Splunk Enterprise
Security.

Enterprise Data Models accelerated 20 for Victoria experience This was the limit tested for Enterprise Security on Splunk
Security Cloud Platform. Note that there are different service limits for
the Victoria and Classic experiences. Data models and data
75 for Classic experience model acceleration are critical components of Enterprise
Security. To provide the best experience possible for
customers, we suggest a maximum of 9 accelerated models.
The most common data models deployed are: Change,
Endpoint, Authentication, Intrusion Detection, Network
Sessions, Network Resolution, Network Traffic, Web, and
Performance. If your use case exceeds the tested limit and is
deemed to be causing performance issues, the remediation is
to change the configured limit to no more than the tested limit.
See Configure data models for Splunk Enterprise Security.

Enterprise Maximum ES search 150 for Victoria experience When you add an Enterprise Security subscription to Splunk
Security concurrency per Splunk Cloud Platform, additional search processes are available for it
Cloud Platform environment that are in addition to the search concurrency included in the
78 for Classic experience Splunk Cloud Platform subscription. This is the standard limit
to the number of searches that Enterprise Security can
concurrently admit as tracked in metrics.log. If you require ES
search concurrency beyond the standard limit, you may be
able to do so through optimizing your existing search
workload or by contacting your Splunk sales representative to
increase your SVC entitlement.

Enterprise Total ES daily searches 500,000 searches/day for This is the maximum tested limit of Enterprise Security
Security entitlement of more than 166 specific searches that can be executed successfully in a well-
SVC or 1 TB for Victoria tuned system.
Experience

If you exceed this soft service limit, you may experience issues
with scheduled search completion. Note that other factors
such as search concurrency limit or the nature of searches may
additionally limit the number of successful searches that run.

Ingest Processor Maximum number of 50 pipelines Maximum number of pipelines per tenant for Ingest Processor
pipelines per tenant

IT Service Event analytics / Alert 100,000 alerts per minute You can ingest up to 100,000 alerts per minute into Event
Intelligence Ingestion Analytics with your Correlation Searches.

If the NEAP's action rules are configured with up to 1500

comment actions per minute and 1000 state change actions
per minute having 50,000 active episodes.
Note: Limit only works without the external episode actions
rules of the NEAP.

IT Service Total Search Concurrency 150 When you add an IT Service Intelligence subscription to
Intelligence Splunk Cloud Platform, additional search processes are
available for it. This starting point scales up at higher ingestion
rates and also for workload-based subscriptions.

KV Store Maximum collection size 25 GB This is the maximum size of a single collection that is tested
with KV Store per Splunk Cloud Platform environment.
KV Store Total maximum size 100 GB This is the total maximum recommended size of KV Store
across all collections per Splunk Cloud Platform environment.

Search Federated search for Amazon 100,000 events This is the maximum configurable implicit default limit for
S3 and Federated Analytics federated search for Amazon S3. You can change this limit by
reaching out to Splunk Support.

Search Federated search for Amazon 10 TB by default This is the maximum configurable overall data volume limit for
S3 and Federated Analytics federated search for Amazon S3. You cannot use a LIMIT
clause to create searches that exceed that volume limit. You
can change this limit by reaching out to Splunk Support..

Search Federated search for Splunk 25 This is the maximum tested limit for the number of Splunk
Cloud Platform and Splunk Enterprise remote deployments
used with federated search for Splunk. If you exceed this soft
service limit, you may experience issues with performing
federated search for Splunk.

Search join command for subsearch 50,000 The join command combines the results of a subsearch with
the results of a main search. This limit is the maximum number
of result rows in the output of a subsearch that can be joined
against a main search. For more information, see
the join command in the Splunk Cloud Platform Search
Reference.

Search Knowledge Bundle 3 GB This is the hard limit of the maximum Knowledge Bundle
replication size replication size. If the Knowledge Bundle exceeds this service
limit, the search tier will not push the bundle to the indexer
tier. Searches on the indexer tier will instead use the
previously pushed bundle, which will be within the size limit.

Search Maximum search 400 for entitlement of more This is the standard limit to the number of ad hoc and
concurrency per Splunk than 900 SVC or 7 TB scheduled searches that Splunk Cloud Platform environment
Cloud Platform environment. can concurrently admit as tracked in metrics.log. Search
concurrency limits apply to searches initiated either from the
Cloud search tier or from on-premises hybrid and federated
search heads.

If you require search concurrency beyond the standard limit,

you may be able to do so through optimizing your existing
search workload or by contacting your Splunk sales
representative to increase your SVC entitlement. For more
information on setting percentages of concurrency for
scheduled and summarization searches, see Configure Search
Settings in Splunk Cloud Platform.

Search Scheduled search 700,000 searches/day for This is the maximum tested limit of scheduled searches that
entitlement of less than 166 can be scheduled successfully. Note the subscription tiers and
SVC or 1 TB applicable service limit.

1.5 M searches/day If you exceed this soft service limit, you may experience issues
entitlement of more than 166 with scheduled search completion. Note that other factors
SVC or 1 TB such as search concurrency limit or the nature of searches may
additionally limit the number of successful scheduled searches
that run.

Storage DDAA restorations 25 TB Dynamic Data Active Archive restorations were not designed
to exceed 25 TB. If more data than 25 TB is needed, split your
desired time frame into multiple smaller restores less than the
recommended size limit.

Storage DDAA restorations 10% of DDAS Dynamic Data Active Archive enables restoring data up to 10%
of your Active Searchable storage. If you no longer need
already restored data, you can clear it before it expires to
reclaim space to perform additional restores.

If you still require more data than 10% of your DDAS, please
reach out to your account team to discuss options.
 Workload Workload Rules 100 You can configure up to 100 Workload Rules.
Management

Securing Splunk Enterprise

Configure Splunk indexing and forwarding to use TLS certificates
Configure Splunk indexing and forwarding to use TLS certificates

You can use transport layer security (TLS) certificates to secure connections between forwarders
and indexers.

The certificates you use can replace the default certificates that Splunk provides. You can either
obtain certificates from a certificate authority, or create and sign them yourself.

Do not use these instructions to configure secure forwarding of data to a Splunk Cloud Platform
instance. Instead, download and use the Splunk Cloud Universal Forwarder Credentials package
and install it on your forwarding infrastructure. For details, see Install and configure the Splunk
Cloud Platform universal forwarder credentials package in the Universal Forwarder Manual.

Prerequisites for configuring Splunk indexing and forwarding using TLS certificates

Before you can secure communications between Splunk indexers and forwarders, you must have
the following:

1. One or more TLS certificates.

o You can either obtain third party certificates from a certificate authority, or create
and sign them yourself

o After you get the certificates, you must prepare the certificates for use with
Splunk platform instances

o The certificates must be in Privacy-Enhanced Mail format and comply with the
x.509 public key certificate standard

o You must have a private key file for each certificate file.

o The key files that come with the certificates must be in RSA security format.

Configure TLS certificates for indexers

You can configure indexers to use TLS certificates. The certificates you configure on indexers
control how the indexer receives data from a forwarder.

When you configure Splunk Enterprise to use TLS certificates, upon restart, it changes the file
permissions on the certificates so that only the user that Splunk Enterprise runs as has full
access. This is by design, in line with security industry standards, and cannot be changed.

1. Open a shell or command prompt.

 2. Using this prompt or file system management tools, copy the server certificate and the
certificate authority public certificate into an accessible directory on the indexer where
you want to configure certificates. For example, you can move the files to a destination
directory of $SPLUNK_HOME/etc/auth/mycerts/.

3. Use a text editor to open

the $SPLUNK_HOME/etc/system/local/inputs.conf configuration file for editing.

4. In the inputs.conf file, configure the indexer to use the server certificate. Add the
following stanzas and settings to the file.

Setting/stanza name Data Description

type

[splunktcp-ssl:<port>] stanza Defines a TCP network input to receive data over TLS/SSL on the port
you specify.

[SSL] stanza Defines the TLS/SSL settings for all inputs that you define for this
instance.

serverCert string The location of the server certificate on the Splunk platform instance.
This is the certificate that the machine uses to support inbound
connections over TLS/SSL. You can specify either the absolute path to
the certificate, such
as /opt/splunk/etc/auth/mycerts/myServerCert.pem, or you can use a
relative path, such as etc/auth/mycerts/myServerCert.pem and the
instance uses the Splunk platform instance installation directory.

sslPassword (Optional) string The password that you entered when you created the certificate, if you
created a password. Do not configure this setting if you did not specify
a password when you created your certificates.

requireClientCert (Optional Boolean Whether or not the Splunk platform instance requires that a
except in certain cases) connecting client present a valid TLS certificate before the connection
can succeed. A value of "true" means that the receiving instance must
see a valid certificate to let the client authenticate. A value of "false"
means that clients can connect without presenting a certificate.
If you want to use the
Configure this setting to "true" if you want your receivers to require
Certificate Assist helper
authentication with certificates. When both the forwarder and receiver
package for the Splunk Assist
have a "true" value for this setting, mutually authenticated TLS or mTLS
monitoring service, then this
is active.
is a required setting.
sslVersions (Optional) comma- The list of SSL versions that the receiver supports. The Splunk platform
separated supports the following versions for SSL and TLS: "ssl3", "tls1.0", "tls1.1",
list and "tls1.2".

cipherSuite (Optional) string The list of cipher suite strings that the TLS/SSL sessions are to use.

sslCommonNameToCheck comma- A list of one or more common names, or fully-qualified host names,
(Optional except in certain separated upon which the receiving Splunk platform instance checks for a match
cases) list in the certificate that the client presents upon connecting to the
receiver. This setting is only valid if you have configured the
'requireClientCert' setting with a value of "true". If none of the
common names in this setting value matches the common name in
the certificate of the connecting client, the receiving instance declines
the connection as not authorized.

sslAltNameToCheck comma- A list of one or more alternate names upon which the receiving Splunk
(Optional except in certain separated platform instance checks for a match in the certificate that the client
cases) list presents upon connecting to the receiver. This setting is only valid if
you have configured the 'requireClientCert' setting with a value of
"true". If none of the alternate names in this setting value matches the
alternate name in the certificate of the connecting client, the receiving
instance declines the connection as not authorized.

5. Save the inputs.conf file and close it.

6. On indexers that do not run on Windows, open

the $SPLUNK_HOME/etc/system/local/server.conf configuration file for editing.

7. Add the following text to establish the location of the certificate authority certificate.

8. [sslConfig]

9. sslRootCAPath = <Absolute path to the CA certificate. The default value is

$SPLUNK_HOME/etc/auth/cacert.pem>

10. Save the server.conf file and close it.

11. Using the CLI, restart the splunkd process:

12. # $SPLUNK_HOME/bin/splunk restart splunkd

Configuration file examples for configuring TLS certificates on receiving indexers

Following is an example of an inputs.conf configuration file on a receiving indexer. The

configuration is as follows:
 • The indexer uses a certificate that is located in
the /opt/splunk/etc/auth/mycerts directory called myServerCert.pem

• The server certificate was created with a password "myCertificatePassword"

• The indexer checks incoming certificates to ensure that the Common Name field in the
certificate contains either "indexer1.mycompany.com" or "indexer2.mycompany.com"

[splunktcp-ssl:9997]

disabled=0

[SSL]

serverCert = /opt/splunk/etc/auth/mycerts/myServerCert.pem

sslPassword = myCertificatePassword

requireClientCert = true

sslVersions = *,-ssl2

sslCommonNameToCheck = indexer1.mycompany.com,indexer2.mycompany.com

If you supply a password for your server certificate in the inputs.conf file by providing a value for
the sslPassword setting, the Splunk platform encrypts that password from clear text when you
restart the Splunk platform instance.

The server.conf configuration file establishes and references the location of the certificate
authority certificate:

[sslConfig]

sslRootCAPath = /opt/splunk/etc/auth/mycerts/myCACertificate.pem

Configure TLS certificates for forwarders

The certificates you configure on forwarders control how the forwarder connects to the indexer
and how it communicates with the indexer to send data. If you configure the receiver to require
a client certificate, you must configure the forwarder to present that client certificate when it
connects to the indexer.

1. Copy the new certificate and the certificate authority certificate files into an accessible
folder on the forwarders you want to configure. For example, you can use a destination
folder of $SPLUNK_HOME/etc/auth/mycerts on the forwarder.

2. Using a text editor, open the $SPLUNK_HOME/etc/system/local/outputs.conf file for

editing.
 3. Use the following settings to define the [tcpout] stanza in the file to configure the
forwarder to use the certificate.

Setting/stanza name Data Description

type

[tcpout:<name>] n/a Defines an output group to send data to a receiver.

server string The hostname or IP address and port on which to connect securely to forward data.

clientCert string The location of the client certificate on the forwarder. This is the certificate that the
forwarder uses to connect to the receiving indexer over TLS. You can specify either the
absolute path to the certificate, such
as /opt/splunk/etc/auth/mycerts/myClientCertificate.pem, or you can use a relative
path, such as etc/auth/mycerts/myClientCertificate.pem and the instance uses the
Splunk platform instance installation directory.

useClientSSLCompression Boolean Whether or not the forwarder performs TLS compression when it connects with a
(Optional) receiver. The default value of "true" means that the client uses TLS compression. A value
of "false" means the client doesn't use compression. Disabling compression, particularly
with TLS, can increase bandwidth usage.

sslPassword (Optional) string Same as the setting in the inputs.conf configuration file

sslVerifyServerCert Boolean Whether or not, upon connection to a receiver, the forwarder confirms that the receiver
(Optional) has a valid TLS server certificate. A value of "true" means that the forwarder checks for a
valid server certificate upon connection, then checks the common or alternate names
against the names in the server certificate against the names in the values for the
'sslCommonNameToCheck' and 'sslAltNameToCheck' settings on the forwarder. If there
is no match against the common or alternate names, the forwarder aborts the
connection to the receiver as not authorized.

sslVerifyServerName Boolean Whether or not, upon connection to a receiver, the forwarder confirms that the valid TLS
(Optional) certificate that the receiver presents contains the host name of the receiver in the
common name or subject alternate name field of the certificate. A value of "true" means
that the forwarder checks for a host name match in the certificate that the receiver
presents. If the host name in the certificate does not match the receiver host name, the
forwarder aborts the connection to the receiver as not authorized.

sslCommonNameToCheck comma- Same as the setting in the inputs.conf configuration file, except that you must give the
(Optional) separated 'sslVerifyServerCert' setting a value of "true" in the outputs.conf configuration file and
list the forwarder does the certificate verification.

sslAltNameToCheck comma- Same as the setting in the inputs.conf configuration file, except that you must give the
(Optional) separated 'sslVerifyServerCert' setting a value of "true" in the outputs.conf configuration file and
list the forwarder does the certificate verification.
cipherSuite (Optional) comma- Same as the setting in the inputs.conf configuration file.
separated
list

4. Save the outputs.conf file and close it.

5. On forwarders that do not run on Windows, open the server.conf configuration file for
editing.

6. Add the following stanza and settings to the file:

7. [sslConfig]

8. sslRootCAPath = <absolute path to the certificate authority certificate>

9. Save the server.conf file and close it.

10. Restart the splunkd process.

11. $SPLUNK_HOME/bin/splunk restart splunkd

Configuration file examples for configuring TLS certificates on forwarders

Following is an example of an outputs.conf configuration file on a forwarder. In this example:

• The forwarder uses a certificate that is located in the /opt/splunk/etc/auth/mycerts

directory

• The forwarder certificate has a password of "myCertificatePassword"

• The forwarder uses TLS compression

• The forwarder requires that the receiving indexer present a certificate, and that that
certificate contain a common name of indexer1.mycompany.com or
indexer2.mycompany.com, or a subject alternate name of indexer3.mycompany.com

[tcpout:group1]

server=10.1.1.197:9997

disabled = 0

clientCert = /opt/splunk/etc/auth/mycerts/myClientCert.pem

useClientSSLCompression = true

sslPassword = myCertificatePassword

sslCommonNameToCheck = indexer1.mycompany.com,indexer2.mycompany.com

sslAltNameToCheck = indexer3.mycompany.com
sslVerifyServerCert = true

When you make edits to the $SPLUNK_HOME/etc/system/local/outputs.conf configuration file

to install certificates, if you supply a password for your server certificate, Splunk Enterprise
encrypts that password from cleartext when you restart Splunk Enterprise.

The server.conf configuration file establishes and references the location of the certificate
authority certificate. This certificate is the trust anchor to verify the indexer certificate in a TLS
connection. You must configure this on the forwarder even though it is the client:

[sslConfig]

sslRootCAPath = /opt/splunk/etc/auth/mycerts/myCACertificate.pem

Send data over TLS from a forwarder to more than one indexer

If you need to forward data securely to multiple indexers, complete the following procedure:

1. On the forwarder where you want to send data to multiple indexers, use the "Configure
forwarders to use a signed certificate" procedure earlier in this topic to open and make
changes to the outputs.conf configuration file.

2. In the target output group definition stanza for the forwarder, add a host:port line for
each indexer to which you want to send data over TLS. Separate multiple entries with
commas.

3. Save the outputs.conf file and close it.

4. Restart the forwarder.

The following example outputs.conf file uses the same certificate for the forwarders as it does
the indexers:

[tcpout]

[tcpout:group1]

server = 10.1.12.112:9997,10.1.12.111:9999

# multiple servers: 10.1.12.112:9997, 10.1.12.111:9999

disabled = 0

clientCert = $SPLUNK_HOME/etc/auth/client.pem

useClientSSLCompression = true

# Defaults to the value set in the useClientSSLCompression

# setting set in server.conf.

sslPassword = <password for the client certificate>

sslCommonNameToCheck = indexercn.example.org

sslVerifyServerCert = true

Forward data over TLS to multiple indexers using certificates with different common
names

If you have created one server certificate for each indexer and you have set a
unique sslCommonNameToCheck or sslAltNameToCheck in each indexer certificate to be
checked by the forwarders, you must configure one [tcpout-server://host:port] configuration
stanza for each indexer in the outputs.conf file. This action lets you specify which name to check
for each indexer.

Next steps

Confirm that the forwarder and indexer configurations work properly. See Test and troubleshoot
TLS connections.

Use Edge Processors

Forward data to an Edge Processor

Forward data to an Edge Processor

After confirming your Edge Processor configurations for receiving data from Splunk forwarders,
configure your forwarder to send data to the Edge Processor.
The following instructions describe how to update the outputs.conf settings for one forwarder to
start sending data to an Edge Processor. As a best practice, if you plan to configure many
forwarders to send data to the same multi-instance Edge Processor, use a DNS record to keep your
outputs.conf settings up to date. Map all the Edge Processor instance hosts to a DNS record, and
then set the server property in your outputs.conf files to the IP address of that DNS record. When
you add or remove instances from your Edge Processor, you only need to update the DNS record
instead of updating multiple outputs.conf files. For more information about using a DNS to manage
forwarder outputs, see Options for configuring receiving targets for load balancing in the Splunk
Cloud Platform Forwarding Data manual.

1. In the Edge Processor service, navigate to the Edge Processors page.

2. In the row that lists the Edge Processor that you want to forward data to, select
the Actions icon ( ) and select Configure data sources.
3. In the Configure data sources panel, make sure that the drop-down list is set
to Splunk forwarders. Then, select Copy to clipboard to copy the outputs.conf
stanzas for configuring a forwarder to send data to an Edge Processor.
 4. On the machine where your forwarder is installed, create the following directory.
*nix Windows

$SPLUNK_HOME/etc/apps/100_edgeprocessor/local %SPLUNK_HOME%\etc\apps\100_edgeprocessor\local

5. Create an outputs.conf file for editing.

6. In the outputs.conf file, paste the settings that you copied during step 3. Confirm
that the server property specifies the IP addresses or host names of your Edge
Processor instances, as well as the listening port that your Edge Processor is
using. The following is an example of the expected outputs.conf contents:
7. [tcpout]
8. defaultGroup=edge-processor
9.
10. [tcpout:edge-processor]
11. server=123.45.123.45:9997, 123.46.123.46:9997, 123.47.123.47:9
997

12. Save the changes to your outputs.conf file.

13. If you configured your Edge Processor to use mTLS to secure communications
from Splunk forwarders, then you must configure the TLS settings in your
forwarder. Do the following:
1. In the outputs.conf file, add the following settings to
the [tcpout:edge-processor] stanza:
Property Value

clientCert The full path to the PEM file containing the combined client certificate, private key, and CA certificate.

sslVerifyServerCert true

sslAltNameToCheck A comma-separated list of alternate names that the forwarder checks when verifying the server certificate used by the
Edge Processor.

2. The following is an example of an updated stanza:

3. [tcpout:edge-processor]
4. server=123.45.123.45:9987
5. clientCert=$SPLUNK_HOME/etc/apps/100_edgeprocessor/loc
al/forwarder_client_cert.pem
 6. sslVerifyServerCert = true
7. sslAltNameToCheck = buttercupgames.com

8. Save the changes to your outputs.conf file.

9. Create a server.conf file for editing.
10. In the server.conf file, add the following stanza, where
<CA_certificate_path> is the full path of the PEM file containing the CA
certificate that was used to sign the server certificate. The forwarder
uses this CA certificate to verify the server certificate used by the Edge
Processor.
11. [sslConfig]
12. sslRootCAPath = <CA_certificate_path>

13. Save the server.conf file and close it.

14. If the Universal Forwarder Credentials package is installed on your forwarder,
and there are additional configuration settings defined in the app, turn it off.
1. Navigate to the
$SPLUNK_HOME/etc/apps/<forwarder_bundle>/default directory,
where <app_name> is the name of the Universal Forwarder
Credentials app, and open the app.conf file.
2. Turn off the app by adding the following setting in
the [install] stanza.

3. state = disabled

This setting turns off any existing data forwarding that was configured in the
Universal Forwarder Credentials app. If you would like to route data to Edge
Processors and to previous destinations that you've configured, see Route and
filter data in the Splunk Enterprise Forwarding Data manual.

15. Restart the forwarder to complete your changes.

*nix Windows

$SPLUNK_HOME/bin/splunk %SPLUNK_HOME%\bin\splunk
restart restart

Your Edge Processor starts receiving data from your forwarder once the forwarder restarts.
Refresh your browser and review the inbound data metrics displayed in the Received data pane to
confirm that your Edge Processor is successfully receiving data from the forwarder.

https://docs.splunk.com/Documentation/SplunkCloud/latest/EdgeProcessor/Forwarders#Forwar
d_data_to_an_Edge_Processor
Congratulations!

This concludes the "Introduction to Edge Processor" course. You learned how to accomplish the
following:

• Explain Edge Processor and how it works

• Identify use cases for Edge Processor

• Create and install an Edge Processor

You can now review these topics or exit the course.