Getting Data In

How to configure props.conf to set specific Datetime-configs on specific sources/sourcetypes from specific hosts?

tweaktubbie
Communicator

I have an issue with two servers with WebSphere logs that have an overriding different timezone setting in the jvm. Other servers don't have an issue. To prevent wrong interpretation of timestamps, I want to add to the props.conf something like:

  1. using specific hosts [host::server1|server2] ór based on the logfile [source::/opt/data/WebSphere/logs/log.log]
  2. DATETIME_CONFIG=NONE

But you can't of course somehow filter host AND source/sourcetype. Using only host would make other (performance/OS) events useless and unreliable; using only source would affect all the other logfiles from multiple other servers.

It's not only datetime related; I also'd like to be able to break_only_before/after some logfiles from specific host (think like, some end with <END>, other must be broken before datetime)

So in general is the question: how can you use some local props.conf settings for specific sources/sourcetypes on specific hosts?

0 Karma
1 Solution

javiergn
SplunkTrust
SplunkTrust

This is what I would do:

  • For those servers that have an issue modify your inputs.conf and rename the sourcetype on those stanzas currently reading your WebSphere logs to something like: MyPreviousSourceTypeName-Host1 and MyPreviousSourceTypeName-Host2
  • Use the new sourcetypes to filter out in your next hop (heavy forwarder or indexer) and do two things: apply the time configurations you want to apply and rename the sourcetype back to whatever it was before.

Let me know if that makes sense.

Some quick instructions on how to rename a sourcetype before indexing:

props.conf:

[MyPreviousSourceTypeName-Host1]
TRANSFORMS-wrongTimeSourcetypeFix1 = set_sourcetype_back_WebSphere

[MyPreviousSourceTypeName-Host2]
TRANSFORMS-wrongTimeSourcetypeFix2 = set_sourcetype_back_WebSphere

tranforms.conf:

[set_sourcetype_back_WebSphere] 
FORMAT= sourcetype::MyPreviousSourceTypeName
DEST_KEY = MetaData:Sourcetype 

View solution in original post

0 Karma

javiergn
SplunkTrust
SplunkTrust

This is what I would do:

  • For those servers that have an issue modify your inputs.conf and rename the sourcetype on those stanzas currently reading your WebSphere logs to something like: MyPreviousSourceTypeName-Host1 and MyPreviousSourceTypeName-Host2
  • Use the new sourcetypes to filter out in your next hop (heavy forwarder or indexer) and do two things: apply the time configurations you want to apply and rename the sourcetype back to whatever it was before.

Let me know if that makes sense.

Some quick instructions on how to rename a sourcetype before indexing:

props.conf:

[MyPreviousSourceTypeName-Host1]
TRANSFORMS-wrongTimeSourcetypeFix1 = set_sourcetype_back_WebSphere

[MyPreviousSourceTypeName-Host2]
TRANSFORMS-wrongTimeSourcetypeFix2 = set_sourcetype_back_WebSphere

tranforms.conf:

[set_sourcetype_back_WebSphere] 
FORMAT= sourcetype::MyPreviousSourceTypeName
DEST_KEY = MetaData:Sourcetype 
0 Karma

tweaktubbie
Communicator

Ah, that indeed is a nice approach I hadn't thought of, also handy for other purposes!

Only one thing I forgot to mention which now comes to mind: I use a deployment server to use a generic configuration on all WebSphere servers. From what I read, precedence should work fine with your solution, if the default etc/apps/websphere app is overruled by inputs.conf with an alternative sourcetype in an app in /etc/apps/(anything starting with a-v) configured.

Thanks a lot for thinking along!

0 Karma
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...