Pass Splunk SPLK-2002 Exam in First Attempt Guaranteed!

All Splunk SPLK-2002 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the SPLK-2002 Splunk Enterprise Certified Architect practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Splunk Architecture

6. Bucket Lifecycle

Hey everyone, and welcome back. In today's video, we will be discussing the Splunk bucket lifecycle. Now, we already know from the previous video that Splunk basically stores all of its data in directories, and that directory, in technical terms, is related to the buckets. Now, a bucket basically moves through several stages as it ages. Now, these stages are primarily hot, warm, cold, and frozen. So let me give you one example. So, for example, if you do a search in Splunk or want to search from the last three days or the last seven days, people will not search for data from the previous year, right? If you want to search from data from the previous year, very few queries will have such requirements. And this is why Splunk will store data based on its age, so that older data—whether it's a year old or whatever you specify—goes into disk, which is the least expensive because the data that needs to be searched or that analysts would search quite frequently. It needs to be on a much faster disk.

Otherwise, there will be a lot of performance impact. Splunk stores any data that is generally intended to be searched in a hot and warm bucket, and then you can move it to a cold bucket, which can be on a different hard drive entirely. However, data in the cold bucket is unlikely to be searched, and the last is a frozen bucket. So this is an overview of why Splunk basically moves the data into several stages depending on the age as well as various different factors. In terms of the bucket lifecycle, you have hot, warm, cold, frozen, and thawed buckets. Now, hot is basically any new data that is being actively written to Splunk or any more recent data. It gets stored in the hot bucket. Data is now rolled from the hot bucket to the warm and awarm buckets, where no writing is permitted. So one important point to remember is that anything you write only goes into the hot bucket. Once the data goes into the warm bucket, it cannot be written to. All right, so "hot" is read plus "warm," "cold," and others are only read, so you cannot write here.

Now, once data goes from hot to warm, we know that data is not actively written to warm buckets. It now goes from warm to cold. All right, so data gets rolled from the warm bucket to the cold bucket. Now, the data in the cold bucket has a lower chance of being searched by the analyst. In general, it is rolled based on its age or the configuration policy that you define. It has now progressed from cold to frozen. Now, frozen data is generally deleted by default unless and until you tell Splunk to not delete it or store it somewhere else. Now, if you archive it, let's say you tell Splunk not to delete the frozen data, so you archive it. And if you want to restore the archive back to Splunk, that process is called a restore. Now, one important part to remember is that, typically, in an organisation that has compliance, they do not delete the data for compliance reasons.

So they might store the data for one year or even for five years. And for this reason, typically, frozen data will not be deleted. So you have to explicitly tell Splunk not to delete the data that goes into "frozen" and archive it instead. Now, this is a nice little diagram for the bucket life cycle that we can understand. So any event that comes into Splunk goes into the "hot bucket." Now, once the hot bucket is full, it goes into the warm bucket. Now, typically, hot and warm buckets are on the same hard disc drive. So you see, they are typically on the same disk. Now, from the warm bucket, it goes into the cold bucket. Cold storage, on the other hand, is typically less expensive. Now, whatever disc you have in the hot and warm bucket needs to be very fast. Otherwise, you will have a lot of performance impact.

And this is the reason why the requirement for disc IOPS or various other disk-related performance matrices is so high. Again, depending on the data volume for hot and warm buckets, you may have a slightly slower disc for cold bucket data. Once the data from the cold bucket has been transferred to the frozen bucket, Now, frozen bucket, so any data that goes into frozen is automatically deleted. You can specify a frozen path so that the data can be archived. And then you have the third part. The third part is that you put the archived data there and do the restoration process so that it is again searchable in Splunk. So there you have it, a high-level overview of the bucket lifecycle. So this is the theoretical perspective.

Now, before we continue with more slides, it will be more theoretical. Let us be practical and consider how this might look. So, we'll go to settings and select indexes. All right, so these are various indexes. And if you see each index here has its own maximum size, It tests how many events are currently present in the index. What is the earlier event? What is the latest event? the path, as well as the frozen path Do remember that if you do not really specify a frozen path, the data will, by default, get deleted. So now let's go ahead and create a new index. So we'll give this index the name "bucket lifecycles" so that we can relate it to our video. And the maximum size of the index you can specify is MB, GB, or TB.

Now, I'll select MB so that we can actually test how exactly this works. and that's about it. So, this is a simple configuration that we'll do with our video. I'll click on "Save." Now, once you have saved it, you will see that you have a new index called BucketLifecycle, and the maximum size is four MB. We have not really specified any frozen paths here. And this is the path where our directory lies, or where our bucket lies. So let's go to the CLI and understand it better. So I'm in my CLI, and if you do an opt plank, we'll do a etc. And we are looking for a file called "Indexes Connect." So, if you normally use the aide command, I'll recommend Indexes Connect. There are numerous indexes that link. Now, we are more interested in the indexes, which are present within the search and reporting app that we have created. So we'll go to apps, we'll go to search, we'll go to local, and within local, you have Indexes conve. Now, this index is convex; this is the bucket that we have created. Now, again, there are two ways.

You can either do it through GUICLI or even directly in configuration. So there are three ways here. Now, each of these indices over here has its associated configuration path. So this is a field-value pair. So Cold Path is a key, and this is the path where the cold data will be stored. We already discussed here that cold data can be stored in a cheaper way. This is why, if you have multiple discs and one of them is a little cheaper, you can specify the path to that disc over here. And along with that, there are various other configuration parameters. One significant difference is that the maximum total data size MD is equal to four. So this is one important configuration path. So that's the end of the Connect indexes. Now, if we go to Osplunkvarlib Splunk, we already know that our bucket will be stored here.

The bucket name is Bucket Lifecycle. I navigate to Bucket Lifecycle, and there you have the cold DB. Here. Again, we'll be discussing this. And the only thing you have right now if you do a DBE is the creation time. So, the DB directory is where your hot and warm buckets will be stored. Cold. We already know this is where the cold data will be stored. And frozen is something that gets deleted by default. So currently, since we do not have any data, you just have the creation time. So now let's do one thing. Let's go ahead and add some data to our Bucket Lifecycle Index. So, for our test purpose, what I have done is I have selected a file. As a result, this file is between four and six megabytes in size. So this is a file that we have selected. So this is the file, and we'll do another one later; the source type is Access combined, and the index is a string. This time we'll give a bucket lifecycle, we'll do a review, and we'll click on submit. Perfect.

So now, if we do start searching, we have a total of 130 events. Now that you have this, let's go back to the indexes once again. And currently, if you look into the bucket lifecycle events, you will see that the current site is three MB. So far, three MB of data have been indexed. The question now is, "How many megabytes?" because we uploaded four, two MB of data, but it only shows three MB. So, to understand this, if I do LS, ifan L, you can see that you now have a hot bucket. So, we already talked about the hot bucket. As a result, any new data or data that is actively written to is saved in the hot bucket. So if I do a hot 10, and here you have the Tsidx file, you have the raw data. Within raw data, you see, you have the journal GC file. Splunk has therefore compressed the data.

So Splunk actively does a lot of compression of raw data. Because it has been compressed, our index is much smaller than the file that was uploaded. Now, one important part, in fact, that is in the next slide that we have, is when will the data from the hot bucket go to the warm bucket? Again, this is an important point to understand. So there are certain conditions, as follows, where the data will be pushed from the hot bucket to the warm bucket.

First is when we have too many buckets, which is basically defined by the "max buckets" parameter within the index corner. That's why Hot Bucket hasn't received data in a while. The bucket's time span is then too long. then its bucket metadata files have grown large. You have an index clustering replication error, and the plank has been restarted. So these are the factors through which the data from the hot bucket gets rolled into the warm bucket. So let's look at one important aspect. Here. We'll restart Splunk and see how it goes. So I'll take the option. Splunk restart, Splunk bin So we'll manually restart Splunk and see how the data gets rolled from the hot to the warm bucket.

All right, so Splunk is now restarted. So if you quickly go to the "opt Splunk War lib Splunkbucket lifecycle," then we'll go to "let's go inside here." If you do LS, we'll go inside the DB. Remember, DB is the directory where hot and warm buckets will be stored. So, if you go into DB, you'll notice that whatever bucket was in hot underscore Vone has been changed to DB underscore. These are the identifiers. So now this is what is referred to as the "warm bucket."

No new data will be stored once the warm bucket is present. This is just read-only data, so it is also possible to back up the data. Do remember that data within the hot bucket cannot be backed up and should not be backed up only in the warm bucket. So if you want to backup data, you need to roll it from the hot bucket to the warm bucket. Then and only then can you back up your data. So let's do some interesting things so that we understand it in a much better way. So now that we have restarted, I'll just have to log in. And these were our previous logs. So now let's do one thing. I'll create a directory at the root. I'll say, "mktirbackup." All right.

So allow me to perform a fictitious act. Now, once we have the backup directory, we will move the entire warm bucket that we have to the backup directory. So now let's move the DB underscore, and we'll move it to the backup directory. We'll have to do a Pseudo here. All right. Now, once you have moved it, if you go back to Splunk and let's do a search again, Now, as you can see, you have zero events. The reason you have zero events is because the entire warm bucket has now been moved to a different directory altogether, and Splunk does not really have access to it. So this is something about backup. So you can safely -- I shouldn't say more -- do something like copy and copy it into your backup drive. It can be AWS 3, which most of the organisation typically backs up the data into. So let's quickly reject our data. I'll just put it here with the sudo. All right. So we have our warm bucket once more. So if I do a quick search, our events are back up. Now, along with that, one interesting thing that I wanted to show you is that typically, if you go inside the warm bucket, the data that you will see inside the raw data will be in a compressed manner. So you see, you have journal entries, and typically, this is the compressed data that you have here.

You will not have data like earlier. We saw that in raw data, like in the previous video. We were able to directly search the data in the file. However, once the data moves to the warm bucket, it will typically get stored in a compressed manner. So there you have it: moving data from the hot bucket to the warm bucket. We'll continue with this series in the upcoming video. Otherwise, the length of the video will be quite long. So with this, we will continue this video. I hope this has been informative for you, and I look forward to seeing you in the next video.

7. Warm to Cold Bucket Migration

Hey everyone. Hey everyone, and welcome back. Now, in the earlier video, we were basically discussing how data moves from a hot bucket to a warm bucket. Now, continuing the series, in today's video, we will discuss how data moves from warm buckets to cold buckets. Now, one important thing to remember is that historical data should ideally be stored in the cold bucket because, as you can see from the diagram, the cold bucket path should ideally be in a cheaper storage. As a result, a hot and warm bucket should be placed in a disc with a much faster performance.

However, the cold bucket can be stored in cheaper storage where the discs are slower but the storage capacity is cheaper. So this is generally how you will see a lot of organisations implementing the architecture. This is why this point says that ideally, historical data should go there because searching for data that is present within the cold bucket will impact your performance. Now, basically, buckets are rolled from warm to cold when there are too many warm buckets. Now, what do you mean by "when there are too many warm buckets"? Now, this is specified within the index configuration that you define. So this is a sample index configuration where you have your index name and your cold path. So this is the cold path. This can be whatever path you define. It could be on the current disc or a remote disk. And the last important configuration here is that the maxwarm DB count is equal to 300. That means that there can be a maximum of 300 warm buckets.

After the 300 warm bucket limit is reached, the bucket will be moved from warm to cold. And in today's video, we'll be looking into this in practical aspects so that we understand how exactly it works. All right, so I'm in my Splunk CLI, so we'll go to Opt, Splunk, etc. Apps, search locally, and within this directory you will find indexes for conversion. So, let's launch the indexes console. And basically, we have two indexes that are present. One is Kpops, and the second is bucket lifecycle. So the bucket lifecycle index is the one we're most interested in. Now, within this index, you will see at the start that you have the cold path. So this is the path where your cold database buckets will be stored. However, we do not have any configuration related to the MaxWARM bucket that we were discussing. So this specific configuration is not present. So let's do one thing. I'll just copy this configuration to avoid any typos, and I'll paste it here.

So this is the max worm DB count, and this time we'll say the count is equal to one. That means there can be a maximum of one warm bucket. We'll go ahead and save it. Now, before we do a restart, let's quickly look at how many warm or hot buckets there are currently. If you go to Opt Splunk or LibSplunk, for example, Within this, we'll go to the bucket lifecycle. Within this. You have DB.

And within DB, you currently have only one warm bucket. So this is the only warm blanket that you have right now. So we'll go ahead and add some new information. So let's go to the indexes now, and then we'll add data. This time, since our index size is quite small, What we'll do is just upload a very small text file. You can just upload any text file that you intend to create. I have one sample test file, which is a lookup. I'll just upload this text file. It does not really have much; it just has this Pi event. I'll just say test source type for now. I'll save it now within the index; I want to save it in the bucket lifecycle index. We'll go ahead, do our review, and then click on "Submit." Perfect. So now your file is uploaded.

So now if you do LS once again, you will see that you have a hot bucket, which is present over here. So this is the hot bucket where your events are currently present. So we have one warm bucket, and we have one hot bucket. Now we have modified the index corner. So now, next time when you reach that, what will happen is that the data that is there in the warm bucket will be shifted to the cold bucket. And the data that is there in the hot bucket will be moved to the warm bucket. The reason why is because there can be only one warm bucket. So currently, this warm bucket is already present. If you restart now, the hot will be converted to warm, and you will have two warms. And our configuration says that there can be a maximum of only one warm bucket, so Splunk will move one of the warm buckets to the cold storage.

So we'll perform our Opt Splunk bin Splunk restart. Perfect. So our Splunk has now been restarted. Now, if you do LSI on L once again, you see that there is only one warm bucket. And previously, if you go a bit up, our warm bucket name ended with 69360. And, as you can see, this is a little unique. So, basically, whatever was in the hot bucket at the time has now moved to the warm bucket here. So this is the new warm bucket. And if you go out of this directory, you also have a directory called ColdB. Now, if you go to Cold Spring, you will see that this is the bomb bucket that we had. So this is how the migration actually happens. However, one problem here is that everything we have here is within the root. In idle practice, you should avoid having the cold DB that you generally create on the main desk, because the main disc is supposed to be very fast. And if you start to store all the cold things here, one thing is for sure: storage will be expensive. As a result, it is preferable to move coldb to a less expensive storage location so that you only have hot and warm data on the disk, which has very good performance. So this is it. About today's video: I hope this has been informative for you, and I look forward to seeing you in the next video.

8. Archiving Data to Frozen Path

Hey everyone, and welcome back. Now continuing the bucket lifecycle journey. In today's video, we'll look into the cold-to-frozen aspect. Now, one important part to remember over here is that whatever data you might have in frozenbucket will no longer be searchable, and by default, Splunk will delete the data unless and until you specifically tell it not to do so. When the total size of the index became too large, data rose from cold to frozen bucket, which essentially means hot plus warm plus cold. This is an important aspect. The second-oldest event in the bucket exceeds the specific age.

So these are the two factors that will cause Splunk to move data from the cold to the frozen bucket. Now, the configuration that you can specify for frozen buckets is this: cold to frozen dir, which basically means store all the data that goes to the frozen buckets in a specific directory instead of deleting them. All right, now by default, in the default process, the Tsidx file is removed when the data goes to the frozen bucket. So you will only have the raw data, even in a compressed format.

Great. So that's the fundamentals of a cold to frozen. Let's go ahead and do this practically so that we'll understand how exactly it works. To spice things up a little, we'll do some interesting things today. So we have a bucket lifecycle. So this is our index. Now, if you see the current size of the index, this is the current size. The current size of the index is three MB, and the maximum size of the index, if you will see it, is four MB. Now, what we'll do is basically add a good amount of data to this index, and we'll look into how Splunk will behave in such a use case. So I'll go to Splunk Enterprise, and basically we'll have our search window open so that the index is equal to the bucket lifecycle. So this is our index, which is equal to the bucket lifecycle. And if you do a search for the last 24 hours, you will see that there are five events. These five events are basically from the lookup file that we had uploaded earlier. Now let's go to settings, and let's click on "add data." So, basically, we'll upload a 28-megabyte file.

So I have an access hyphen big. This will be in the upload directory; I'll show you the link. So we'll upload this and look into how Splunk will handle things. When the index size is reached, you continue to upload massive amounts of data. So, now that this is completed, we'll proceed to the next step because the source type has been determined automatically. This time, the index would be bucket lifecycle. We'll go ahead and review it before submitting it. Great. So now the file is uploaded.

Let's go ahead and start the search. So, these are all the events that are currently present. However, we are not interested in this event. We are interested in the events that were present earlier, before this big file was uploaded. So instead of searching for the entire string, I'll just search by index equal to bucket lifecycle. And within this, if you will look at the source, there is only one source that you can see over here. However, earlier we had a file of source code for lookup sample 1, but it seems that the source is still not present. That means the earlier data, which was present, is now deleted. Let's confirm that also.

So I'm going to get my border lips plucked. So if you go to the CD bucket lifecycle and if I do LS over here, let's do a cold DB. You don't have anything here; let's do a DB. The only thing you have is a hot bucket. So there was a lot of data because we uploaded a lot of data, and whatever data we had previously went to "frozen," and we already know that frozen buckets are deleted by default, so we don't really have anything over here. So now let's specify this frozen bucket directory also.

So I'll do optslunk and other apps, searchlocal, and we'll edit the indexes together. So, at this point in the bucket lifecycle, you are aware that there is a specific path known as "cold to frozen Dir." So now we'll specify this path, and here we have to specify what the path is. So I'll say ten. I'll say frozen DB. As a result, this could be any path. I'm just specifying it for our ease of understanding. And along with that, we'll go to Temp and create a new directory called Frozen DB. All right, so now let's do one thing. Let's go ahead and restart Splunk. I'll use the command opt Splunk beam splunk restart. Perfect. So, now that Splunk has been restarted so quickly, if you try to open a frozen DB, you'll notice that the warm bucket has appeared.

So this is what frozen DB is all about. It is especially recommended if you are struggling with compliance. Many regulations state that you should not delete your data. Instead, you should archive the data, and archiving is the best way to go with the help of the frozen deep parameters we had set in the indexes convey. Again, it's very important; it's better never to delete your data, at least for a period of one year. Especially if you work in security, because it is possible that a security breach occurred six to seven months ago and you only discovered it because it became public, as if the attacker had released the data into the public domain. It has happened with a lot of major organizations, and therefore, if you do not have the data, you will not be able to search the log files.

So that's it for the fundamentals of moving data from a cold to a frozen database. I hope this video has been useful for you, and I look forward to seeing your next video. Now, before we actually stop the video, I forgot that there is one last step that we forgot to discuss: in the default process, the Psidx file is removed and the buckets are specified for the destination we specify. So this is an important part to remember: the Psidx file is removed. So we did not confirm it. So if you go to DB, I say frozen DB, and within this, you see you only have raw data, you see? You do not have a Tsidx file. Now, within the raw data, you'll only have journalGB, which is the compressed version of the data. You don't have any other files. So this is one last one that I forgot to discuss. But now that we have the entire slide covered, that's it. And I look forward to seeing the next video.

9. Thawing Process

Hey everyone, and welcome back. Now, in today's video, we will be discussing the last stage of the bucket lifecycle, which is for restoration. Now, generally, the restoration is a manual process, and it is also referred to as a "thawing process." Now, we already discussed that the data that is supposed to be deleted can be moved to a frozen DB directory that we specify. Now, if we want to restore the data from the frozen DB back to Splunk, there are certain steps that we need to perform. Because, as you may recall, data in frozen DB only contains the compressed format, journal GZ.

It does not really have any TSDX files or other metadata files. So there are three steps that are required as part of the thawing process. One is moving the data from frozenDB to the third database here. So this is the third DB directory that we have within our bucket. We have to move our archive data here. The second thing is that you need to run the SplunkRebuild command and specify the path of your restored archive that you want to index again. And the third part is that you have to do a Splunk restart. So these are the three steps, and we'll be looking at these three steps.

Now, there's one more part that I wanted to quickly show you. Let me just open up. The index is the bucket lifecycle. And there are no events if you search by all time. Right now, this is primarily because Planck has deleted those events. Because we had specified it, they would be in the frozen DB in our case. Now, typically, when the size of the index is much higher, i.e., the data size is much higher, the change process begins, and Splunk moves the data to the frozen buckets.

So let's go to our CLI. And this is our bucket lifecycle. We are insiders at DB, and we don't really have any data over here. So, as previously stated, our data is stored in a DMP frozen DB. and this is the directory path. So what we'll be basically doing is moving this specific bucket inside our third EV. So let's go to the third EV. And now we'll be moving—or performing a recursive copy. I'll say "temp frozen DB" and I'll specify here. So now, within the third database, we have this specific directory, which contains the raw data. So if you quickly open this up, it only contains the raw data. And if you open the raw data, it only contains the journal GZ file.

So this is what we want to reindex back to Splunk. Now, in order to reinvest in Splunk, you must first visit the Splunk bin. And here you have to run the Splunk rebuild command. So if you look into the Splunk Rebuild command here, you will see that to have Splunk rebuild, you have to specify the exact path inside the third database where your DB directory lies. So this is the path. So let's try it out. I'll say "splunk rebuild." Splunk word lip is an option. Splunk.

The index name is Bucket Lifecycle. You have tor DB, and you have the tor DB directory. So this is the command. And currently, you see that the maximum bucket size is larger than the index size limit. So basically, it is saying that the data that is present in the compressed format is much larger than what we have in the maximum index size limit.

However, if you look over here, the events are archived. Over here, whatever events we wanted to represent as part of the compressed format are archived. But do remember that although the maximum index size is smaller, it is very important that we increase the index size of our bucket lifecycle. Otherwise, the events will be moved to the frozen bucket yet again. Now, if I quickly go to indexes, you need to edit and make sure that if you are archiving, or rebuilding the data from the archive, your index size matches the data that was archived.

For example, let's say every year your total index size is 10 GB and you want to rebuild or reindex the data from the previous two years. That means you need to make sure that you increase your index size by 20 GB so that the older data can be reindexed without your maximum index size being reached.

Now, if you want to do that, you can do so directly from the GUI or the CLI. You need to increase the maximum index size, let's say to 20 GB or whatever you intend to do, and just restart Splunk. After that, you can rearrange. Now, whatever data you have.

10. Splunk Workflow Actions

Hey everyone, and welcome back. In today's video, we will be speaking about Splunk's workflow action. Now, workflow action is one of my favourite features that I really like about Splunk. So let's get started. Now a Splunk workflow action basically allows us to add that into the interactivity between the indexed field and other web resources. Now let's understand this with an example. So let's suppose that there is a field called "client IP" in our access underscore-combined source type-based log file. Now what you can do is add a host lookup-based field that can automatically query this specific IP address on the client IP field whenever someone clicks on it.

So let us understand with a practical example so that we can understand much better. So I'm in my Splunk, so I'll go to the Search and Reporting app, and within the data summary, we'll select the source type, which is access underscore combined underscore test, and these are the log files. Now, if you open up this log and go up and down, you will see that there is a client IP feeder. Now, what you might want—or you also have a referral domain—so maybe what you want is to see whether this IP is a blacklisted IP or whether there are any known reports of this IP spamming other providers.

So if you just do a Google search here and basically see there are so many results over here, you can get a lot of information, like from which country and from which city the IP is coming from, the data center, ISV-related information, and various others. As a result, this can be quite useful at times, particularly during the analysing phase, when a security attack occurs. In such cases, a typical analyst would copy this IP address, go to Google, and create a query to obtain some useful information. So maybe what we can do is automate that specific part so that all the analyst has to do is click on certain fields and they are automatically redirected to this specific page, which is abused at ipdb.com. So this part can be done with the help of workflow actions.

So in order to create a workflow action, you need to go to settings, and you need to go to fields. Now, within the field page, you have a Workflowactions section, and currently there are three workflow actions. So these are the default ones that come. So we'll go ahead and create a new workflow action. The destination app is now Search. The name would be, let's say, "Who is looking up?" The label that will basically appear as a field in search is "Who is looking up again?" Let it be the same. Now it can apply only to the following field: So which is the field that contains the IP address?

Here it is. The client IP feed So what we have to do is specify the client IP feed over here. Now here you have to basically specify the URI, and you can say http://www.google.com. Dora Client IP should be used for search and query. So the client IP here is a variable. So instead of going through Google, what we'll do is make use of this website, which is abuseipdb.com. house, and at the end, you have the variable here. So this is the IP address that you can feed here. So we'll put this here, replace the last part of the URL with the client IP address, and add the open link. It's definitely a new window, because if someone clicks in and it just opens up in this window, your search will go away.

So it's better to open up a new window and use the link method to get in post. We'll make do with what we have. For the time being, I'll save it. Perfect. So what we'll do now is quickly refresh because Chrome is known to cache some things, making it not work very well. So once we have refreshed it, if you quick click on "Open," you will see the client IP and within the event action, you will see a host lookup. When you click on who is lookup, you will be automatically redirected to abuse.ipdb.com, where the variable associated with the client IP will be set.

And now you have some nice information about which city or country it belongs to, and so on. As you can see, this workflow action can have a variety of meanings depending on the use case. This again is one of the interesting use cases, and in the organisations that I have been working with, we only have security logs, Splunk is extensively used as SI M, and we douse this specific type of workflow action so that it becomes easier for the analysts to do things.

Splunk SPLK-2002 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass SPLK-2002 Splunk Enterprise Certified Architect certification exam dumps & practice test questions and answers are to help students.