[Reporting] Remove EventLog Dependency#124762
Conversation
|
Pinging @elastic/kibana-app-services (Team:AppServicesUx) |
| event: { duration, start: start?.toISOString(), end: end?.toISOString() }, | ||
| }; | ||
| const mProperties: Partial<IEvent> = deepMerge(lProperties, timing); | ||
| logger.debug(JSON.stringify(deepMerge(mProperties, properties)), ['reporting-event-log']); |
There was a problem hiding this comment.
This tag controls how users can filter for the event data. Maybe the tag should be something more future-proof than reporting-event-log
There was a problem hiding this comment.
I don't think I'd put log in there, but reporting-event seems appropriate ...
| } | ||
| duration = end && start ? end.valueOf() - start.valueOf() : undefined; | ||
| const timing: Partial<IEvent> = { | ||
| event: { duration, start: start?.toISOString(), end: end?.toISOString() }, |
There was a problem hiding this comment.
This should include other fields that can be derived, such as Kibana UUID and maybe @timestamp
There was a problem hiding this comment.
Since this is an 8.1 blocker, the changes should be kept minimal. Extra fields can always be added later, if they're really needed.
|
I'll leave the code review to the team, but I am on board with no longer storing reporting data in the event log index and using DEBUG level server logs instead. Thanks Tim! |
pmuellr
left a comment
There was a problem hiding this comment.
LGTM; main concern is having us log JSONified strings. I've played a bit with this, with the event log itself, and it's ... not pretty. Especially if you get sent Kibana logs with the JSON layout, as then every quote in the JSONified bit is escaped :-)
| event: { duration, start: start?.toISOString(), end: end?.toISOString() }, | ||
| }; | ||
| const mProperties: Partial<IEvent> = deepMerge(lProperties, timing); | ||
| logger.debug(JSON.stringify(deepMerge(mProperties, properties)), ['reporting-event-log']); |
There was a problem hiding this comment.
I don't think I'd put log in there, but reporting-event seems appropriate ...
| event: { duration, start: start?.toISOString(), end: end?.toISOString() }, | ||
| }; | ||
| const mProperties: Partial<IEvent> = deepMerge(lProperties, timing); | ||
| logger.debug(JSON.stringify(deepMerge(mProperties, properties)), ['reporting-event-log']); |
There was a problem hiding this comment.
I think we should consider making use the second, optional param to the logger methods, which is basically an ECS record. I suspect the fields in the JSONified string are going to be hard to search for, as long as the JSON layout is used for the Kibana logger, it should write the standard (not custom though) fields out.
That might mean changing the string message parameters on these bit, to make them more useful to humans.
I poked around and found this PR which brought some of the "ECS-ish" bits to the Kibana log, which is about the total of my knowledge on this subject. Not clear to me if this would be more useful than the JSONified string, but guessing it could be, at least in some cases ... #96350
| } | ||
| export function registerEventLogProviderActions(eventLog: IEventLogService) { | ||
| eventLog.registerProviderActions(PLUGIN_ID, Object.values(ActionType)); | ||
| EXECUTE_ERROR = 'execute-error', |
There was a problem hiding this comment.
This change is not related to this PR. It's a discovered oversight that should have gone into the first Event Log PR for Reporting.
| } | ||
| } | ||
| }, | ||
| "reporting": { |
There was a problem hiding this comment.
Normally, mappings can never be removed, but in this case this mapping was added and being removed in 8.1 PRs.
pmuellr
left a comment
There was a problem hiding this comment.
The changes (reverts) of the event log LGTM.
I think we should get someone in Core to review - I think the log "meta" param, being ECS-ish, is pretty new, would be good to see someone from Core see it used in practice, in case there's some gotchas. One thing I'm wondering about in particular, is using the kibana object property - perhaps that's something that Kibana itself would want to standardize on, and so maybe reporting instead of kibana would be "safer"? Though I think kibana.reporting would be fine. kibana.user might not be a shape core would want. And actually, looking at that user.name field, there are a bunch of user fields in ECS already. Including top-level user.*, but also client.user.*, server.user.*, source.user.*: see https://www.elastic.co/guide/en/ecs/current/ecs-user.html and https://github.com/elastic/ecs/blob/main/generated/csv/fields.csv
Would also be great to try this out in the Kibana-a-la-cart stuff, so we could try this in cloud, before merging. In case there are some tweaks we'd want for usage in when using viewing logs in cloud.
| export function reportingEventLoggerFactory(eventLog: IEventLogService) { | ||
| const genericLogger = eventLog.getLogger({ event: { provider: PLUGIN_ID } }); | ||
| export function reportingEventLoggerFactory(logger: LevelLogger) { | ||
| const genericLogger = getEventLog(logger, { event: { provider: PLUGIN_ID } }); |
There was a problem hiding this comment.
Why don't we instantiate that directly? The getEventLog function seems redundant in a way.
| const genericLogger = getEventLog(logger, { event: { provider: PLUGIN_ID } }); | |
| const genericLogger = new EcsLogAdapter(logger, { event: { provider: PLUGIN_ID } }); |
@pmuellr Maybe it was a small oversight, but this PR keeps the I also think it's a good idea to have someone in @elastic/kibana-core review this. Initially, I hoped I could customize |
| */ | ||
|
|
||
| import { LoggerFactory } from 'src/core/server'; | ||
| import { LoggerFactory, LogMeta } from 'src/core/server'; |
There was a problem hiding this comment.
This file will be removed, hopefully soon: #125011
|
@elasticmachine merge upstream |
lukeelmers
left a comment
There was a problem hiding this comment.
Initially, I hoped I could customize event.type but in the LogMeta interface, it looks like that field is not touchable. Instead, I have kibana.reporting.actionType
Yeah, this one is not touchable because ECS requires it to be one of a predefined list of values, which is why we enforce it as such in the core typings.
💚 Build SucceededMetrics [docs]Public APIs missing comments
History
To update your PR or re-run it, just comment with: |
lukeelmers
left a comment
There was a problem hiding this comment.
Latest changes LGTM! Thanks for pinging us on this one.
…124762) * [Reporting] Remove EventLog Dependency * calculate duration * use LogMeta interface of core logger * fix ts * rename the debug log tag * clean up return types for testing * remove reporting fields from the event log mappings * unwrap code from iife * add class for log adapter * remove useless factory fn * remove eventLog * user field was meant to be ECS field * duration is nanoseconds * fix nanoseconds application and test Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 87eaa75)
…#125184) * [Reporting] Remove EventLog Dependency * calculate duration * use LogMeta interface of core logger * fix ts * rename the debug log tag * clean up return types for testing * remove reporting fields from the event log mappings * unwrap code from iife * add class for log adapter * remove useless factory fn * remove eventLog * user field was meant to be ECS field * duration is nanoseconds * fix nanoseconds application and test Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 87eaa75)
Summary
Closes #124753
Closes #124649
This PR switches the Reporting Event Log integration to a logging DEBUG messages to the Kibana server logs instead. It preserves the shape of the ECS-compliant objects that previously were stored in the
.kibana-event-log-*index pattern, and uses those objects as "meta" data for the core logger. (The LogMeta parameter was introduced to the logger API in this PR: #96350)Test logs from PDF report:
Test logs from CSV download:
Viewing the Reporting logs in that format requires this logging configuration:
Using Filebeat, the metric data can be indexed into Elasticsearch for aggregations / visualizations, which will be the path (for now) for Monitoring of Reporting.