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!

Sending Metrics to Splunk Enterprise With the OpenTelemetry Collector

This blog post is part of an ongoing series on OpenTelemetry. The OpenTelemetry project is the second largest ...

What's New in Splunk Cloud Platform 9.0.2208?!

Howdy!  We are happy to share the newest updates in Splunk Cloud Platform 9.0.2208! Analysts can benefit ...

Want a chance to win $500 to the Splunk shop? Take our IT Incident Management Survey!

  Top Trends & Best Practices in Incident ManagementSplunk is partnering up with Constellation Research to ...