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...`cCLI 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]

Reply via email to