add support for metrics and logs#128
Conversation
This change adds support for metrics & logs to the exporter code. The
commits are as follows:
1. add methods to the factory to make the component available for
metrics/logs pipelines
2. add extract methods for logs/metrics
This is also adding a telemetry store alongside the existing trace store. The
idea being the current functionality will continue to work while the
telemetry store is being filled in. In this PR:
- created the `internal/telemetry` package and ended up moving a big
chunk of the existing models in there
- added a telemetry store to the server & exporter
- adding code to generate samples for logs/metrics
- adding endpoints /telemetry & /telemetry/{id}
There's still many details to fill in, but I wanted to get the pieces
in place to fill in the details later, without too big of a PR.
Signed-off-by: Alex Boten <[email protected]>
jmorrell
left a comment
There was a problem hiding this comment.
I like the approach of keeping everything working and building up the new stuff in parallel. I also like keeping the new store logic separate.
The code changes look solid, and I'm generally supportive of this direction if you want to take this and run with it.
My experience is mostly with production code-bases and less open-source, with those biases in mind, if I were to make these changes a big PR like this for high-level feedback would be my first step, and then I'd break it up into smaller PRs and try to bring all of the existing tests along with each change.
I'd probably break this up into something like:
- handle the moving functions and type definitions into the new
internal/telemetrymodule - extend the collector side to receive the new data types, but do nothing with them
- introduce the telemetry store + tests
- hook up the telemetry store to receive data and expose new endpoints
- extend the sample generation code
I understand that's a significant amount of overhead for a tool with users that count maybe in the dozens, so feel free to move forward with this as-is if that's your preference. My main concern is that everything keeps working as it is now so we can make iterative releases if we need to for bugs, and that is handled in this PR.
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
Signed-off-by: Alex Boten <[email protected]>
This change adds support for metrics & logs to the exporter code. The
commits are as follows:
1. add methods to the factory to make the component available for
metrics/logs pipelines
2. add extract methods for logs/metrics
This is also adding a telemetry store alongside the existing trace
store. The idea being the current functionality will continue to work
while the telemetry store is being filled in. In this PR:
- created the `internal/telemetry` package and ended up moving a big
chunk of the existing models in there
- added a telemetry store to the server & exporter
- adding code to generate samples for logs/metrics
- adding endpoints `/telemetry` & `/telemetry/{id}`
There's still many details to fill in, but I wanted to get the pieces in
place to fill in the details later, without too big of a PR.
---------
Signed-off-by: Alex Boten <[email protected]>
This change adds support for metrics & logs to the exporter code. The commits are as follows:
This is also adding a telemetry store alongside the existing trace store. The idea being the current functionality will continue to work while the telemetry store is being filled in. In this PR:
internal/telemetrypackage and ended up moving a big chunk of the existing models in there/telemetry&/telemetry/{id}There's still many details to fill in, but I wanted to get the pieces in place to fill in the details later, without too big of a PR.