although this would work technically... this would be a bad idea Reasons: if you add libraries in the native folder... clustered environments would require you to login to every search heads to do this update. you may by mistake break the native folder of splunk where it gets its own libraries.... Support wont be happy with you if they notice unwanted libraries in there. when you upgrade Splunk software that directory gets nuked for the new release... meaning if you forget you may loose all your libraries. To stay a happy admin and deploy quick and keep support on your side. you want to publish a hidden app with the libraries and reference them from there during execution of your code ... if your not familiar with this setup and want more details let me know and i can post a more detailed step to setting it up. ... View more

Hey ebuitweb. if you put your library inside the splunk home... the minute you do an upgrade to Splunk... your libraries would get nuked... also if you have a cluster this would require you to login to every search head and edit the internal splunk home scripts directory... as well you may break the native product looking into that directory.... i would advise if you dont want headaches with support... dont put stuff in there... instead put it inside an app and deploy to the search heads. if you need more granular details about it, let me know and i can post a more granular detailed way to set it up and keep support on your side. ... View more

Best supported way to do this and still have Splunk support on your side. Do not overwrite Splunk native libraries as you could break the product. or even upgrades to the product or your server could break you. What you do is import the library on the fly during execution of your script. Your initial script would do these three lines at the top import sys sys.path.insert(0,'/Path of Library you want to add') import YOURLIBRARY Even better for clustered environments with many search heads out there. Create an App on your cluster master responsible for deploying to the search heads and leave it hidden so it wont show on the searcheads. call your app lets say "prod_searchhead_bin" in there you have the magic folder BIN where you put all you secret libraries. then you command would look like this import sys sys.path.insert(0,'/opt/splunk/etc/apps/prod_searchhead_bin/bin') import YOURLIBRARY then when you publish to the cluster all search heads will comply and have libraries making it a breeze during upgrades/ updates. if you upgrade or move environments. easy to deploy as it is a native app to deploy and make all your much needed libraries available. ... View more

Good question, if your table is small then this is not a problem. if your table is of large size and you want to eliminate full table scans or minimize footprint of your query lets assume your using oracle for a second... most databases have similar perks. you could also check with your DBA about optimizing your search queries as well for best performance. But here are a couple options that come to my mind. option 1 - You could create a materialized view on the database which only holds no more then x amount of time and then have Splunk query the materialized view with or without the index. option 2 - You can create a "function based" index on the regular table and allow Splunk to query the tables normally with its concatenated time field used for filtering which should match the function based index created. basically, the same way you manipulated the field that you are trying to use for filtering could be created as an index. option 3 - if you have no access to the database or its a vendor databases and your trying to query with limited access. in your base sub-query - You could add a second date filter to the original field unmodified that is only date without time and force filter it to less than 24 hours of data. Your Splunk filter will full scan what comes out which is only 24 hours of data in this case instead of full table scan without further indexes available. Example : Select A, B, CD from (Select A, B, A||B as CD from table Where ENTRY_DATE > (select TRUNC(sysdate)-1 from dual) ) as query1 {{ where ... rising...column....}} ... View more

We have this working on production for one of our ingests. (just make sure when you connect the two fields together that they are still in date format for rising column) You cannot do a single query and just connect the fields and alias it as it will not work. somehow splunk gets confused with your alias as it is not real column. bit if you actually query your sub query and call the field as a column. Splunk will in this case think its a regular column and then it can us it for the rising column. This is very similar if you would of created a view on the database and splunk is only aware of the column your calling from the view. It does not know it was made up from logic behind the scenes. ... View more

There is a Way to Trick Splunk with 2 Columns, WRITE a sub query within your query Select A, B, CD from (Select A, B, A||B as CD from table) as query1 CD becomes your Rising Column ... View more