Hi Pieter, Welcome to the Metron community.
The logic used by the CEF parser right now is to populate the timestamp field as follows: 1. if the rt field exists, use that. 2. if there is a field matching the syslogTime pattern (either the old pattern of 5424) 3. If neither are present, it uses current system time (as a last resort) You can use stellar fieldTransformations after the fact to change the timestamp field to map to anything you like, including any parsed field. The field type is ignored in custom fields from CEF, since type is not a required construct in the Metron JSON object, so we just take the corresponding label field and map the value to that, since the Metron schema is more flexible than the CEF schema. I can see there may be edge cases where this could create a collision, and would be interested to hear about your use case around this, and any problems that approach might cause, but it seems to have worked for most people so far. Simon On Mon, 17 Dec 2018 at 15:38, Pieter Baele <[email protected]> wrote: > Hi, > > For correlation & profiling the presense of a correct timestamp / > eventtime is important, > what to do with a device implementing CEF output, but not properly > providing the rt field? > Also syslogTime is not parsed by the CEF parser. > > There is another field present, how can I assure this field is taken as > timestamp for further analysis and ingest in ES and HDFS? > > Also, is it not necessary to have the type of a field set during (CEF) > parsing (maybe I am missing something there) > > Sincerely > Pieter > > > > -- -- simon elliston ball @sireb
