GitHub user weiqingy edited a comment on the discussion: [Feature]
Per-Event-Type Configurable Log Levels for Event Log
@xintongsong Thanks so much for the detailed review. You were absolutely right
- the first draft got too bogged down in the implementation weeds. I’ve
reorganized the design document to focus on the high-level concepts,
user-facing interfaces, and expected behaviors. I've stripped out the low-level
code modifications and internal class details.
Here is how I addressed your specific feedback in the updated design:
- Complete Config Options: I added a "Complete Config Key Reference" table that
lists the available configuration keys, their types, and their default values.
- Truncation Strategy: I added a dedicated "Truncation Strategy (STANDARD
Level)" section. It explains the high-level approach (shortening long strings,
trimming large arrays, capping deep nesting) without exposing the internal code
mechanics to the user.
- Config Key Pattern & Full Class Names: I adopted your suggestion. The pattern
is now event-log.<EVENT_TYPE>.level, and it strictly uses the Fully Qualified
Class Name (FQCN) to prevent package collisions. I also noted how this tail-end
property structure allows for future extensibility (e.g., your
event-log.<EVENT_TYPE>.logger example).
- Hierarchical Inheritance vs. Wildcards: Instead of explicit wildcard patterns
like `foo.bar.*`, I implemented standard hierarchical logger inheritance
(similar to log4j). event-log.org.apache.flink.agents.api.event.level: OFF will
silence all events in that package. The root event-log.level serves as the
global default, so no default keyword or explicit .`*` is needed.
- Java vs. Python & Language-Independent Events: I added a specific section
("Migration to Language-Independent Events") addressing this. Since most jobs
today may still be pure Java or pure Python, the initial implementation uses
FQCNs and Python module paths. However, the document now explicitly maps out
how this config structure will seamlessly adapt to plain type strings once the
project moves to language-independent JSON objects.
- Usage Examples: I removed all references to internal classes like
EventLoggerConfig. The usage examples now exclusively show what a user would
actually write: yaml configuration blocks and `flink run -D...` CLI overrides.
Let me know if this high-level direction aligns better with what you had in
mind!
GitHub link:
https://github.com/apache/flink-agents/discussions/552#discussioncomment-15952276
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]