Initial front-end metrics implementation - #51171
Conversation
|
Site note, but one thing I'd love to be captured in an early PR for this work (mainly for future readers who don't have access to internal documents/discussions), is the strategic impetus for this new system; how it relates to our other metrics systems such as Google Analytics, Amplitude, Firehose; how we migrate to this new system; and what backends it might cover. |
Good call - I'll add more context in the description. |
molly-moen
left a comment
molly-moen
left a comment
There was a problem hiding this comment.
This all seems reasonable to me, just a couple comments!
| * Interface for interacting with a metrics service API. | ||
| */ | ||
| export default interface MetricsApi { | ||
| sendLogs: (logs: object[]) => Promise<Response>; |
There was a problem hiding this comment.
should we define the log type more than just an object?
There was a problem hiding this comment.
I was thinking this could just be a generic JSON object payload; but I guess if we know about some required parameters that the metrics reporter adds (such as device info), this could be defined in a little more detail?
There was a problem hiding this comment.
I opted to just keep this as an object for now for flexibility and to match the backend method signature (which just takes a list of JSON objects to log).
| } | ||
|
|
||
| private fallbackLog(payload: object) { | ||
| console.log( |
There was a problem hiding this comment.
Do we have an idea of how we would handle the case of needing a fallback long term, or is this just for the testing phase? Hopefully we would have alerting if whatever service we were using is down, and we could send logs as a best effort.
There was a problem hiding this comment.
Yeah, this would just be for the experiment/testing phase. This should also only happen if we get an explicit 401 unauthorized from the server. I think long term, yeah we'd just try to send logs as a best effort.
3 participants
Initial implementation for a generic front-end metrics reporter. For now, this isn't used anywhere and isn't hooked up to any backend service, but I wanted to get some initial feedback before moving forward. Quick walkthrough of the new classes:
MetricsApi.ts
MetricsReporter.ts
export default MetricsReporter(new SomethingThatImplementsMetricsApi()))example structure of logs appearing in Cloudwatch (currently reporting to a test log group).
Background/Context
Some context on why this change is happening. We currently have various reporting solutions on the back-end and the front-end, but none currently meet our needs for robust developer-facing debugging. A quick summary of the services we use on the front-end specifically:
Given the issues with New Relic and Firehose, we have been exploring alternatives. The work started by this PR will add a new reporting path that reports client metrics to AWS Cloudwatch, where logs and metrics can be more easily viewed, retained, and visualized. As of the writing of this PR, we are implementing this metrics path as a time-boxed experiment to gather data on its usefulness. As such, we are including mechanisms such as the ability to turn off reporting via experiment flags.
Testing story
Tested locally. Will add unit tests before shipping or as a follow up, once I get some initial feedback.