[10:49:48] <claime>	 Hey y'all. I have some question around ECS and indexation. If I understand correctly from https://doc.wikimedia.org/ecs/#field-error-stack-trace and https://doc.wikimedia.org/ecs/#ecs-conventions I need to use error.stack_trace.text rather than error.stack_trace to be able to search on partial matches? Also, I am sending ECS formatted logs containing the orchestrator object but they don't
[10:49:50] <claime>	 seem to be indexed so I can't filter on them. Thoughts?
[14:14:16] <godog>	 no sorry claime nothing comes to mind atm :|
[14:43:15] <claime>	 I'll check in with c.white when he gets in
[15:29:15] <cwhite>	 Hey claime, that is correct.  `error.stack_trace`is set to be not indexed because the keyword type is length-limited and stack traces are usually longer than what keyword can support.  In order to support some form of querying, error.stack_trace.text allows for match queries on the field.
[15:30:09] <claime>	 Cool, thanks, should I duplicate the field, or just use the error.stack_trace.text one?
[15:30:15] <cwhite>	 I refreshed the field mapping so orchestrator object should be useful now?
[15:30:24] <claime>	 checking my dash
[15:30:48] <claime>	 yep, they're now seen as text fields
[15:30:50] <claime>	 <3
[15:31:03] <claime>	 Thanks a bunch
[15:31:23] <cwhite>	 No need to duplicate the field.  error.stack_trace is what's called a multi-field: https://www.elastic.co/guide/en/elasticsearch/reference/7.12/multi-fields.html#_multi_fields_with_multiple_analyzers
[15:53:02] <claime>	 Ah that's what multifield means :')
[15:53:17] <claime>	 So to be completely sure, I put my stack trace in error.stack_trace.text
[15:53:51] <claime>	 (I mean completely sure of what I should do)
[15:58:21] <cwhite>	 No, the log producer should write the stack trace at error.stack_trace.
[15:58:47] <cwhite>	 OpenSearch populates the .text multi-field on the back end.
[16:12:28] <claime>	 Ah, all right, understood.