Hello and welcome back to the Splunk Enterprise certified Administrator course on Cyber. This is the beginning of module eight, where we'll be discussing distributed search. As you can see from the outline, we're getting through the course quite nicely where pretty much closing in on the end. This will be the last module that
goes over getting Splunk ready for data before we actually start bringing dad it into the system.
We'll have to lessons in this module as well as a lab. So without further do, let's get started on less than 8.1, where we'll just do a quick overview off distributed search.
But before we get into the contents of this lesson, let's do a knowledge assessment to see what you remember from the last video. So which scenario of three listed best justifies using a heavy forwarder? Um, pause here for a second if you need to to pick an answer and will review in the next slide.
So the answer here is option one bringing data envious Plunk caps, modular inputs. It's just another way of saying configuring an A P I input through Splunk web, basically so three other two instances you could just use a universal forwarder and actually will be
preferred to do that way
and just set the max kilobytes per second and limits dot com 20 This is the only scenario where you need the functionality of a heavy four order to actually perform the configuration.
So now we've got that knowledge check out of the way. Let's go move onto what the learning objectives for this lesson are gonna be. So we're going to discuss what distributed search is identified. Two ways to configure distributed search. And then we'll also discuss which devices you'll need to do these configurations on.
Why are we learning this? So now that we have, like the indexers all set up there ready to receive data, we need to make sure that our search heads, when our users are logged in, will actually be able to retrieve that data and distributed search is going to be essential to that. So it just makes sense is the next logical step in getting you were
spline configuration. Ready for use is to link up your search heads so that in the next step when we bring down in, we will actually be able to see it.
So what is distributed? Search at the at the highest level. It's just when you break out from it all in one, and you brave the search function into two separate pieces. Search head in an indexer versus a single device doing it because it's now spread across at least two devices. It is technically distributed.
yeah, that's the most basic example.
Use cases for this is when you need horizontal scaling. So basically, when you're
system isn't able to process all the data you're getting in, it's easier to scale this up when we break out the functions. Then we can just keep adding mawr, Uh, indexers, as we need to keep up with the processing of our data in jest.
And then also you have the ability to group these indexers, and then it gives search heads.
So you have one search. Had that searches across all your indexers, and then maybe another search had that only searches against a subset. If you need to do some access control to determine which data certain users will be able to access, and then also, if you want to manage geographically dispersed data,
this could be helpful as well, because you could have indexers in
multiple different geographic locations, all collecting data locally. And then you can either have you research, I'd be able to search across all of it. Or, as we just discussed, you could also have, you know, a New York
search. Had that only searched New York indexers or, you know, whatever location combinations you want to do there.
So those are the three main use cases of
using distributed search.
Let's talk about how to actually configure it now, so there's two ways you can do it. You can go through the command line, and you can edit this search dot com. Or you can go into the Web gooey and just up at the corner. If you select settings distributed, search under distribute environment, then you'll be able to configure it through the Web there as well.
If you're doing it through dis search dot com, this is how you would do it. This is an example file where basically you just created this search, are distributed, search stanza and then specify a list of the of the servers that represent your indexers.
Similarly, you could also set this up
the Splunk Web, which has demonstrated on the right side here, where you just eo https colon ford slash ford slash Either you are l or an I p. Address Colon, the management port for Splunk that that devices using
and then you congest See that you have to authenticate as well when you set it up through Splunk web. So either way that you choose to do this is acceptable. I've done it both ways. Don't really have a preference on this one.
On which devices should you configure distributed? Search. So search heads, obviously, because they're gonna need to have all of the indexers visible to them. So another word for that
is they need to be searched peers of the search head. It's probably important for you to know. So basically, what that means is that when it searches, issued the list of search peers or will be the devices that the searches run against.
So search heads need all indexers, and then additionally, you will have to configure just search on the Meiring Council because the Myron Council, if you remember from our components overview, is the device that's going to use Splunk internal logs as well as the rest api I
to provide monitor like health monitoring and alerting for your entire Splunk enterprise environment. So it needs
every Splunk enterprise device to be configured as a search peer for it.
A quick side note, I kind of already touched on this. So this is good, but I just wanted to throw this in here to emphasize that, you know, distributed environments Your indexers will be referred to a search piers. But as I mentioned,
technically, any device that's configured through distributed search can be a search. Appears well. So, for example, in your monitoring console, devices other than indexer will be a search. Pierre
search. Pierre essentially just means which devices am I searching against when a search is issued. So for search heads, it'll be your indexers. For Meiring council, it will be all their Splunk enterprise
devices. So in summary, we've covered what distributed search is. It's just separating the search function into dedicated devices. So you have a search head and you have an indexer or multiple of each.
We talked about where to configure to search dot com that you can do it through either the web or you can also do it the command line, if you like. We talked about how to configure each of those options. And then we also discuss that you'll need to configure this on your monitor council as well as any search heads.
So that wraps it up for this lesson will move into the next video where I believe will actually be setting up distributed search. So I look forward to see you in the next one.