Turns out this particular example is a bug. Splunk 8.0.0 through 8.0.6 generates this "info message" when you use sparkline without an argument (such as sparkline(count) or sparkline(count(cpu)). This isn't supposed to happen. The bug is fixed in upcoming versions of Splunk.  As for supporting deprecated syntax - well, sometimes we do that for backwards-compatibility, when people are upgrading from older versions of the product.  ... View more

Hi Simpkins - The answer to your question depends on the data you are working with and what you are trying to do. Data models are in fact collections of hierarchically arranged datasets--you might want to create a data model if you are working with a large dataset that can be divided into lots of very specifc subsets. A data model allows you to see the overall data model dataset hierarchy and then work with specifc elements (datasets) within that hierarchy. You can run searches on specifc data model datasets. You can also use the Pivot tool to build visualizations based on specific data model datasets. Also, when you accelerate a data model, you can potentially accelerate all of the datasets within that data model (see the Knowledge Manager Manual docs for for information about data model acceleration restrictions). This means that searches and dashboards that use datasets in that data model can return results quicker than they would without acceleration. To create a data model, you need to have a pretty solid understanding of your data and have a clear idea of how you'd like to subdivide it into smaller datasets. The Data Model Builder is not really designed for data exploration. It requires that you have a decent understanding of the search processing language (SPL). On the other hand, you can also create table datasets with the Datasets Add-on. You might do this if you just want to work with a simple dataset that represents the results of a simple search. You can use the Table Editor to refine and focus the boundaries of that dataset without interacting with SPL. You can also use it to better understand the contents of a particular dataset. This might be a better solution if any of the following are true: You are working with a relatively small dataset You do not know your data very well You do not know SPL well You do not want to spend time designing complicated searches of a dataset You do not need to design a collection of hierarchically-related datasets You can accelerate table datasets in much the same way that you accelerate data models. You can also use Pivot to design visualizations based on specific table datasets. You can also use the from command to create table datasets that "extend" other datasets. This creates a hierarchical relationship--a change to dataset can also affect any datasets that extend it--but currently the Splunk platform's ability to show you table dataset dependencies is pretty limited. I think this sums it up. Hopefully this helped you more than it confused you. Let me know if you have more questions. ... View more

Hi jsinnott_ At this time, union behaves alternately like multisearch (for distributable streaming subsearches) or append (for subsearches that are not distributable streaming). This is not adequately explained in the doc topic for the union command at present and I'll see what I can do to fix that. (For more information about the types of streaming search commands, see Command types in the Splunk Enterprise Search Manual.) Let's take your first search: | union maxout=10000000 [ search index=union_1 ] [ search index=union_2 ] [ search index=union_3 ] | stats count by index In this case, all of the searches are distributable streaming, so they area all unioned with multisearch . This is why you see 60k in each. Your second search uses the head command for one of the subsearches. Because head is centralized streaming rather than distributable streaming, it causes the subsearches that follow it to use the append command. "Under the hood," the search is converted to: | search index=union_1 | head 60000 | append [ search index=union_2 ] | append [ search index=union_3 ] | stats count by index When union is used in conjunction with a search that is not distributable streaming, the default for the maxout argument applies: 50k events. This is mentioned in the doc topic for the union command. Your third search also ends up being an append search, because the second subsearch is not distributable streaming due to the head command. Here's how it looks "under the hood": | search index=union_1 | append [ search index=union_2 | head 60000 ] | append [ search index=union_3 ] | stats count by index Again, the maxout argument default applies here, limiting the results of the appended searches to 50k events. In your last example, the first two subsearches are distributable streaming, so they are unioned with multisearch . But the final subsearch has the head command, so it gets unioned with append at the end. | multisearch [ search index=union_1 ] [ search index=union_2 ]| | append [ search index=union_3 | head 60000 ] | stats count by index The maxout argument applies to that last subsearch because it is not distributable streaming due to the head command. So it returns 50k events rather than 60k events. Note that multisearch has to be the first command. If your union search unpacks in a way that puts append first, you won't get multisearch to follow it. Kindest regards, Matt (Splunk Docs Team) ... View more

Hi kiril123-- To answer this question, it's probably helpful to revisit what report acceleration does. Say you have an unaccelerated search that runs over the last month, and when it does, it searches through an average of 500k events to return maybe 300 events, which means it has low cardinality--only a few events from the original set are returned. This search takes awhile to complete because it has to look through all 500k events to find those 300 events. So you accelerate that search. This starts a search running in the background. It runs on a schedule using the same criteria as the original search, and builds a summary of just the results the original search was looking for. This summary will be far smaller than 500k events--it may contain just a few thousand events at any given time. The next time you run your accelerated search, it runs against that summary. Because the summary is far smaller than the original search set, the search should complete much faster than it did before. Ok, now imagine you have a second unaccelerated search that, like the first search, runs over the past month, and when you run it, it also searches through an average of 500k events. But this search has far higher cardinality than the first search: each time you run it, it matches at least 50k events, maybe more. This second search is slow to complete as well, because it also has to look through 500k events each time it runs. However, when you accelerate the second search, it ends up with a much larger summary than the first search. This is because the second search has high cardinality. Each time its background search runs, it adds at least 50k events to the summary. If the summary has a range of 3 months, that's an average of 150k events at any given time. When you run the accelerated search, it runs against that summary. It will complete faster than it did before, but not that much faster, because it's still running over a lot of events. Its report acceleration summary just isn't much of a summary. So the lesson here is--when you must search across large volumes of data, try to design low cardinality searches--searches that return significantly fewer events than the total amount of events searched. Then, when you accelerate them, you'll get searches that are actually accelerated. I'll see if I can rewrite the documentation to clarify this point. ... View more

In 6.5 there was a terminology change. The term "data model object" was replaced by "data model dataset." Nothing about the functionality actually changed. Splunk is just clarifying that data models are in fact made up of hierarchies of datasets. Nothing has changed for Pivot with regard to how it works with data models except for this terminology change. Previous to 6.5, you had to select a data model object and open it in Pivot. Now you select a data model dataset and open it in Pivot. The concept of datasets was formally introduced in 6.5. You can use the new datasets functionality to work with three new dataset types. Two of these types already existed as knowledge objects: lookups and data model datasets. The third type, table datasets, is new to Splunk. For more information about dataset types, see http://docs.splunk.com/Documentation/Splunk/6.5.0/Knowledge/Aboutdatasets One difference for Pivot now is that any dataset type can be opened in Pivot. You can do this from the Datasets listing page. For more information see http://docs.splunk.com/Documentation/Splunk/6.5.0/Knowledge/Workwithdatasets#Open_a_dataset_in_Pivot ... View more

Apologies for your confusion, Ben--that was a typo. You are correct that the accelerate_search capability does not exist in v 6.0.5. It was introduced in v6.1, and the documentation should have been fixed so it gave the correct information for the correct version at that time. In v6.0 the only capability required for report acceleration is schedule_search. If you remove schedule_search from the role, the ability to accelerate reports should be removed from users with that role. In v6.1 and later, the ability to accelerate reports requires both schedule_search and accelerate_search. I've updated the topic so it shows the correct capability requirements for 6.0.x and 6.1+ ... View more