PDF printing and logos
Working on the Splunk OEM team, we are often asked if it is possible to replace the logo printed on PDF reports. The short answer is yes, it is possible but it is kind of a hack. The workaround would not be Splunk upgrade safe, there are some limitations to what the SVG can do, and you would need to edit some Python. With that being said, the request to make this easier is already in the laundry list of improvements we are looking at for PDF printing.
Let’s get started:
- The default Splunk logo is hardcoded in the $SPLUNK_HOME/lib/python2.7/site-packages/splunk/pdf/pdfrenderer.py file. Make sure you backup the file before editing!
- At the bottom of the file, you will notice a variable
Updating the iplocation db
When Splunk added the new version of the iplocation command in v6.0, it added the ability to add location info without the need for internet concenttivity. We did this by shipping a custom version of the MaxMind DB in the 6.0.x release. However, because we used a Splunk specific version of the DB, you still had to wait for a new version of Splunk to get a new copy of the DB.
In 6.1 we added support for using the native MaxMind DB (.mmdb), allowing you to update the DB yourself at anytime! It looks like some of you have already figured this out (Go George go!), but I figured I would add some additional info about this …
Adding a subtotal to your report
If you’ve taken Splunk training, you should already be familiar with the appendpipe command (it’s used in one of the labs). For those who haven’t, the appendpipe command is an easy way to add a subtotal to your stats command. In my use case, I wanted to get a subtotal of the data indexed by day, but I still wanted a break down by index and pool for the report:
index=_internal source=*license_usage.log type="Usage" | eval idx=if(len(idx)=0 OR isnull(idx),"(UNKNOWN)",idx) | bin _time span=1d | stats sum(b) as b by _time, pool, idx | eval GB=b/1024/1024/1024 | appendpipe [stats sum(GB) as GB by _time| eval b="Daily Total"] | sort + _time
Time based load balancing – Part 2
This is a follow up to my earlier post on the forceTimebasedAutoLB setting for outputs.conf.
There was some discussion (read: prove it to me) on the IRC channel about how would this feature behave with multi-line events or double byte characters. Well, you will be glad to know it worked flawlessly.
My events are from a Japanese Windows instance:
I sent over 500,000 events using the oneshot command from the UF.
And it worked as expected.
Lastly, there was some talk about data munging. Meaning part of one event being incorrectly added to another event. This can happen when Splunk doesn’t break a multi-line event proper. In my test, I didn’t even setup a BREAK_ONLY_BEFORE or LINE_BREAKER rule on the …
Time based load balancing
*** As of Splunk 6.5, using forceTimebasedAutoLB is no longer recommended. I recommend using EVENT_BREAKER (props.conf) going forward ***
Just found out about another cool feature that apparently has been in the product a while. By default, the Universal Forwarder can only load balance between indexers when it is safe for us to cut over the data stream. Meaning, to avoid half an event going to one server and the other half going to another server, we have to wait for a safe place to break. When reading a file this can only be done when we hit EOF. For TCP, it’s when we don’t get data on a port for 10 seconds. Over the long run, all the indexers …
Testing alerts using local SMTP server
When setting up alerts that send emails, I find it nice to be able to send the sample alerts to a local SMTP server. It’s useful for testing my thresholds and to rule out spam or mail routing rules. Luckily for us, the Python shipped with Splunk also comes with smtpd.py, which is very easy to setup.
Using a terminal, run the following from the $SPLUNK_HOME/bin directory:
./splunk cmd python -m smtpd -n -d -c DebuggingServer localhost:2500
Setup your alert as you normally would. You can put in anything for the email as the email won’t actually be sent anywhere.
You should now see the message in …
Working with old data
This has tripped up a few people (including myself) in the last couple of weeks, so I figured it would be worth pointing out. If you are working with old data (>5 years), you need to let Splunk know. The default value of MAX_DAYS_AGO (props.conf) is 2000 days, which works out to little over 5 years. If you use the preview feature of Splunk, you can see the issue right away.
But of course, thinking I was an Über Splunker, I bypassed the preview and spent the next 20 minutes trying to figure out what I did wrong. So let that be a lesson, use the data preview feature!…
Splunk Enterprise & Hunk for Hadoop at Cisco Labs
At the end of October, Splunk announced the release of new product called Hunk: Splunk Analytics for Hadoop. Once you get over the awesome name, you realize how much of a game-changer it is to give individuals across the organization the ability to interactively explore, analyze and visualize data stored natively in Hadoop.
(Admittedly that sounds like marketing, but in this case it’s also true.)
At the recent Strata Hadoop World conference, the Cisco Labs team showcased best practices for rapidly deploying Big Data clusters with predictable performance and massive scale using Cisco Nexus, UCS and other tools – including Splunk Enterprise and Hunk.
The Cisco Labs team is tasked with evaluating the infrastructure challenges associated with Hadoop deployments …
CLI sparklines? Yea we got that!
The lunch table at Splunk is an odd place. Sometimes you can have a 45-minute discussion about bananas (I regret having missed out on the Gros Michel), other times you learn about stealth features in Splunk. Did you know you can create sparklines on the CLI?!? I didn’t either!
Thanks Mitch! …
I don’t use the streamstats command very often, but last week I ended up using it for a customer and finally realized how powerful it is:
The use case was to figure out when a DHCP IP lease address changed for a MAC address. I don’t have access to the real data, so I mocked some up:
Notice for the 54:00:00:00:00:00 MAC address there are 3 changes to the IP address:
Using streamstats and a few cleanup commands, I can quickly see when those changes occur:
source=/Users/kbains/Desktop/dhcp.csv 54:00:00:00:00:00 | head 10 | streamstats current=false last(DHCP_IP) as new_dhcp_ip last(_time) as time_of_change by MAC | where DHCP_IP!=new_dhcp_ip | convert ctime(time_of_change) as time_of_change | rename DHCP_IP as old_dhcp_ip | table …