From the outside looking in, this proposal seems to assume
monitoring/metrics are similar enough to APM traces that they can and should converge in a
single collection system. Whereas I would have expected the proposal was to combine the in
the presentation/UI *after* collection. Am I misunderstanding? Because I would have
thought the characteristics of these systems would be unique enough to stay separate, e.g.
the traffic rates for metrics vs traces would be different, the ‘schema’ of what needs to
be forwarded and stored is different, and for sure the APM traces need to be correlated
based on their trace IDs and otherwise filtered based on somewhat arbitrary tags supplied
in the instrumentation.
On Feb 27, 2017, at 8:58 AM, John Mazzitelli <mazz(a)redhat.com>
wrote:
> *b) I think it would make sense to always use the Prometheus protocol (and
> Hosa may learn how to use the more efficient binary protocol)
If you are referring to the Prometheus binary exposition format [1] (aka content type of
"application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily;
encoding=delimited" as opposed to "text/plain"), HOSA already supports this
- it can read any Prometheus endpoint that exposes metric data in either the text or
binary format.
See the source code [2] and a test [3] that shows this working.
[1]
https://prometheus.io/docs/instrumenting/exposition_formats/
[2]
https://github.com/hawkular/hawkular-openshift-agent/blob/master/promethe...
[3]
https://github.com/hawkular/hawkular-openshift-agent/blob/master/promethe...
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev