OpenTelemetry

OpenTelemetry Collector Official Releases. Contribute to open-telemetry/opentelemetry-collector-releases development by creating an account on GitHub.

Discover the key differences between OpenTelemetry and Fluent Bit, their use cases, and how to choose the right observability tool for your needs.

Contrib repository for the OpenTelemetry Collector - open-telemetry/opentelemetry-collector-contrib

As our software complexity increases, so does our telemetry—and as our telemetry increases, it needs more and more tweaking en route to its final destination. You’ve likely needed to change an attribute, parse a log body, or touch up a metric before it landed in your backend of choice.

Explore OpenTelemetry and experiment your OTTL statements on the OTTL Playground!

Contrib repository for the OpenTelemetry Collector - open-telemetry/opentelemetry-collector-contrib

Learn how to configure the Collector to suit your needs

The OpenTelemetry Collector is a convenient place to transform data before sending it to a vendor or other systems. This is frequently done for data quality, governance, cost, and security reasons. Processors available from the Collector Contrib repository support dozens of different transformations on metric, span and log data. The following sections provide some basic examples on getting started with a few frequently-used processors. The configuration of processors, particularly advanced transformations, may have a significant impact on collector performance.

Learn how Datadog provides rich insights into serverless app performance using your existing OpenTelemetry instrumentation, with no code changes required.

If you are planning to build and debug custom collector receivers, processors, extensions, or exporters, you are going to need your own Collector instance. That will allow you to launch and debug your OpenTelemetry Collector components directly within your favorite Golang IDE. The other interesting aspect of approaching the component development this way is that you can use all the debugging features from your IDE (stack traces are great teachers!) to understand how the Collector itself interacts with your component code.

Protocol and libraries for sending and receiving OpenTelemetry data using Apache Arrow - open-telemetry/otel-arrow

Status: Beta Introduction Open Agent Management Protocol (OpAMP) is a network protocol for remote management of large fleets of data collection Agents. OpAMP allows Agents to report their status to and receive configuration from a Server and to receive Agent installation package updates from the Server. The protocol is vendor-agnostic, so the Server can remotely monitor and manage a fleet of different Agents that implement OpAMP, including a fleet of mixed Agents from different vendors.

In order to gain insights into the inner workings of a system – put another way: to have obervability – we can build upon the three pillars of observability: logs, traces and metrics. In this series w

Feature: Enable/disable pipelines via an env-subst-able key When deploying a collector configuration via tools like the opentelemetry-operator and Kustomize, it's difficult to dynamically mangl...

Contrib repository for the OpenTelemetry Collector - open-telemetry/opentelemetry-collector-contrib

Setup and collect telemetry in minutes!

Yes! You really can use curl to send OpenTelemetry logs! This is the easy button. Send a curl to an OpenTelemetry collector and get a log line into your observability system. Transcript Open telemetry, metrics, logs, traces, processors, receivers. Where is the easy button? I just want to send a log line in and see something. Let's get straight to it. Now, everyone has curl, so what I really want is some way to use curl to send data into an open telemetry collector, process that data if I need to, and send it on out as a log entry or some other data type to my backend system. That's precisely what we're going to do now. We are going to use the webhook event receiver in the collector and send it on through to a backend. So let's get straight to it. As you'd expect, we need somewhere to send the data. I'm going to use open observe, so I'll start it here. This is just from their quick start guide, and you can see it's running on port 5080. So there we are. Find out how to ingest logs. I'm going to go to custom and then hotel collector and copy and paste this snippet into my collector configuration YAML file. I've made one change, though, which is to use it as an environment variable. So I'll need to set open observe key as an environment variable when I run the collector, but that's okay. The next thing I need is a receiver. That's a way to get data into the collector. And this is the magic. This is how why we can use curl. I'm going to use webhook event, and I'm going to set the endpoint. That's the endpoint that it makes available to local host on a port that I decide like 8088 and some other properties that you may care to set and a path of events. Now I want the ability to send any old data into the open telemetry collector and it gets exported as a log line. The problem is the open telemetry collected doesn't know when data was sent. So we need to enrich those log lines as they flow through the collector and add the timestamps. That's what you're seeing here. We're using the transform processor. We are adding a field called observed underscore time and setting the time to now. And we're doing the same with the time field. And then we're sending the data on out to open observe. Finally, we build our pipeline, which says we receive data at the webhook event receiver. We process it by adding the timestamp and we export it to open observe. So now that we've done that, let's run our collector and let's send a log line to the collector. Back in open observe, go to the homepage and we can now see one stream, click view more, click the explore icon. And there we are. There's my first log line in our back end. There's something else very special about this setup. We can send a curl message to the open telemetry collector and use the open telemetry's multicasting capability to send that curl to as many different endpoints as we like. So we can use this as kind of a message bus if you need to. This opens up so many possibilities basically anywhere that you have curl available and can run curl, you can now get log lines into your observability systems. So think about GitHub actions, think about CICD pipelines, think about shell scripts. This is a really, really key starting point for observability, especially for those who aren't steeped in observability and tracing history and aren't comfortable yet with those more advanced topics. As always, I hope this has been helpful to get you started on your observability journey. If it has, please like, subscribe, all that good stuff and I'll see you next time. Thanks, bye.

This video covers everything you need to know if you're new to the OpenTelemetry collector. In it I discuss the components: receivers, processors, exporters, pipelines, connectors and extensions. Timestamps 00:00 Intro 00:27 What is the OpenTelemetry collector? 00:51 How do you run an OpenTelemetry collector? 00:58 Collector standalone binary 01:11 Collector container image 01:18 Collector on Kubernetes 01:34 The components of a OpenTelemetry collector 02:25 Quick recap 02:34 Receivers 04:25 Processors 05:34 Exporters 06:57 Pipelines 07:26 How to monitor the OTEL collector itself (service telemetry) 08:00 Connectors 08:29 Extensions 08:53 Recap 09:03 The collector: Getting Observability signals from A to B 09:27 Thank you for your comments and feedback

At Airplane, we collect observability data from our own systems as well as remote “agents” that are running in our customers’ infrastructure. The associated outputs, which include the standard “three pillars of observability” (logs, metrics, and traces) are essential for us to monitor our infrastructure and also help customers debug problems in theirs. Over the last year, we’ve made a concerted effort to migrate most of our observability data generation and collection to the OpenTelemetry (OTe

Learn how to deploy a self-hosted gateway component of Azure API Management on Kubernetes with OpenTelemetry

Kubernetes monitoring is a critical process for keeping your Kubernetes clusters running in fine...

Apache HTTP Server and NGINX are the most popular web servers. It’s most likely that you are using one of them in your application. In a previous blog post, you learned how to use the OpenTelemetry Module for Apache HTTP Server to add observability to Apache HTTP Server. In this blog post, you will learn how you can get observability for NGINX! Install the module for NGINX In the following, you are going to use docker to run a NGINX server with the ngx_http_opentelemetry_module.so enabled and configured. Of course, you can use the same set of commands used in the Dockerfile below to configure a NGINX server on a bare-metal machine.

This page describes how the Kubernetes attributes processor can be used

OpenTelemetry is not perfect, but the value of having one shared standard for instrumentation and telemetry is huge

This talk was recorded at NDC Oslo in Oslo, Norway. #ndcoslo #ndcconferences #developer #softwaredeveloper Attend the next NDC conference near you: https://ndcconferences.com https://ndcoslo.com/ Subscribe to our YouTube channel and learn every day: / @NDC Follow our Social Media! https://www.facebook.com/ndcconferences https://twitter.com/NDC_Conferences https://www.instagram.com/ndc_conferences/ #javascript #devops #azure You've likely heard about OpenTelemetry and are either starting to use it, or thinking about using it in your applications as you should! But how do you use it effectively, how should you set things up, what spans or activities should you create, how should you name them? In this talk we'll cover: * Codeless instrumentation * Frontend Observability vs Backend Observability vs RUM * Getting automatic spans from popular libraries * What application context is important in your observability * Different setup techniques * Using OpenTelemetry in messaging systems like Azure ServiceBus and SQS/SNS * How to export your telemetry signals to a backends * How K8s can make observability simpler This will be a talk about best practices, tips and tricks for getting the most out of OpenTelemetry.