32 subscribers
با برنامه Player FM !
پادکست هایی که ارزش شنیدن دارند
حمایت شده


1 SISTER WIVES: The Brown Family Plans Garrison's Funeral, Gives NEW Details About His Passing. Justin Baldoni v Blake Lively UPDATES, First Pictures Of Micah Plath’s Broken Nose Have Surfaced!… 36:16
Adopting OpenTelemetry in Confluent and Beyond ft. Xavier Léauté
Manage episode 424666807 series 2510642
Collecting internal, operational telemetry from Confluent Cloud services and thousands of clusters is no small feat. Stakeholders need to rely on the same data to make operational decisions. Whether it be metrics from clusters in Confluent Cloud or traces from our internal service, they all provide valuable insights not only to engineering teams but also to customers for their own operations and for business reporting needs. Traditionally, this data needs to be collected in multiple ways to satisfy all the different requirements. We leverage third-party vendors for our operational needs, which usually means deploying vendor agents or libraries in addition to our own, as we also need to collect some of the same data to expose to customers.
However, this sometimes leads to discrepancies between various systems, which are often hard to reconcile and make it harder to troubleshoot issues across engineering, data science, and other teams.
One of the earliest software engineers at Confluent, Xavier Léauté is no stranger to this. At Confluent, he leads our observability engineering efforts in Confluent Cloud.
With OpenTelemetry, we can collect data in a vendor-agnostic way. It defines a standard format that all our services can use to expose telemetry, and it provides Go and Java libraries that we can use to instrument our services. Many vendors already integrate with OpenTelemetry, which gives us the flexibility to try out different observability solutions with minimal effort, without the need to rewrite applications or deploy new agents. This means that the same data we send to third parties can also be collected internally (in our own clusters).
The same source of data can then be leveraged in many different ways:
- Using Kafka Connect, we can send this data to our data warehouse and data science teams in real time to derive many of the metrics that we use to track the health of our cloud business
- That very same data also powers our Cloud Metrics API to provide our customers visibility into their infrastructure
- Engineers and support teams can collect more fine-grained data to troubleshoot incidents or understand low-level application behavior
We’ve also adopted the same approach for on-prem customers, which enables us to collect telemetry into our cloud and help them troubleshoot issues, leveraging the same infrastructure that we already built for Cloud.
Regarding OpenTelemetry efforts in Apache Kafka®, we’re working on KIP-714 which will allow us to collect Kafka client metrics to help better understand client-side problems without the need to instrument client applications. Our ultimate goal has always been to migrate to OpenTelemetry, which is now underway. We’d like to make a way for direct integration with OpenTelemetry in Kafka, based on the work that we’ve done at Confluent.
EPISODE LINKS
- OpenTelemetry Twitch channel
- Confluent Cloud Metrics API
- Confluent Platform Proactive Support
- KIP-714: Client Metrics and Observability
- Watch the video version of this podcast
- Join the Confluent Community
- Learn more at Confluent Developer
- Use 60PDCAST to get an additional $60 of free Confluent Cloud usage (details)
265 قسمت
Manage episode 424666807 series 2510642
Collecting internal, operational telemetry from Confluent Cloud services and thousands of clusters is no small feat. Stakeholders need to rely on the same data to make operational decisions. Whether it be metrics from clusters in Confluent Cloud or traces from our internal service, they all provide valuable insights not only to engineering teams but also to customers for their own operations and for business reporting needs. Traditionally, this data needs to be collected in multiple ways to satisfy all the different requirements. We leverage third-party vendors for our operational needs, which usually means deploying vendor agents or libraries in addition to our own, as we also need to collect some of the same data to expose to customers.
However, this sometimes leads to discrepancies between various systems, which are often hard to reconcile and make it harder to troubleshoot issues across engineering, data science, and other teams.
One of the earliest software engineers at Confluent, Xavier Léauté is no stranger to this. At Confluent, he leads our observability engineering efforts in Confluent Cloud.
With OpenTelemetry, we can collect data in a vendor-agnostic way. It defines a standard format that all our services can use to expose telemetry, and it provides Go and Java libraries that we can use to instrument our services. Many vendors already integrate with OpenTelemetry, which gives us the flexibility to try out different observability solutions with minimal effort, without the need to rewrite applications or deploy new agents. This means that the same data we send to third parties can also be collected internally (in our own clusters).
The same source of data can then be leveraged in many different ways:
- Using Kafka Connect, we can send this data to our data warehouse and data science teams in real time to derive many of the metrics that we use to track the health of our cloud business
- That very same data also powers our Cloud Metrics API to provide our customers visibility into their infrastructure
- Engineers and support teams can collect more fine-grained data to troubleshoot incidents or understand low-level application behavior
We’ve also adopted the same approach for on-prem customers, which enables us to collect telemetry into our cloud and help them troubleshoot issues, leveraging the same infrastructure that we already built for Cloud.
Regarding OpenTelemetry efforts in Apache Kafka®, we’re working on KIP-714 which will allow us to collect Kafka client metrics to help better understand client-side problems without the need to instrument client applications. Our ultimate goal has always been to migrate to OpenTelemetry, which is now underway. We’d like to make a way for direct integration with OpenTelemetry in Kafka, based on the work that we’ve done at Confluent.
EPISODE LINKS
- OpenTelemetry Twitch channel
- Confluent Cloud Metrics API
- Confluent Platform Proactive Support
- KIP-714: Client Metrics and Observability
- Watch the video version of this podcast
- Join the Confluent Community
- Learn more at Confluent Developer
- Use 60PDCAST to get an additional $60 of free Confluent Cloud usage (details)
265 قسمت
Todos os episódios
×
1 Migrate Your Kafka Cluster with Minimal Downtime 1:01:30

1 Top 6 Worst Apache Kafka JIRA Bugs 1:10:58

1 Optimizing Apache JVMs for Apache Kafka 1:11:42

1 International Podcast Day - Apache Kafka Edition | Streaming Audio Special 1:02:22

1 Capacity Planning Your Apache Kafka Cluster 1:01:54

1 Streaming Analytics and Real-Time Signal Processing with Apache Kafka 1:06:33

1 Common Apache Kafka Mistakes to Avoid 1:09:43

1 Scaling an Apache Kafka Based Architecture at Therapie Clinic 1:10:56

1 The Evolution of Apache Kafka: From In-House Infrastructure to Managed Cloud Service ft. Jay Kreps 46:32

1 Expanding Apache Kafka Multi-Tenancy for Cloud-Native Systems ft. Anna Povzner and Anastasia Vela 31:01

1 From Batch to Real-Time: Tips for Streaming Data Pipelines with Apache Kafka ft. Danica Fine 29:50

1 How to Build a Strong Developer Community with Global Engagement ft. Robin Moffatt and Ale Murray 35:18

1 Collecting Data with a Custom SIEM System Built on Apache Kafka and Kafka Connect ft. Vitalii Rudenskyi 25:14

1 Engaging Database Partials with Apache Kafka for Distributed System Consistency ft. Pat Helland 42:09

1 The Truth About ZooKeeper Removal and the KIP-500 Release in Apache Kafka ft. Jason Gustafson and Colin McCabe 31:50

1 Building a Microservices Architecture with Apache Kafka at Nationwide Building Society ft. Rob Jackson 48:54

1 Event Streaming Trends and Predictions for 2021 ft. Gwen Shapira, Ben Stopford, and Michael Noll 44:34

1 Mastering DevOps with Apache Kafka, Kubernetes, and Confluent Cloud ft. Rick Spurgeon and Allison Walther 46:18

1 Tales from the Frontline of Apache Kafka DevOps ft. Jason Bell 1:00:25

1 Using Apache Kafka as the Event-Driven System for 1,500 Microservices at Wix ft. Natan Silnitsky 49:12

1 Disaster Recovery with Multi-Region Clusters in Confluent Platform ft. Anna McDonald and Mitch Henderson 43:04

1 IoT Integration and Real-Time Data Correlation with Kafka Connect and Kafka Streams ft. Kai Waehner 40:55
به Player FM خوش آمدید!
Player FM در سراسر وب را برای یافتن پادکست های با کیفیت اسکن می کند تا همین الان لذت ببرید. این بهترین برنامه ی پادکست است که در اندروید، آیفون و وب کار می کند. ثبت نام کنید تا اشتراک های شما در بین دستگاه های مختلف همگام سازی شود.