DPLT-1044 Expose context method for writing custom Grafana metrics #126
Conversation
morgsmccauley
force-pushed
the
DPLT-1044-custom-metrics
branch
from
be3a5d1
to
6bca022
Compare
morgsmccauley
force-pushed
the
DPLT-1044-custom-metrics
branch
from
6bca022
to
2d79627
Compare
There was a problem hiding this comment.
Really neat work! The current implementation ties us to Cloud Watch logs but that is probably fine since we are still using Lambda for now, but later we most likely want to abstract it out with an interface for a more general metrics collection library like Prometheus as you mentioned.
| @@ -254,7 +254,16 @@ export default class Indexer { | |||
| }, | |||
| log: async (log) => { | |||
| return await this.writeLog(functionName, block_height, log); | |||
| } | |||
| }, | |||
| putMetric: (name, value) => { | |||
There was a problem hiding this comment.
Why are graphql, set, and log present in buildFunctionalContextForFunction as well as buildImperativeContextForFunction whereas the new putMetric is only present in the latter?
There was a problem hiding this comment.
Good question. We don't use the functional mode anymore. The place we would potentially resurrect it is to parallelize historical processing. That would be for a scenario where we want to execute against blocks in parallel, accumulating mutations to be run, and then running those mutations sequentially. For that sort of disjointed processing metrics might end up weird.
Still, we should probably add it, or we could remove "functional" mode until it's needed.
There was a problem hiding this comment.
I didn't add it because functional is essentially unused now.
Like you said @gabehamilton, metrics could end up weird in functional because of the deferred execution, unless there is someway to pass the timestamp directly 🤔. Probably not worth spending too much time on this though since it's not really used. Happy to remove it in a follow up PR if everyone agrees.
This PR exposes a new context method (
context.putMetric()) to allow writing of arbitrary metrics to CloudWatch Metrics, and eventually Grafana.The main driver for this change is to expose the 'latest post block height lag' of the Feed Indexer. This requires comparing the latest block height in Postgres/GraphQL, to the latest block height from
api.social.near. To do this we could use a scheduled Lambda, but it would be extremely tailored to this one Indexer. This PR provides the necessary tools to do this within the Feed Indexer itself.After merging and adding the metrics writing to the Feed Indexer, I'll remove the existing scheduled Lambda which writes an incorrect block height lag.