Splunking Game Data - Darkfire Heroes part 2

In part of one of this series I went down the path of Splunking game data from a 2 day, single challenge event. In this installment I'm going to dive into a bit of data from an event that encompassed several different challenges. 

In looking back at the dashboard I created, how I was working with some of the data, and the sheer volume of data across all of the challenges - the dashboard itself might not have much value from a game analytic perspective lol. I also realized how much I focused on one challenge - waves. In looking back I think that was largely due to the numbers being smaller. The approaches to displaying the data will work across all of the events so at some level it would be a lot of copy and paste as well. At any rate hopefully folks will take something away from the underlying queries and some of the challenges with trying to display the data/volume of data. TBH this is the more primary focus of this overall effort. 

Data was captured across 4 challenges, 3 player level brackets, and listed scores for the top 100 positions (other than the clan boss fight).

1. Waves - 5 separate groups of mobs attack your heroes
2. Pacifism - multi-level, player vs environment (PvP) track where you couldn't bring damage dealers
3. No Healers - multi-level, PvE track where you couldn't bring a healer
4. Boss - big bad dude that everyone in the clan attacked

Splunking Game Data - Darkfire Heroes

(Part 2 Link)

So there is somewhat of an eclectic mix of drivers going into this post. As I talk with individual Splunk users, Splunk administrative teams, and larger teams that have access to Splunk (security, operations, etc) I sometimes come across a subset of folks who have a tough time trying to figure out how to take advantage of the data they have access to. In some cases it is because they lack imagination, vision, or strategy relative to what they are trying to accomplish. Sometimes it is being so heads down in the daily grind they have trouble 'looking up' so to speak and collecting their thoughts. More often than not though they are wearing multiple hats and could use a hand getting over the Splunk language learning curve. This post is designed to help a bit - some Splunk Processing Language (SPL) exposure mixed with a bit of dialogue on why I made the dashboard/dashboard panels the way I did.

To start with I need data. Turns out I've started playing a mobile game called Darkfire Heroes. It isn't quite in a beta state but isn't available globally quite yet. The other day, Dec 8 & 9 to be exact, they had a 2 day Player vs Player (PvP) contest. Individual match wins were tracked as well as aggregate win total if you belonged to a group within the game; a clan. As a total side note it is interesting to see people's gaming pedigree based on descriptions they use. Are some of the bad guys/monsters you fight creeps, mobs, trash, etc and are you a part of a clan, guild, or alliance? Outside of this mini event there is a clan rewards chest that also gives varying level of rewards based on aggregate PvP wins over a week. PvP matches won during this 2 day event will count towards that reward chest. 

User Aware Splunk Dashboards

One of the more interesting aspects of Splunk is giving users direct access to raw data. This is great on so many levels from a troubleshooting or investigative perspective. However there are times when you'd rather or need to give people, let's call it, a guided experience to what data they see. This is particularly true when within the same overarching or umbrella organization you have separate lines of business or groups of people such that you don't want to give people direct access to the data; you want/need to limit access at more of the UI level. You might have some data source like a vulnerability scanner where all of the data is coming into one index and you want to give people access to only the scan data that applies to them. One way to accomplish this is by adding search time restrictions to particular roles. While effective this approach can get complex very quickly. The following Splunk .conf talk gets into some great detail (link).  Another approach is to slice and dice what index the data goes into as it is indexed based on the user groups you have setup. This can be effective as well but then data from that singular tool is all over the place and what happens if you are using something like CIDR blocks to map data to index and those CIDR blocks change? In this article I'm going to get into a third approach that is making the dashboard user aware and displays information based on who the user is without giving them native access to the data.

I should say there are likely several ways to accomplish this that might be more efficient or work better for particular use cases. This worked for me though and can be a good starting point. If you know of other ways to limit data access at the UI level I'd love to hear about them; feel free to put them in the comments!

Drilling into the OTHER category in Splunk

So what has broken my 3 year blog posting hiatus you might ask? Some nerd-like delight in working through a Splunk dashboard capability I didn't realize was there!

Several days ago some fellow Splunk users asked if there was a way to drill into the "OTHER" category. They had an overview dashboard with a bar chart viz allowing the user to pivot to a more detailed interactive dashboard. The challenge was the overview graphic leveraged Splunk's ability to show the top N results with the rest of the results up as OTHER. The interactive dashboard didn't like receiving OTHER as that wasn't a value in the data. I tried a few different approaches but they honestly didn't work. Through that effort though I stumbled upon the ability to set a condition match in XML.

Wait whuuut? I've known about condition match from adjusting navigation bars in Splunk and it turns out this capability is also available in dashboards themselves. Could I use this mechanism for the use case at hand?

Adjusting Splunk forwarder phonehome / throughput

I was in the process of writing up a few things for a new EDU that is going to be spinning up a larger scale Splunk environment and figured if I was going to the effort it might as well be placed here for others to see. In working with my own environment today I realized I was making some adjustments that I take for granted but that we had to learn and bake in. For this installment these items are focused on the following:

1. Adjusting the forwarder to deployment server phone home interval
2. Allowing forwarders to send more than 256 kbps