Conversation
|
Hi @smalyshev, I've created a changelog YAML for you. |
64e1a9a to
6491a80
Compare
consulthys
left a comment
There was a problem hiding this comment.
Thanks for the updates.
Added some comments
server/src/main/java/org/elasticsearch/common/logging/activity/ActivityLogProducer.java
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/common/logging/activity/ActivityLogProducer.java
Outdated
Show resolved
Hide resolved
| @Override | ||
| public ESLogMessage produce(EqlLogContext context, ActionLoggingFields additionalFields) { | ||
| ESLogMessage msg = produceCommon(context, additionalFields); | ||
| msg.field(ES_FIELDS_PREFIX + "query", context.getQuery()); |
There was a problem hiding this comment.
Since ES_FIELDS_PREFIX is elasticsearch.activitylog. I feel these search-specific fields should go into another sub-section dedicated to search if in the future we were to add more non-search-related activities. Makes sense?
Thoughts @jimczi ?
There was a problem hiding this comment.
Not sure if having query in separate places for different modules is beneficial, but it's possible to do, please tell which one is preferred.
There was a problem hiding this comment.
My point is that the elasticsearch.activitylog. is not about search/query activities specifically. If the activity logs get extended at some point to also include other non-search activities, all the search-specified fields (i.e. took, took_ms, query, indices, etc) should be in their own sub-section (e.g. elasticsearch.activitylog.search.took, etc)
There was a problem hiding this comment.
OK I see what you mean here, but I am not sure how to better configure this space. "search" name would be confusing, as there's separate module "search". So the question is - do we want to have separate section for each module (despite a lot of info being common between them) or we have a section for all "searching/reading/querying" modules and potentially another section for "indexing"?
I think we need to discuss it more in detail, but I don't want to hold this patch for this - I think after we figure it out we'd do a followup if necessary?
| @Override | ||
| public ESLogMessage produce(EsqlLogContext context, ActionLoggingFields additionalFields) { | ||
| ESLogMessage msg = produceCommon(context, additionalFields); | ||
| return msg.field(ES_FIELDS_PREFIX + "query", context.getQuery()); |
There was a problem hiding this comment.
Same comment as for EQL above and having another sub-section dedicated to search
| @Override | ||
| public ESLogMessage produce(SqlLogContext context, ActionLoggingFields additionalFields) { | ||
| ESLogMessage msg = produceCommon(context, additionalFields); | ||
| return msg.field(ES_FIELDS_PREFIX + "query", context.getQuery()).field(ES_FIELDS_PREFIX + "rows", context.getRows()); |
There was a problem hiding this comment.
Same comment as for EQL above and having another sub-section dedicated to search
server/src/main/java/org/elasticsearch/common/logging/activity/ActivityLogger.java
Outdated
Show resolved
Hide resolved
| ); | ||
|
|
||
| List<? extends ActionLoggingFieldsProvider> slowLogFieldProviders = pluginsService.loadServiceProviders( | ||
| List<? extends ActionLoggingFieldsProvider> loggingFieldsProviders = pluginsService.loadServiceProviders( |
There was a problem hiding this comment.
Should we rename ActionLoggingFieldProvider to ActivityLoggingFieldProvider for consistency?
There was a problem hiding this comment.
Not necessarily, they are not strongly linked - any logger can use ActionLoggingFieldProvider (and slowlogs, while they exist, do still use it).
There was a problem hiding this comment.
Is there a plan to make slow logs an ActivityLogProducer or is it going to remain it's own thing? It'd be nice to just consolidate all these things as "activity logs" and not have slow logs be a one-off.
There was a problem hiding this comment.
That depends on what you mean by "plan". We agree that eventually we'd want all those to merge into the new system, but it's not a high priority right now, though eventually that's where we want to end up. Probably starting with ESQL log, then search slow log, than indexing slow log (indexing is the last because current system doesn't support indexing yet). But we do not have a definite plan of when and who will be doing it. Here's issue for ESQL: #142425 for the rest I don't think it's tracked yet (@naj-h may know more).
There was a problem hiding this comment.
I think we could discuss eventually renaming ActionLoggingFieldsProvider if slow logs go away (which may happen in the future) but it's probably not the time yet for this patch.
There was a problem hiding this comment.
We agree that eventually we'd want all those to merge into the new system, but it's not a high priority right now, though eventually that's where we want to end up.
Yeah, that's good enough for me. Just wanted to make sure we're aligned that we do want to consolidate these.
x-pack/plugin/sql/src/main/java/org/elasticsearch/xpack/sql/plugin/TransportSqlQueryAction.java
Outdated
Show resolved
Hide resolved
...ck/plugin/eql/src/main/java/org/elasticsearch/xpack/eql/plugin/TransportEqlSearchAction.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/common/logging/activity/ActivityLogProducer.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Mark Vieira <portugee@gmail.com>
Co-authored-by: Mark Vieira <portugee@gmail.com>
Co-authored-by: Mark Vieira <portugee@gmail.com>
Co-authored-by: Mark Vieira <portugee@gmail.com>
This patch creates framework for generic action logging, serving search, SQL, EQL, ESQL, etc. Enabling logging:
Will produce search logs in JSON format like this: