beryllw opened a new issue, #3676: URL: https://github.com/apache/fluss/issues/3676
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Description #### Motivation We use the table-level lake tiering metric tierLag to derive the time of the last successful lake tiering for a table. However, tierLag is a derived value, and reconstructing the actual tiering time from it requires two subtractions on two different clocks: 1. On the CoordinatorServer, tierLag is computed as coordinatorNow - tieredTime when the metric is reported. 2. On the frontend (dashboard/monitoring), the tiering time is then reconstructed as frontendNow - tierLag. #### Solution: Add a new table-level gauge lastTieredTime under the lakeTiering_table scope that directly reports the raw timestamp (milliseconds since epoch) of the last successful tiering round, i.e. the tieredTime already tracked in LakeTableTieringManager.LastTieringResult.Semantics (consistent with tierLag): 1. For a newly registered table that has never completed a tiering round, report the table registration time. 2. Report -1 when the table is no longer tracked. ### Willingness to contribute - [ ] I'm willing to submit a PR! -- 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]
