CryoThrust opened a new issue, #12750: URL: https://github.com/apache/seatunnel/issues/12750
### Search before asking - [x] Searched existing issues and PRs. #12685 identifies this as the separate realtime follow-up; #12688 implements its checkpoint-history slice. No separate CLI realtime-diagnosis PR was found. #11352 covers the dedicated UI, which remains separate. ### Description Extend `seatunnel --diagnose <jobId>` with evidence from the retained realtime edge/vertex metrics. Checkpoint history can explain that a running job degraded, but cannot identify which queue/downstream vertex is under sustained pressure. The output should identify a **candidate to investigate**, retaining queue ID, target vertex, measured window and ratios. A source's read time alone must not blame the source, because it can include synchronous downstream work. Sink prepare/commit time must remain visible when write busyness is low. A working prototype is available [as a six-file follow-up](https://github.com/CryoThrust/seatunnel/compare/210e7eb191e36e190cc51f8014bb86edf50c73c4...1f16471da). Its base combines current `dev` (`b0f6fedd`) with the still-open #12631/#12688 changes, preserving their authorship; the comparison shows only this follow-up. This is not a ready-to-merge PR or accepted scope. Proposed initial rules: - Match the endpoints' window intersection, bucket width, timestamps and target vertex. Analyze the latest three distinct, consecutive, completed buckets; exclude partial/conflicting points and preserve each physical queue. - Report persistent queue pressure when all three buckets have `bpRatio >= 0.5` and `queueFillRatio >= 0.8`. Busy downstream sink writes/transform processing provide corroboration, not proof of root cause. Preserve the engine's raw backpressure ratios, including values above one. - Analyze `(sinkPrepareCommitNs + sinkCommitNs) / (bucketNs * subtaskCount)` separately, with the same three-bucket persistence requirement and an initial 0.5 threshold. - Missing/disabled/insufficient evidence is a coverage gap, including a missing queue next to a healthy one. Optional metric failures preserve job/checkpoint diagnosis; only running jobs request realtime data. Are these candidate rules and initial thresholds a useful CLI follow-up? If someone is already implementing this slice, I can contribute the contract fixtures/review instead. ### Usage Scenario A CDC job remains RUNNING with both counters advancing, but its lag grows. With `env.engine.observability.enabled = true`, read-only diagnosis should correlate a full/backpressured queue with work in its downstream vertex, or explain that available metrics cannot establish the cause. No provider/API key is needed. ### Verification Python 3.10 and 3.13 each pass the complete CLI suite: 368 tests plus three subtests, zero failures/errors/skips. Ruff passes. Loopback HTTP tests exercise actual GET paths, terminal rendering, model-free execution and optional endpoint failure. Removing bucket completion/target matching makes the corresponding controls fail; restoring them passes. ```sh cd seatunnel-cli python -m pytest tests -q ruff check . ``` English/Chinese CLI docs are included. Root-only Maven formatting and skip-tests verification pass; no full Zeta build or live cluster verification is claimed. No generation benchmark improvement is expected from a model-free diagnosis branch. ### Related issues #12685, #12688, #12631, #12630. This does not take over #11352. ### Are you willing to submit a PR? - [x] Yes, once scope and the pending diagnosis dependencies are agreed. ### Code of Conduct - [x] I agree to follow this project's Code of Conduct. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
