Deployment Architecture

What can we not do without a deployment server?

aanataliya
Explorer

I am new to Splunk. Our organization is using Splunk Cloud and I have been asked to configure 200+ EC2 instances to forward log. I am configuring Universal forwarder on client systems to directly forward log to Splunk Cloud. I am not planning to have deployment server.

I would like to know, will I face any issue in future without deployment server? What are the things which cannot be done without DS? In future, if I plan to use DS, what possible changes do I have to make?

Thanks.

0 Karma
1 Solution

FrankVl
Ultra Champion

I don't think there really is something you cannot do without a DS, apart of course from taking benefit from the centralized management of configuration that it offers. So without a DS, each time you want to change some config on the UF (e.g. inputs / outputs) you need to touch each UF, or use some other automation tooling to do that for you.

If you later want to introduce a DS, key action to do is make the UFs a deployment client of that DS.

Depending on how you deployed the manual UF configs, you can or cannot take control over that from the DS. For example: DS cannot take control over config defined in system/local on the UF. So if you want to keep options open for the future, avoid making any changes in system/local on the UF, but bundle configuration files into apps, that you put in etc/apps on the UF. That way, you can later on have the DS take over control of those apps and manage them centrally.

View solution in original post

dpetracca_splun
Splunk Employee
Splunk Employee

Good simple example of using a deployment server here: https://docs.splunk.com/Documentation/MSApp/1.4.3/MSInfra/Createthesendtoindexerapp

This will give you better idea of why/when you would want to use a DS

0 Karma

FrankVl
Ultra Champion

I don't think there really is something you cannot do without a DS, apart of course from taking benefit from the centralized management of configuration that it offers. So without a DS, each time you want to change some config on the UF (e.g. inputs / outputs) you need to touch each UF, or use some other automation tooling to do that for you.

If you later want to introduce a DS, key action to do is make the UFs a deployment client of that DS.

Depending on how you deployed the manual UF configs, you can or cannot take control over that from the DS. For example: DS cannot take control over config defined in system/local on the UF. So if you want to keep options open for the future, avoid making any changes in system/local on the UF, but bundle configuration files into apps, that you put in etc/apps on the UF. That way, you can later on have the DS take over control of those apps and manage them centrally.

Get Updates on the Splunk Community!

Welcome to the Splunk Community!

(view in My Videos) We're so glad you're here! The Splunk Community is place to connect, learn, give back, and ...

Tech Talk | Elevating Digital Service Excellence: The Synergy of Splunk RUM & APM

Elevating Digital Service Excellence: The Synergy of Real User Monitoring and Application Performance ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...