By Splunk November 20, 2017
It’s November, which means my favorite holiday of the year is coming up—Friendsgiving! Ever since I moved away from the suburbs of Chicago, I’ve found a new community to celebrate stuffing my face silly with on a yearly basis when I couldn’t make it home to the Windy City.
The best one yet was definitely “Spacegiving,” during which everyone dressed like their favorite planet, extraterrestrial, or space concept. The host baked a crumble cake topped with space-enlightening ingredients that he shared with guests after they completed a race up the steep terrain of “Space Mountain” (i.e. their block). This year I‘m looking forward to celebrating ThanksBASSgiving with the Splunk fam, which I’ve gathered entails pie eating contests, pumpkin pie (shots), and mad beats dropped on the bass.
Until then, here are this week’s featured Splunk Answers posts:
Math Within addtotals
Splunk user icrit was trying to do math with values calculated in an addtotals command then put them back into the same search to find billable and nonbillable hours based on the hire date, but he couldn’t figure out how to nail it. He had a long search that was resulting in the sum of columns, but that wasn’t his intended goal. User group leader, Answers moderator, and SplunkTrust member cmerriman came to the rescue with a search that included addtotals, eval, sort, rename as, and fields with a perfect result that merited the response: “That worked flawlessly! Thank you for your help,” from icrit.
Read the results for how to do math within addtotals, and learn more about mathematical functions in Splunk.
What does "summariesonly" mean in this Splunk Enterprise Security search?
Test_qweqwe, who is new to Splunk Answers, wanted to know how to make a search that he found in a Splunk Enterprise Security content update work, but first he needed to understand what “summariesonly” meant. Splunker rphillips_splunk had just the answer for test_qweqwe, explaining that the “summariesonly” referenced a macro that indicates (summariesonly=true), meaning it would only search data that was summarized by the data model acceleration. In that case, summarized data would only be available after data model acceleration was enabled on the data model Network_Traffic.
Read the post to learn more about data model acceleration and check out the Splunk Enterprise Security Sandbox.
What causes unioned data sets to be truncated?
Confused about the union command for too long, jsinnott_ decided to ask the Answers community. Specifically, jsinnott_ wanted to better understand what caused the unioned searches to be truncated—in his case, to 50,000 events—after adding a head command to his first search. After encountering that issue, jsinnott_ tried altering the search, but wound up instead with a truncated search each time. Moderator and Splunker mattness helped jsinnott_ understand the behavior of union, explaining that it worked alternately like both multisearch (for distributable streaming subsearches) and append (for subsearches that are not distributable streaming). Mattness attributed the behavior from each of the three searches to the fact that they were distributable streaming and therefore all unioned with multisearch.
Mattness went on to explain that the second search used the head command for one of the subsearches. Because head is centralized streaming rather than distributable streaming, it caused the subsearches that follow it to use the append command. It turns out that when union is used in conjunction with a search that is not distributable streaming, the default for the maxout argument applies: 50k events.
Read the post to learn about the truncation issue and become a union whiz.
Interested in being a part of the Splunk Community? You can learn more about Splunk and socialize with other users in the community by contributing to the Splunk Answers forum, joining discussions in our Slack community chat, or attending a Splunk user group meeting. Happy Splunking!
To see more from Splunk Answers, check out all the posts in our Smart AnSwerS blog series.