Conversation
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
a2a7ec1 to
f88b4c8
Compare
bwplotka
left a comment
There was a problem hiding this comment.
Thanks!
Added some questions. I propose we offload as much of shared things to client_golang. Then I would focus on migrating only one package, so we can nail the details on API etc.
There was a problem hiding this comment.
- Should we make those internal so it's not imported?
- Can we add some
.gen.gosuffix to make it clear it's generated?
| // defined in this semantic convention registry. | ||
| package metrics | ||
|
|
||
| import ( |
There was a problem hiding this comment.
Shouldn't this be hosted on client_golang?
There was a problem hiding this comment.
If the alternatives are here or client_golang, agreed that client_golang would be better :)
I've added here just while I was playing around with the code. We can definitely move if we're committed to this change.
There was a problem hiding this comment.
FYI: Weaver is moving towards changing their packaging, so Weaver includes default templates and policies in their distribution. We could include prometheus SDK templates and policies there, that way we could just use weaver and nothing else :)
| # ============================================================================= | ||
| # Rule 1: Histogram metrics MUST have annotations.prometheus.histogram_type | ||
| # ============================================================================= | ||
| deny contains metric_violation( |
There was a problem hiding this comment.
ditto - hosting it in client_golang probably make more sense?
There was a problem hiding this comment.
Then we can simply wget this from GitHub URL
| if _, ok := seen[us]; ok { | ||
| continue | ||
| } | ||
| s.metrics.latencySummary.SummaryVec.DeleteLabelValues(us) |
There was a problem hiding this comment.
I agree with lint - why do you want to have SummaryVec explicit? We can skip it.
| } | ||
|
|
||
| // This will initialize the Counters for the AM to 0. | ||
| s.metrics.sent.With(metrics.AlertmanagerAttr(us)) |
There was a problem hiding this comment.
Hm.. have we benchmarked to decided on the final API? Is this fast enough for hot-paths in some Prometheus places? I wonder if there's something to optimize here. I guess supporting WithAlertmanager(string) as an option would be helpful for those cases.
There was a problem hiding this comment.
No benchmarks yet, and agreed we should explore different implementations and compare the results!
Super heavy WIP
Currently, I'm just playing around with replacing our existing internal telemetry with auto-generated instrumentation from OTel Schemas+Weaver
This is related to the consensus we had in previous Dev Summits[1], I just couldn't find the time to work on it yet 😬 .
Yeah, LOC is huge. If this move forwards I'll work on breaking this down, but for now I'm playing around with what's possible