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.

Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Announcing Modern Navigation: A New Era of Splunk User Experience

We are excited to introduce the Modern Navigation feature in the Splunk Platform, available to both cloud and ...

Modernize your Splunk Apps – Introducing Python 3.13 in Splunk

We are excited to announce that the upcoming releases of Splunk Enterprise 10.2.x and Splunk Cloud Platform ...

Step into “Hunt the Insider: An Splunk ES Premier Mystery” to catch a cybercriminal ...

After a whole week of being on call, you fell asleep on your keyboard, and you hit a sequence of buttons that ...