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!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...