40 Days of Splunk 4.0

This will be a very brief post, to fulfill my obligations. I'll share something a little more informative, perhaps even more interesting, in an upcoming post (soon... I promise (kinda) this time). As of Splunk 4.0, our old somewhat-of-an-API has been replaced with an entirely new REST API, invalidating my old post on reloading authentication from the command line.

Many companies produce RSS (Really Simple Syndication) feeds for their employees, partners, and customers. Moreover, these same companies consume RSS feeds from their suppliers whether it be personal news information or more timely business data. RSS is a great way to digest this information, but after a certain period, it may not be possible to find it again. If information from a RSS feed were indexed on a regular basis, say every 10 minutes to 30 minutes, into Splunk it could be searched at anytime.

Now that I've (hopefully) convinced you that ldapsearch is your friend, let's get down to the matter. How can you use that information to configure Splunk to authenticate against LDAP? The file used to configure LDAP authentication: authentication.conf If you have never attempted to configure ldap auth before then you won't have one of these files in your $SPLUNK_HOME/etc/system/local/. You can either create it by hand or use the UI (which creates the file for you.) Here's a sample authentication.conf file that I will break down for you.

I've had this topic come up in several technical conversations lately, so I thought I would blog about it now. Situation: You have two different source types containing common key field values, but the actual name of the field itself is different within each of the source types. Question: How do you produce a report within Splunk that correlates all of these fields values together under one normalized field name? Answer: Use the new FIELDALIAS and EXTRACT features included with Splunk 4.0 to normalize the field name at search-time.

If you've ever tried exporting lots of events from Splunk UI then you probably know that there's a hardcoded max of 10,000 lines. This is to prevent users from potentially crashing splunkd or python. Taking the previous into consideration may allow you to view this restriction as a safety feature. In most cases, users should not need to export 10,000 lines of data. If you've got more than 10,000 lines, you should refine your search so that your have less (a lot less) than that.

With the previous setup, here's what I want for my app: A dashboard with a couple pretty pictures and some top N lists Saved searches for advanced users to explore further It should work for all my users with whatever indexes they have access to I'm going to start with the sample_app template available in Manager and add what I want. Then I'll clean up the sample stuff I don't need. So the first step is to create a new app in Manager->Apps.

In this post I will be talking about a feature of Splunk that got turbo charged for 4.0 : Distributed Search. Splunk is a great tool when it's just running on a single system but distributed search has some great advantages. Provides completely different views into the same data by having different apps on different systems. Allow leveraging of map reduce architecture to run complex queries. Linearly scale Splunk indexing by simply adding more servers

If you are a long time enterprise user of the 3.x product, you may have become used to the pull-down menu for distributed searching. One of the common use cases for this menu was searching specific indexers in your distributed search. A common question was: "Can we restrict the server via search syntax?". In the 3.3 and 3.4 product, you cannot restrict via syntax through the web interface. There is a trick you can use via the command line, but that doesn’t help when you want to do this in a saved search.

If you are comfortable editing XML, here’s a handy hack to get the list of your default indexes in the "All indexed data" dashboard. It will show whatever the logged-in user has access to.

Many customers tell me that they see a lot of value when Splunk is used to enrich IT data with information from another source. An example of such an enrichment could be a cross reference between a customer’s username found in an application log and that same customer’s information extracted from a contact management system. How amazing would it be to have a customer service representative make a phone call to Mr. Smith to ask if he needed help logging onto their system after a number of failed logins?

Need a friend to help you in the war against seemingly complex LDAP configuration tasks? Let me introduce you to a handy dandy tool called ldapsearch. Next to an LDAP browser, ldapsearch is your friend when it comes to configuring Splunk, or any other LDAP capable app for that matter, to authenticate against LDAP as it allows you to test out your configuration purely from command-line and then implement once you know its working

Coming from an engineering perspective, I’m excited about Splunk 4 because it represents a monumental improvement in search power. Not only is search about ten times faster than the previous release, but we have added several new features that empower users to search smarter and faster. This blog post is going to highlight just a few of these new features.

Last week we continued our road show launching Splunk 4 through the Southwestern US in Phoenix, San Diego and Los Angeles.This was our second annual gathering of customers, partners and users and we had more than double the attendees at this year’s Splunk Live events. In the morning we held a three-hour hands on technical workshop.

This year's London Splunk Live was really special. More than 100 customers and users attended.But the dominant reason to attend any Splunk Live are the presentations and round tables with forward thinking IT professionals who are using Splunk to transform the way they manage IT. This year we were very fortunate to have three Splunk customers who took time out of their busy schedules to come to London and share their experiences with us.

Getting out the office to see successful Splunk customers is always a pleasure, and the presentations and conversations at SplunkLive in London were especially a treat. One of the most striking things about all three customers (Vodafone, Telenor and Accenture) is how Splunk has transitioned from a tool used by a couple of working teams into a cross-organization IT utility. Despite being from two different industry verticals, they also all approached the problem in a similar way, and that way suggests the new dynamic lookup feature is going to be very popular.

There's a big reason I haven't blogged here for a while: Splunk 4. I've been so wrapped up in it for the last year that I haven't really been interested in writing about anything else. Well, now it's out, so I'm back! So I'll kick it off with some background on why 4 is the Splunk I've always wanted and a little story about how my team and I have used Splunk ourselves in a new way the past few days.

Splunk 4 is out of the bag. One of the areas that I’m especially interested in hearing about is our new App focus. We are in the very early stages of creating Splunk Apps and making them available to the Splunk community. And we want your input. What would Churchill say?

Our first full day of Splunk 4.0 is under our belt and so far so good. More than 2400 people ultimately registered for the Launch webinar yesterday representing more than 61 countries and 1500+ organizations. To keep that momentum going, we're introducing 40 days of Splunk 4.0.