The time has finally come for us to bring Splunk(x) to the far reaches of the galaxyworld. I got a call from our Fed team requesting Splunk(x) monitors in our Bethesda, MD office so they could show off how we use Splunk to our public sector opportunities and customers. Always eager to go take awesome photographstravel for work, I happily obliged and you can see the results after the break.

I was thrilled to be a part of this year’s worldwide user’s conference showcasing what we’ve done with Splunk(x) and hinting about where we’re going with it. I had the privilege of presenting a session and a Splunkbase lab on how we use Splunk within Splunk. We showcased several of the dashboards I presented in my last blog post on Splunking the Enterprise (which was far too long ago) and highlighted how we’re using SalesForce.com data mashed against our machine data.

It’s been a while since our last update on Splunk(x)! We’ve been busy working out the architecture to get to a point where we can implement NOC-like dashboards above our IT/ops space in our San Francisco office. We had a continual crowd around the Splunk(x) monitors for the first week in operation! They’re one of the first things people see when entering the office and are a great conversation piece. More importantly, the team sitting beneath them has only to look up to see a complete status snapshot of business application, infrastructure, website, and even Splunk(x) itself!

Of course, really important bits are still fired off in real-time through Splunk alerting and herein lies much of the value of…

One of the more recent use cases for which we’ve begun using Splunk(x) is website availability monitoring. It’s not enough to know that our web server is up—we want to know that it’s able to properly serve requests within tolerances of response time, bytes received, and HTTP status code expected.

The most requested information since my last Splunk(x) blog post was regarding the VMware environment. I would like to take a few moments to describe the Splunk(x) virtualization stack and the Splunk environment.

Our production VMware cluster is hosted in our private cloud at Equinix. The cluster consists of 8 ESX hosts with 12 cores and 96GB RAM for a total of 96 CPU cores and 768 GB RAM. Splunk(x) shares this environment with our production web infrastructure serving almost everything on splunk.com.

Hi there! My name is Paul and I manage Splunk’s (the company) use of Splunk (the product). I come from a background of web development, web analytics, and Linux administration so I’m no stranger to digging through logfiles when things go wrong. With Splunk, I can do this more quickly and elegantly.

Splunk(x) is our internal, enterprise deployment of Splunk. Splunk consists of 10 virtualized indexers, 3 virtualized search heads, a deployment server, a couple of heavy forwarders, and dozens of light and universal forwarders. We’re splunking our website, firewalls switches, F5 load balancers, *NIX and Windows OS logs, Active Directory, and SalesForce.com objects.

The first major goal with Splunk(x) was getting it deployed, onboarding…