-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Reporting] Remove EventLog Dependency #124762
[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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should include other fields that can be derived, such as Kibana UUID and maybe @timestamp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | ||
export function registerEventLogProviderActions(eventLog: IEventLogService) { | ||
eventLog.registerProviderActions(PLUGIN_ID, Object.values(ActionType)); | ||
EXECUTE_ERROR = 'execute-error', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -309,19 +309,6 @@ | |||
} | |||
} | |||
}, | |||
"reporting": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally, mappings can never be removed, but in this case this mapping was added and being removed in 8.1 PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 } }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
@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 |
@@ -5,14 +5,14 @@ | |||
* 2.0. | |||
*/ | |||
|
|||
import { LoggerFactory } from 'src/core/server'; | |||
import { LoggerFactory, LogMeta } from 'src/core/server'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file will be removed, hopefully soon: #125011
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]> (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 <[email protected]> (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.