![]() ![]() Thus, the nf you’re going to have on the other search heads with the “acceleration.source_guid” setting must be defined in the same namespace (the same app) as the one in which the data model accelerations are generated on the originating search head. So, the data models you’re accelerating are defined in the context of an app. That’s it, but there are a few “gotchas” to keep in mind.įirst, keep in mind that everything in Splunk exists in the context of an app, also known as a namespace. If the accelerated data was created by data model searches run on a search head cluster, you will find the GUID for the cluster in nf on any cluster member in the stanza. If a standalone search head created the accelerated data, the GUID is in $SPLUNK_HOME/etc/instance.cfg. You do this in nf on Search Head 2 under the stanzas for each of the data models you want to share by adding the setting “acceleration.source_guid” like this:Īcceleration.source_guid = guid of Search Head 1 Then, on Search Head 2, you direct Splunk to use the accelerated data created by the searches run on Search Head 1. You accelerate the data models as usual on Search Head 1. Beginning with version 8.0, you can now share data models across instances-run once, use everywhere in your deployment that uses the same indexers. That’s a lot of duplicate searches consuming CPU and memory on both your search heads and your indexers and duplicate accelerated data-consuming storage on those indexers. In a large distributed deployment with separate search heads or search head clusters for Enterprise Security, IT Service Intelligence, adhoc searching, etc., you end up accelerating these data models everywhere you want to use them-on each search head or search head cluster, on your Monitoring Console instance, on one or more of your heavy forwarders running DB Connect, and more. All this summarized data is stored again and again on the indexers, each copy of a bucket’s summary data identical, but tied to a different search head. All these data models on all these search heads running search jobs to maintain and keep their summarized data current. Many times you need the same data models accelerated on several different search heads for different purposes. So, imagine it: You’re employing many different apps and add-ons in your Splunk deployment that all require these data models. And, because of the design of data models and data model accelerations, this summarized data stored on the indexers is tied to the search head or search head cluster that created it. This means that at regular, frequent intervals, the searches that define these data models are run by Splunk and the results are summarized and stored on the indexers. In order for a data model-powered search to function at peak performance, they are often accelerated. Share and Share Alike: Using a Data Model Job Server for Shared Data Model Accelerationsīy: Jon Walthour | Senior Splunk Consultant, Team LeadĪll these Splunk apps and add-ons and many others use data models to power their searches. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |