I don't believe that using SEDCMD or another transform will allow you to detect the fields from the header, since the header is on the 6th line when the detection takes place. If this is the issue, then you could use CHECK_FOR_HEADER = true with the following: If the files will only be updated every hour, rather than continuously, you can use a scripted input or any scheduler (1x/hr) to place a cropped version of the files in another location. The new location will be the "monitored files" location. MANGLE.SH: #!/bin/bash for i in *.csv; do sed "1,5d" $i >"/monitoredpath/$i"; done This simple script will take all .csv files in a folder and place a corresponding cropped version in /monitoredpath. Use /monitoredpath as your monitored file location. This isn't ideal, but it will even support the case where a new log file is generated of a type not previously seen. And Splunk shouldn't have any issues detecting the changes in the files, even though they are being overwritten every hour -- since new events still appear in the proper place at the end of each file. Here is another thought, though I haven't tested this -- it seems ideal (in theory) and is easy to implement, if it would work: Use a transform to make part of the filename be the sourcetype. Do a one-time index of a location containing just enough data for header detection for each sourcetype -- use a script to generate the header files. Then when the real files are indexed, field detection is already configured based on the sourcetype, so you could use SEDCMD or another transform to crop the top prior to indexing. This method would only support known sourcetypes that we pre-indexed for field recognition. ... View more

AF helps you determine how accurately each field predicts the specified field. As an example, look at the following data: 02/03/2011 01:00,st=CA,state_no=1,vote_no=1 02/03/2011 14:00,st=CA,state_no=1,vote_no=1 02/03/2011 01:00,st=MA,state_no=2,vote_no=2 02/03/2011 02:00,st=MA,state_no=2,vote_no=2 02/03/2011 07:00,st=MO,state_no=4,vote_no=1 02/03/2011 08:00,st=MO,state_no=4,vote_no=1 If you run the following search: * | af classfield=vote_no You can see that there is a 100% chance (1.0) that my state (state_no) will predict my vote (vote_num), by looking at the accuracy field (acc). You can also see that state is always declared for a vote (cocur = 1). The use case here is to determine if we can use the data to predict which state will vote for which candidate and with what accuracy we might make a prediction. This is too small a dataset to make accurate predictions, but given a much more representative dataset, I could, with reasonable confidence, predict that a CA or MO voter will pick candidate #1. HTH ron ... View more

If you want this for the search app, do the following: cd $SPLUNK_HOME/etc/apps/search/appserver/static edit application.css Paste this into the bottom of the file (application.css😞 /* AppBar */ ul.appBarNav li a:hover, ul.appBarNav li a.menuOpen { background: url(/static/img/skins/default/overlay_white_28.png) repeat-x 0 0; _background: url(/static/img/skins/default/backgrounds_ie.gif) repeat-x 0 -727px; } ul.appBarNav li a { font-size: 18px; font-weight: bold; } .AppBar .splMenu-primary ul li.splUserCreated { background-image: url(/static/img/skins/default/splIcons.gif); background-repeat: no-repeat; background-position: -3px -536px; } font-size: 18px is the magic style you want to change. 11px is the default, I believe. Cheers, ron ... View more

This seems like it would display readable dates along the x-axis: sourcetype="p5_reports" | dedup PredictionTime regionID | chart max(Price) over PredictionTime by regionID ... View more

If Splunk doesn't recognize those timestamps, use the following in props.conf: [checkpoint] TIME_FORMAT=%e%b%Y %k:%M:%S Set your sourcetype to "checkpoint" and this will teach Splunk to recognize the timestamps. By the way, there are Check Point apps posted here, if you want LEA integration: http://splunkbase.splunk.com/apps/All/4.x/app:OPSEC+LEA+for+Check+Point+(Linux) http://splunkbase.splunk.com/apps/All/4.x/app:OPSEC+LEA+for+Check+Point+(Solaris) ... View more

You should install the *NIX app on those RHEL servers. The reason for this is that the app provides all the scripted inputs to grab the diagnostics data you will want to track (i.e. lsof, df, top, ps, etc.) without any additional work. My recommendation is to install Splunk on a RHEL server, install the *NIX app, configure the app, ensure the app is operating properly -- you can see the populated dashboards -- then configure forwarding/receiving. Once you confirm the data is being received by your Indexers, convert Splunk on the RHEL server to an LWF: ./splunk enable app SplunkLightForwarder ... View more

Here's a props.conf trick that's used by the *NIX app to consume long outputs as a single entry. A stanza like the following will allow you to consume your entire config file or document as a single event. Be sure to manually set your sourcetype on the Data Input to whatever you use in your stanza (myconfigs in the example): [myconfigs] SHOULD_LINEMERGE=false LINE_BREAKER=(?=!) TRUNCATE=1000000 ... View more