Deployment Architecture

What can we not do without a deployment server?

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

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

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

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