vrto
commented
2 years ago FYI
I have been looking into OpenTelemetry as we can potentially leverage an existing standard for log data. The summary of my findings is available in this document.
From my findings, I think should re-shuffle here a bit. The push towards RED metrics is a useful initiative but is aligned with OpenTelemetry’s Tracing functional component. For Metrics, we should consider whether adopting the OpenTelemetry instruments (counter, measure, observer) is worth adopting.
bobheadxi
Problem to solve
Today, our services do not export uniform metrics. With various implementations and custom metrics, this makes it difficult to interpret what a user is actually experiencing when the metrics are being viewed by an individual, or take any meaningful action if it isn't clear what the metric represents. It's also been noted that custom metrics can be very expensive, which we'd like to avoid.
In order to accurately display what users are experiencing when using Sourcegraph and provide a way to determine service issues more easily, we should export metrics using the RED method.
Measure of success
Solution summary
We will propose a migration of any services not currently using the RED metrics package to provide better information for our users.
Artefacts:
What specific customers are we iterating on the problem and solution with?
Internal Sourcegraph developers, and those teams who consume these metrics most often (Customer Engineering, Delivery, Cloud DevOps).
Impact on use cases
This effort contributes to the company-wide effort to improve Observability.
Delivery plan
Tracked issues
@unassigned
Completed
@bobheadxi: 3.00d
Completed: 3.00d
Legend