OpenMetrics project accepted into CNCF Sandbox | Hacker News Reader

OpenMetrics project accepted into CNCF Sandbox

opensource.googleblog.com

29 pointsngaut7 comments

Can someone explain to me, what the pros/cons of this are as opposed to OpenTracing?

EDIT: Tracing deals with annotating methods, and how long they take. E.g. function a took 3 seconds, and make 2 DB calls that took 1.4 seconds. Metrics deal with how many times you made calls, how long they took, etc. So two importantly related parts of application monitoring.

Metrics is different to Tracing in this case. From the surface (or from someone who doesn't closely follow), OpenCensus contains metrics and tracing (and maybe more).

OpenMetrics appears to be the standardising the metrics part, hence the sentence that OpenMetrics is being integrated with OpenCensus.

Now, you might ask, because I've also asked: what are the pros/cons of Census over Tracing for tracing purposes?

It does look like both standards compete and perhaps diverge. I once sensed a bit of bashing of the latter in the OpenCensus Gitter channel; which convinced me to just stay with OpenTracing as they already had more integrations at the time.

At least Metrics is being promoted by the same interests as those working on Census, so we won't see another set of standards targeting the same applications (LightStep, StackDriver, etc).

In short, why can't OC and OT combine their efforts?

Well, actually that's what I'm mainly interested in - what the technical differences between OpenTracing and the tracing part of OpenCensus are.

Excuse me for my badly worded question.

However, why they can't combine their efforts:

Probably a lot of infrastructure is built on both of them, having the aforementioned potential technical differences, which could make any unification backwards incompatible, as in: traces produced by the unified standard wouldn't be parsable by todays infrastructure tooling of the companies using them.

There may also be different tradeoffs chosen, which again boils down to the question regarding the technical differences.

The thing is that they both target similar applications. Zipkin has been around for years, and as both support sending data to it, surely there's enough common ground. I understand what you mean regarding infra, but I think the parties could work towards unity in future.

gRPC supports OpenCensus for example, I recall that OpenTracing has been working on an RPC for reporting traces. gRPC by being the RPC framework, it would make sense if it could self-report to OT in addition to OC.

I work on Jaeger at Uber. In short, OC is not a standard, OT is a standard. It's like asking what is the difference between HTML5 and a web browser. HTML5 is a standard for developers to use when developing web pages, allowing rendering on a number of different web browsers, whereas a single browser constitutes a single implementation. At the moment, OpenCensus is like a web browser not accepting HTML5 and demanding web developers adopt a custom markup language. If they would adopt the OpenTracing API, developers could instrument an application once, and switch between Jaeger and OpenCensus with no changes in the code. Clearly, I am biased against this approach as I have spent considerable time working with the OpenTracing project to make it the de-facto tracing API and OpenCensus is kind of breaking that.

About OpenCensus, "Open" seems to mean open source and census was the original name internally at Google (there is evidence for this in gRPC git history where it was just census). Anyway, we are waiting on OC to adopt OT, but they don't seem to be interested at the moment.

The blog post mentions that OpenCensus supports .NET, but on https://opencensus.io/language-support/ .NET is not mentioned. What is true? Has anyone used opencensus with .NET ?

Google accepted spam comment on their blog :D

https://opensource.googleblog.com/2018/08/openmetrics-projec...

Reply on news.ycombinator.com