CryoThrust commented on issue #12685: URL: https://github.com/apache/seatunnel/issues/12685#issuecomment-6138913810
For the separate realtime-metrics follow-up mentioned above, I checked current `dev` (`b0f6fedd`). A narrow CLI slice could reuse the existing vertices/edges responses and report **bottleneck candidates with evidence**, without changing the runtime metrics contract or taking on the dedicated UI work in #11352. The boundaries I would use are: - Treat missing endpoints, an empty job response and `enabled: false` as unavailable evidence. `getJobVertices` / `getJobEdges` return an empty map for an unknown job, and an empty series with `enabled` for a known job with no store; an empty list must not mean “healthy”. Keep checkpoint/job diagnosis working independently. - Compare distinct, completed buckets in the intersection of the two responses' windows, matched by `ts`, and exclude the current partial bucket. The collector runs every 5 seconds, while `bucketMs` is configurable, so repeated reads are not additional samples. Require several usable buckets before calling pressure persistent. - Correlate an edge's `targetVertexId` with the downstream vertex, while retaining its `queueId`. Several physical queues may share a target; do not collapse them into one edge. Persistent high `bpRatio` plus `queueFillRatio`, together with downstream busy/write evidence, can identify a candidate worth checking. - Describe high `sourceReadRatio` cautiously: synchronous downstream work can execute inside `pollNext()`. Without an isolating async boundary, it does not establish that the source itself is slow. Likewise `sinkBusyRatio` covers `write()`, while prepare/commit durations have separate fields; low write busyness does not rule out commit pressure. - Start with pure fixture-based rules: transient spike vs sustained pressure, missing/partial buckets, idle upstream, multiple queues sharing a target, disabled observability and commit-only sink time. Keep recommendations generic and display the measured window/sample count. Would this fit the intended follow-up after #12688? If you are already implementing that CLI slice, I can help with the contract fixtures and review instead. This is a source-checked design outline, not a live-cluster reproduction or a new implementation claim. -- 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]
