Are you interested in dipping your toes in the cloud native observability waters, but as an engineer you are not sure where to get started with tracing problems through your microservices and application landscapes on Kubernetes? Then this is the session for you, where we take you on your first steps in an active open-source project that offers a buffet of languages, challenges, and opportunities for getting started with telemetry data.
The project is called openTelemetry, but before diving into the specifics, we’ll start with de-mystifying key concepts and terms such as observability, telemetry, instrumentation, cardinality, percentile to lay a foundation. After understanding the nuts and bolts of observability and distributed traces, we’ll explore the openTelemetry community; its Special Interest Groups (SIGs), repositories, and how to become not only an end-user, but possibly a contributor.We will wrap up with an overview of the components in this project, such as the Collector, the OpenTelemetry protocol (OTLP), its APIs, and its SDKs.
Attendees will leave with an understanding of key observability concepts, become grounded in distributed tracing terminology, be aware of the components of openTelemetry, and know how to take their first steps to an open-source contribution!
Key Takeaways: Open source, vendor neutral instrumentation is an exciting new reality as the industry standardizes on openTelemetry for observability. OpenTelemetry is on a mission to enable effective observability by making high-quality, portable telemetry ubiquitous. The world of observability and monitoring today has a steep learning curve and in order to achieve ubiquity, the project would benefit from growing our contributor community.
Report
Share
Report
Share
1 of 31
Download to read offline
More Related Content
Observability For You and Me with OpenTelemetry
1. Observability For
You and Me with
OpenTelemetry
Eric D. Schabell
Director Evangelism
@ericschabell{@fosstodon.org}
4 Jul 2024
Tech Meetup Glasgow
10. chronosphere.io
“It’s remarkable how common this
situation is, where an organization
is paying more for their
observability data, than they do
for their production
infrastructure.”
?
12. chronosphere.io
Telemetry is automatically collecting, transmitting
and measuring data from remote sources. It
transmits data back to a central location and
analyzes to monitor and control remote systems.
16. chronosphere.io
Traces give us the big picture and understanding
the full path a request takes in your application.
Spans represents a unit of work or operation and
are building blocks of traces.
Metrics are measurements of a service
captured at runtime.
Logs are a timestamped text record,
either structured (recommended) or
unstructured, with metadata.
17. chronosphere.io
● API - generating & correlating tracing data
● SDK - language specific impl
● Data - OpenTelemetry Protocol (OTLP)
Specification
23. chronosphere.io
Metrics in OTel
● Counter - value accumulates over time
● Asynchronous Counter - Same as the Counter, but is
collected once for each export (aggregated value)
● UpDownCounter: example could be a queue length
● Asynchronous UpDownCounter - Same as the
UpDownCounter, but is collected once for each export
● Gauge: Measures a current value at the time it is read
● Histogram: A client-side aggregation of values, such as request
latencies (buckets)
24. chronosphere.io
OpenTelemetry’s approach with logs is different. Because existing logging
solutions are widespread in language and operational ecosystems,
OpenTelemetry acts as a “bridge” between those logs, the tracing and
metrics signals, and other OpenTelemetry components.
29. chronosphere.io
Workshop (aka Demo)
Demo application is a Flask web application
written in Python:
● http://localhost:8001/ - page load count
● http://localhost:8001/doggo - photo from the Dog API
● http://localhost:8001/rolldice - simulated dice roll
● http://localhost:16686 - Jaeger UI