opentelemetry-specification VS zipkin

The OpenTelemetry specification has design and implementation guidelines for how the instrumentation libraries should be implemented. In addition, it provides client libraries (commonly known as SDKs) in all the major programming languages that follow the specification.

You can read a more in-depth and updated status on OpenTelemetry status. A more detailed status of each SDK can be found on OpenTelemetry - Compliance of implementation with the specification.

OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize the way we generate and collect telemetry data. It follows a specification-driven development. The OpenTelemetry specification has design and implementation guidelines for how the instrumentation libraries should be implemented. In addition, it provides client libraries in all the major programming languages which follow the specification.

The OpenTelemetry specification defines a Propagators interface to allow any implementation to establish its own propagation convention, such as W3C TraceContext.

very cool - made me consider the contrasts with token-bucket rate limiting for log collection and stumbled across a interesting discussion https://github.com/open-telemetry/opentelemetry-specificatio...

If you encounter issues with logs not being ingested or exported, double-check your configuration and consult the OpenTelemetry Discussions forum for help and insights from the community.

Well actually. They (python SDK maintainers) argue their implementation is the correct one according to the spec. See this issue thread for example.

https://github.com/open-telemetry/opentelemetry-specificatio...

There are more. This is a symptom of a how hard it is to dive into Otel due to its surface area being so big.

It means that the OpenTelemetry project provides not only a specification to define the contract between the applications, collectors, and telemetry databases, but also a set of APIs, SDKs, and tools like instrumentation libraries (for different languages), collectors, operators, etc. OpenTelemetry is open-source and vendor-agnostic, so the project is not tied to any specific vendor or cloud provider.

Sure, happy to provide more specifics!

Our main issue was the lack of a synchronous gauge. The officially supported asynchronous API of registering a callback function to report a gauge metric is very different from how we were doing things before, and would have required lots of refactoring of our code. Instead, we wrote a wrapper that exposes a synchronous-like API: https://gist.github.com/yolken-airplane/027867b753840f7d15d6....

It seems like this is a common feature request across many of the SDKs, and it's in the process of being fixed in some of them (https://github.com/open-telemetry/opentelemetry-specificatio...)? I'm not sure what the plans are for the golang SDK specifically.

Another, more minor issue, is the lack of support for "constant" attributes that are applied to all metrics. We use these to identify the app, among other use cases, so we added wrappers around the various "Add", "Record", "Observe", etc. calls that automatically add these. (It's totally possible that this is supported and I missed it, in which case please let me know!).

Overall, the SDK was generally well-written and well-documented, we just needed some extra work to make the interfaces more similar to the ones were were using before.

OpenTelemetry is an open-source collection of tools, APIs, and SDKs that aims to standardize the way we generate and collect telemetry data. It follows a specification-driven development. The OpenTelemetry specification  has design and implementation guidelines for how the instrumentation libraries should be implemented. In addition, it provides client libraries in all the major programming languages that follow the specification.

Distributed tracing as a discipline is older than most engineers writing about it think. Google's 2010 Dapper paper, by Sigelman and colleagues, is the canonical reference; Twitter open-sourced Zipkin in 2012 as a Dapper-inspired implementation, and Uber open-sourced Jaeger in 2017 on similar lineage. For most of the 2010s, however, the operational reality was vendor-specific: each APM (Datadog, New Relic, AppDynamics, Dynatrace) shipped its own SDK, and instrumenting an application meant choosing a vendor and accepting that the instrumentation work was, structurally, lock-in.

Distributed tracing systems like zipkin aim to address these challenges by allowing visualisation of flows on environments with a full setup. Code can be traced by using mono-repos with the event names being the same across services. These are techniques to deal with the inability to trace code/flows across systems and while neither of them are as effective as tracing usages of your code, they help drive a balance between decoupling and ease of use.

The standard observability stack includes Prometheus for metrics collection, Grafana for visualization, and AlertManager for notifications. For logging, consider Fluent Bit or Fluentd with Elasticsearch or cloud logging services. Jaeger or Zipkin provide distributed tracing for microservices debugging.

Distributed tracing: This technology follows requests as they bounce between services, showing you exactly where things slow down or break. Tools like Jaeger and Zipkin support OpenTracing standards, and leveraging an OpenTelemetry plugin can make it possible to track requests across different service boundaries without losing the thread.

Getting Started: Use tools like Jaeger, Zipkin, or OpenTelemetry. Focus on critical paths, set smart sampling rules, and align trace data with system metrics.

Logging and Tracing: Use centralized logging and distributed tracing to gain visibility into the flow of requests across microservices. This helps you diagnose issues more effectively and understand the impact of changes. Tools like Jaeger or Zipkin can be integrated with your API gateway to provide detailed tracing information.

Zipkin is an open-source distributed tracing system that helps gather timing data needed to troubleshoot latency problems in microservice architectures. It manages the collection, storage, and querying of tracing data, providing a user-friendly interface to analyze traces.

When choosing distributed tracing tools, considerations include your technology stack, business requirements, and monitoring complexity. Zipkin, SkyWalking, and OpenTelemetry are popular distributed tracing solutions, each with its unique features.

From the perspective of the realization of GraphQL infrastructure, the interesting direction is "Finding". How to find the problem? How to find the bottleneck of the system? Distributed Tracing System (DTS) will help answer this question. Distributed tracing is a method of observing requests as they propagate through distributed environments. In our scenario, we have dozens of subgraphs, gateway, and transport layer through which the request goes. We have several tools that can be used to detect the whole lifecycle of the request through the system, e.g. Jaeger, Zipkin or solutions that provided DTS as a part of the solution NewRelic.

Zipkin is a distributed tracing system used for tracking and analyzing how requests move through complex systems, especially in setups with many interconnected services, known as microservices.