All Apps and Add-ons

Fields parsing issue for tomcat add on

Koushik_Katta
Explorer

Hi Team ,
We have issue with tomcat add on logs , the fields are not parsing properly , if i use sourcetype=tomcatweb.access host=TOMCAT GET NOT xxx.xxx NOT xx.x*0 . In "interesting fields" i had encounteredfields which are not proper example .
ga
t
p_p_id
s_fid
WT_FPC

If i Run query sourcetype=tomcatweb.access host=TOMCAT , i have seen proper fields like
index
eventtype
linecount .

Kindly let me know how to fix this

Tags (1)
0 Karma

woodcock
Esteemed Legend

Not all event logs have the same fields. Usually an index has several different sourcteypes but even within a sourcetype, not all event logs have the same fields. There are a couple of things that might help.

1: If you have installed an app on your Search Head for your data, make sure that you are inside of that app when running your searches.
2: Make sure that the setting just under the TimePicker says verbose mode.
3: Make sure that when you are in the field picker dialog, make sure that the setting just to the left of the search box says All Fields instead of Coverage ....

0 Karma

DalJeanis
SplunkTrust
SplunkTrust

1) I've seen fields like that in Tomcat output. What makes you think they are "not proper example"?

2) NOT can be really a funny thing. Try something like this

sourcetype=tomcatweb.access host=TOMCAT GET 
| eval keepme=if(like(_raw,"%XXX.XXX%") OR like(_raw,"%xx.x%0%"),"N","Y")
| where keepme="Y"

or like this

sourcetype=tomcatweb.access host=TOMCAT GET NOT TERM("xxx.xxx*")  
| eval keepme=if(like(_raw,"%xx.x%0%"),"N","Y")
| where keepme="Y"

3) This part is especially problematic if you are trying to exclude certain IPs.

NOT "XXX.YYY" 

I've been reading up on this recently and I actually don't know exactly what that is going to do, because splunk breaks that "XXX.YYY" into "XXX" and "YYY", checks those, and then checks the combination. However, it MAY only reject that exact combination, and not "XXX.YYY.ZZZ.AAA". If you want all IPs starting with that combination to be rejected, then you need "XXX.YYY*". The example for "xx.x*0" is even more brutal. Unless you want to review a lot of information on how minor and major delimiters are going to affect the search language, it may be better to avoid putting those NOTs on complex matches before the first pipe.

0 Karma
Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...