#not really, tl;dr we're at a point where
1 messages ยท Page 1 of 1 (latest)
sorry, a couple random questions for this ๐
- have you tried using OTEL metrics? have heard various... not positive reviews of them, but potentially quite interesting. buildkit is also starting to add quite a few integration points with these (measuring file transfer time, etc)
haven't tried yet but it's in the cards! I remember you bringing metrics up as something that'd be cool to see in Cloud, and agree
(like CPU/RAM/etc)
- how feasible does it seem to plug the honeycomb stuff currently we're using to https://github.com/dagger/dagger/pull/6492
(and have it integrate through deep into the dagger stack)
aha yes, currently this is not connected into traces, it only makes it into the buildkit history api, but theoretically wouldn't be a huge amount of work to change that
hitting a parse error on this question, but I've been emitting to Honeycomb while testing, if that helps answer: https://ui.honeycomb.io/dagger/environments/experimental/datasets/dagger-cli/home
I've prioritized making it easy to configure on the CLI side without having to touch the engine; it'll proxy data out from the engine, through to the CLI (which it already has to do for the TUI), and then to the CLI's locally configured exporter, set with the standard OTEL_ env vars
ah sorry, i mean the current github actions scraping we're doing with https://ui.honeycomb.io/dagger/environments/experimental/board/rwVFwnnSCqy/GitHub-Actions-Workflows
it could be really nice if the steps that call dagger could potentially call through the dagger otel stack
right right, like basically having everything show up in this span?
yes ๐
if it's doing "standard otel things" (setting $TRACEPARENT, $OTEL_) it should just work
aha, awesome ๐
thanks for indulging me for a moment!