We use Ambassador as an API Gateway that receives all the inbound traffic to our kubernetes cluster, and forwards it to the correct application.OpenTelemetry vs OpenTracing A (Real) Example of OpenTelemetryĪt my company, we use the OpenTelemetry Collector to both centralize and distribute traces and metrics for several reasons. The Collector tool specifically acts as a universal middleware application for receiving traces and metrics data of various standards, and forwarding them to various backends in the correct standard that backend expects.
The OpenTelemetry project is building tools to wrangle all these different observability producers and receivers, and make them usable for organizations. These scenarios create a nightmare for observing a whole system. Or, there might be a third-party tool that uses a different standard than the engineering org has decided on. In many organizations many of these tools are deployed in multiple applications. On the metrics side there are Prometheus, Graphite, StatsD, and more. On the tracing side there’s been Jaeger and Zipkin competing for mindshare, and the OpenTelemetry project that attempted to unify those standards. Over the last few years, there has been a proliferation of observability standards in the cloud-native space. This article will walk you through configuring and deploying the OpenTelemetry Collector for such scenarios. It is a powerful tool in a cloud-native observability stack, especially when you have apps using multiple distributed tracing formats, like Zipkin and Jaeger or, you want to send data to multiple backends like an in-house solution and a vendor.
The OpenTelemetry Collector is a new, vendor-agnostic agent that can receive and send metrics and traces of many formats.
0 kommentar(er)
