This document outlines a webinar focused on microservices and observability, emphasizing the importance of Opentelemetry for monitoring and collecting data in microservice applications. It covers key topics such as the challenges posed by microservices, the structure and benefits of Opentelemetry, and provides guidance on how to implement observability in applications. The document includes an agenda, speaker information, and instructions for hands-on labs.

1. ©2023 F5
1
Welcome to Unit 4

2. ©2023 F5
2
üAttend all webinars
üComplete all hands-on labs
Use same email for all activities
Obtain Your Badge!

3. ©2023 F5
3
üJoin #microservices-march
üGet help with Microservices
March questions
üConnect with NGINX experts
nginxcommunity Slack

4. ©2023 F5
4
Agenda
1. Lecture
2. Q&A
3. Hands-On Lab with Office Hours
(only for live session – if you’re watching this on
demand, complete the lab on your own time)

5. ©2023 F5
5
Meet the Speakers
DAVE McALLISTER
Sr. OSS Technical Evangelist
NGINX
JAVIER EVANS
Solutions Architect
NGINX

6. ©2023 F5
6
Observability

7. ©2023 F5
7
A microservice is a single application composed of many
loosely coupled and independently deployable smaller
services:
• Often polyglot in nature
• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Often in Cloud environments
• Organized around business capabilities
• Each potentially owned by a small team
Why Observability?
Microservices!

8. ©2023 F5
8
But They Add Challenges
Cynefin Framework 8
Especially when we consider this in a cloud:
● Microservices create complex interactions
● Failures don't exactly repeat
● Debugging multitenancy is painful
● So much data!

9. ©2023 F5
9
Observability Data Signals
Observability helps detect, investigate and resolve the unknown unknowns – FAST
Monitoring Observability
Keep an eye
on things
we know can
go wrong
Find the
unexpected
and explain why
it happened
Metrics
Do I have
a problem?
Traces
Where is the
problem?
Logs
Why is the problem
happening?
Observability Signals
DETECT TROUBLESHOOT ROOT CAUSE
• Better visibility to the state of the system
• Precise and predictive alerting
• Reduces Mean Time to Clue (MTTC)
and Mean Time to Resolution (MTTR)
Content Propagation

10. ©2023 F5
10
• Avoid Lock In
– Ability to switch between observability technologies
• Ease of Use
– Reduction in friction for implementation
– Automated instrumentation when possible
• Visualization Tooling
– Ability to use and correlate data to make decisions
• Low Resource Use
Some Desired Observability Traits

11. ©2023 F5
11
OpenTelemetry

12. ©2023 F5
12
What is OpenTelemetry (OTel)?
• Standards-based agents, cloud-integration
• Automated code instrumentation
• Support for developer frameworks
• Any code, any time
+ =
OpenCensus

13. ©2023 F5
13
Why Does OTel Matter?
•OpenTelemetry users build and own their collection
strategies, without vendor lock-in
•OpenTelemetry puts the focus on analytics not
collection

14. ©2023 F5
14
So what’s OTel good for?
• Observability tracks requests
(mostly)
• Provides actionable insights into
app/user experiences
• Defines additional metrics for
alerting, debugging
• Rapid MTTC, MTTR

15. ©2023 F5
15
RUM, Synthetics, NPM, APM, Infrastructure
Different models driven by observability signals

16. ©2023 F5
16
Let’s look at a trace
Request Microservices path
Service names
Connection duration
µService app duration

17. ©2023 F5
17
A different way of looking at a trace
Request Microservices path
Service names µService app duration µService total performance
Note the 2 spans makes up the trace duration (almost)

18. ©2023 F5
18
Observability includes baggage

19. ©2023 F5
19
OTel Architecture

20. ©2023 F5
20
OTel API - packages, methods, & when to call
● Tracer
○ A Tracer is responsible for tracking the currently active span.
● Meter
○ A Meter is responsible for accumulating a collection of statistics.
● BaggageManager
○ A BaggageManager is responsible for propagating key-value pairs across systems.

21. ©2023 F5
21
OTel Specification Status
Tracing
• API is stable
• SDK is stable
• Protocol is stable
Metrics
• API is stable
• SDK is mixed
• Protocol is stable
Baggage
• API is stable, feature
freeze
• SDK is stable
• Protocol is N/A
Logs
• API is draft
An OpenTelemetry logging API is not
currently under development.
• SDK is draft
• Protocol is stable

22. ©2023 F5
22
OTel Languages
Language Tracing Metrics Logging
C++ v1.8.2 Stable Stable Experimental
.NET v1.4.0 Stable Stable iLogger: Stable
OTLP log protocol:
Experimental
Erlang/Elixir v1.0.2 Stable Experimental Experimental
Go v 1.14.0 / 0.37.0 Stable Alpha NYI
Java v1.23.1 Stable Stable Experimental
JavaScript v1.9.1 Stable Stable Development
Check https://opentelemetry.io for additional languages

23. ©2023 F5
23
Tracing

24. ©2023 F5
24
Tracing Concepts
● Span: Represents a single unit of work in
a system
● Trace: Defined implicitly by its spans. A
trace can be thought of as a directed
acyclic graph of spans where the edges
between spans are defined
as parent/child relationships
● Distributed Context: Contains the
tracing identifiers, tags, and options that
are propagated from parent to child spans
24

25. ©2023 F5
25
Enabling Distributed Tracing
Two basic options:
• Traffic Inspection (e.g., service mesh with context propagation)
• Code Instrumentation with context propagation
Focusing on Code:
• Add a client library dependency
• Focus on instrumenting all service-to-service communication
• Enhance spans (key value pairs, logs)
• Add additional instrumentation (integrations, function-level, async calls)

26. ©2023 F5
26
Tracing Semantic Conventions
In OpenTelemetry, spans can be created freely
It’s up to the implementor to annotate them with attributes specific to the represented operation.
These attributes are known as semantics
Some span operations represent calls that use well-known protocols like HTTP or database calls.
It is important to unify attribution to avoid confusion for aggregation and analysis
Some major semantic conventions
• General: General semantic attributes that may be used describing different operations
• HTTP: For HTTP client and server spans
• Database: For SQL and NoSQL client call spans
• FaaS: For Function as a Service (e.g., AWS Lambda) spans

27. ©2023 F5
27
Metrics

28. ©2023 F5
28
Metrics Concepts
● Gauges: Instantaneous point-in-timevalue
(e.g. CPU utilization)
● Cumulative counters: Cumulative sums
of data since process
start (e.g. request counts)
● Cumulative histogram: Grouped
counters for a range of buckets (e.g. 0-
10ms, 11-20ms)
● Rates: The derivative of a counter,
typically. (e.g. requests per second)
28

29. ©2023 F5
29
Metric Instrument Types
Name Instrument Kind Function(argument) Default Aggregation
Counter Synchronous additive
monotonic
Add(increment) Sum
UpDownCounter Synchronous additive Add(increment) Sum
ValueRecorder Synchronous Record(value) MinMaxSumCount / DDSketch
SumObserver Asynchronous additive
monotonic
Observe(sum) Sum
UpDownSumObserver Asynchronous additive Observe(sum) Sum
ValueObserver Asynchronous Observe(value) MinMaxSumCount / DDSketch

30. ©2023 F5
30
Logs

31. ©2023 F5
31
OpenTelemetry and Logs (Beta-ish)
● The Log Data Model Specification : https://opentelemetry.io/docs/reference/specification/logs/data-model/
● Designed to map existing log formats and be semantically meaningful
● Mapping between log formats should be possible
● Logs and events
○ System Formats
○ Infrastructure Logs
○ Third-party applications
○ First-party applications

32. ©2023 F5
32
OpenTelemetry and Logs
Two Field Kinds:
● Named top-level fields
● Fields stored in key/value
pairs
Field Name Description
Timestamp Time when the event occurred.
ObservedTimestamp Time when the event was observed.
TraceId Request trace id.
SpanId Request span id.
TraceFlags W3C trace flag.
SeverityText The severity text (also known as log
level).
SeverityNumber Numerical value of the severity.
Body The body of the log record.
Resource Describes the source of the log.
InstrumentationScope Describes the scope that emitted the log.
Attributes Additional information about the event.

33. ©2023 F5
33
Collector

34. ©2023 F5
34
OpenTelemetry Collector
OTel Collector
Receivers
Exporters
Batch ... Queued Retry
Processors
Extensions: health, pprof, zpages
OTLP
Jaeger
Prometheus
OTLP
Jaeger
Prometheus
Batch ... Queued Retry
Processors

35. ©2023 F5
35
Getting Started

36. ©2023 F5
36
• Apps must be instrumented
• Must emit the desired observability signals
• You can use automatic instrumentation
• Your results may vary
• You can manually instrument your code
• You can use automatic and manual at the same time
Instrumenting

37. ©2023 F5
37
• Automatic
• Just add the appropriate files to the app.
This is language dependent
• Manual
• Import the OTel API and SDK
• Configure the API
• Configure the SDK
• Create your traces
• Create your metrics
• Export your data
What this basically means
Traces
1. Instantiate a tracer
2. Create spans
3. Enhance spans
4. Configure SDK
Metrics
1. Instantiate a meter
2. Create metrics
3. Enhance metrics
4. Configure observer

38. ©2023 F5
38
The most effective debugging tool is still careful thought,
coupled with judiciously placed print statements.
-Brian Kernighan Unix for Beginners 1979
Observability is the new print statement
Closing Thoughts

39. ©2023 F5
39
DEMO TIME

40. ©2023 F5
40
Q&A

41. ©2023 F5
41
Lab Time!
1. Click link in Related Content box
2. Log in using the same email address from your registration
3. Complete the lab
• Estimated Time: 30-40 minutes
• Max Time: 50 minutes
• Attempts: 3
4. Problems? Use webinar chat
How to Use OpenTelemetry Tracing to Understand Your Microservices

42. ©2023 F5
42
• Progress bar:
• Progress in lab
• Time remaining
• Instruction pane is adjustable
• “Check” runs against a script
• Click “Finish” at end to qualify
for badge
Instruqt Basics

43. ©2023 F5
43
Wrap Up