G’day from Sydney, Australia! This my first Splunk Blogs post as a proud new Splunker.
One of my first tasks at Splunk was to put together a fun, engaging and relevant keynote demo for our SplunkLive! events here in Australia. The idea of “Splunking SplunkLive!” was floated, e.g. ingesting data live from the event to show some really cool uses, or “event analytics."
This sounded like a great challenge, and what could possibly go wrong with a live demo in front of hundreds of people?
With the help of a partner, Cisco Meraki, I became the temporary owner of seven Cisco Meraki WiFi access points that became the foundation of the SplunkLive! demo.
The night before the event, I set up a SplunkLive! WiFi network in the venue to be used for some really interesting statistics. Stay tuned for details on that.
To add to the live data feeds from the Meraki WiFi network, I also built a room sensor system based on a Raspberry Pi with the Splunk Forwarder for ARM on it. With this little device, I could collect room enviromentals, temperature, humidity and even the loudness of the presentations via a USB-attached microphone.
But what is event analytics without some external data sources?
So I brought in live weather data from the Australian Bureau of Meteorology and Twitter data about the event, which provided interesting social impact details. For example, the number of Tweets about #splunklive or—more interestingly—the social reach (the sum of the followers of the tweets). For some bling, how could I not put a word cloud in for the Twitter data?
Now back to my secret WiFi…
By Splunking the Cisco Meraki data, I was able to effectively count attendees in each space; for example, an estimate of the number in the keynote. This was done by generating a search that summed the devices seen by the WiFI APs and filtering the count to a specific RSSI value, or the WiFi strength of the client. The Meraki access points can see WiFi and Bluetooth-enabled clients whether connected to my WiFi network or not.
My keynote dashboard had all this data summarised, including the famous applause-o-meter. I was able to show live updates of crowd loudness along with the maximum, which was 71 dBA for Sydney (sorry Sydney, Melbourne beat you!).
No event would be complete with some security use cases, and a SplunkLive! SOC (security operations centre). Here, I showed how the same data sources from the Meraki access points could be used as data sources for the SOC, getting exponential value as more data sources are ingested—a key value point of Splunk.
A simulated bad guy was created; someone named “Gilfoyle” had been visiting blacklisted sites from the SplunkLive! WiFi. This was a great opportunity to showcase some cool Splunk visualisations, such as a chloropleth map and a missile map.
But what about tracking down that simulated bad guy Gilfoyle?
The Cisco Meraki access points passed back to Splunk both the latitude/longitude and x/y co-ordinate data about the clients connected and the clients seen. They also provided an estimated uncertainty of the calculated client locations in metres. With some simple searches within Splunk, I was able to confidently plot client locations within the venue, including where Gilfoyle was hanging out! (BTW – Gilfoyle was actually an extra iPhone of mine.)
I utilised a new indoor mapping visualisation created by a Splunker Scott Haskell which can be found on GitHub. This was probably to most popular part of the demo that I was asked about after the event. The use cases for indoor mapping are endless; imagine the possibilities in retail, universities, industrial and more.
Lastly, what about the event breakout presentations?
With some carefully placed access points in each room, I was able to do some event analytics on these sessions. By creating some simple searches related to the access point in the room, I could again get an approximate count of attendees in the rooms. These counts could obviously be done more accurately with the traditional manual scan at door method, but mine were automated and allowed me to get a very important metric—audience retention.
By counting the devices seen over time, it’s possible to determine how long the audience remained during the presentation. You can see here that audience retention was quite good...until the dreaded last session of the day. Obviously attendees in this session were keen to get a head start on the SplunkLive! social drinks at the end of the event!
In summary, doing live “event analytics” with Splunk is not a hard task. With very little help, I was able to set up some really cool uses cases and get some useful insight into the event.
Imagine “the possible” if it was a properly organised effort and not just a simple keynote demo.
Any questions? Happy to answer them!