About capnjosh

capnjosh · ‎02-25-2015

Some progress, and possibly some answers. But I'm not sure if I'm at a dead end yet. I created a few VMs and installed Splunk 4.3.3, 4.3.4, 4.3.7, 5.0, and 6.2.1. Then I tried out connecting to each one with Tableau 8.3. Here's the kicker: When Tableau 8.3 connects to Splunk to list the "tables" (saved searches) it calls this URL: https://sp437:8089/servicesNS/admin/-/saved/searches?f=eai%3Aacl&search=disabled%3DFalse&sort_dir=asc&sort_key=name&count=0&output_mode=json In Splunk versions 5.x+ it's happy. In Splunk versions prior to 5.0 it throws an error with this: In handler 'savedsearch': Argument "output_mode" is not supported by this handler. The problem is specifically with the "output_mode=json" part. Splunk 5.0+ handles it while earlier versions are not. I saw some mention in other places that seemed to indicate installing the "xml2json" may fix it. However, just blandly doing so didn't do it for me. Soo.... the problem is now specifically that I need to get the ?output_mode=json bit to work on Splunk 4.x. Has anyone done that?

capnjosh · ‎02-24-2015

I've confirmed I can connect as expected to a trial Splunk 6.2.1 instance (and query it) from the same client that is exhibiting problems when connecting to a Splunk 4.3.3 instance (always throwing "invalid username/password" error). I've made sure the permissions look the same in both instances. I've seen the browsing path is the same on both instances when browsing on port 8089 with a web browser (the links are all the same and I can see saved searches on the 4.3.3 instance just like I can see them on the 6.2.1 instance).

capnjosh · ‎02-23-2015

Does the Splunk ODBC driver work when pointed at a Splunk 4.3.3 server? I'm hoping there is a trick to make it work. I've gone through the various troubleshooting steps to outlined below to get the ODBC driver to connect to Splunk Enterprise 4.3.3 from Tableau 8.3: Made sure the port was 8089 and that there were no firewalls preventing access (tested with telnet and actually browsing to it) Made sure to use https in the connection string Tested with both the 64-bit and 32-bit ODBC drivers. configured the ODBC system DSN to point at the correct URL and use valid username/password (admin-level even). Confirmed the URL and creds used in the SSH can actually log in (browsing to the URL and logging in) Looked at Splunkd logs and I see the following: A new Splunk Connection always results in "Invalid username or password". However, on the Splunk machine in audit.log I can see "user=mytestuser, action=login attempt, info=succeeded][n/a]". And I can confirm functionality by intentionally submitting an incorrect password, noting the audit.log showed "user=mytestuser, action=login attempt, info=failed][n/a]".

capnjosh · ‎02-05-2015

If you could just query the views, that might be easiest. If you're concerned with the size of the table and if a long-running query from DB Connect might block other queries, just make sure you set the database connection in DB Connect to use "read uncommitted"... .and if it's SQL Server set the jdbc flag to use cursors (which I've found seems to prevent any blocking, especially on a large table query).

capnjosh · ‎02-05-2015

You have to filter down to only the specific event types you want before your do any automatic field extractions or "table *" commands. I've hit this problem myself, and you have to prefilter. If you have to filter on extracted fields (or if you have a kv_mode=json in your props.conf), you could remove all but the _raw field and then re-extract all the fields; when you do "table *" after that you should see only fields that actually show up in the results.

capnjosh · ‎02-05-2015

" --your search that filters down to only the event types you want-- | fields + _raw | spath input=_raw | table *" In my experience you have to filter out the event types you don't want right from the beginning. Otherwise, when you do table *, you will get any and all fields that showed up at any point in your piped search. The key is to filter down to the specific event type as early as possible in your search pipes; and before you do any spath or field extractions. For example, if I have a bunch of JSON events, and in order to filter them I have to do "* | spath input=myjsonfield | search Data.eventtype = 33 | table *" in order to show only events of eventtype=33, then that "table *" command will return all fields for all eventtypes. I think that's what is happening in the OP's case. Note, if your sourcetype has a kv_mode=json in the props.conf, it will always return all the fields if you pipe to "table *".

capnjosh · ‎01-16-2015

Try this, if I understand the question correctly (and yes I realize this is necroing an old post, but this post kept coming up in my searches, so I figure it's doing that for others): for the fields you want to ignore in your final output, set the fields to null() that you don't want to show up, e.g. | eval process3a=if(process3<20,null(),process3) | fields - process3 | rename process3a as process3 This should have the effect you're looking for: if there are no rows in the result with a non-null value for process3, then the process3 column won't even show up.

capnjosh · ‎01-16-2015

Create a new field set to the value of the field you may want to get rid of then get rid of that field name, e.g. say the field in question is named "possiblynull" | eval maybenull=possiblynull | fields - possiblynull | rename maybenull as possiblynull This way, if the original field is actually empty, your search results will not end up with it present. In my case, I needed to use rex to extract a "message" field that may or may not be present in an event, but if it was it could be really dirty (since it's user-generated text). However, rex has the side effect of always creating the field you specify, even if there is no actual match in the event. As a result, every search had that rex-extracted field name, which was not desired.

capnjosh · ‎01-13-2015

I had been hitting the same problem: some events had xml that was longer than 5000 characters, and spath wasn't extracting all the fields I knew were in there. Here's how to fix it: Override the spath character limit in $splunk_home%/etc/system/local/limits.conf. My exact edit was to add the below config section to /opt/splunk/etc/system/local/limits.conf (since it wasn't there be default in 4.3.3). I pulled this from /opt/splunk/etc/system/default/limit.conf: [spath] number of characters to read from an XML or JSON event when auto extracting extraction_cutoff = 10000 I copied and pasted my answer from here: http://answers.splunk.com/answers/179968/parsing-very-long-json-lines.html. I hope that's ok. These two Splunk answers were the top 2 in Google searches for, so I figured I'd contribute my solution in case it helps others.

capnjosh · ‎01-13-2015

I had been hitting the same problem: some events had xml that was longer than 5000 characters, and spath wasn't extracting all the fields I knew were in there. Here's how to fix it: Override the spath character limit in $splunk_home%/etc/system/local/limits.conf. My exact edit was to add the below config section to /opt/splunk/etc/system/local/limits.conf (since it wasn't there be default in 4.3.3). I pulled this from /opt/splunk/etc/system/default/limit.conf: [spath] #number of characters to read from an XML or JSON event when auto extracting extraction_cutoff = 10000

Posts	10
Solutions	1
Karma Given	0
Karma Received	10
Member Since	‎07-14-2012

Online Status	Offline
Date Last Visited	‎06-05-2020 02:04 AM

ODBC Driver and Splunk 4.3.3 - anybody able to mak...

Re: ODBC Driver and Splunk 4.3.3 - anybody able to...

Re: ODBC Driver and Splunk 4.3.3 - anybody able to...

ODBC Driver and Splunk 4.3.3 - anybody able to mak...

Re: Best method for working with a large SQL table...

Re: How to dynamically extract fields from Events(...

Re: recommendations for pruning away emptystring-v...

Re: Remove columns that meet a criteria

Re: Can not get rid of a blank field.

Re: Bug in spath ? Not recovering every fields

Re: Parsing very long JSON lines