Skip to content

branch-4.1: [improvement](streamingjob) change streaming job source log lag in bytes #66409 - #67187

Merged
yiguolei merged 1 commit into
branch-4.1from
auto-pick-66409-branch-4.1
Aug 27, 2026
Merged

branch-4.1: [improvement](streamingjob) change streaming job source log lag in bytes #66409#67187
yiguolei merged 1 commit into
branch-4.1from
auto-pick-66409-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #66409

…tes (#66409)

### What problem does this PR solve?

Issue Number: N/A

Related PR: #62269

Problem Summary:

Streaming job lag was calculated from the current time and the timestamp
of the last consumed event. The value kept increasing when the source
was idle, so it could not distinguish source inactivity from an actual
synchronization backlog.

This change reports source-log backlog in bytes. MySQL-compatible
sources calculate the remaining bytes from the committed binlog file and
position to the current end offset. PostgreSQL calculates the WAL byte
difference from the replication slot confirmed position to the current
WAL position. Snapshot-only jobs report `-1`, and transient lag
calculation failures retain the latest successful observation.

The `jobs("type"="insert")` output renames `Lag` to `LagBytes` and adds
`LastSourceEventTimestamp`. The new field is the Unix timestamp in
seconds of the latest source binlog or WAL event recorded in the job's
committed offset. MySQL-compatible sources use `ts_sec`, while
PostgreSQL converts `ts_usec` to seconds. It is empty before a source
event timestamp is available. The existing formatted
`LastTaskSuccessTime` remains unchanged.

The per-job Prometheus metrics now expose:

- `doris_fe_streaming_job_per_job_lag_bytes`
- `doris_fe_streaming_job_per_job_last_source_event_timestamp_seconds`
- `doris_fe_streaming_job_per_job_last_task_success_time_seconds`

The two timestamp metrics are Unix seconds. A value of `0` means that
the corresponding source event or successful task has not been observed
yet.
@github-actions
github-actions Bot requested a review from yiguolei as a code owner August 27, 2026 02:54
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

FE UT Coverage Report

Increment line coverage 65.22% (60/92) 🎉
Increment coverage report
Complete coverage report

@yiguolei
yiguolei merged commit 32019fd into branch-4.1 Aug 27, 2026
28 of 32 checks passed
@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by anyone and no changes requested.

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Aug 27, 2026
@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by at least one committer and no changes requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants