tignaj
Joined 7 years ago
Karma
47
Submissions
20
Member since
Aug 18
Recent submissions
Comment · 4 months ago
Is ourcommons.ca an official House of Commons website? It says so but how do I verify before I submit the petition with my information?
Comment · 10 months ago
If you are looking for a fast format with schema support see STEF: https://www.stefdata.net/
Disclosure: I am the author.
Comment · 1 year ago
Here is a fairly efficient version of a simple union like that I did a while back https://github.com/tigrannajaryan/govariant
Comment · 3 years ago
This is also because Google's Protobuf implementations aren't doing a very good job with avoiding unnecessary allocations. Gogoproto is better and it is possible to do even better, here is an example prototype I have put together for Go (even if you do not use the laziness part it is still much faster than Google's implementation): https://github.com/splunk/exp-lazyproto
Comment · 3 years ago
Otel logs aim to record the execution context in the logs.
In languages when the context is implicitly passed (e.g. via thread-local storage / MDC in Java) Otel automatically injects trace id and span id in the logs emitted using your regular logging library (e.g. log4j). Then in your log backend you can make queries like "show me all log records of all services in my distributed system that were part of this particular user request".
Disclosure: I am an Otel contributor, working on logs (work-in-progress, not for production use yet).
Comment · 4 years ago
This. The statelessness of the OTLP is by design. I did consider stateful designs with e.g. shared state dictionary compression but eventually chose not to, so that the intermediaries can remain stateless.
An extension to OTLP that uses shared state (and columnar encoding) to achieve more compact representation and is suitable for the last network leg in the data delivery path has been proposed and may become a reality in the future: https://github.com/open-telemetry/oteps/pull/171
Comment · 4 years ago
Here is a OneOf Go implementation I wrote that hopefully is less ugly and is significantly faster: https://github.com/splunk/exp-lazyproto#oneof-fields
Comment · 4 years ago
Article author here, good to see it on HN, someone else has submitted it (thanks :-)).
If you are interested in the topic you may be also interested in a research library I wrote recently: https://github.com/splunk/exp-lazyproto, which among other things exploits the partial (de)serialization technique. This is just a prototype for now, one day I may actually do a production quality implementation.
Comment · 5 years ago
Please submit a bug at https://github.com/open-telemetry/opentelemetry-go/issues
We want to make the SDKs rock-solid.
Comment · 6 years ago
Here is the draft plan for logs: https://github.com/open-telemetry/opentelemetry-specificatio...
Logs are not going to be part of OpenTelemetry 1.0 release (only traces and metrics will). Logs are coming later (no specific timeline yet).
Disclaimer: I work on OpenTelemetry spec and wrote most of the linked doc. Comments/issues/PRs welcome in the repo.
Comment · 6 years ago
Disclaimer: I work on OpenTelemetry spec.
Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858
It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id
Comment · 6 years ago
Disclaimer: I work on OpenTelemetry specification and Collector.
I don't contribute to Go implementation but I encourage you to submit the feedback to https://github.com/open-telemetry/opentelemetry-go or https://gitter.im/open-telemetry/opentelemetry-go
You can also attend Go SIG meetings and provide the feedback directly. SIG meetings are open for attendance: https://github.com/open-telemetry/community#special-interest...
I am sure the Maintainers of Go implementation will appreciate your feedback.
Comment · 6 years ago
Disclaimer: I work on OpenTelemetry specification and Collector.
It is true that the spec and libraries have been changing. This is to be expected since we haven't yet made a stable release. We are aiming for 1.0 GA release this year. The current plan is to freeze trace spec this week, followed by metric spec freeze in 3 weeks, followed by the release of several language implementations in 4 weeks after the spec freeze.
Like everyone else I wish we could release earlier, but the reality is that making dozens of companies agree on a standard takes time. I am very excited that we are approaching the finish line.