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
Super Champion

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
Super Champion

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
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Agentic SOC Triage: Investigating Splunk ES Notables with MCP Server and a Local LLM

The Problem: Too Many Alerts, Too Little Context Security operations teams running Splunk Enterprise Security ...

All Work and No Play? Not at .conf26! Unwind at These Evening Events

Between hands-on technical sessions, keynote reveals, and diving into live architectures, .conf26 is packed ...

Join the Hackathon at .conf26 and build a No-Code AI agent

Join us for the AI Agent Buildathon, an in-person, three-hour hands-on Hackathon where you’ll use Splunk Agent ...