2015-06-30 09:27 AM
Question from partner:
We have a customer who collect windows eventlogs to RSA Security Analytics, they configured a very simple forward rule that will send only one type of eventlog to another system via syslog.
We are trying to add milliseconds to this eventlog , the thing is that when RSA Security Analytics gets this eventlog, it contains milliseconds, but when it send this eventlog via a forward rule it doesn't contain the milliseconds, is it doable?
2015-07-02 10:30 AM
Nfurze,
I'm asking around for you. Stay tuned.
2015-07-02 10:38 AM
Nfurze,
Can you be a little mor specific? What method of log collection are they using? You mention windows collection then you say syslog. Can you detail the log flow?
Thanks
Dave
2015-07-02 01:56 PM
Thanks. I don't have more details but asked the partner to reach out to the customer to gather more information.
2015-07-04 07:10 AM
I think should be fine as long as the field is in the raw log. Mostly you may need use ESI to edit the parser to get the field.
2016-07-29 07:19 PM
If he's talking about decoder forwarding i would think it wouldn't be a problem it should be raw...
If he means time meta (ie: event.time) does not support milliseconds, its 8 bytes that store epoch.
You could try storing time in a Text value instead, but I would be super careful about indexing that (you probably don't want to) but you could then display it. Maybe some options:
1. Create new text meta (event.time.string?) and change the parser/tablemap to store it in there.
2. Leave parser aloneand change table-map to store time into new meta (this would affect all parsers that leverage event.time)
3. Change event.time from time to text type
All of these have consequences (your meta is going to grow larger if event.time is a text value instead of time).
It would be nice to see a new time type that stored more precise time and support in the parsers for zone offset information.