Part of my focus as Knowledge Manager at Splunk is capturing best practices, particularly the best practices around using Splunk. Gathering this information is a lot like researching a story, getting me to draw on:

• My own knowledge of how to use Splunk (hey, I’m not a guru but I have been using it for over a year now)
• Our sales engineers who encounter what customers want to do in the field
• Folks in support who hear a lot about what aspects of Splunk might be confusing, along with what folks are trying to do with it
• Our developers, who can give me those sweet little tips and tricks that I can share to help people do things more efficiently
• The folks in professional services, who definitely encounter what customers are doing in the field.
• Doc writers, who spend a lot of time explaining the nitty gritty of things and can often have some pretty interesting tips.
• And really anyone else in the company who might have something interesting to share.

Update 22 April 2008: As of Leopard 10.5, you can use the dot_clean utility to get rid of these files!

When building Splunk applications, I’m often working on a Mac. There are files that begin with ._ that are resource files, which contain extended attribute information about the files for the OS. This is great and all but I don’t want to include these files when I package up an application and upload it to SplunkBase.

If you don’t have deep OSX knowledge, then keeping these files out of your tarball is harder than it looks. One of our OSX gurus pointed me toward the answer, and I was so excited (yes, I am a geek) that I just had to share.

To build a tarball in Leopard that doesn’t contain the ._ files, use:

COPYFILE_DISABLE=true tar cvzf filename.tar.gz dirtotar

In Tiger, use:

COPY_EXTENDED_ATTRIBUTES_DISABLE=true tar czvf filename.tar.gz dirtotar

This is definitely going in my .bashrc so I don’t have to fuss with it again:

export COPYFILE_DISABLE=true

Knowledge management is one of those strange terms that sounds like it was made up to make someone’s job sound more important than it is. However, the task of the knowledge manager is no small one: “capture” the knowledge within a company, whether across the board or in a vertical section such as human resources or technology usage. This process is multi-step, as you have to get a feeling for what there is to learn, who to go to in order to learn it, and then get it all down in ways that people can find and make use of.

In my case, I capture best practices in using the Splunk product to accomplish key tasks. Since I’m surrounded by experts in various aspects of using Splunk at work, this task involves a bit of mind-melding so I can learn and understand cool things that other Splunkers have discovered and then put them down in a way our users can follow. I’m sure that many users out there who have come up with some pretty interesting ways to efficiently utilize Splunk for their own purposes. If you’re one of them, I’d love to hear what you’re up to!