GitHub user xintongsong added a comment to the discussion: [Feature] Per-Event-Type Configurable Log Levels for Event Log
Thanks for preparing this document, @weiqingy. However, this doc is more like a coding plan, which contains lots of implementation details like how to modify each file and how to implement the desired behavior. I think what we need now is a more high-level design, focusing on the definition of concepts, user-facing interfaces and expected behaviors. IMO, the following questions should be clearly answered, some of which seem missing from the current doc (or swamped in the massive implementation details). - What log levels do we support, and their definitions - already mentioned - What config options do we have - some are mentioned, there's no clear complete list - How to specify log level for each class - already mentioned - How to truncate the log when the level is STANDARD - not found, we don't need to expose this to users, but the initial strategy should be described Additionally, I have a few more comments concerning the design: - Config key pattern: - I think we should include the full name of the classes. We may have different events with the same class name from different packages. - Shall we also support patterns like `foo.bar.*`? If we do, then there's no need for `default` and we can just use `event-log.level.*`. - I'd suggest to use the pattern `event-log.<EVENT_TYPE>.level`. Moving `level` to the tail gives us the flexibility to introduce more per-type configs in future. E.g., `event-log.<EVENT_TYPE>.logger` for dispatching the logs to different destinations based on their type. That's how log4j works. - Do we need to differentiate java & python events? We are also thinking about changing the events to language-independent json objects. The purpose is to simplify the custom event definition for users, especially in the cross-language use cases where otherwise users may need to define the same event type in both java and python and deal with the serialization. @wenjin272, please also take a look at this. - Usage Example: `EventLoggerConfig` is an internal class used by `ActionExecutionOperator` to instantiate an `EventLogger. It's in the `api` module because user may implement their custom event loggers and need to read configs from it. Users should never directly build an `EventLoggerConfig`. GitHub link: https://github.com/apache/flink-agents/discussions/552#discussioncomment-15930713 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
