Fields parsing issue for tomcat add on

[Koushik_Katta]

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

[woodcock]

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 ....

[DalJeanis]

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.