Add sub-interface LogDescriptor.LogLine (and the extension to WebServerAccessLogLine), the first interface will simply provide one method that returns a line from the log.
LogDescriptor will need to be extended to provide all LogLines, which includes sub-interface specific parsing and retrieving the unrecognized lines up to a limit (100 for a start).
Sub-interface WebServerAccessLogLine, which extends LogLine, is more specific for access-logs and provides methods for all fields that contain useful data after the sanitation process, i.e., it doesn't provide all Apache log fields.
(cf. discussion in #22983 (moved))
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
we discussed today that limiting unrecognized lines to 3 or 10 would be sufficient, and
we didn't conclude on restricting the API to the fields varying in sanitized logs yet. However, after giving this some thought I'd say that we can indeed restrict the API for now and add new methods later if we need them. What we should not do is reject log lines with fields that typically do not vary in sanitized logs. But not providing getters for those fields sounds okay to me.
The first step is to provide the interface definitions and extensions based on the latest branch in #22983 (moved).
Once everyone is happy with these definitions the implementation will follow.
Trac: Owner: metrics-team to iwakeh Status: needs_information to accepted
Please find some trivial tweaks in commit a4a66b1 of my task-23046 branch. If these look okay, I'll squash and push to master. Setting to needs_revision, but really revision here means looking those trivial tweaks only.