-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faro Exporter structure #24
Conversation
exporter/faro_translator.go
Outdated
|
||
type faroTranslator struct{} | ||
|
||
func (t *faroTranslator) TranslateMetrics(_ context.Context, _ pmetric.Metrics) ([]faro.Measurement, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
faro.Measurement is not metric if I'm not mistaken, it is custom signal that is ingested into Loki as log record
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm OK - leaving it out of the exporter currently, since structure-wise it'll probably be a copy of some of the other - what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree 👍
Can we move the translator to it's own package? I'd suggest This will be used by the receiver as well when we add Faro -> OTLP translations. |
OK moved around the packages so it fits that - reminder that the |
) | ||
|
||
type FaroClient interface { | ||
SendPayload(payload faro.Payload) error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think only the SendPayload method should be defined. Because the endpoint accepts faro payload object that contains Logs, Events, Exceptions, Measurements, Traces, etc. I don't think we should split the payload and send all the custom signals separately. Wdyt? Or we can keep the current skeleton, merge it, and tweak its methods later during the implementation
No description provided.