Expose MillisBehindLatest from GetRecords() call about amazon-kinesis-client

[dosani]

Hi @wushujames,

Thanks for the suggestion. We are considering adding this feature. Would you be able to share how you are planning to use this metric in your application?

Btw, in case you weren't aware, KCL currently sends this metric to Cloudwatch (which may be useful for monitoring purposes).

Thanks,
-Adnan.

[jqr]

I am also interested in this feature, particularly when exposed to the MultiLangDaemon protocol. My use-case is easy enough to explain:

We batch thousands of smaller subrecords into each Kinesis record and we track latency of these subrecords individually, but to track the record itself we're presently using the ExplicitHashKey to the same thing that HashKey is normally set to, but this allows us to use HashKey to store the time of record insertion and compute latency of Kinesis itself while not changing any Kinesis behavior.

This little bit of clever work-around gives us a per-record metadata field and the ability to easily use our own monitoring and alerting systems with extremely low latency. Cloudwatch is more difficult and less effective in this case due to reporting latency and having to query another system for simple data that is actually provided by the underlying API.

There's a way to address most of this in our record encoding format, to add this data in, but by adding it within the Kinesis record we would be required to do another layer of encoding and encapsulation for 1 simple field.

[wushujames]

I only just recently discovered that it is in CloudWatch. Thanks for that.

We have an application that needs to be mostly caught up to "now" before it is allowed to answer API requests. 1 minute back from "now" might be acceptable, 5 minutes might be acceptable, but hours back is unacceptable. This metric would let the application and operations decide when it is "mostly caught up" and when the application is allowed to start servicing requests.

Since this metric is per GetRecords() call, and the GetRecords() calls is per shard, we would have to have some heuristics that examines the MillisBehindLatest value for each shard, and only takes action when all shards have MillisBehindLatest lower than our desired threshold.

[stephenh]

I was looking to get MillisBehindLatest in IRecordProcessor as well, because we want to report it to CW.

The KCL already reports it to CW, but AFAICT it's only reported on the (combined) Operation+ShardId dimension, which means we don't have a single application-wide metric/dimension that we could use for both CW dashboards and auto scaling, e.g. to scale/up down based on MillisBehindLatest.

(Or if I want to put MillisBehindLatest in a CW dashboard, and I've got ~50 shards, I've got to select all 50 lines one-by-one. And then reselect 100-shards if I reshard from to 50 to 100.)

Is there an easy way for KCL to publish MillisBehindLatest both with and without shard id? Or am I overlooking something in CW?

[stephenh]

You have that nice ProcessRecordsInput now, it wouldn't even be a breaking change. :-)

[manango]

The KCL exposes MillisBehindLatest value to the record processor in 1.5.0 release. Thanks everyone for feedback.