The Last Updated At column in the ApsaraMQ for Kafka console shows the timestamp of the most recent message in each partition. When the column displays 1970 or --, one of the following causes applies.
Symptoms
The Last Updated At column for topic partitions shows an unexpected value:
| Displayed value | Meaning |
|---|---|
| 1970 | The partition timestamp defaults to the Unix epoch (January 1, 1970) because the stored timestamp is zero or missing. |
| -- | The console cannot retrieve a timestamp for the partition. |
Causes
"1970" is displayed
| Cause | Details |
|---|---|
| Empty or fully expired partition | No valid messages exist in the partition. The timestamp falls back to epoch zero (January 1, 1970). |
| Outdated Kafka client | Client versions earlier than V0.10.2 do not populate the timestamp field. Messages produced by these clients carry a zero timestamp. |
| Null timestamp from the producer | The producer explicitly passes null as the message timestamp. The broker stores this as epoch zero. |
"--" is displayed
| Cause | Details |
|---|---|
| Local storage is used | The open source Apache Kafka API does not support the local storage option. The console cannot retrieve the timestamp, so it displays "--". This is expected behavior for partitions that use local storage. |
| Cloud storage cache expired | With cloud storage, the last update time is cached. If no new messages arrive in the partition for an extended period, the cache expires and "--" appears. |
Solutions
Upgrade an outdated Kafka client
Upgrade the client to V0.10.2 or later.
Fix a null timestamp from the producer
Check the producer code and pass a valid timestamp instead of null.
Resolve "--" for local storage or expired cloud storage cache
When local storage is used, "--" is the expected display because the open source Apache Kafka API does not support the local storage option.
In either case, query information about the message to view the point in time when the message was produced.