Right now a specific custom parser generates a single event type, which has the name of the custom parser.
For the custom text parser, you can define more than one 'root line' regular expressions. Then each of those can parse it's own fields, some unique and some common. In the end the events will all have the same event type, and the columns (fields) of every event will be a merge of the fields from all lines, and therefore some events can have blanks in some columns. You might have noticed that already.
We have thought about allowing the custom parser wizard to define
different event types, either by parsing it as a field from the log (captured in a regex group), or
defining it directly with the root line. But this has not made it to
the top of our priority list yet. We will see if we can work on that in the near future, this would probably be useful for many users.
As far as I can tell, event types are considered equal if they have the same string 'type id'. So if we update the parser to decouple the type id from the custom parser name, you might be able to use similar event types from different parsers in analyses.
