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.

Example: Let’s suppose you have two different types of call detail records, each containing a number that represents the total duration in seconds that someone is on a phone call.

One CDR event looks like this:

TELCOE,2.1,7e197787-655330a9-7a458301-70845177@12.13.20.20,,0,,H,,S,,sip:7622550@127.10.15.17:5050, sip:5558889999@120.10.20.20:55555,TELCO:Dallas,TX,0,sip:7622555@110.130.52.25:5050,NORTH:NORTH,200,0
,1,0,1,0,08/02/2009:05:03:21,08/02/2009:02:03:22,92,UNKNOWN,0,0

and the other CDR record looks like this:

TIME=20090802104826865|CHAN:332|SESSIONID:100102345|CALLDURATION:93|CALLINGNUM:5558431297|
CALLEDNUM:5559903894|UNIQID:8948373827100002938847889873474893

Now, let’s take a look at the Splunk configuration files to index these source types and extract the call duration values out into fields.

inputs.conf
[monitor:///$SPLUNK_HOME/etc/apps/cdr/logs/CDR.txt]
sourcetype= cdr_log

[monitor:///$SPLUNK_HOME/etc/apps/cdr/logs/cdr2.txt]
sourcetype= cdr2_log

props.conf
[cdr_log]
EXTRACT-calldur = ^.*?:\d\d:\d\d:\d\d,(?<callDuration>\d+),\w+,\d+\.\d+\.\d+\.\d+,

[cdr2_log]
REPORT-cdr2 = cdr2-kvpairs

transforms.conf
[cdr2-kvpairs]
DELIMS = “|”, “:”

Happy New Year and thanks to everyone who has been subscribing to my blog recently. I greatly appreciate it!

Every week people ask me to show them how to use Splunk to stitch together multiple events that might exist in different locations within different sources because, from an IT perspective, they are considered to be part of larger transaction groups. They tell me they want to know how to do this because the ability to trend against transitively-related events becomes very powerful in helping them understand the reality of IT operations and how efficiencies can be increased and costs can be more quickly and significantly reduced.

I thought I would share a quick example of how to do this using the transaction command.

Let’s start with a couple sample user activity log files containing some events that are related by multiple keys. Take a moment to study the two following sample activity log files and notice how the user and session key values are related between the files.

That’s right! It’s “on fire” folks! Hotter than the sun! Burning its way into the thoughts and minds and data centers across the world.

Unfortunately, what I wanted to talk about today is not related to how hot Splunk is, but rather a very special and sometimes misunderstood character called “the pipe”. For most of us tech geek types, the pipe is our friend. We use it all the time at the command-line to make efficient use of our tools and our time. For non-techie folks, it may be more mysterious or intimidating concept, so I felt it might be a good topic to discuss and demonstrate just what it is and how to use it in the Splunk search box.

Also known as the vertical bar character, the pipe (|) allows you to create simple yet powerful ad-hoc Splunk searches. You might think of it as if it were an actual pipe where things flow into one end and then flow back out the opposite end. Within the context of Splunk searches, the “things” that flow in and out of the pipe are your IT events.

Recently, I received an email from a client that was struggling with a Splunk configuration issue. He was a sysadmin trying to figure out how to setup Splunk-2-Splunk within his private testing environment. The specific issue he was encountering was not so much related to the Splunk software not working or throwing an exception, etc. But rather, it was more about him trying to understand the “how to” part of Splunk-2-Splunk.

I think anytime you have a technical IT tool like Splunk combined with the ability for a technical person to download, install, and evaluate it for FREE, you will also have plenty of “how to” questions that will naturally accompany those evaluation efforts.

With this said, I want to remind all you technical folks, especially those of you who may still be struggling with the HowTos of Splunk, that as Sales Engineers, it’s our job to provide you with the HowTo support you need during your evaluation of Splunk. In a way, you can think of us as Splunk’s HowTo Team, always willing and able to discuss and recommend the best ways to configure and test out Splunk. It’s our job to make sure you understand all of the technical features and how best to leverage them for your specific needs. And, it’s also our job to help you develop a strong business case for purchasing a Splunk license based on the technical benefits. That way, your manager or director can more easily justify the purchase of that license for you. And, if you are like me, more often than not you need all the justification you can get.