Clarify mapping related to logging

Hello,

For logging from some of our applications we produce a log line that is ISO8601 Date (microsecond + tz), log level, thread id/name, file, function, line number, message. This provides information about where in our code the log message originated, any thoughts on where/how to map these items into ecs?

From this line it seems like the mapping would be as follows optionally logging the original to log.original. date/time to @timstamp log level (think syslog facility) to log.level thread id/name to ?? file to ?? function to ?? line number to ?? message to message

If process.tid and process.thread (or equivalent) are added, I can see those being used for thread id/name.

Thanks!

[bmagistro]

Thanks for the input. I think I have gotten our common logs (auditd, secure, messages, nginx, apache, and some of our apps) mapped in at a very basic level. With in the log section, we added path that would map to filebeat “source”. For the app log described above, leveraging error.function and adding a “line” to file seemed to make the most sense. I would like to get a little more run time but would be happy to share the logstash filter file for this if anyone is interested. I am very certain that we can be doing MUCH more parsing than we are in some logs.

[webmat]

Hey @bmagistro, I’ll close this for the time being, as it looks like everything has been answered.

Please open other issues if you have further questions, or if you’ve faced problems and would like to contribute ideas to ECS.

Thanks for getting in touch!