diff --git a/.cspell.yml b/.cspell.yml
index 57d3c4fbc4f2..25d636125d38 100644
--- a/.cspell.yml
+++ b/.cspell.yml
@@ -40,6 +40,7 @@ dictionaries:
# Natural languages
- es-es
- pt-br
+ - fr-fr
# Local word lists
- en-words
- es-palabras
diff --git a/.cspell/en-words.txt b/.cspell/en-words.txt
index aa514245f43a..78a77f7d49b9 100644
--- a/.cspell/en-words.txt
+++ b/.cspell/en-words.txt
@@ -108,6 +108,7 @@ quantile
quantiles
quarkus
quoteservice
+react-native-app
recommendationservice
redis
relref
diff --git a/.cspell/fr-mots.txt b/.cspell/fr-mots.txt
index 7970e82b0e43..3ea4303ab141 100644
--- a/.cspell/fr-mots.txt
+++ b/.cspell/fr-mots.txt
@@ -1,213 +1,4 @@
-analyse
-analyser
-avec
-collecter
-collectez
-comportement
-contenant
-créez
-dans
-découvrez
-définie
-démo
-dessous
-données
-d'utiliser
-efficace
-entièrement
-être
-générer
-gratuit
-indépendant
-instrumenter
-intégrations
-langages
-librairies
-logiciels
-métriques
-nombreux
-nombreuses
+extensibilité
observabilité
-outils
-permet
-permettant
-projet
-projets
-peut
-qualité
-savoir
-s'intègre
-supporte
-supporté
-tant
télémétrie
-transmettez
-universelle
-utilisé
-visuel
-votre
-vous
-l'état
-système
-incluent
-rendre
-signifie
-émettre
-metriques
-produites
-doivent
-transmises
-Pourquoi
-l'essor
-commerciales
-besoin
-répond
-suivant
-principes
-clés
-propriétaire
-générez
-dépendance
-fournisseur
-n'avez
-d'apprendre
-seul
-combinés
-offrent
-équipes
-organisations
-flexibilité
-dont
-informatique
-Extensibilité
-conçu
-extensible
-Quelques
-façon
-étendu
-Ajouter
-receveur
-Collecteur
-afin
-prendre
-venant
-personnalisée
-bibliothèques
-personnalisées
-Créer
-collecteur
-adaptée
-utilisation
-spécifique
-nouvel
-exportateur
-personnalisé
-prend
-propagateur
-contexte
-plupart
-utilisateurs
-n'aient
-d'étendre
-presque
-tous
-niveaux
-Histoire
-trouve
-antérieurs
-créés
-résoudre
-même
-problème
-norme
-décrivant
-manière
-transmettre
-Aucun
-n'étant
-indépendante
-fusionné
-leurs
-offrant
-utilisez
-actuellement
-pouvez
-découvrir
-migrer
-ensuite
-commencer
-Lancez
-directement
-composants
-standardisé
-définissant
-sémantiques
-décrire
-langage
-implémentent
-spécifications
-écosystème
-instrumentent
-automatique
-génèrent
-requérir
-reçoit
-modifie
-autre
-Opérateur
-ressources
-Faas
-variété
-intègrent
-fournir
-défaut
-pris
-fournisseurs
-fournissent
-contribuent
-n’aient
-d’étendre
-conçus
-créer
-gérer
-telles
-outil
-compris
-ainsi
-commerciaux
-d'autres
-génération
-collecte
-gestion
-objectifs
-principaux
-pouvoir
-aisément
-systèmes
-quelque
-soit
-leur
-environnement
-d'exécution
-stockage
-visualisation
-sont
-intentionnellement
-laissés
-d'autres
-comprendre
-sortantes
-logiciel
-d’aujourd’hui
-souhaitez
-jetez
-oeil
-valeurs
-principaux
-suivants
-spécification
-communautaires
-brève
-êtes
-standardisée
-autres
+traçage
\ No newline at end of file
diff --git a/.github/workflows/auto-update-community-members.yml b/.github/workflows/auto-update-community-members.yml
new file mode 100644
index 000000000000..c53e24f027e4
--- /dev/null
+++ b/.github/workflows/auto-update-community-members.yml
@@ -0,0 +1,48 @@
+name: Auto-update community members page
+
+on:
+ workflow_dispatch:
+ schedule:
+ # At 03:41, every day
+ - cron: 41 3 * * *
+
+jobs:
+ auto-update-versions:
+ name: Auto-update community members page
+ runs-on: ubuntu-24.04
+ # Remove the if statement below when testing againt a fork
+ if: github.repository == 'open-telemetry/opentelemetry.io'
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v4
+
+ - name: Set up Node.js
+ uses: actions/setup-node@v4
+ with:
+ node-version: '22'
+
+ - name: Install dependencies
+ working-directory: ./scripts/generate-community-data
+ run: npm install
+
+ - name: Run script
+ working-directory: ./scripts/generate-community-data
+ run: node generate.js ../../data/community/members.yaml
+ env:
+ GITHUB_TOKEN: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}
+
+ - name: Create pull request
+ uses: peter-evans/create-pull-request@v7
+ with:
+ add-paths: 'data/community/members.yaml'
+ author:
+ opentelemetrybot
+ <107717825+opentelemetrybot@users.noreply.github.com>
+ committer:
+ opentelemetrybot
+ <107717825+opentelemetrybot@users.noreply.github.com>
+ token: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}
+ branch: update-community-members
+ title: Update community members
+ body: |
+ This pull request contains automated updates to files by the GitHub Action.
diff --git a/.github/workflows/build-dev.yml b/.github/workflows/build-dev.yml
index b06ae635762d..da819bb42103 100644
--- a/.github/workflows/build-dev.yml
+++ b/.github/workflows/build-dev.yml
@@ -4,8 +4,7 @@ on:
workflow_dispatch:
inputs:
submodule_path_regex:
- description:
- Regex of submodule paths to updated to HEAD before building.
+ description: Regex of submodule paths to update to HEAD before building.
default: content-modules
type: string
diff --git a/.github/workflows/check-format.yml b/.github/workflows/check-format.yml
index 8c625eca46f3..e3227341e0e4 100644
--- a/.github/workflows/check-format.yml
+++ b/.github/workflows/check-format.yml
@@ -21,7 +21,7 @@ jobs:
- name: Create NPM cache-hash input file
run: |
mkdir -p tmp
- jq '{devDependencies, dependencies, engines, gitHubActionCacheKey}' package.json > tmp/package-ci.json
+ jq '{devDependencies, engines, gitHubActionCacheKey}' package.json > tmp/package-ci.json
- uses: actions/setup-node@v4
with:
@@ -29,5 +29,11 @@ jobs:
cache: npm
cache-dependency-path: tmp/package-ci.json
- - name: Check file format
- run: npm run check:format --ignore-scripts
+ - name: Install package(s)
+ run: |
+ PRETTIER_AT_VERS=@$(npm pkg get devDependencies.prettier | tr -d '^"')
+ echo "PRETTIER_AT_VERS=$PRETTIER_AT_VERS" | tee -a $GITHUB_ENV
+ npm install prettier$PRETTIER_AT_VERS --no-save
+ set -x && npx prettier --version
+
+ - run: npm run check:format
diff --git a/.github/workflows/pr-actions.yml b/.github/workflows/pr-actions.yml
index 0917cd66f6bb..214e08172a88 100644
--- a/.github/workflows/pr-actions.yml
+++ b/.github/workflows/pr-actions.yml
@@ -1,4 +1,5 @@
name: PR actions
+# cSpell:ignore esac htmltest refcache nvmrc
on:
issue_comment:
@@ -29,9 +30,9 @@ jobs:
- name: Extract action name
id: extract_action_name
run: |
- PR_ACTION=$(echo $COMMENT | grep -oP '/fix:\K[-_0-9a-z]+')
+ PR_ACTION=$(echo $COMMENT | grep -oP '/fix:\K[:-_0-9a-z]+')
echo "Action is $PR_ACTION"
- ACTION_NAMES="all|dict|filenames|format|htmltest-config|i18n|markdown|refcache|submodules?|text"
+ ACTION_NAMES="all|dict|expired|filenames|format|htmltest-config|i18n|markdown|refcache(:refresh)?|submodules?|text"
if [[ ! "$PR_ACTION" =~ ^($ACTION_NAMES)$ ]]; then
echo "Invalid action name: $PR_ACTION"
echo "Action name should be one of: $ACTION_NAMES"
@@ -69,7 +70,7 @@ jobs:
- run: |
case $PR_ACTION in
- all|refcache|text)
+ all|refcache*|text)
npm install --omit=optional
;&
*)
diff --git a/.github/workflows/survey-on-merged-pr.yml b/.github/workflows/survey-on-merged-pr.yml
new file mode 100644
index 000000000000..38ee45b2703b
--- /dev/null
+++ b/.github/workflows/survey-on-merged-pr.yml
@@ -0,0 +1,32 @@
+name: Survey on Merged PR by Non-Member
+
+on:
+ pull_request:
+ types: [closed]
+
+jobs:
+ comment-on-pr:
+ runs-on: ubuntu-latest
+ if: github.event.pull_request.merged == true
+ steps:
+ - name: Check if user is a member of the org
+ id: check-membership
+ run: |
+ USERNAME=$(jq -r '.pull_request.user.login' "$GITHUB_EVENT_PATH")
+ ORG="${{ github.repository_owner }}"
+ STATUS=$(gh api "orgs/$ORG/members/$USERNAME" --silent && echo "true" || echo "false")
+ if [[ "$STATUS" == "true" ]]; then
+ echo "MEMBER_FOUND=true" >> $GITHUB_ENV
+ else
+ echo "MEMBER_FOUND=false" >> $GITHUB_ENV
+ fi
+ env:
+ GH_TOKEN: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}
+
+ - name: Add comment to PR if author is not a member
+ if: env.MEMBER_FOUND == 'false'
+ run: |
+ PR_NUMBER=${{ github.event.pull_request.number }}
+ gh pr comment $PR_NUMBER --body "Thank you for your contribution! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by filling out this survey: https://forms.gle/WV58koUBGSG9HBY66"
+ env:
+ GH_TOKEN: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}
diff --git a/.gitmodules b/.gitmodules
index 510ebd44bdb2..4604a4b1a92e 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,13 +1,14 @@
+# cSpell:ignore docsy javaexamples
[submodule "themes/docsy"]
path = themes/docsy
url = https://github.com/google/docsy.git
- docsy-pin = v0.11.0-2-g68aa7b3
+ docsy-pin = v0.11.0-22-g2f361b2b
docsy-note = "2024-04-01 Switching to google/docsy.git from cncf/docsy.git since we don't have any CNCF customizations."
docsy-reminder = "Ensure that any tag referenced by `docsy-pin` is present in the remote repo (url), otherwise add (push) the tags to the repo."
[submodule "content-modules/opentelemetry-specification"]
path = content-modules/opentelemetry-specification
url = https://github.com/open-telemetry/opentelemetry-specification.git
- spec-pin = v1.39.0
+ spec-pin = v1.40.0
[submodule "content-modules/community"]
path = content-modules/community
url = https://github.com/open-telemetry/community
@@ -15,7 +16,7 @@
[submodule "content-modules/opentelemetry-proto"]
path = content-modules/opentelemetry-proto
url = https://github.com/open-telemetry/opentelemetry-proto
- otlp-pin = v1.4.0
+ otlp-pin = v1.5.0
[submodule "content-modules/semantic-conventions"]
path = content-modules/semantic-conventions
url = https://github.com/open-telemetry/semantic-conventions
@@ -31,4 +32,4 @@
[submodule "content-modules/opentelemetry-java-examples"]
path = content-modules/opentelemetry-java-examples
url = https://github.com/open-telemetry/opentelemetry-java-examples.git
- javaexamples-pin = f9553ef
+ javaexamples-pin = cce0f6a
diff --git a/.htmltest.yml b/.htmltest.yml
index f5e73895ca1a..7fb6e34637ea 100644
--- a/.htmltest.yml
+++ b/.htmltest.yml
@@ -10,6 +10,8 @@ IgnoreDirs:
# DO NOT EDIT! IgnoreDirs list is auto-generated from markdown file front matter.
# Ignore blog index pages for all locales and in all blog sections (top-level and years)
- ^(../)?blog/(\d+/)?page/\d+
+ # Ignore old blog posts
+ - ^(../)?blog/20(19|21|22|23)/
# TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages:
- ^zh/docs/concepts/signals/baggage/
- ^zh/docs/zero-code/php/
diff --git a/content-modules/opentelemetry-java-examples b/content-modules/opentelemetry-java-examples
index f9553eff58aa..cce0f6a84169 160000
--- a/content-modules/opentelemetry-java-examples
+++ b/content-modules/opentelemetry-java-examples
@@ -1 +1 @@
-Subproject commit f9553eff58aabb28dabee8c14274d9860b4c52bd
+Subproject commit cce0f6a84169b978bba17b3bf7cbf972a0fda230
diff --git a/content-modules/opentelemetry-proto b/content-modules/opentelemetry-proto
index 0adf6aac0045..2bd940b2b77c 160000
--- a/content-modules/opentelemetry-proto
+++ b/content-modules/opentelemetry-proto
@@ -1 +1 @@
-Subproject commit 0adf6aac004578b28267394514b2e55ee9cc012f
+Subproject commit 2bd940b2b77c1ab57c27166af21384906da7bb2b
diff --git a/content-modules/opentelemetry-specification b/content-modules/opentelemetry-specification
index 8954d3b52509..0d046c07e2b2 160000
--- a/content-modules/opentelemetry-specification
+++ b/content-modules/opentelemetry-specification
@@ -1 +1 @@
-Subproject commit 8954d3b525098dc4dadc364e7b82da9235c7f37e
+Subproject commit 0d046c07e2b24bc2405a3e1d367f93ab102d889d
diff --git a/content/en/announcements/2024-community-awards.md b/content/en/announcements/2024-community-awards.md
deleted file mode 100644
index eaf465e9499b..000000000000
--- a/content/en/announcements/2024-community-awards.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: OpenTelemetry Community Awards
-date: 2024-10-29
-expiryDate: 2024-11-08
----
-
-
-[**2024 OpenTelemetry Community Awards**](/blog/2024/community-awards/)
-nominations are open!
diff --git a/content/en/announcements/devex-survey.md b/content/en/announcements/devex-survey.md
new file mode 100644
index 000000000000..ebe0831fbabc
--- /dev/null
+++ b/content/en/announcements/devex-survey.md
@@ -0,0 +1,11 @@
+---
+title: Developer Experience Survey
+date: 2024-12-16
+expiryDate: 2025-01-31
+---
+
+ Help us [improve the developer experience] (5-10
+min). Survey closes January 31.
+
+[improve the developer experience]:
+ https://docs.google.com/forms/d/1orPz5ayzosFrgYRm3-y90UMrt2ZjvIBKMDL_a2E3Fq8/viewform
diff --git a/content/en/announcements/eBPF.md b/content/en/announcements/eBPF.md
deleted file mode 100644
index 971fc2fcf4d2..000000000000
--- a/content/en/announcements/eBPF.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: eBPF
-date: 2024-06-07
-expiryDate: 2024-07-25
----
-
-Elastic's **eBPF profiling agent** is now part of OTel.
-[Learn more](/blog/2024/elastic-contributes-continuous-profiling-agent)
diff --git a/content/en/announcements/kubecon-china.md b/content/en/announcements/kubecon-china.md
deleted file mode 100644
index b90ac8484b8e..000000000000
--- a/content/en/announcements/kubecon-china.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: KubeCon China
-date: 2024-07-10
-expiryDate: 2024-08-23
----
-
- Join us in Hong Kong for
-[**KubeCon + CloudNativeCon + OpenSourceSummit + AI_dev**](/blog/2024/kubecon-china/)
-, August 21 - 23, 2024
diff --git a/content/en/announcements/kubecon-na-2024.md b/content/en/announcements/kubecon-na-2024.md
deleted file mode 100644
index 9b2e1850206c..000000000000
--- a/content/en/announcements/kubecon-na-2024.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: KubeCon North America 2024
-date: 2024-10-15
-expiryDate: 2024-11-15
----
-
- Join us in Salt Lake City for
-[**KubeCon + CloudNativeCon North America 2024**](/blog/2024/kubecon-na/) ,
-November 12 - 15, 2024
diff --git a/content/en/announcements/otel-community-day.md b/content/en/announcements/otel-community-day.md
deleted file mode 100644
index 23046e424222..000000000000
--- a/content/en/announcements/otel-community-day.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: OTel Community Day
-date: 2024-04-05
-expiryDate: 2024-06-25
-weight: -1 # top
----
-
- Join us for
-[**OTel Community Day**](https://events.linuxfoundation.org/open-telemetry-community-day/)
-on June 25th
diff --git a/content/en/announcements/otel-localized.md b/content/en/announcements/otel-localized.md
deleted file mode 100644
index ffd873e45ca2..000000000000
--- a/content/en/announcements/otel-localized.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: OpenTelemetry website goes multilingual!
-date: 2024-08-21
-expiryDate: 2024-09-30
-weight: -240821 # top
----
-
- {{% param title %}}
-[Learn more](/blog/2024/docs-localized/)
diff --git a/content/en/blog/2022/knative/index.md b/content/en/blog/2022/knative/index.md
index 236fbace218d..894b3501bdfc 100644
--- a/content/en/blog/2022/knative/index.md
+++ b/content/en/blog/2022/knative/index.md
@@ -2,9 +2,9 @@
title: Distributed tracing in Knative
linkTitle: Tracing in Knative
date: 2022-04-12
+author: '[Pavol Loffay](https://github.com/pavolloffay)'
# prettier-ignore
cSpell:ignore: apng Cloudevents datacontenttype httpbody khtml knativearrivaltime pavolloffay spanid specversion traceid webp
-author: '[Pavol Loffay](https://github.com/pavolloffay)'
---
In this article, you will learn how distributed tracing works in Knative and we
diff --git a/content/en/blog/2023/ecs-otel-semconv-convergence.md b/content/en/blog/2023/ecs-otel-semconv-convergence.md
index e76417d4beea..0cfdb755febd 100644
--- a/content/en/blog/2023/ecs-otel-semconv-convergence.md
+++ b/content/en/blog/2023/ecs-otel-semconv-convergence.md
@@ -4,8 +4,8 @@ title:
Convention Convergence
linkTitle: ECS and OTel SemConv Convergence
date: 2023-04-17
-cSpell:ignore: ECS Reiley SemConv Yang
author: '[Reiley Yang](https://github.com/reyang)'
+cSpell:ignore: ECS Reiley SemConv Yang
---
Today, we're very excited to make a joint announcement with
diff --git a/content/en/blog/2023/exponential-histograms.md b/content/en/blog/2023/exponential-histograms.md
index 9b481cf8f681..635c0846a8eb 100644
--- a/content/en/blog/2023/exponential-histograms.md
+++ b/content/en/blog/2023/exponential-histograms.md
@@ -2,8 +2,8 @@
title: Exponential Histograms
date: 2023-05-22
author: '[Daniel Dyla](https://github.com/dyladan)'
-cSpell:ignore: Ganesh Ruslan subsetting Vernekar Vovalov
canonical_url: https://dyladan.me/histograms/2023/05/04/exponential-histograms/
+cSpell:ignore: Ganesh Ruslan subsetting Vernekar Vovalov
---
Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over
diff --git a/content/en/blog/2023/histograms-vs-summaries/index.md b/content/en/blog/2023/histograms-vs-summaries/index.md
index ade5c001052f..546e4a51644c 100644
--- a/content/en/blog/2023/histograms-vs-summaries/index.md
+++ b/content/en/blog/2023/histograms-vs-summaries/index.md
@@ -2,8 +2,8 @@
title: Histograms vs Summaries
date: 2023-05-15
author: '[Daniel Dyla](https://github.com/dyladan)'
-cSpell:ignore: aggregatable Björn Ganesh Kovalov Rabenstein Ruslan Vernekar
canonical_url: https://dyladan.me/histograms/2023/05/03/histograms-vs-summaries/
+cSpell:ignore: aggregatable Björn Ganesh Kovalov Rabenstein Ruslan Vernekar
---
In many ways, histograms and summaries appear quite similar. They both roll up
diff --git a/content/en/blog/2023/kubecon-eu.md b/content/en/blog/2023/kubecon-eu.md
index 5091e3e93549..bba363717be0 100644
--- a/content/en/blog/2023/kubecon-eu.md
+++ b/content/en/blog/2023/kubecon-eu.md
@@ -2,9 +2,9 @@
title: Join us for OpenTelemetry Talks and Activities at KubeCon EU 2023
linkTitle: KubeCon EU '23
date: 2023-04-03
+author: '[Severin Neumann](https://github.com/svrnm)'
# prettier-ignore
cSpell:ignore: Aiven Benedikt Bongartz Jaglowski Kowall observ Oliveira Pathak Vider Xiaochun
-author: '[Severin Neumann](https://github.com/svrnm)'
---
The OpenTelemetry project maintainers, members of the governance committee, and
diff --git a/content/en/blog/2023/kubecon-na.md b/content/en/blog/2023/kubecon-na.md
index 643fbd8fc131..9fc9aca998b0 100644
--- a/content/en/blog/2023/kubecon-na.md
+++ b/content/en/blog/2023/kubecon-na.md
@@ -2,9 +2,9 @@
title: Join us for OpenTelemetry Talks and Activities at KubeCon NA 2023
linkTitle: KubeCon NA '23
date: 2023-10-02
+author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
# prettier-ignore
cSpell:ignore: Anusha Aronoff Benedikt Bongartz Broadbridge Contribfest Coralogix Danielson Endo Flamegraphs Hrabovcak Itiel Itoh Jaglowski Kanal Komodor Kota Masanori Matej Mirabella Narapureddy observ Ohly Pivotto Purvi Reddy Sharone Shishi Shivanshu Shrivastava Shwartz Zitzman
-author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
---
The OpenTelemetry project maintainers, members of the governance committee, and
diff --git a/content/en/blog/2023/otel-arrow/index.md b/content/en/blog/2023/otel-arrow/index.md
index afd27364d60d..6b6db82c4e9c 100644
--- a/content/en/blog/2023/otel-arrow/index.md
+++ b/content/en/blog/2023/otel-arrow/index.md
@@ -140,7 +140,7 @@ aligning OpenTelemetry more closely with modern data pipelines that are
increasingly pivoting towards Apache Arrow.
A specification for this protocol (OTEP 0156) can be found
-[here](https://github.com/open-telemetry/oteps/blob/main/text/0156-columnar-encoding.md).
+[here](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0156-columnar-encoding.md).
A reference implementation of the encoding/decoding function can be accessed
[here](https://github.com/open-telemetry/otel-arrow).
@@ -269,7 +269,7 @@ invaluable assistance.
## Links
- OpenTelemetry Protocol with Apache Arrow Specification -
- [OTEP 0156](https://github.com/open-telemetry/oteps/blob/main/text/0156-columnar-encoding.md)
+ [OTEP 0156](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0156-columnar-encoding.md)
- OpenTelemetry Protocol with Apache Arrow (encoder/decoder)
[repository](https://github.com/open-telemetry/otel-arrow).
- Receiver
diff --git a/content/en/blog/2023/why-histograms/index.md b/content/en/blog/2023/why-histograms/index.md
index 15c816972869..cdc6215c2a70 100644
--- a/content/en/blog/2023/why-histograms/index.md
+++ b/content/en/blog/2023/why-histograms/index.md
@@ -2,8 +2,8 @@
title: Why Histograms?
date: 2023-05-08
author: '[Daniel Dyla](https://github.com/dyladan)'
-cSpell:ignore: reimplementation
canonical_url: https://dyladan.me/histograms/2023/05/02/why-histograms/
+cSpell:ignore: reimplementation
---
A histogram is a multi-value counter that summarizes the distribution of data
diff --git a/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/index.md b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/index.md
new file mode 100644
index 000000000000..7a2413371628
--- /dev/null
+++ b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/index.md
@@ -0,0 +1,379 @@
+---
+title: Collecting OpenTelemetry-compliant Java logs from files
+linkTitle: OTel-compliant Java logs from files
+date: 2024-12-09
+author: >
+ [Cyrille Le Clerc](https://github.com/cyrille-leclerc) (Grafana Labs), [Gregor
+ Zeitlinger](https://github.com/zeitlinger) (Grafana Labs)
+issue: https://github.com/open-telemetry/opentelemetry.io/issues/5606
+sig: Java, Specification
+# prettier-ignore
+cSpell:ignore: Clerc cust Cyrille Dotel Gregor Logback logback otlphttp otlpjson resourcedetection SLF4J stdout Zeitlinger
+---
+
+If you want to get logs from your Java application ingested into an
+OpenTelemetry-compatible logs backend, the easiest and recommended way is using
+an OpenTelemetry protocol (OTLP) exporter. However, some scenarios require logs
+to be output to files or stdout due to organizational or reliability needs.
+
+A common approach to centralize logs is to use unstructured logs, parse them
+with regular expressions, and add contextual attributes.
+
+However, regular expression parsing is problematic. They become complex and
+fragile quickly when handling all log fields, line breaks in exceptions, and
+unexpected log format changes. Parsing errors are inevitable with this method.
+
+## Native solution for Java logs
+
+The OpenTelemetry Java Instrumentation agent and SDK now offer an easy solution
+to convert logs from frameworks like SLF4J/Logback or Log4j2 into OTel-compliant
+JSON logs on stdout with all resource and log attributes.
+
+This is a true turnkey solution:
+
+- No code or dependency changes, just a few configuration adjustments typical
+ for production deployment.
+- No complex field mapping in the log collector. Just use the
+ [OTLP/JSON connector](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/otlpjsonconnector)
+ to ingest the payload.
+- Automatic correlation between logs, traces, and metrics.
+
+This blog post shows how to set up this solution step by step.
+
+- In the first part, we'll show how to configure the Java application to output
+ logs in the OTLP/JSON format.
+- In the second part, we'll show how to configure the OpenTelemetry Collector to
+ ingest the logs.
+- Finally, we'll show a Kubernetes-specific setup to handle container logs.
+
+![OTLP/JSON Architecture](otlpjson-architecture.png)
+
+## Configure Java application to output OTLP/JSON logs
+
+{{% alert title="Note" color="info" %}}
+
+Blog post instructions can easily get outdated. In case of issues, check this
+[sample application deployed on Kubernetes](https://github.com/grafana/docker-otel-lgtm/tree/main/examples/java/json-logging-otlp),
+which is continuously updated and tested against the latest versions.
+
+{{% /alert %}}
+
+No code changes needed. Continue using your preferred logging library, including
+templated logs, mapped diagnostic context, and structured logging.
+
+```java
+Logger logger = org.slf4j.LoggerFactory.getLogger(MyClass.class);
+...
+MDC.put("customerId", customerId);
+
+logger.info("Order {} successfully placed", orderId);
+
+logger.atInfo().
+ .addKeyValue("orderId", orderId)
+ .addKeyValue("outcome", "success")
+ .log("placeOrder");
+```
+
+Export the logs captured by the OTel Java instrumentation to stdout using the
+OTel JSON format (aka [OTLP/JSON](/docs/specs/otlp/#json-protobuf-encoding)).
+Configuration parameters for
+[Logback](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/logback/logback-appender-1.0/javaagent)
+and
+[Log4j](https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/log4j/log4j-appender-2.17/javaagent)
+are optional but recommended.
+
+```bash
+# Tested with opentelemetry-javaagent v2.10.0
+#
+# Details on -Dotel.logback-appender.* params on documentation page:
+# https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/logback/logback-appender-1.0/javaagent
+
+java -javaagent:/path/to/opentelemetry-javaagent.jar \
+ -Dotel.logs.exporter=experimental-otlp/stdout \
+ -Dotel.instrumentation.logback-appender.experimental-log-attributes=true \
+ -Dotel.instrumentation.logback-appender.experimental.capture-key-value-pair-attributes=true \
+ -Dotel.instrumentation.logback-appender.experimental.capture-mdc-attributes=* \
+ -jar /path/to/my-app.jar
+```
+
+The `-Dotel.logs.exporter=experimental-otlp/stdout` JVM argument and the
+environment variable `OTEL_LOGS_EXPORTER="experimental-otlp/stdout"` can be used
+interchangeably.
+
+{{% alert title="Note" color="info" %}}
+
+The OTLP logs exporter is experimental and subject to change. Check the
+[Specification PR](https://github.com/open-telemetry/opentelemetry-specification/pull/4183)
+for the latest updates.
+
+{{% /alert %}}
+
+Verify that OTLP/JSON logs are outputted to stdout. The logs are in the
+OTLP/JSON format, with a JSON object per line. The log records are nested in the
+`resourceLogs` array. Example:
+
+
+ {"resourceLogs":[{"resource" ...}]}
+
+```json
+{
+ "resourceLogs": [
+ {
+ "resource": {
+ "attributes": [
+ {
+ "key": "deployment.environment.name",
+ "value": {
+ "stringValue": "staging"
+ }
+ },
+ {
+ "key": "service.instance.id",
+ "value": {
+ "stringValue": "6ad88e10-238c-4fb7-bf97-38df19053366"
+ }
+ },
+ {
+ "key": "service.name",
+ "value": {
+ "stringValue": "checkout"
+ }
+ },
+ {
+ "key": "service.namespace",
+ "value": {
+ "stringValue": "shop"
+ }
+ },
+ {
+ "key": "service.version",
+ "value": {
+ "stringValue": "1.1"
+ }
+ }
+ ]
+ },
+ "scopeLogs": [
+ {
+ "scope": {
+ "name": "com.mycompany.checkout.CheckoutServiceServer$CheckoutServiceImpl",
+ "attributes": []
+ },
+ "logRecords": [
+ {
+ "timeUnixNano": "1730435085776869000",
+ "observedTimeUnixNano": "1730435085776944000",
+ "severityNumber": 9,
+ "severityText": "INFO",
+ "body": {
+ "stringValue": "Order order-12035 successfully placed"
+ },
+ "attributes": [
+ {
+ "key": "customerId",
+ "value": {
+ "stringValue": "customer-49"
+ }
+ },
+ {
+ "key": "thread.id",
+ "value": {
+ "intValue": "44"
+ }
+ },
+ {
+ "key": "thread.name",
+ "value": {
+ "stringValue": "grpc-default-executor-1"
+ }
+ }
+ ],
+ "flags": 1,
+ "traceId": "42de1f0dd124e27619a9f3c10bccac1c",
+ "spanId": "270984d03e94bb8b"
+ }
+ ]
+ }
+ ],
+ "schemaUrl": "https://opentelemetry.io/schemas/1.24.0"
+ }
+ ]
+}
+```
+
+
+
+## Configure the Collector to ingest the OTLP/JSON logs
+
+{{< figure class="figure" src="otel-collector-otlpjson-pipeline.png" attr="View OTel Collector pipeline with OTelBin" attrlink="https://www.otelbin.io/s/69739d790cf279c203fc8efc86ad1a876a2fc01a" >}}
+
+```yaml
+# tested with otelcol-contrib v0.112.0
+
+receivers:
+ filelog/otlp-json-logs:
+ # start_at: beginning # for testing purpose, use "start_at: beginning"
+ include: [/path/to/my-app.otlpjson.log]
+ otlp:
+ protocols:
+ grpc:
+ http:
+
+processors:
+ batch:
+ resourcedetection:
+ detectors: ['env', 'system']
+ override: false
+
+connectors:
+ otlpjson:
+
+service:
+ pipelines:
+ logs/raw_otlpjson:
+ receivers: [filelog/otlp-json-logs]
+ # (i) no need for processors before the otlpjson connector
+ # Declare processors in the shared "logs" pipeline below
+ processors: []
+ exporters: [otlpjson]
+ logs:
+ receivers: [otlp, otlpjson]
+ processors: [resourcedetection, batch]
+ # remove "debug" for production deployments
+ exporters: [otlphttp, debug]
+
+exporters:
+ debug:
+ verbosity: detailed
+ # Exporter to the OTLP backend like `otlphttp`
+ otlphttp:
+```
+
+Verify the logs collected by the OTel Collector by checking the output of the
+OTel Collector Debug exporter:
+
+```log
+2024-11-01T10:03:31.074+0530 info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 1}
+2024-11-01T10:03:31.074+0530 info ResourceLog #0
+Resource SchemaURL: https://opentelemetry.io/schemas/1.24.0
+Resource attributes:
+ -> deployment.environment.name: Str(staging)
+ -> service.instance.id: Str(6ad88e10-238c-4fb7-bf97-38df19053366)
+ -> service.name: Str(checkout)
+ -> service.namespace: Str(shop)
+ -> service.version: Str(1.1)
+ScopeLogs #0
+ScopeLogs SchemaURL:
+InstrumentationScope com.mycompany.checkout.CheckoutServiceServer$CheckoutServiceImpl
+LogRecord #0
+ObservedTimestamp: 2024-11-01 04:24:45.776944 +0000 UTC
+Timestamp: 2024-11-01 04:24:45.776869 +0000 UTC
+SeverityText: INFO
+SeverityNumber: Info(9)
+Body: Str(Order order-12035 successfully placed)
+Attributes:
+ -> customerId: Str(cust-12345)
+ -> thread.id: Int(44)
+ -> thread.name: Str(grpc-default-executor-1)
+Trace ID: 42de1f0dd124e27619a9f3c10bccac1c
+Span ID: 270984d03e94bb8b
+Flags: 1
+ {"kind": "exporter", "data_type": "logs", "name": "debug"}
+```
+
+Verify the logs in the OpenTelemetry backend.
+
+After the pipeline works end-to-end, ensure production readiness:
+
+- Remove the `debug` exporter from the `logs` pipeline in the OTel Collector
+ configuration.
+- Disable file and console exporters in the logging framework (for example,
+ `logback.xml`) but keep using the logging configuration to filter logs. The
+ OTel Java agent will output JSON logs to stdout.
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+## Configure an OpenTelemetry Collector in Kubernetes to handle container logs
+
+To support Kubernetes and container specifics, add the built-in
+[`container`](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/stanza/docs/operators/container.md)
+parsing step in the pipeline without needing specific mapping configuration.
+
+Replace `<>`, `<>`, and `<>` with the
+desired values or use a broader [glob pattern](https://pkg.go.dev/v.io/v23/glob)
+like `*`.
+
+```yaml
+receivers:
+ filelog/otlp-json-logs:
+ # start_at: beginning # for testing purpose, use "start_at: beginning"
+ include: [/var/log/pods/<>_<>_*/<>/]
+ include_file_path: true
+ operators:
+ - type: container
+ add_metadata_from_filepath: true
+
+ otlp:
+ protocols:
+ grpc:
+ http:
+
+processors:
+ batch:
+ resourcedetection:
+ detectors: ['env', 'system']
+ override: false
+
+connectors:
+ otlpjson:
+
+service:
+ pipelines:
+ logs/raw_otlpjson:
+ receivers: [filelog/otlp-json-logs]
+ # (i) no need for processors before the otlpjson connector
+ # Declare processors in the shared "logs" pipeline below
+ processors: []
+ exporters: [otlpjson]
+ logs:
+ receivers: [otlp, otlpjson]
+ processors: [resourcedetection, batch]
+ # remove "debug" for production deployments
+ exporters: [otlphttp, debug]
+
+exporters:
+ debug:
+ verbosity: detailed
+ # Exporter to the OTLP backend like `otlphttp`
+ otlphttp:
+```
+
+## Conclusion
+
+This blog post showed how to collect file-based Java logs with OpenTelemetry.
+The solution is easy to set up and provides a turnkey solution for converting
+logs from frameworks like SLF4J/Logback or Log4j2 into OTel-compliant JSON logs
+on stdout with all resource and log attributes. This JSON format is certainly
+verbose, but it generally has minimal impact on performances and offers a solid
+balance by providing highly contextualized logs that can be correlated with
+traces and metrics.
+
+If any of the steps are unclear or you encounter issues, check this
+[sample application deployed on Kubernetes](https://github.com/grafana/docker-otel-lgtm/tree/main/examples/java/json-logging-otlp),
+which is continuously updated and tested against the latest versions.
+
+Any feedback or questions? Reach out on
+[GitHub](https://github.com/open-telemetry/opentelemetry-specification/pull/4183)
+or on [Slack](/community/#develop-and-contribute) (`#otel-collector`).
diff --git a/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otel-collector-otlpjson-pipeline.png b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otel-collector-otlpjson-pipeline.png
new file mode 100644
index 000000000000..6b743a64085b
Binary files /dev/null and b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otel-collector-otlpjson-pipeline.png differ
diff --git a/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otlpjson-architecture.png b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otlpjson-architecture.png
new file mode 100644
index 000000000000..480519dfecdb
Binary files /dev/null and b/content/en/blog/2024/collecting-otel-compliant-java-logs-from-files/otlpjson-architecture.png differ
diff --git a/content/en/blog/2024/collector-roadmap/index.md b/content/en/blog/2024/collector-roadmap/index.md
index 3a1d5bafa3ac..204638ac9865 100644
--- a/content/en/blog/2024/collector-roadmap/index.md
+++ b/content/en/blog/2024/collector-roadmap/index.md
@@ -2,9 +2,9 @@
title: The roadmap to v1 for the OpenTelemetry Collector
linkTitle: Collector Roadmap
date: 2024-05-06
+author: '[Alex Boten](https://github.com/codeboten) (Honeycomb)'
# prettier-ignore
cSpell:ignore: Antipatterns Boten Broadbridge Helmuth Hrabovcak Ishan Jaglowski OTTL Pantuza pushback Shishi Vijay
-author: '[Alex Boten](https://github.com/codeboten) (Honeycomb)'
---
The [OpenTelemetry Collector](/docs/collector/) is a very popular component in
diff --git a/content/en/blog/2024/elastic-contributes-continuous-profiling-agent.md b/content/en/blog/2024/elastic-contributes-continuous-profiling-agent.md
index 05d65358f7e9..0167f0a06889 100644
--- a/content/en/blog/2024/elastic-contributes-continuous-profiling-agent.md
+++ b/content/en/blog/2024/elastic-contributes-continuous-profiling-agent.md
@@ -2,8 +2,6 @@
title: Elastic Contributes its Continuous Profiling Agent to OpenTelemetry
linkTitle: Elastic Contributes Profiling Agent
date: 2024-06-07
-# prettier-ignore
-cSpell:ignore: Bahubali Christos Dmitry Filimonov Geisendörfer Halliday Kalkanis Shetti
author: >
[Bahubali Shetti](https://github.com/bshetti) (Elastic), [Alexander
Wert](https://github.com/AlexanderWert) (Elastic), [Morgan
@@ -11,6 +9,8 @@ author: >
Perry](https://github.com/Rperry2174) (Grafana)
issue: https://github.com/open-telemetry/community/issues/1918
sig: Profiling SIG
+# prettier-ignore
+cSpell:ignore: Bahubali Christos Dmitry Filimonov Geisendörfer Halliday Kalkanis Shetti
---
Following significant collaboration between
diff --git a/content/en/blog/2024/fuzzing-audit-results.md b/content/en/blog/2024/fuzzing-audit-results.md
new file mode 100644
index 000000000000..f8acf94c04fd
--- /dev/null
+++ b/content/en/blog/2024/fuzzing-audit-results.md
@@ -0,0 +1,75 @@
+---
+title: OpenTelemetry Collector Completes Fuzzing Audit
+linkTitle: Fuzzing Audit Results
+date: 2024-12-20
+author: '[Adam Korczynski](https://github.com/AdamKorcz)'
+issue: 5798
+sig: GC
+cSpell:ignore: containerd Korczynski
+---
+
+OpenTelemetry is happy to announce the completion of the Collector's fuzzing
+audit [sponsored by the CNCF] and carried out by
+[Ada Logics](https://adalogics.com/). The audit marks a significant step in the
+OpenTelemetry project, ensuring the security and reliability of the Collector
+for its users.
+
+[sponsored by the CNCF]:
+ https://contribute.cncf.io/resources/project-services/audits/
+
+## What is fuzzing?
+
+Fuzzing is a testing technique that executes an API with a high amount of
+pseudo-random inputs and observes the API's behavior. The technique has
+increased in popularity due to its empirical success in finding security
+vulnerabilities and reliability issues. Fuzzing initially developed with a focus
+on testing software implemented in memory-unsafe languages, where it has been
+most productive. However, in recent years, fuzzing has expanded to memory-safe
+languages as well.
+
+Over several years, the CNCF has invested in fuzzing for its ecosystem. This
+testing has found numerous security vulnerabilities in widely used projects such
+as Helm (CVE-2022-36055, CVE-2022-23524, CVE-2022-23526, CVE-2022-23525), the
+Notary project (CVE-2023-25656), containerd (CVE-2023-25153), Crossplane
+(CVE-2023-28494, CVE-2023-27483) and Flux (CVE-2022-36049).
+
+## OSS-Fuzz
+
+To initiate the audit, Ada Logics auditors integrated the OpenTelemetry
+Collector into [OSS-Fuzz](https://github.com/google/oss-fuzz). OSS-Fuzz is a
+service offered by Google to critical open source projects, free of charge. The
+service runs a project's fuzzers with excess resources multiple times per week.
+If OSS-Fuzz finds a crash, it notifies the project. It then checks if the
+project has fixed the crash upstream and if so, marks the issue(s) as fixed. The
+whole workflow happens continuously on Google's fuzzing infrastructure,
+supported by thousands of CPU cores. These testing resources outperform what
+developers or malicious threat actors can muster.
+
+## The tests
+
+After the Ada Logics team integrated OpenTelemetry into OSS-Fuzz, the next step
+was to write a series of fuzz tests for the OpenTelemetry Collector. The
+auditors wrote 49 fuzz tests for core components of the Collector, as well as
+several receivers and processors in the `opentelemetry-collector-contrib`
+repository.
+
+The fuzz tests were left to run while the audit team observed their health in
+production. At the completion of the fuzzing audit, the 49 fuzz tests on the
+OSS-Fuzz platform were healthy.
+
+To ensure continued reliability, the fuzz testing continues on the Collector
+even though the audit is complete.
+
+## The results so far
+
+Fuzz testing for the Collector is ongoing, allowing for changes to the project
+to be tested as well. As of the date of this post, no crashes have been
+detected.
+
+But the work is not done! The Ada Logics team created the Collector's fuzzing
+setup as a reference implementation that other OpenTelemetry subprojects can
+rely on to create their own fuzz testing, ensuring greater stability for the
+project as a whole.
+
+For more insight into the audit process, see the
+[published summary](https://github.com/open-telemetry/community/blob/main/reports/ADA_Logics-collector-fuzzing-audit-2024.pdf).
diff --git a/content/en/blog/2024/hardening-the-collector-one.md b/content/en/blog/2024/hardening-the-collector-one.md
index 57ef5a0b6846..443131840ae6 100644
--- a/content/en/blog/2024/hardening-the-collector-one.md
+++ b/content/en/blog/2024/hardening-the-collector-one.md
@@ -3,10 +3,10 @@ title: 'Hardening the Collector Episode 1: A new default bind address'
linkTitle: A new default bind address for the Collector
date: 2024-07-02
author: '[Pablo Baeyens](https://github.com/mx-psi) (OpenTelemetry, Datadog)'
-# prettier-ignore
-cSpell:ignore: awsfirehose awsproxy awsxray Baeyens jaegerremotesampling loki remotetap sapm signalfx skywalking splunk
issue: 4760
sig: Collector SIG
+# prettier-ignore
+cSpell:ignore: awsfirehose awsproxy awsxray Baeyens jaegerremotesampling loki remotetap sapm signalfx skywalking splunk
---
The OpenTelemetry Collector recently went through a security audit sponsored by
diff --git a/content/en/blog/2024/humans-of-otel-na-2024.md b/content/en/blog/2024/humans-of-otel-na-2024.md
new file mode 100644
index 000000000000..87ec407c5cc7
--- /dev/null
+++ b/content/en/blog/2024/humans-of-otel-na-2024.md
@@ -0,0 +1,523 @@
+---
+title: The Humans of OpenTelemetry - KubeCon NA 2024
+linkTitle: Humans of OTel NA 2024
+date: 2024-12-19
+author: >-
+ [Adriana Villela](https://github.com/avillela) (Dynatrace)
+issue: 5812
+sig: End User SIG
+# prettier-ignore
+cSpell:ignore: Adriana Akhigbe Bhattacharya Bluesky brainer Braydon Budha causely Christos commoditize Creeden David Endre Eromosele Gohberg google hazel Kains Lee Luna Markou Miguel nivenly Outreachy Reese Sara sematext Sharr TIMgKXCeiyQ traducción traduction transformative tyk weakly youtube
+---
+
+We're back with our third edition of
+[Humans of OpenTelemetry](/blog/2024/humans-of-otel-eu-2024/), this time from
+KubeCon NA in Salt Lake City, Utah, USA. Once again,
+[Reese Lee](https://github.com/reese-lee) and I interviewed OpenTelemetry
+contributors and end users (and each other!), and learned how they got involved
+with OTel:
+
+- [Hazel Weakly (The Nivenly Foundation)](https://github.com/hazelweakly)
+- [Eromosele Akhigbe (Sematext)](https://github.com/AkhigbeEromo)
+- [Budha Bhattacharya (Tyk)](https://github.com/hellobudha)
+- [Miguel Luna (Elastic)](https://github.com/mlunadia)
+- [Adriana Villela (Dynatrace)](https://github.com/avillela)
+- [David Gohberg (Monday)](https://github.com/dattto)
+- [Endre Sara (Causely)](https://github.com/esara)
+- [Braydon Kains (Google)](https://github.com/braydonk)
+- [Christos Markou (Elastic)](https://github.com/ChrsMark)
+- [Reese Lee (New Relic)](https://github.com/reese-lee)
+
+Also, special thanks to:
+
+- [Reese Lee](https://github.com/reese-lee), my co-interviewer
+- [Henrik Rexed](https://github.com/henrikrexed) for providing the audio and
+ video recording equipment, and doing the initial edits of the raw footage
+
+## Video
+
+You can watch the full recording here:
+
+{{}}
+
+ Thanks to everyone who has contributed to OpenTelemetry to date, and we
+look forward to your continued contributions in 2025 and beyond! 🎉
+
+## Transcript
+
+If reading is more your thing, the transcript of our conversations are below.
+
+### 1- Meet the Humans of OTel
+
+**Hazel Weakly:** Hey there. My name is Hazel Weakly and I have thoughts, lots
+of thoughts. They never stop thinking. And they never stop thinking.
+
+**Eromosele Akhigbe:** My name is Eromosele Akhigbe: and I'm currently a
+software engineer at Sematext. Hello everyone.
+
+**Budha Bhattacharya:** I am Budha. I'm a developer advocate at Tyk. Apart from
+that I've got a very deep relationship with open standards because I'm also the
+board chair for the OpenAPI Initiative and a board member for the GraphQL
+Foundation.
+
+**Miguel Luna:** My name is Miguel Luna and I'm a product manager at Elastic
+where I'm the product lead for the OpenTelemetry efforts across the company and
+what we contribute to the to the community.
+
+**Adriana Villela:** My name is Adriana Villela and I'm a Principal Developer
+Advocate at Dynatrace.
+
+**David Gohberg:** My name is David and I work Monday dot com. I'm a software
+engineer and I work there on the CRM product.
+
+**Endre Sara:** My name is Endre Sara, I'm the co-founder of a company called
+Causely. I started Causely two years ago.
+
+**Braydon Kains:** My name is Braydon Kains. I'm a software developer at Google
+in the Google Cloud Org. I work for the Cloud Observability service and I mainly
+work on agents that customers install in their environments to collect telemetry
+signals and send them to Google Cloud.
+
+**Christos Markou:** My name is Christos. I'm a software engineer at Elastic. I
+have been working mainly in observability over the past five years now and since
+last year I have been contributing mostly to the OpenTelemetry ecosystem.
+
+**Reese Lee:** Hi, my name is Reese Lee and I am a Senior Developer Relations
+Engineer at New Relic.
+
+### 2- How did you get involved in OpenTelemetry?
+
+**Hazel Weakly:** OpenTelemetry. So I got into the project sort of almost
+accidentally, although I think at this point that's an answer that I give for
+everything. When I mean accidentally, it was I was, looking for answers to
+questions that I had and more importantly, how do I teach other people to find
+answers to questions better and how do I continue to level up the teams that I
+worked with, the organizations that I worked with and in figuring out how to get
+people better at asking questions, getting answers, and learning from that? I
+finally stumbled onto OpenTelemetry.
+
+**Eromosele Akhigbe:** In March, I entered an internship called Outreachy and in
+Outreachy I was privileged to work on OpenTelemetry and I worked on building a
+logging bridge in Golang, and by the end of the internship I was able to build a
+logging bridge using OTel zerolog.
+
+**Budha Bhattacharya:** How did I get involved with OpenTelemetry? This is a
+multi part question or answer, I think in this case, because there were a couple
+of, couple of reasons why it caught my attention. Starting off with actually
+advocacy from our new group product manager who had recently joined and she was
+a big proponent of observability and OpenTelemetry specifically. I kind of had
+played around with OpenTracing and OpenCensus for a little while, but I hadn't
+really looked into OpenTelemetry. But once she came in I was a huge advocate for
+it and that got my attention. That was trigger number one. Trigger number two
+was the fact that it was this open standard. So I think anything open standards
+to me is a no brainer.
+
+I've got a lot of time to invest in any sort of open standard that makes life
+easy. I think from a flexibility standpoint that's the way to go. So that was
+trigger number two. Trigger number three was actually when we started using
+OpenTelemetry. So we are an API management platform at Tyk. For us,
+OpenTelemetry was being used internally as well as externally. So internally we
+could already start seeing results in terms of how quickly and efficiently we
+were getting to troubleshoot problems and getting to the heart of issues. And
+not just limited to rest APIs but actually with GraphQL APIs as well, which you
+wouldn't have considered as a possible use case. But we were able to remediate
+some of those issues that we were facing with that. So that was sort of trigger
+number three. And all of that collectively came together to say, hey,
+OpenTelemetry deserves attention.
+
+**Miguel Luna:** Initially I started as a product manager. It was a very
+interesting role because I started in a role where it was more about
+coordination rather than contributing directly. But I've been recently involved
+in the localization of the documentation. So that means translating the
+documentation, more specifically in my case among Spanish speakers. So, la
+traducción de la telemetria abierta. So, the traduction...the translation into
+the Spanish of the OpenTelemetry documentation.
+
+**Adriana Villela:** At my previous role, my manager at the time, as part of it,
+he encouraged me to actually join the OpenTelemetry community. And it was
+actually my first time ever contributing to open source and I never contributed
+to open source. I've been in tech for like over 20 years and my manager
+basically said, yeah, just attend a couple meetings. And my first meeting was
+for the OTel comms. And so that was kind of my gateway into OpenTelemetry.
+
+**David Gohberg:** I started my career in embedded applications and I was doing
+eBPF tracing before that was even a thing. And I then moved into Dropbox where
+all our telemetry was in-house before OpenTelemetry was mainstream and now on
+Monday I continue doing trace-based testing.
+
+**Endre Sara:** I started to learn about OpenTelemetry. I realized that this is
+such an opportunity for the whole industry to actually commoditize and
+standardize how instrumentation is being done and to be able to use common
+semantic conventions so people can understand what's going on. So I got
+instantly excited and I started to work on it. First it was just a few test
+applications, then I played with and demoed to people on how to do
+instrumentation. But as we started our current company, from day one I said we
+have to make sure that we are properly instrumenting our software so that we can
+actually operate this as we get more customers for logs, metrics and disability
+testing, it has been helping us a lot.
+
+**Braydon Kains:** I got involved in OpenTelemetry because our team uses
+OpenTelemetry, namely the OpenTelemetry Collector, to support our customers
+collecting data off of their environments. When we had bugs and issues with
+OpenTelemetry in the past, there would be some light involvement from the team,
+but largely we would open an issue and sort of wait for. Wait for it to get
+addressed. And I really wanted to change that within the group. And I wasn't the
+only one on our team who wanted to change that. So, you know, we all sort of
+started to make a more genuine effort to open issues that came with PRs. And
+that has generally moved our whole team forward into being more involved in
+OTel. And I've ended up being much more involved in OTel to the point where now
+I'm a code owner on the Host Metrics Receiver, which is an important receiver to
+us, but I get to dedicate more time to making sure it's good for everyone and
+not just fixing our own problem.
+
+**Christos Markou:** I was originally asked to contribute to the OpenTelemetry
+by helping with the Elastic Common Schema donation to the OpenTelemetry,
+specifically to the specification and the semantic conventions. And since then I
+have been more and more involved in other projects like the Collector. And right
+now I'm mainly focusing on the semantic conventions and the OpenTelemetry
+Collector, specifically the Collector contrib project.
+
+**Reese Lee:** The way I got involved in OpenTelemetry was at New Relic. And at
+first my first experience with it was through some support tickets that we
+started to get around some of our customers who had adopted OpenTelemetry. And
+then I had a great opportunity to join our dedicated OpenTelemetry team at the
+time as a developer relations engineer. And this was back in November 2021. And
+I was able to integrate within the OpenTelemetry community pretty soon after
+that. And actually my previous manager, Sharr Creeden, she kind of spearheaded
+the work to build the End User Working Group at the time, and now we are the End
+User SIG.
+
+### 3- How has OpenTelemetry helped you?
+
+**Hazel Weakly:** OpenTelemetry has been really useful at my organizations that
+I've worked on because it's become something that you can tie into different
+vendors, tie into different tools, and into other intermediary ways. And the
+huge benefit of it for me is that I can take all these different bits of
+knowledge, not necessarily signals, but different bits of context from the
+company, tie it all together in a way that I can show people these answers to
+their questions, regardless of whether or not they're in engineering. And that
+is a new capability because previously engineering was kind of in its own bubble
+and increasingly it really can't continue to do that. And so OpenTelemetry has
+been super impactful for me for bringing our knowledge outside of engineering
+and bringing the outside knowledge into engineering.
+
+**Budha Bhattacharya:** Things have become a lot more efficient internally. When
+I talk to our SRE teams, our DevOps teams, they're a lot happier when they're
+interacting or working with different elements of our platform stack. It's a lot
+easier to manage and handle it. Now when I talk about the end users, they can
+truly talk about the value of it. And personally, I think just the advocacy side
+of things, I think has been really, really enriching for me to learn more about
+it. Being involved with the community in different ways. Earlier this year I had
+the privilege of putting together a mini conference called LEAP, which was the
+API Observability Conference, where a lot of the folks from the community were
+able to scroll, speak to the different areas and elements of OpenTelemetry, not
+just limited to, again, the engineering side of things, but also how decision
+makers could perceive the value of adopting something like OpenTelemetry within
+their organization.
+
+**Miguel Luna:** It all started when Elastic, we decided to donate the Elastic
+Common Schema, which was a natural fit to the goals of OpenTelemetry, or
+standardizing observability and driving efficiency across getting telemetry data
+converged into a single standard.
+
+**David Gohberg:** When I just started my career, there was no OpenTelemetry, so
+I had to figure out how to do traces and how to correlate them with metrics and
+how to do logs. But now all this effort has already been standardized by the
+community, so new engineers that are onboarding into OpenTelemetry have a much
+easier time than I have.
+
+**Endre Sara:** In general, I think that the ability to be able to take signals
+from your application and to be able to use them to operate the environment to
+understand the behavior of the system is significantly easier with OpenTelemetry
+than it was with other proprietary instrumentations in the past. What I think is
+more interesting is what do you do with this data? Is most of this information
+is being exposed to people in dashboards which are amazingly nicely presented,
+contextualized based on semantic conventions. But I think that the biggest
+advantage is to be able to use software to reasonably data.
+
+**Braydon Kains:** The main way OpenTelemetry has helped me personally is really
+learning how to interact with a large community. I already had some experience
+with open source communities and there is this sort of general culture of like,
+you know, you do the work, you get a say in the project. That's pretty common in
+the open source world and I think that's fine. But OpenTelemetry has a very
+large structure for getting changes in.
+
+**Christos Markou:** I really like working with the OpenTelemetry ecosystem in
+general because I believe that working with people from other companies, other
+teams, helps me personally as an engineer a lot because I see how other people
+do observability out there. So I keep learning a lot. So that's something that I
+really like and I believe in general my team is also really helped by this, by
+this fact and also for my job. I mean it's amazing because I really love open
+source, I really love working with open source projects. And yeah, I think that
+on a personal level it's really helpful.
+
+**Reese Lee:** OpenTelemetry has helped me personally in honestly really big
+way, in the sense that working in developer relations with OpenTelemetry, I've
+gotten to meet a lot of wonderful people which I talked about earlier. But as
+part of my role I get to submit topics to different events and part of that is
+being able to learn about all these different topics myself and being able to
+talk to people who are using in production or trying it on themselves has been a
+really wonderful experience.
+
+### 4- What does Observability mean to you?
+
+**Hazel Weakly:** My definition of observability, it is the process through
+which one develops the ability to ask meaningful questions, get useful answers
+and then act effectively on when you learn. So what I mean by that is it's not
+enough to be able to kind of figure out the answer. There's this process where
+you have to actually work on it over and over and over and you're developing a
+skill not just on a personal level, but on an organization level, on a group
+level, and in even broader an industry level. So as you continue to do that,
+continue to get those really, really useful answers and really, really
+meaningful questions that you can ask. You start to have this whole process of
+group learning that transcends the boundaries that we draw for ourselves and
+lets those boundaries become empowering rather than limiting.
+
+**Eromosele Akhigbe:** Observability Engineers are like the doctors of your
+system. So if something is going wrong in your system, you need us to be able to
+pinpoint where exactly or what exactly is wrong and how to solve whatever is
+wrong. So that's what observability means to me.
+
+**Budha Bhattacharya:** What does observability mean to me? There is a technical
+answer to this, where it goes into the realm of perhaps monitoring, perhaps
+logging, and, you know, getting to the troubleshooting of all things. To me,
+it's all about understanding. It is essentially understanding the pulse of your
+platform that you have created. I work with APIs quite a lot, so everything
+underlying is all to do with API platforms. So understanding the pulse of your
+API platform, the different components coming together and knowing exactly
+what's functioning, not functioning, the good, bad and ugly of it all, that, to
+me, is what observability is all about. So to be able to get to that part of the
+problem, to be able to know what's working, what's not working, and making
+decisions more effectively.
+
+**Miguel Luna:** Monitoring means knowing answers to questions that you know you
+needed to ask. Observability means knowing questions to answers that you didn't
+know that you need to ask.
+
+**Adriana Villela:** To me, observability means the ability to get insights into
+your system. And for me, like, this was extremely transformative, because, like,
+there's so many times in my life where, you know, I was, like, debugging code,
+whether it was like my own code, like, as a developer or code in production, and
+not understanding, like, just looking through logs and not understanding, like,
+okay, but how does this relate to the bigger picture? Like, I have so many
+memories of, like, troubleshooting production issues, and it's like, oh, the
+system is slow. So you ask the person who's responsible for administering the
+app server, hey, can you check the logs? No, not my problem. You ask the DBA,
+no, no, it's not my problem. And then you ask whoever else, and you go down the
+whole line and, like, it's nobody's problem. And yet you're still seeing
+latency. And I feel like observability kind of like it. It uncloaks the whole
+thing because all of a sudden it exposes. Like, it exposes where the actual root
+cause is. And I think that's the magic and power of observability.
+
+**David Gohberg:** The most important thing in software engineering today is the
+user experience. And because our software is getting much more complex, it's
+getting harder to answer the question, how are my users experiencing my product?
+And OpenTelemetry allows us to answer these difficult questions and provide us
+with visibility into our software.
+
+**Endre Sara:** I think that probably the most obvious answer is to be able to
+collect signals. But I think that the real point of observability is to
+understand and reason about the behavior of the systems. Simply collecting data
+doesn't actually accomplish much. I think also with the becomes meaningful and
+valuable, and people are able to use this to drive actions, to drive decisions.
+Where do I need to improve reliability? Where do I need to improve the
+performance of my application? Where do I need to make architectural changes? I
+think observability is really serving that. Otherwise it's just a lake of data.
+
+**Braydon Kains:** Observability means to me that you can tell what's going on.
+Computers are black boxes that understand what ones and zeros do. And being able
+as a human to understand what ones and zeros are doing at any given time, when a
+computer is blazing so fast, how would you ever be able to figure out what that
+means? So observability to me is the human version of understanding what a
+computer is doing.
+
+**Christos Markou:** So for me, observability is something that I. I have been
+working on since university, and it's a really important area because I think
+that what really matters when we are running systems, it's the way that you can
+observe your systems, you can know if your systems are doing good or not. And
+specifically, I'm coming from an infrastructure background, as I mentioned
+before. So for infrastructure specifically, it's really, really important when
+it comes to cost reduction. And this sort of stuff or how the whole system is
+working is an important piece that you cannot miss.
+
+**Reese Lee:** Observability to me means that I, as an end user of various
+applications and software programs, get to have a better experience because the
+companies that build these products, you know, assuming that they're using
+observability and being able to stay on top of issues that are happening in
+their code, it means I get to have a better experience as an end user.
+
+### 5- What does OpenTelemetry mean to you?
+
+**Hazel Weakly:** OpenTelemetry to me is one really interesting approach towards
+building something that takes a very sort of capitalistic notion of companies
+need to be profitable, companies wanting to innovate, people wanting to compete,
+and people want to develop different solutions to things. And how do you wrap
+all that together in a project that's flexible enough to allow that competition,
+to allow those ideas to happen, and to allow this Innovation to continue without
+limiting what's possible and without burdening the industry with the
+intermediate details of the evolution of that complex, the evolution of pursuing
+excellence.
+
+**Eromosele Akhigbe:** OpenTelemetry is, I believe, the future of observability.
+In March, when I started doing research on OpenTelemetry, I discovered how big
+this can be and I decided that I was going to go in fully into OpenTelemetry. So
+I believe that it's the future of observability and everyone should take it.
+
+**Budha Bhattacharya:** What does OpenTelemetry mean? To me that's an extension
+of that understanding. In a way it's the. Well, again, the technical answer to
+this would be, is the open standard that essentially powers distributed tracing.
+That's all fine. To me it's the extension of that understanding by creating a
+common language or framework, however you want to put it, that the different
+components and elements of your platform stack can unite together to speak to
+the health of your overall platform. And that could go from the engineering
+standpoint all the way to the business standpoint. There are repercussions to
+both of those. So to me that's what OpenTelemetry as a technology brings, both
+from a business and a technical standpoint. But it's also about the community as
+well. It's sort of again the industry coming together and agreeing on a standard
+so that the life of SRE, DevOps organizations, tooling providers, end users, all
+of their lives are made a lot more easier because by virtue of having an open
+standard, it means that your platform is a lot more flexible, you have a lot
+more freedom to evolve, to mature and actually be a bit more future ready. So
+that to me is the promise of flexibility and freedom that OpenTelemetry brings.
+
+**Miguel Luna:** For me it means a common language. So it's a place where we
+all, where users can made and at least understand that everything that we are
+going to collect is going to be collect in a similar way, with a similar
+mechanism. Also what we call things. So the semantic conventions we, we agree on
+common standards of what, what are we going to call things? So the telemetry is
+the same and it can be reusable. So yeah, so that's, that's OpenTelemetry for
+me.
+
+**Adriana Villela:** What does OpenTelemetry mean to me? To me, you know, it's,
+it feels like home actually, because it's been like my home for the last like
+two and a half years. So it's been like really transformative in my life because
+it's like I said, was my gateway into like open source, into the CNCF community.
+And so it takes on like a very personal flavor for me, just beyond like the, you
+know, the, the typical definition of OpenTelemetry, which is like this open
+standard for instrumenting your code. For me, it's just so much more than that.
+It really is like this lovely community where we're working with different
+vendors from across the board and we're not enemies, we're all friends because
+we're working towards the same goal.
+
+**David Gohberg:** OpenTelemetry is basically a way to standardize all the
+efforts, all the engineers that want to ask all the difficult questions about
+software.
+
+**Endre Sara:** OpenTelemetry gives a way for multiple vendors to work together,
+to collaborate together and take the instrumentation as a given that is not a
+function of competition and really focus on adding value on how this information
+turns into an actionable insight. And I think that that is really where people,
+vendors, end users are expecting to innovate in. So OpenTelemetry is basically
+the enabler for vendors to focus on where the real value is.
+
+**Braydon Kains:** OpenTelemetry to me is a representation of the industry
+coming together and understanding, you know, what are we competing about really?
+Like what are, where are we really as different companies trying to fit in the
+market? And I think we all sort of collectively understand that the signals
+themselves really aren't worth differentiating on. It's generally a net negative
+for everyone for us to not agree on this stuff. And if we can agree on the
+signal part, it just leaves everyone, all companies, more time to differentiate
+in the ways that, that actually are tangible in terms of how the data works.
+
+**Christos Markou:** Having been involved in OpenTelemetry over the past year, I
+think that OpenTelemetry is a great place to learn things and meet other people
+that are really passionate about the whole observability area. And I think that
+consists of people that really like what they are doing and they are really good
+at this. So it's a great place for engineers to come together and work and share
+the observability space to evolve.
+
+**Reese Lee:** OpenTelemetry to me means a lot of things, you know, beyond the
+project and kind of the way it's helped different organizations, you know, move
+into and adopt open source throughout their stack. It's also such a huge,
+wonderful community. I really enjoy meeting the maintainers and getting to know
+the end users. I have really good relationships with a lot of the OpenTelemetry
+community people and that's what it means to me.
+
+### 6- What's your favorite OpenTelemetry signal?
+
+**Hazel Weakly:** My favorite OpenTelemetry signal. I'm going to cheat a little
+bit here and I'm going to say my favorite OpenTelemetry signal is the one that
+gives people the answer that they find most useful for the question that they
+find most use meaningful.
+
+**Eromosele Akhigbe:** Traces. Traces are my favorite signal because, like, they
+give a full, you know, a full picture of everything going on in the system and
+you can easily spot on errors.
+
+**Budha Bhattacharya:** Favorite OpenTelemetry signal. This is, this is a tough
+one. I think traces has to take the win at this point of time because again,
+just thinking about how things connect well. I'm also very, very keenly pursuing
+profiling. I think that's going to be potentially the winner in the next
+conversation we have because I think performance is a big area for a lot of
+organizations and especially when, as an API gateway, when we are working with
+different components, we have one part of the API platform stack to know if
+there are potential bottlenecks. Are we a bottleneck? Are there other elements
+that are potential bottlenecks there? How do we improve performance? How do we
+actually put our money where the numbers are, essentially? That's what profiling
+again, sort of promises to a point?
+
+**Miguel Luna:** Because of the background, Elastic, I gotta say logs. But of
+course, you know, it's. The logs are, you know, they. They bring like deep
+contextual insights, but at the end of the day, you need them all. Like metrics
+are gonna let us know there is a problem. Tracing is gonna help us to understand
+where the problem is, and logs are gonna help us understand what the problem is.
+
+**Adriana Villela:** My favorite signal is traces because I fell in love with
+observability and OpenTelemetry because of traces.
+
+**David Gohberg:** I would have to say that I got the most value out of tracing.
+But recently I started to correlate traces with metrics, and I think that is
+like the golden flow.
+
+**Endre Sara:** I have been a huge fan of distributed tracing in general. I
+think it gives you the understanding of how big, like, services interact with
+each other. But I've been growing to like profiling. I think it gives
+interesting, exciting opportunities on how people understand even deeper how
+their systems behave, especially how their systems behave under different flow,
+different conditions, and to be able to adjust, improve their architectures and
+the scale of their systems to cater to future loads.
+
+**Braydon Kains:** My favorite OpenTelemetry signal right now is logs, because
+even though I'm fully immersed in OpenTelemetry now and I know what all three of
+the signals mean, I started on logs because logs are easy. It just makes so much
+sense and I understand where people are coming from, coming from with
+observability, second wave, you know, everything should just be trace or lot
+wide events. I understand the value of that, but I just feel like logs aren't
+ever going away.
+
+**Christos Markou:** My favorite signal coming from an infrastructure and
+systems background. I really like metrics, and this is something that actually
+is my personal goal for the next months. Coming to help a lot stabilizing
+metrics like system metrics in the semantic conventions and Kubernetes metrics
+as well, and make the collector providing more confidence to our users because
+having the semantic stable, that will help us.
+
+**Reese Lee:** My favorite signal. You know, I want to say traces, because they
+were kind of the first thing I learned when I got into the world of
+observability to begin with, and I think that was kind of what my mind
+understood. And I really like the trace waterfalls, so I'll go with that.
+
+## Join us!
+
+If you have a story to share about how you use OpenTelemetry at your
+organization, we’d love to hear from you! Ways to share:
+
+- Join the
+ [#otel-sig-end-user channel](https://cloud-native.slack.com/archives/C01RT3MSWGZ)
+ on the
+ [CNCF Community Slack](https://communityinviter.com/apps/cloud-native/cncf)
+- Join our [OTel in Practice](/community/end-user/otel-in-practice/) sessions
+- Share your stories on the [OpenTelemetry blog](/docs/contributing/blog/)
+- Contact us on the
+ [CNCF Community Slack](https://communityinviter.com/apps/cloud-native/cncf)
+ for any other types of sessions you'd like to see!
+
+Be sure to follow OpenTelemetry on
+[Bluesky](https://bsky.app/profile/opentelemetry.io),
+[Mastodon](https://fosstodon.org/@opentelemetry) and
+[LinkedIn](https://www.linkedin.com/company/opentelemetry/), and share your
+stories using the **#OpenTelemetry** hashtag!
+
+And don't forget to subscribe to our
+[YouTube channel](https://youtube.com/@otel-official) for more great
+OpenTelemetry content!
diff --git a/content/en/blog/2024/kubecon-china.md b/content/en/blog/2024/kubecon-china.md
index 8e3a787985e2..fd9d6111c837 100644
--- a/content/en/blog/2024/kubecon-china.md
+++ b/content/en/blog/2024/kubecon-china.md
@@ -2,10 +2,10 @@
title: OpenTelemetry Talks at KubeCon China 2024
linkTitle: KubeCon China 2024
date: 2024-07-10
-# prettier-ignore
-cSpell:ignore: Alhamdani Censhare EBPF Hrabusa Husni Huxing Jiahang Krom Sianturi Wanqi Zhang Zihao Ziyi
author: '[Tiffany Hrabusa](https://github.com/tiffany76)'
sig: Communications SIG
+# prettier-ignore
+cSpell:ignore: Alhamdani Censhare EBPF Hrabusa Husni Huxing Jiahang Krom Sianturi Wanqi Zhang Zihao Ziyi
---
Join members of the OpenTelemetry community at
diff --git a/content/en/blog/2024/kubecon-eu.md b/content/en/blog/2024/kubecon-eu.md
index 1af8ce7a9fca..2e6f39776bbb 100644
--- a/content/en/blog/2024/kubecon-eu.md
+++ b/content/en/blog/2024/kubecon-eu.md
@@ -4,9 +4,9 @@ title:
Europe 2024
linkTitle: KubeCon EU '24
date: 2024-02-28
+author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
# prettier-ignore
cSpell:ignore: Aiven Alexandre Anusha Arbiv Beemer Benedikt Blanco Bongartz Chekuri Coralogix Cosmonic Dyrmishi Jiekun Joonas Kanal Kolachala Kowall Machado Magno Marcin Matej Mirabella Narapureddy Nenashev Oleg Oluwalolope Outshift Pismo Purvi Quwan Reddy Ridwan Rollouts Ryanair Skyscanner Sodkiewicz Soluções Srikanth Tecnológicas Yosef
-author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
---
The OpenTelemetry project maintainers, members of the governance committee, and
diff --git a/content/en/blog/2024/kubecon-na.md b/content/en/blog/2024/kubecon-na.md
index f687279e02e6..1becdaeda917 100644
--- a/content/en/blog/2024/kubecon-na.md
+++ b/content/en/blog/2024/kubecon-na.md
@@ -2,9 +2,9 @@
title: Join us for OpenTelemetry Talks and Activities at KubeCon NA 2024
linkTitle: KubeCon NA '24
date: 2024-11-05
+author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
# prettier-ignore
cSpell:ignore: Arnell Ashok Chandrasekar Clario Contribfest Ekansh Grabner Haeussler Helmuth Jernigan Kalkanis Kats Kowall Kruthika Liudmila Mclean Molkova Novatec OTTL Prasanna Shivanshu Shrivastava simha Woerner
-author: '[Severin Neumann](https://github.com/svrnm) (Cisco)'
---
The OpenTelemetry project maintainers, members of the governance committee, and
diff --git a/content/en/blog/2024/otel-arrow-production/index.md b/content/en/blog/2024/otel-arrow-production/index.md
index ac27be966449..030859134db5 100644
--- a/content/en/blog/2024/otel-arrow-production/index.md
+++ b/content/en/blog/2024/otel-arrow-production/index.md
@@ -5,9 +5,9 @@ date: 2024-09-25
author: >-
[Joshua MacDonald](https://github.com/jmacd) (ServiceNow), [Laurent
Querel](https://github.com/lquerel) (F5)
-cSpell:ignore: Querel Zstd
issue: 5193
sig: OpenTelemetry Arrow
+cSpell:ignore: Querel Zstd
---
The OpenTelemetry Protocol with Apache Arrow (OTel-Arrow) project's
@@ -54,7 +54,7 @@ The compression bridge consists of two OpenTelemetry Collectors labeled exporter
and receiver, or they could equally be two pools of load-balanced collectors.
As described in the
-[OTEP 0156 design document](https://github.com/open-telemetry/oteps/blob/main/text/0156-columnar-encoding.md#mapping-otel-entities-to-arrow-records),
+[OTEP 0156 design document](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0156-columnar-encoding.md#mapping-otel-entities-to-arrow-records),
the exporter converts arbitrary OpenTelemetry data into an Arrow record batch.
The Arrow record batch is a block of memory, with a standardized layout, making
it possible to exchange data across address spaces and virtual process
diff --git a/content/en/blog/2024/otel-docs-survey/component-explanations.png b/content/en/blog/2024/otel-docs-survey/component-explanations.png
new file mode 100644
index 000000000000..611a29df0300
Binary files /dev/null and b/content/en/blog/2024/otel-docs-survey/component-explanations.png differ
diff --git a/content/en/blog/2024/otel-docs-survey/feature-request.png b/content/en/blog/2024/otel-docs-survey/feature-request.png
new file mode 100644
index 000000000000..08219be96c29
Binary files /dev/null and b/content/en/blog/2024/otel-docs-survey/feature-request.png differ
diff --git a/content/en/blog/2024/otel-docs-survey/index.md b/content/en/blog/2024/otel-docs-survey/index.md
new file mode 100644
index 000000000000..afa77bdff3d8
--- /dev/null
+++ b/content/en/blog/2024/otel-docs-survey/index.md
@@ -0,0 +1,191 @@
+---
+title: Insights from the OpenTelemetry Docs Usability Survey
+linkTitle: OTel-docs Survey
+date: 2024-12-18
+author: '[Tiffany Hrabusa](https://github.com/tiffany76) (Grafana Labs)'
+issue: https://github.com/open-telemetry/opentelemetry.io/issues/5793
+sig: Communications, End-User
+cSpell:ignore: Hrabusa
+---
+
+[The OpenTelemetry End-User SIG](/community/end-user/) recently surveyed the
+community to find out how user-friendly [OpenTelemetry's documentation](/docs/)
+is. In an earlier survey, two-thirds of respondents named comprehensive
+documentation as a top resource they wished they'd had when getting started with
+OpenTelemetry. So we decided to dig a little deeper.
+
+The Docs Usability Survey asked users where they go for OTel documentation, what
+they'd like to see more of in the docs, and how they rate the current state of
+the docs. We received 48 responses, which we'll use to focus our documentation
+efforts and help us improve in key areas.
+
+A big thank you to everyone who participated in the survey! Let's review the
+results.
+
+## Key takeaways
+
+- Respondents expressed a desire for **more visual aids**, such as diagrams and
+ screenshots.
+- Of the three types of documentation we asked about (component concepts,
+ installation instructions, and troubleshooting), the **troubleshooting docs**
+ were identified as needing the most improvement.
+- When asked about the information they’d most like to see added to OTel's docs,
+ the top responses were **more examples** and **expanded coverage**, both in
+ depth and breadth.
+- The [Collector](/docs/collector/) docs emerged as the most frequently
+ consulted resource, a finding that aligns with the page view analysis in the
+ SIG Communications'
+ [year-end review](../year-in-review/#which-pages-were-the-most-popular).
+- After normalization and weighting, the [Java](/docs/languages/java/)
+ documentation received the **highest overall rating**, reflecting the positive
+ impact of recent improvements to its
+ [organization](../year-in-review/#ia-improvements). Conversely, the
+ [Swift](/docs/languages/swift/) docs received the lowest overall rating.
+- Among the six most popular documentation sets, the
+ [JavaScript](/docs/languages/js/) docs received the **lowest rating**.
+
+## Detailed insights
+
+### About the respondents
+
+- 79% are using OTel in production.
+- 21% work for an observability or APM vendor.
+- 98% have previous knowledge of observability: intermediate (60%) or expert
+ (38%).
+
+#### Q: What source do you primarily rely on when you're looking for information about OpenTelemetry?
+
+- Overall, the majority of respondents (52%) rely on the [opentelemetry.io]
+ documentation.
+- Respondents early in their observability practice (beginner and intermediate)
+ are more likely to use the [opentelemetry.io] documentation.
+- Expert observability practitioners prefer the code repository documentation.
+
+[opentelemetry.io]: /docs/
+
+> **Respondents who use [opentelemetry.io] as their primary information**
+> source _By level of observability knowledge_
+>
+> | Beginners | Intermediates | Experts |
+> | :-------: | :-----------: | :-----: |
+> | 100% | 62% | 44% |
+
+### Documentation wish list
+
+#### Q: What features or information would you like to see added to opentelemetry.io that aren't currently available?
+
+We asked respondents to describe in their own words what they'd like to see
+added to the [opentelemetry.io] documentation. We loosely grouped their
+responses into six categories. Some answers fell in more than one category. For
+full responses, see [Docs Usability Survey Responses].
+
+[Docs Usability Survey Responses]:
+ https://docs.google.com/spreadsheets/d/1kpJQYiEGtpZorICbl-QfYL3mKfeoRLiUywvKcV8fcNA
+
+- More examples: 17 (35%)
+- Deeper or broader coverage: 13 (27%)
+- Better structure: 8 (17%)
+- Add code repository docs: 5 (10%)
+- Other: 2 (4%)
+- No response: 7 (15%)
+
+![Horizontal bar graph showing the number of feature requests by category](feature-request.png)
+
+#### Q: Would more visual aids (e.g., diagrams and screenshots) explaining OpenTelemetry concepts be helpful?
+
+An overwhelming 81% said yes: they want more visual aids.
+
+### Current state of the docs
+
+#### Q: How well do the current docs at opentelemetry.io explain the different components of OpenTelemetry?
+
+Most respondents felt the component conceptual documentation was average, with a
+top score of 3.
+
+![Stacked row chart showing the percentage of users who rated the component conceptual documentation from 1 (low) to 5 (high)](component-explanations.png)
+
+#### Q: How straightforward and user-friendly are the installation instructions for OpenTelemetry?
+
+Most respondents found OTel instructions better than average, with a top score
+of 4. Respondents with intermediate-level observability knowledge rated them
+higher than experts: 55% of intermediates rated the installation instructions 4
+or 5, compared with only 17% of experts.
+
+![Stacked row chart showing the percentage of users who rated the installation instructions from 1 (low) to 5 (high)](installation-instructions.png)
+
+#### Q: How comprehensive are the troubleshooting sections?
+
+Most respondents believe that this section of docs needs work. Only 15% rated
+the troubleshooting docs 4 or 5, and they were all intermediate-level
+respondents. None of the expert-level respondents rated the troubleshooting docs
+above a 3.
+
+![Stacked row chart showing the percentage of users who rated the troubleshooting documentation from 1 (low) to 5 (high)](troubleshooting.png)
+
+#### Q: How would you rate your experience using the current OTel documentation for the following languages and components?
+
+Respondents were asked to rate only the documentation that applied to them, so
+we can infer based on their responses which docs sets are the most used.
+
+- The Collector documentation is the most used: 77% of respondents rated it.
+- The next five documentation sets are close in popularity, with 50 to 67% of
+ respondents rating them.
+
+![Horizontal bar graph showing the number of ratings per OTel component](top-six-bar.png)
+
+Here are the tabulated ratings for all languages and components. When the
+results are normalized and weighted, we can see additional insights:
+
+- The Java documentation has the highest overall rating.
+- The Swift documentation has the lowest overall rating.
+
+> **How would you rate your experience using the current OTel documentation for
+> the following languages and components?**
+>
+> | Language or component | Poor | Okay | Great | Total responses | Normalized & weighted |
+> | :-------------------- | :--: | :--: | :---: | :-------------: | :-------------------: |
+> | Java | 3 | 16 | 8 | 27 | 7.3333 |
+> | PHP | 1 | 4 | 2 | 7 | 7.1429 |
+> | GO | 6 | 12 | 9 | 27 | 7.1111 |
+> | Collector | 9 | 17 | 11 | 37 | 6.8108 |
+> | Python | 6 | 17 | 8 | 31 | 6.7742 |
+> | Kubernetes | 6 | 20 | 6 | 32 | 6.3750 |
+> | C++ | 0 | 7 | 0 | 7 | 6.0000 |
+> | JavaScript | 3 | 19 | 2 | 24 | 6.0000 |
+> | Ruby | 1 | 5 | 1 | 7 | 6.2857 |
+> | Rust | 4 | 4 | 2 | 10 | 5.6000 |
+> | .NET | 4 | 8 | 2 | 14 | 5.7143 |
+> | Erlang | 1 | 6 | 0 | 7 | 5.4286 |
+> | FaaS | 5 | 7 | 0 | 12 | 4.3333 |
+> | Swift | 3 | 3 | 0 | 6 | 4.0000 |
+> | **Total** | 52 | 145 | 51 | | |
+
+If we combine these insights, we can see that the documentation used by the most
+people that needs the most work is the JavaScript documentation.
+
+> **Where should we focus our improvement efforts?** _JavaScript is one of
+> the six most-used docs sets, but its rating is the lowest._
+>
+> | Language or component | Poor | Okay | Great | Total responses | Normalized & weighted |
+> | :-------------------- | :--: | :--: | :---: | :-------------: | :-------------------: |
+> | GO | 6 | 12 | 9 | 27 | 7.1111 |
+> | Java | 3 | 16 | 8 | 27 | 7.3333 |
+> | JavaScript | 3 | 19 | 2 | 24 | 6.0000 |
+> | Python | 6 | 17 | 8 | 31 | 6.7742 |
+> | Collector | 9 | 17 | 11 | 37 | 6.8108 |
+> | Kubernetes | 6 | 20 | 6 | 32 | 6.3750 |
+
+## Learn more
+
+For detailed survey results, see [Docs Usability Survey Responses].
+
+## Your feedback is essential
+
+Thanks again to everyone who participated in the survey! Your feedback is
+crucial for guiding the future development of OpenTelemetry and ensuring it
+continues to meet your evolving needs. Stay connected and learn about upcoming
+surveys through the following channels:
+
+- [#otel-sig-end-user Slack channel](https://cloud-native.slack.com/archives/C01RT3MSWGZ)
+- [#otel-comms Slack channel](https://cloud-native.slack.com/archives/C02UN96HZH6)
+- [End user resources page](/community/end-user/)
diff --git a/content/en/blog/2024/otel-docs-survey/installation-instructions.png b/content/en/blog/2024/otel-docs-survey/installation-instructions.png
new file mode 100644
index 000000000000..f92c07860fe6
Binary files /dev/null and b/content/en/blog/2024/otel-docs-survey/installation-instructions.png differ
diff --git a/content/en/blog/2024/otel-docs-survey/top-six-bar.png b/content/en/blog/2024/otel-docs-survey/top-six-bar.png
new file mode 100644
index 000000000000..dbd3f6217711
Binary files /dev/null and b/content/en/blog/2024/otel-docs-survey/top-six-bar.png differ
diff --git a/content/en/blog/2024/otel-docs-survey/troubleshooting.png b/content/en/blog/2024/otel-docs-survey/troubleshooting.png
new file mode 100644
index 000000000000..4284c43754ea
Binary files /dev/null and b/content/en/blog/2024/otel-docs-survey/troubleshooting.png differ
diff --git a/content/en/blog/2024/otel-errors/index.md b/content/en/blog/2024/otel-errors/index.md
index c102787383ff..02e8dcf5362f 100644
--- a/content/en/blog/2024/otel-errors/index.md
+++ b/content/en/blog/2024/otel-errors/index.md
@@ -5,8 +5,8 @@ date: 2024-04-19
author: >-
[Reese Lee](https://github.com/reese-lee) (New Relic), [Adriana
Villela](https://github.com/avillela) (ServiceNow)
-cSpell:ignore: Dalle
canonical_url: https://newrelic.com/blog/how-to-relic/dude-wheres-my-error
+cSpell:ignore: Dalle
---
![A confused penguin trying to learn about errors and exceptions. Image generated with AI using Dalle3 via Bing Copilot](penguin-chalkboard.jpg)
diff --git a/content/en/blog/2024/profiling.md b/content/en/blog/2024/profiling.md
index c55baec614b5..c290ceff299c 100644
--- a/content/en/blog/2024/profiling.md
+++ b/content/en/blog/2024/profiling.md
@@ -58,7 +58,7 @@ utilization at a code-level and allows for this profiling data to be stored,
queried, and analyzed over time and across different attributes. It’s an
important technique for developers and performance engineers to understand
exactly what’s happening in their code. OpenTelemetry’s
-[profiling signal](https://github.com/open-telemetry/oteps/blob/main/text/profiles/0239-profiles-data-model.md)
+[profiling signal](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/0239-profiles-data-model.md)
expands upon the work that has been done in this space and, as a first for the
industry, connects profiles with other telemetry signals from applications and
infrastructure. This allows developers and operators to correlate resource
@@ -120,7 +120,7 @@ many more.
2024 promises to be another big year for OpenTelemetry as we continue to
implement and stabilize our existing tracing, metrics, and log signals while
adding support for profiling, client-side RUM, and more. It’s a great time to
-get involved – check out our [website](https://opentelemetry.io) to learn more!
+get involved! To learn more, check out the rest of the [website](/).
[^1]: Pending due diligence and review by the OpenTelemetry maintainers.
diff --git a/content/en/blog/2024/prom-and-otel/index.md b/content/en/blog/2024/prom-and-otel/index.md
index d20f9799e948..da8f5746dc74 100644
--- a/content/en/blog/2024/prom-and-otel/index.md
+++ b/content/en/blog/2024/prom-and-otel/index.md
@@ -5,8 +5,8 @@ date: 2024-09-04
author: >-
[Reese Lee](https://github.com/reese-lee) (New Relic), [Adriana
Villela](https://github.com/avillela) (ServiceNow)
-cSpell:ignore: hashmod kubelet sharded targetallocator
canonical_url: https://newrelic.com/blog/how-to-relic/prometheus-and-opentelemetry-better-together
+cSpell:ignore: hashmod kubelet sharded targetallocator
---
![Image of a Greek god holding a torch with the Prometheus logo, and OTel logo](Prom-and-otel-logos.png)
diff --git a/content/en/blog/2024/prometheus-compatibility-survey/index.md b/content/en/blog/2024/prometheus-compatibility-survey/index.md
index 83a6fa8e2cca..85352faadf43 100644
--- a/content/en/blog/2024/prometheus-compatibility-survey/index.md
+++ b/content/en/blog/2024/prometheus-compatibility-survey/index.md
@@ -121,7 +121,7 @@ should not generally be included in the metric name. Prometheus conventions
[recommend](https://prometheus.io/docs/practices/naming/#metric-names) that the
unit be included as a suffix of the metric name. OpenMetrics goes a step further
and
-[requires this unit suffix](https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#unit).
+[requires this unit suffix](https://github.com/prometheus/OpenMetrics/blob/v1.0.0/specification/OpenMetrics.md#unit).
Currently, when exporting in Prometheus format from an OpenTelemetry SDK, the
unit is added as a suffix to the metric name.
diff --git a/content/en/blog/2024/state-profiling.md b/content/en/blog/2024/state-profiling.md
index 70010be554bd..7a22e712194a 100644
--- a/content/en/blog/2024/state-profiling.md
+++ b/content/en/blog/2024/state-profiling.md
@@ -2,7 +2,6 @@
title: The State of Profiling
linkTitle: Profiling state
date: 2024-10-25
-cSpell:ignore: Baeyens Florian Geisendörfer Kalkanis Lehner Mathieu Rühsen
author: >-
[Damien Mathieu](https://github.com/dmathieu) (Elastic), [Pablo
Baeyens](https://github.com/mx-psi) (Datadog), [Felix
@@ -13,6 +12,7 @@ author: >-
Rühsen](https://github.com/rockdaboot) (Elastic)
issue: https://github.com/open-telemetry/opentelemetry.io/issues/5477
sig: Profiling SIG
+cSpell:ignore: Baeyens Florian Geisendörfer Kalkanis Lehner Mathieu Rühsen
---
A little over six months ago, OpenTelemetry announced
diff --git a/content/en/blog/2024/year-in-review.md b/content/en/blog/2024/year-in-review.md
new file mode 100644
index 000000000000..9a0693bab409
--- /dev/null
+++ b/content/en/blog/2024/year-in-review.md
@@ -0,0 +1,230 @@
+---
+title: OpenTelemetry.io 2024 review
+linkTitle: Year in review
+date: 2024-12-17
+author: >-
+ [Severin Neumann](https://github.com/svrnm) (Cisco), [Patrice
+ Chalin](https://github.com/chalin/) (CNCF), [Tiffany
+ Hrabusa](https://github.com/tiffany76) (Grafana Labs)
+sig: Comms
+cSpell:ignore: Chalin Hrabusa opentelemetrybot
+---
+
+As 2024 draws to a close, we reflect on the year and share some insights and
+accomplishments from [SIG Communications][Comms meetings], the team responsible
+for managing this website, blog, and documentation.
+
+## Key achievements of 2024
+
+Several key accomplishments stand out in our efforts to make OpenTelemetry
+documentation more accessible, user-friendly, and impactful for our global
+community.
+
+### Multilingual documentation {#multilingual-documentation}
+
+A major accomplishment this year was achieving multilingual support with the
+launch of our [localized documentation](/blog/2024/docs-localized/). Thanks to
+the efforts of localization teams, over 120 pages were translated from English
+into other languages. The available translations include:
+
+- [Chinese](/zh/)
+- [French](/fr/)
+- [Japanese](/ja/)
+- [Portuguese](/pt/)
+- [Spanish](/es/)
+
+A big thank you to everyone who contributed to this initiative. These
+translations make OpenTelemetry more accessible, enhancing the user experience
+for our global audience.
+
+### Information Architecture (IA) improvements {#ia-improvements}
+
+To **improve readership experience** and make OpenTelemetry **documentation more
+intuitive and accessible**, we undertook important updates to our Information
+Architecture (IA) this year. These changes were driven by the need to better
+organize content, clarify the purpose of key sections, and provide a more
+structured and user-friendly experience for end-users and developers.
+
+Key IA updates include:
+
+- Renaming the `Instrumentation` section to
+ [Language APIs & SDKs](/docs/languages/) to better reflect its purpose and set
+ clearer expectations for users.
+- Moving `Automatic Instrumentation` into the new
+ [Zero-code Instrumentation](/docs/zero-code/) section to more clearly
+ distinguish between instrumentation APIs & SDKs and tools like the Java agent,
+ used to inject telemetry.
+- Following these updates, the Java SIG [proposed] and [reorganized their
+ documentation][java-reorg], introducing substantial improvements to the
+ structure and clarity of the content. The bulk of this effort is reflected in
+ these PRs:
+
+ - [Refactor Java SDK and configuration #4966][#4966]
+ - [Refactor Java instrumentation #5276][#5276]
+ - [Move performance to Java agent, merge Javadoc into API page #5590][#5590]
+
+
+ Kudos to [Jack Berg] and the [Java SIG] for their exemplary leadership in
+ improving language-SIG documentation!
+ {.mt-3}
+
+Next year, we aim to redesign how OpenTelemetry is introduced to beginners,
+ensuring a smoother and more accessible learning experience. If you're
+passionate about making OpenTelemetry easier to understand and use, we’d love
+your contributions — [join us][#2427] in this collaborative effort.
+
+[#2427]: https://github.com/open-telemetry/community/pull/2427
+[#4966]: https://github.com/open-telemetry/opentelemetry.io/pull/4966
+[#5276]: https://github.com/open-telemetry/opentelemetry.io/pull/5276
+[#5590]: https://github.com/open-telemetry/opentelemetry.io/pull/5590
+[Jack Berg]: https://github.com/jack-berg
+[Java SIG]:
+ https://docs.google.com/document/d/1D7ZD93LxSWexHeztHohRp5yeoTzsi9Dj1HRm7Tad-hM
+[proposed]: https://github.com/open-telemetry/opentelemetry.io/discussions/4853
+[java-reorg]:
+ https://github.com/open-telemetry/opentelemetry.io/pulls?q=is%3Apr+java+is%3Aclosed+label%3Asig%3Ajava+merged%3A2024-01-01..2024-12-31+author%3Ajack-berg
+
+## Year in numbers {#year-in-numbers}
+
+### Contributions
+
+In [December 2022], we started [monthly releases] of the website so that we
+could regularly summarize activities and highlight significant contributions.
+These releases allow us to track progress over time and perform long-term
+comparisons.
+
+For instance, comparing the periods [December 2022 to November 2023] and
+[December 2023 to November 2024], we observed an upward trend in contributions:
+
+- **Commits** increased 33% from 1,011 to 1,340
+- **Contributors** grew 15% from 92 to 106
+- The only metric that declined was the **number of files changed**, which
+ decreased from 1,864 to 1,624 (13%)
+
+Since the repository’s inception in April 2019, the community has seen
+remarkable growth, with:
+
+- 3,824 merged pull requests (3,982 commits) by
+- 768 contributors
+
+Thank you to every contributor for helping to build and improve the
+OpenTelemetry website. Your efforts make a difference!
+
+[December 2022]:
+ https://github.com/open-telemetry/opentelemetry.io/releases/tag/2022.12
+[December 2022 to November 2023]:
+ https://github.com/open-telemetry/opentelemetry.io/compare/2022.12...2023.11
+[December 2023 to November 2024]:
+ https://github.com/open-telemetry/opentelemetry.io/compare/2023.12...2024.11
+[monthly releases]: https://github.com/open-telemetry/opentelemetry.io/releases
+
+### Which pages were the most popular?
+
+According to our publicly available [analytics] data, [opentelemetry.io](/) was
+viewed **12 million** times across 4 million sessions this year. This marks a
+**16% increase** over last year's nearly 10 million views and over 3 million
+sessions.
+
+The most popular pages and sections of the documentation were:
+
+| Page/Section | Views | % [^1] |
+| ------------------------ | ----: | -----: |
+| [What is OpenTelemetry?] | 290K | 2.4% |
+| [Collector] | 1.3M | 10.5% |
+| [Concepts] | 1.2M | 9.8% |
+| [Demo] | 829K | 6.7% |
+| [Ecosystem] | 500K | 4.0% |
+
+[analytics]: https://lookerstudio.google.com/s/tSTKxK1ECeU
+[Collector]: /docs/collector
+[Concepts]: /docs/what-is-opentelemetry/
+[Demo]: /docs/demo/
+[Ecosystem]: /ecosystem/
+[What is OpenTelemetry?]: /docs/what-is-opentelemetry/
+
+[^1]: Percentage of the site-total 12M views.
+
+### Fun trivia {#trivia}
+
+Did you know that:
+
+- "OpenTelemetry" occurs 7.3K times in the English website pages, making it the
+ 3rd most frequent word after "the" and "to." The word "collector" is used 3.2K
+ times, putting it in 11th place!
+- The [Collector landing page] has been the most updated file since its
+ creation, with 91 changes.
+- With 511 commits (27K additions, and 10K deletions) the [opentelemetrybot] is
+ the fourth most active contributor. Go bots!
+- The record for the PR with the most comments this year—and of all time is held
+ by:
+
+ - [Generative AI updates blog post (#5575)][#5575], with 150 comments!
+
+
+ A close second goes to:
+ {.mt-3}
+
+ - [Portuguese translation of Go instrumentation][#5380], with 146 comments
+
+[#5380]: https://github.com/open-telemetry/opentelemetry.io/pull/5380
+[#5575]: https://github.com/open-telemetry/opentelemetry.io/pull/5575
+[Collector landing page]: /docs/collector/
+[opentelemetrybot]: https://github.com/opentelemetrybot
+
+## Amazing Community {#amazing-community}
+
+With [1.3K PRs], we collectively contributed an equally impressive number of
+reviews to ensure that content is accurate, valuable, aligned with our
+documentation goals, and easy to read and understand.
+
+In addition to PRs, contributors created nearly [500 issues] and engaged in many
+[discussions], reporting bugs, suggesting improvements, and driving
+collaboration. Each of these efforts reflects our community's dedication to
+maintaining the quality of OpenTelemetry docs.
+
+We are fortunate to have many contributors who take on responsibilities,
+including:
+
+- **Approvers and maintainers** from other SIGs who co-own parts of the docs
+- **Localization teams** who oversee translations into various languages
+- **The OpenTelemetry community**, whose contributions make all the difference
+ — every drive-by edit and typo fix counts!
+- **SIG Communications team members**, for their contributions and for
+ orchestrating it all!
+
+Thank you to everyone who contributed their time and expertise to OpenTelemetry
+docs this year!
+
+[500 issues]:
+ https://github.com/open-telemetry/opentelemetry.io/issues?q=is%3Aissue+created%3A2024-01-01..2024-12-31
+[1.3K PRs]:
+ https://github.com/open-telemetry/opentelemetry.io/pulls?q=is%3Apr+is%3Amerged+merged%3A2024-01-01..2024-12-31
+
+## Join us in 2025
+
+A big shout-out to everyone for making 2024 a successful year! We look forward
+to continuing our collaboration in 2025.
+
+Whether you're an end user, a contributor, or simply enthusiastic about
+OpenTelemetry, we welcome your participation. You can [get involved] by raising
+[issues], participating in [discussions], or [submitting PRs].
+
+You can also join us:
+
+- On the [CNCF Slack](https://slack.cncf.io/) at any one of the many
+ `#otel`-prefixed channels.
+- In [Comms meetings], held every other Monday at 10:00 AM Pacific time.
+
+Together, we can make 2025 another amazing year for [opentelemetry.io](/)!
+
+_[Cross-posted] to the [CNCF blog]._
+
+[CNCF blog]: https://www.cncf.io/blog/
+[Comms meetings]:
+ https://docs.google.com/document/d/1wW0jLldwXN8Nptq2xmgETGbGn9eWP8fitvD5njM-xZY
+[Cross-posted]:
+ https://www.cncf.io/blog/2024/12/20/opentelemetry-io-2024-review/
+[discussions]: https://github.com/open-telemetry/opentelemetry.io/discussions
+[get involved]: /docs/contributing/
+[issues]: https://github.com/open-telemetry/opentelemetry.io/issues
+[submitting PRs]: /docs/contributing/pull-requests/
diff --git a/content/en/blog/2025/_index.md b/content/en/blog/2025/_index.md
new file mode 100644
index 000000000000..a426ecf8bf8e
--- /dev/null
+++ b/content/en/blog/2025/_index.md
@@ -0,0 +1,9 @@
+---
+title: 2025
+weight: -2025
+outputs: [HTML, RSS]
+---
+
+## Happy New Year!
+
+Amazing posts are on their way for 2025 — check back soon.
diff --git a/content/en/blog/_index.md b/content/en/blog/_index.md
index 4b8d78607c2c..59ef757d54a2 100644
--- a/content/en/blog/_index.md
+++ b/content/en/blog/_index.md
@@ -8,8 +8,10 @@ redirects:
- { from: 'index.xml', to: '2024/index.xml 302!' }
outputs: [HTML, RSS]
htmltest:
- # 2024-11-07 DO NOT COPY the following IgnoreDirs to non-en pages because handles all locales.
+ # 2024-11-07 DO NOT COPY the following IgnoreDirs to non-en pages because it handles all locales.
IgnoreDirs:
# Ignore blog index pages for all locales and in all blog sections (top-level and years)
- ^(../)?blog/(\d+/)?page/\d+
+ # Ignore old blog posts
+ - ^(../)?blog/20(19|21|22|23)/
---
diff --git a/content/en/community/marketing-guidelines.md b/content/en/community/marketing-guidelines.md
index 35c20ca77caf..aed53f5f3402 100644
--- a/content/en/community/marketing-guidelines.md
+++ b/content/en/community/marketing-guidelines.md
@@ -1,8 +1,8 @@
---
title: OpenTelemetry Marketing Guidelines for Contributing Organizations
linkTitle: Marketing Guidelines
-cSpell:ignore: devstats
weight: 999
+cSpell:ignore: devstats
---
OpenTelemetry (aka OTel) is a collaboration among end-users, adjacent OSS
diff --git a/content/en/docs/collector/_index.md b/content/en/docs/collector/_index.md
index 0aae375deea3..ea422d429eb2 100644
--- a/content/en/docs/collector/_index.md
+++ b/content/en/docs/collector/_index.md
@@ -3,7 +3,7 @@ title: Collector
description: Vendor-agnostic way to receive, process and export telemetry data.
aliases: [collector/about]
cascade:
- vers: 0.115.1
+ vers: 0.117.0
weight: 270
---
diff --git a/content/en/docs/collector/architecture.md b/content/en/docs/collector/architecture.md
index fdbd2d0600f2..091423d7ed41 100644
--- a/content/en/docs/collector/architecture.md
+++ b/content/en/docs/collector/architecture.md
@@ -83,7 +83,7 @@ service:
```
The previous example defines a pipeline for the traces type of telemetry data,
-with three receivers, two processors, and three exporters.
+with two receivers, two processors, and two exporters.
### Receivers
diff --git a/content/en/docs/collector/configuration.md b/content/en/docs/collector/configuration.md
index dc600b5c45ad..0a78db729990 100644
--- a/content/en/docs/collector/configuration.md
+++ b/content/en/docs/collector/configuration.md
@@ -350,14 +350,28 @@ processors:
# Data sources: traces, metrics, logs
batch:
- # Data sources: metrics
+ # Data sources: metrics, metrics, logs
filter:
+ error_mode: ignore
+ traces:
+ span:
+ - 'attributes["container.name"] == "app_container_1"'
+ - 'resource.attributes["host.name"] == "localhost"'
+ - 'name == "app_3"'
+ spanevent:
+ - 'attributes["grpc"] == true'
+ - 'IsMatch(name, ".*grpc.*")'
metrics:
- include:
- match_type: regexp
- metric_names:
- - prefix/.*
- - prefix_.*
+ metric:
+ - 'name == "my.metric" and resource.attributes["my_label"] == "abc123"'
+ - 'type == METRIC_DATA_TYPE_HISTOGRAM'
+ datapoint:
+ - 'metric.type == METRIC_DATA_TYPE_SUMMARY'
+ - 'resource.attributes["service.name"] == "my_service_name"'
+ logs:
+ log_record:
+ - 'IsMatch(body, ".*password.*")'
+ - 'severity_number < SEVERITY_NUMBER_WARN'
# Data sources: traces, metrics, logs
memory_limiter:
@@ -401,10 +415,14 @@ Exporters send data to one or more backends or destinations. Exporters can be
pull or push based, and may support one or more
[data sources](/docs/concepts/signals/).
-The `exporters` section contains exporters configuration. Most exporters require
-configuration to specify at least the destination, as well as security settings,
-like authentication tokens or TLS certificates. Any setting you specify
-overrides the default values, if present.
+Each key within the `exporters` section defines an exporter instance, The key
+follows the `type/name` format, where `type` specifies the exporter type (e.g.,
+`otlp`, `kafka`, `prometheus`), and `name` (optional) can be appended to provide
+a unique name for multiple instance of the same type.
+
+Most exporters require configuration to specify at least the destination, as
+well as security settings, like authentication tokens or TLS certificates. Any
+setting you specify overrides the default values, if present.
> Configuring an exporter does not enable it. Exporters are enabled by adding
> them to the appropriate pipelines within the [service](#service) section.
diff --git a/content/en/docs/collector/deployment/gateway/index.md b/content/en/docs/collector/deployment/gateway/index.md
index 6b3dae479b81..ed10bf0c74ad 100644
--- a/content/en/docs/collector/deployment/gateway/index.md
+++ b/content/en/docs/collector/deployment/gateway/index.md
@@ -251,3 +251,45 @@ Cons:
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor
[spanmetrics-connector]:
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/spanmetricsconnector
+
+## Multiple collectors and the single-writer principle
+
+All metric data streams within OTLP must have a
+[single writer](/docs/specs/otel/metrics/data-model/#single-writer). When
+deploying multiple collectors in a gateway configuration, it's important to
+ensure that all metric data streams have a single writer and a globally unique
+identity.
+
+### Potential problems
+
+Concurrent access from multiple applications that modify or report on the same
+data can lead to data loss or degraded data quality. For example, you might see
+inconsistent data from multiple sources on the same resource, where the
+different sources can overwrite each other because the resource is not uniquely
+identified.
+
+There are patterns in the data that may provide some insight into whether this
+is happening or not. For example, upon visual inspection, a series with
+unexplained gaps or jumps in the same series may be a clue that multiple
+collectors are sending the same samples. You might also see errors in your
+backend. For example, with a Prometheus backend:
+
+`Error on ingesting out-of-order samples`
+
+This error could indicate that identical targets exist in two jobs, and the
+order of the timestamps is incorrect. For example:
+
+- Metric `M1` received at `T1` with a timestamp 13:56:04 with value `100`
+- Metric `M1` received at `T2` with a timestamp 13:56:24 with value `120`
+- Metric `M1` received at `T3` with a timestamp 13:56:04 with value `110`
+- Metric `M1` received at time 13:56:24 with value `120`
+- Metric `M1` received at time 13:56:04 with value `110`
+
+### Best practices
+
+- Use the
+ [Kubernetes attributes processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor)
+ to add labels to different Kubernetes resources.
+- Use the
+ [resource detector processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md)
+ to detect resource information from the host and collect resource metadata.
diff --git a/content/en/docs/collector/installation.md b/content/en/docs/collector/installation.md
index 492531bd2131..cdafb4c1893f 100644
--- a/content/en/docs/collector/installation.md
+++ b/content/en/docs/collector/installation.md
@@ -1,8 +1,8 @@
---
title: Install the Collector
+weight: 2
# prettier-ignore
cSpell:ignore: darwin dpkg GOARCH journalctl kubectl otelcorecol pprof tlsv zpages
-weight: 2
---
You can deploy the OpenTelemetry Collector on a wide variety of operating
diff --git a/content/en/docs/collector/internal-telemetry.md b/content/en/docs/collector/internal-telemetry.md
index f125988bdbe8..55914dc16883 100644
--- a/content/en/docs/collector/internal-telemetry.md
+++ b/content/en/docs/collector/internal-telemetry.md
@@ -25,9 +25,26 @@ You can configure how internal metrics are generated and exposed by the
Collector. By default, the Collector generates basic metrics about itself and
exposes them using the OpenTelemetry Go
[Prometheus exporter](https://github.com/open-telemetry/opentelemetry-go/tree/main/exporters/prometheus)
-for scraping at `http://127.0.0.1:8888/metrics`. You can expose the endpoint to
-one specific or all network interfaces when needed. For containerized
-environments, you might want to expose this port on a public interface.
+for scraping at `http://127.0.0.1:8888/metrics`.
+
+The Collector can push its internal metrics to an OTLP backend via the following
+configuration:
+
+```yaml
+service:
+ telemetry:
+ metrics:
+ readers:
+ - periodic:
+ exporter:
+ otlp:
+ protocol: grpc/protobuf
+ endpoint: http://localhost:14317
+```
+
+Alternatively, you can expose the Prometheus endpoint to one specific or all
+network interfaces when needed. For containerized environments, you might want
+to expose this port on a public interface.
Set the Prometheus config under `service::telemetry::metrics`:
@@ -105,7 +122,7 @@ journalctl | grep otelcol | grep Error
{{% /tab %}} {{< /tabpane >}}
The following configuration can be used to emit internal logs from the Collector
-to an OTLP/gRPC backend:
+to an OTLP/HTTP backend:
```yaml
service:
@@ -115,7 +132,7 @@ service:
- batch:
exporter:
otlp:
- protocol: grpc/protobuf
+ protocol: http/protobuf
endpoint: https://backend:4317
```
@@ -151,69 +168,6 @@ Note that the `tracer_provider` section there corresponds to `traces` here.
[kitchen-sink-config]:
https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/kitchen-sink.yaml
-### Self-monitoring
-
-The Collector can be configured to push its own telemetry to an
-[OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver)
-and send the data through configured pipelines. In the following example, the
-Collector is configured to push metrics, traces, and logs every 10s using OTLP
-gRPC to `localhost:14317`:
-
-```yaml
-receivers:
- otlp/internal:
- protocols:
- grpc:
- endpoint: localhost:14317
-exporters:
- debug:
-service:
- pipelines:
- metrics:
- receivers: [otlp/internal]
- exporters: [debug]
- traces:
- receivers: [otlp/internal]
- exporters: [debug]
- telemetry:
- metrics:
- readers:
- - periodic:
- interval: 10000
- exporter:
- otlp:
- protocol: grpc/protobuf
- endpoint: http://localhost:14317
- traces:
- processors:
- - batch:
- exporter:
- otlp:
- protocol: grpc/protobuf
- endpoint: http://localhost:14317
- logs:
- processors:
- - batch:
- exporter:
- otlp:
- protocol: grpc/protobuf
- endpoint: http://localhost:14317
-```
-
-{{% alert title="Caution" color="warning" %}}
-
-When self-monitoring, the Collector collects its own telemetry and sends it to
-the desired backend for analysis. This can be a risky practice. If the Collector
-is underperforming, its self-monitoring capability could be impacted. As a
-result, the self-monitored telemetry might not reach the backend in time for
-critical analysis.
-
-Moreover, sending internal telemetry through the Collector's own pipelines can
-create a continuous loop of spans, metric points, or logs, putting undue strain
-on the Collector's performance. This setup should not be used in production.
-
-{{% /alert %}}
-
## Types of internal telemetry
The OpenTelemetry Collector aims to be a model of observable service by clearly
diff --git a/content/en/docs/collector/quick-start.md b/content/en/docs/collector/quick-start.md
index d782ced91ca6..7cca2334c99e 100644
--- a/content/en/docs/collector/quick-start.md
+++ b/content/en/docs/collector/quick-start.md
@@ -1,10 +1,9 @@
---
title: Quick start
-cSpell:ignore: docker dokey dpkg okey telemetrygen
description: Setup and collect telemetry in minutes!
aliases: [getting-started]
weight: 1
-cSpell:ignore: gobin
+cSpell:ignore: docker dokey dpkg gobin okey telemetrygen
---
diff --git a/content/en/docs/concepts/instrumentation/libraries.md b/content/en/docs/concepts/instrumentation/libraries.md
index 38a19054ad73..f299f171f037 100644
--- a/content/en/docs/concepts/instrumentation/libraries.md
+++ b/content/en/docs/concepts/instrumentation/libraries.md
@@ -22,7 +22,7 @@ and document hooks. Other advantages provided by native instrumentation include:
various consumption scenarios using a wide variety of well-documented
OpenTelemetry extensibility points.
-![ Native Instrumentation vs instrumentation libraries](/img/libraries-instrumentation.svg)
+![ Native Instrumentation vs instrumentation libraries](../native-vs-libraries.svg)
## Semantic conventions
@@ -115,7 +115,7 @@ to help you decide how to minimize dependency conflicts:
- While your instrumentation stabilizes, consider shipping it as a separate
package, so that it never causes issues for users who don't use it. You can
keep it in your repository, or
- [add it to OpenTelemetry](https://github.com/open-telemetry/oteps/blob/main/text/0155-external-modules.md#contrib-components),
+ [add it to OpenTelemetry](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0155-external-modules.md#contrib-components),
so it ships with other instrumentation libraries.
- Semantic conventions are [stable, but subject to evolution][]: while this does
not cause any functional issues, you might need to update your instrumentation
diff --git a/content/en/docs/concepts/instrumentation/native-vs-libraries.svg b/content/en/docs/concepts/instrumentation/native-vs-libraries.svg
new file mode 100755
index 000000000000..f7afa432b2d6
--- /dev/null
+++ b/content/en/docs/concepts/instrumentation/native-vs-libraries.svg
@@ -0,0 +1,186 @@
+
diff --git a/content/en/docs/concepts/instrumentation/zero-code.md b/content/en/docs/concepts/instrumentation/zero-code/index.md
similarity index 98%
rename from content/en/docs/concepts/instrumentation/zero-code.md
rename to content/en/docs/concepts/instrumentation/zero-code/index.md
index 14a158f40975..035bf2952cda 100644
--- a/content/en/docs/concepts/instrumentation/zero-code.md
+++ b/content/en/docs/concepts/instrumentation/zero-code/index.md
@@ -13,6 +13,8 @@ quickly gain some observability for a service without having to use the
OpenTelemetry API & SDK for
[code-based instrumentation](/docs/concepts/instrumentation/code-based).
+![Zero Code](./zero-code.svg)
+
Zero-code instrumentation adds the OpenTelemetry API and SDK capabilities to
your application typically as an agent or agent-like installation. The specific
mechanisms involved may differ by language, ranging from bytecode manipulation,
diff --git a/content/en/docs/concepts/instrumentation/zero-code/zero-code.svg b/content/en/docs/concepts/instrumentation/zero-code/zero-code.svg
new file mode 100644
index 000000000000..6fb577835258
--- /dev/null
+++ b/content/en/docs/concepts/instrumentation/zero-code/zero-code.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/signals/_index.md b/content/en/docs/concepts/signals/_index.md
index d1f2b7d21a97..13b250861d7a 100644
--- a/content/en/docs/concepts/signals/_index.md
+++ b/content/en/docs/concepts/signals/_index.md
@@ -20,7 +20,7 @@ OpenTelemetry currently supports [traces](/docs/concepts/signals/traces),
[metrics](/docs/concepts/signals/metrics), [logs](/docs/concepts/signals/logs)
and [baggage](/docs/concepts/signals/baggage). _Events_ are a specific type of
log, and
-[_profiles_ are being worked on](https://github.com/open-telemetry/oteps/blob/main/text/profiles/0212-profiling-vision.md)
+[_profiles_ are being worked on](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/0212-profiling-vision.md)
by the Profiling Working Group.
[signals]: /docs/specs/otel/glossary/#signals
diff --git a/content/en/docs/concepts/signals/metrics.md b/content/en/docs/concepts/signals/metrics.md
index 62569d57f920..98dddec38d5a 100644
--- a/content/en/docs/concepts/signals/metrics.md
+++ b/content/en/docs/concepts/signals/metrics.md
@@ -68,7 +68,7 @@ The instrument kind is one of the following:
continuous changes, but only to the aggregated value (e.g., current queue
size).
- **Gauge**: Measures a current value at the time it is read. An example would
- be the fuel gauge in a vehicle. Gauges are asynchronous.
+ be the fuel gauge in a vehicle. Gauges are synchronous.
- **Asynchronous Gauge**: Same as the **Gauge**, but is collected once for each
export. Could be used if you don't have access to the continuous changes, but
only to the aggregated value.
diff --git a/content/en/docs/concepts/signals/traces.md b/content/en/docs/concepts/signals/traces.md
index a0624d769c01..0b6b330ee1ac 100644
--- a/content/en/docs/concepts/signals/traces.md
+++ b/content/en/docs/concepts/signals/traces.md
@@ -1,8 +1,8 @@
---
title: Traces
weight: 1
-cSpell:ignore: Guten
description: The path of a request through your application.
+cSpell:ignore: Guten
---
**Traces** give us the big picture of what happens when a request is made to an
@@ -312,6 +312,9 @@ trace. Now, they are causally associated with one another.
Links are optional but serve as a good way to associate trace spans with one
another.
+For more information regarding Span Links, see
+[Link](/docs/specs/otel/trace/api/#link).
+
### Span Status
Each span has a status. The three possible values are:
diff --git a/content/en/docs/contributing/development.md b/content/en/docs/contributing/development.md
index 434eade6a876..74f03654048f 100644
--- a/content/en/docs/contributing/development.md
+++ b/content/en/docs/contributing/development.md
@@ -1,13 +1,12 @@
---
title: Development setup and commands to build, serve, and more
linkTitle: Dev setup and more
-description:
- Learn how to set up a development environment for the opentelemetry.io site.
+description: Learn how to set up a development environment for this website.
weight: 60
---
The following instructions explain how to set up a development environment for
-the website.
+this website.
## Cloud-IDE setup
@@ -31,7 +30,8 @@ website files.
## Local setup
-1. [Fork][] and then [clone][] this repository.
+1. [Fork][] and then [clone][] the website repository at
+ <{{% _param github_repo %}}>.
2. Go to the repository directory.
3. Install or upgrade to the [**active LTS** release][nodejs-rel] of Node.js.
We recommend using [nvm][] to manage your Node installation. Under Linux,
diff --git a/content/en/docs/contributing/issues.md b/content/en/docs/contributing/issues.md
index 37442bd9d135..588c0bf998e2 100644
--- a/content/en/docs/contributing/issues.md
+++ b/content/en/docs/contributing/issues.md
@@ -4,9 +4,9 @@ description:
How to fix an existing issue, or report a bug, security risk, or potential
improvement.
weight: 10
-cSpell:ignore: prepopulated
_issues: https://github.com/open-telemetry/opentelemetry.io/issues
_issue: https://github.com/open-telemetry/opentelemetry.io/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A
+cSpell:ignore: prepopulated
---
## Fixing an existing issue
diff --git a/content/en/docs/demo/_index.md b/content/en/docs/demo/_index.md
index 5eaecbffd280..d21b43875c50 100644
--- a/content/en/docs/demo/_index.md
+++ b/content/en/docs/demo/_index.md
@@ -29,7 +29,8 @@ here.
| C++ | | | [Currency Service](services/currency/) |
| Go | | [Checkout Service](services/checkout/), [Product Catalog Service](services/product-catalog/) | [Checkout Service](services/checkout/), [Product Catalog Service](services/product-catalog/) |
| Java | [Ad Service](services/ad/) | | [Ad Service](services/ad/) |
-| JavaScript | | [Frontend](services/frontend/) | [Frontend](services/frontend/), [Payment Service](services/payment/) |
+| JavaScript | | | [Payment Service](services/payment/) |
+| TypeScript | | [Frontend](services/frontend/), [React Native App](services/react-native-app/) | [Frontend](services/frontend/) |
| Kotlin | | [Fraud Detection Service](services/fraud-detection/) | |
| PHP | | [Quote Service](services/quote/) | [Quote Service](services/quote/) |
| Python | [Recommendation Service](services/recommendation/) | | [Recommendation Service](services/recommendation/) |
@@ -54,6 +55,7 @@ found here:
- [Recommendation Service](services/recommendation/)
- [Shipping Service](services/shipping/)
- [Image Provider Service](services/imageprovider/)
+- [React Native App](services/react-native-app/)
## Scenarios
diff --git a/content/en/docs/demo/architecture.md b/content/en/docs/demo/architecture.md
index 245ff539c225..d703c51c8f1f 100644
--- a/content/en/docs/demo/architecture.md
+++ b/content/en/docs/demo/architecture.md
@@ -32,6 +32,7 @@ quoteservice(Quote Service):::php
recommendationservice(Recommendation Service):::python
shippingservice(Shipping Service):::rust
queue[(queue (Kafka))]:::java
+react-native-app(React Native App):::typescript
adservice ---->|gRPC| flagd
@@ -73,6 +74,8 @@ recommendationservice -->|gRPC| productcatalogservice
recommendationservice -->|gRPC| flagd
shippingservice -->|HTTP| quoteservice
+
+react-native-app -->|HTTP| frontendproxy
end
classDef dotnet fill:#178600,color:white;
@@ -123,7 +126,7 @@ Follow these links for the current state of
demo applications.
The collector is configured in
-[otelcol-config.yml](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otelcollector/otelcol-config.yml),
+[otelcol-config.yml](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/otel-collector/otelcol-config.yml),
alternative exporters can be configured here.
```mermaid
diff --git a/content/en/docs/demo/services/_index.md b/content/en/docs/demo/services/_index.md
index b09a35f1c016..12ae06ed9b98 100644
--- a/content/en/docs/demo/services/_index.md
+++ b/content/en/docs/demo/services/_index.md
@@ -15,10 +15,11 @@ To visualize request flows, see the [Service Diagram](../architecture/).
| [currencyservice](currency/) | C++ | Converts one money amount to another currency. Uses real values fetched from European Central Bank. It's the highest QPS service. |
| [emailservice](email/) | Ruby | Sends users an order confirmation email (mock/). |
| [frauddetectionservice](fraud-detection/) | Kotlin | Analyzes incoming orders and detects fraud attempts (mock/). |
-| [frontend](frontend/) | JavaScript | Exposes an HTTP server to serve the website. Does not require sign up / login and generates session IDs for all users automatically. |
+| [frontend](frontend/) | TypeScript | Exposes an HTTP server to serve the website. Does not require sign up / login and generates session IDs for all users automatically. |
| [loadgenerator](load-generator/) | Python/Locust | Continuously sends requests imitating realistic user shopping flows to the frontend. |
| [paymentservice](payment/) | JavaScript | Charges the given credit card info (mock/) with the given amount and returns a transaction ID. |
| [productcatalogservice](product-catalog/) | Go | Provides the list of products from a JSON file and ability to search products and get individual products. |
| [quoteservice](quote/) | PHP | Calculates the shipping costs, based on the number of items to be shipped. |
| [recommendationservice](recommendation/) | Python | Recommends other products based on what's given in the cart. |
| [shippingservice](shipping/) | Rust | Gives shipping cost estimates based on the shopping cart. Ships items to the given address (mock/). |
+| [react-native-app](react-native-app/) | TypeScript | React Native mobile application that provides a UI on top of the shopping services. |
diff --git a/content/en/docs/demo/services/cart/exemplars.png b/content/en/docs/demo/services/cart/exemplars.png
new file mode 100644
index 000000000000..6bb7a08973df
Binary files /dev/null and b/content/en/docs/demo/services/cart/exemplars.png differ
diff --git a/content/en/docs/demo/services/cart.md b/content/en/docs/demo/services/cart/index.md
similarity index 53%
rename from content/en/docs/demo/services/cart.md
rename to content/en/docs/demo/services/cart/index.md
index 075f250e838c..29edafef087c 100644
--- a/content/en/docs/demo/services/cart.md
+++ b/content/en/docs/demo/services/cart/index.md
@@ -31,8 +31,8 @@ Action appResourceBuilder =
builder.Services.AddOpenTelemetry()
.ConfigureResource(appResourceBuilder)
.WithTracing(tracerBuilder => tracerBuilder
+ .AddSource("OpenTelemetry.Demo.Cart")
.AddRedisInstrumentation(
- cartStore.GetConnection(),
options => options.SetVerboseDatabaseStatements = true)
.AddAspNetCoreInstrumentation()
.AddGrpcClientInstrumentation()
@@ -87,12 +87,85 @@ Action appResourceBuilder =
builder.Services.AddOpenTelemetry()
.ConfigureResource(appResourceBuilder)
.WithMetrics(meterBuilder => meterBuilder
+ .AddMeter("OpenTelemetry.Demo.Cart")
.AddProcessInstrumentation()
.AddRuntimeInstrumentation()
.AddAspNetCoreInstrumentation()
+ .SetExemplarFilter(ExemplarFilterType.TraceBased)
.AddOtlpExporter());
```
+### Exemplars
+
+[Exemplars](/docs/specs/otel/metrics/data-model/#exemplars) are configured in
+the Cart service with trace-based exemplar filter, which enables the
+OpenTelemetry SDK to attach exemplars to metrics.
+
+First it creates a `CartActivitySource`, `Meter` and two `Histograms`. The
+histogram keeps track from the latency of the methods `AddItem` and `GetCart`,
+as those are two important methods in the Cart service.
+
+Those two methods are critical to the Cart service as users shouldn't wait too
+long when adding an item to the cart, or when viewing their cart before moving
+to the checkout process.
+
+```cs
+private static readonly ActivitySource CartActivitySource = new("OpenTelemetry.Demo.Cart");
+private static readonly Meter CartMeter = new Meter("OpenTelemetry.Demo.Cart");
+private static readonly Histogram addItemHistogram = CartMeter.CreateHistogram(
+ "app.cart.add_item.latency",
+ advice: new InstrumentAdvice
+ {
+ HistogramBucketBoundaries = [ 500000, 600000, 700000, 800000, 900000, 1000000, 1100000 ]
+ });
+private static readonly Histogram getCartHistogram = CartMeter.CreateHistogram(
+ "app.cart.get_cart.latency",
+ advice: new InstrumentAdvice
+ {
+ HistogramBucketBoundaries = [ 300000, 400000, 500000, 600000, 700000, 800000, 900000 ]
+ });
+```
+
+Note that a custom bucket boundary is also defined, as the default values don't
+fit the microseconds results Cart service has.
+
+Once the variables are defined, the latency of the execution of each method is
+tracked with a `StopWatch` as follows:
+
+```cs
+var stopwatch = Stopwatch.StartNew();
+
+(method logic)
+
+addItemHistogram.Record(stopwatch.ElapsedTicks);
+```
+
+To connect it all together, in the Traces pipeline, it is required to add the
+created source. (Already present in the snippet above, but added here to
+reference):
+
+```cs
+.AddSource("OpenTelemetry.Demo.Cart")
+```
+
+And, in the Metrics pipeline, the `Meter` and the `ExemplarFilter`:
+
+```cs
+.AddMeter("OpenTelemetry.Demo.Cart")
+.SetExemplarFilter(ExemplarFilterType.TraceBased)
+```
+
+To visualize the Exemplars, navigate to Grafana
+ > Dashboards > Demo > Cart Service Exemplars.
+
+Exemplars appear as special "diamond-shaped dots" on the 95th percentile chart
+or as small squares on the heatmap chart. Select any exemplar to view its data,
+which includes the timestamp of the measurement, the raw value, and the trace
+context at the time of recording. The `trace_id` enables navigation to the
+tracing backend (Jaeger, in this case).
+
+![Cart Service Exemplars](exemplars.png)
+
## Logs
Logs are configured in the .NET dependency injection container on
diff --git a/content/en/docs/demo/services/react-native-app.md b/content/en/docs/demo/services/react-native-app.md
new file mode 100644
index 000000000000..6b4f9ca8d261
--- /dev/null
+++ b/content/en/docs/demo/services/react-native-app.md
@@ -0,0 +1,149 @@
+---
+title: React Native App
+cSpell:ignore: typeof
+---
+
+The React Native app provides a mobile UI for users on Android and iOS devices
+to interact with the demo's services. It is built with
+[Expo](https://docs.expo.dev/get-started/introduction/) and uses Expo's
+file-based routing to layout the screens for the app.
+
+[React Native app source](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/react-native-app/)
+
+## Instrumentation
+
+The application uses the OpenTelemetry packages to instrument the application at
+the JS layer.
+
+{{% alert title="Important" color="warning" %}}
+
+The JS OTel packages are supported for node and web environments. While they
+work for React Native as well, they are not explicitly supported for that
+environment, where they might break compatibility with minor version updates or
+require workarounds. Building JS OTel package support for React Native is an
+area of active development.
+
+{{% /alert %}}
+
+The main entry point for the application is `app/_layout.tsx` where a hook is
+used to initialize the instrumentation and make sure it is loaded before
+displaying the UI:
+
+```typescript
+import { useTracer } from '@/hooks/useTracer';
+
+const { loaded: tracerLoaded } = useTracer();
+```
+
+`hooks/useTracer.ts` contains all the code for setting up instrumentation
+including initializing a TracerProvider, establishing an OTLP export,
+registering trace context propagators, and registering auto-instrumentation of
+network requests.
+
+```typescript
+import {
+ CompositePropagator,
+ W3CBaggagePropagator,
+ W3CTraceContextPropagator,
+} from '@opentelemetry/core';
+import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
+import { BatchSpanProcessor } from '@opentelemetry/sdk-trace-base';
+import { XMLHttpRequestInstrumentation } from '@opentelemetry/instrumentation-xml-http-request';
+import { FetchInstrumentation } from '@opentelemetry/instrumentation-fetch';
+import { registerInstrumentations } from '@opentelemetry/instrumentation';
+import { Resource } from '@opentelemetry/resources';
+import {
+ ATTR_DEVICE_ID,
+ ATTR_OS_NAME,
+ ATTR_OS_VERSION,
+ ATTR_SERVICE_NAME,
+ ATTR_SERVICE_VERSION,
+} from '@opentelemetry/semantic-conventions/incubating';
+import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
+import getLocalhost from '@/utils/Localhost';
+import { useEffect, useState } from 'react';
+import {
+ getDeviceId,
+ getSystemVersion,
+ getVersion,
+} from 'react-native-device-info';
+import { Platform } from 'react-native';
+import { SessionIdProcessor } from '@/utils/SessionIdProcessor';
+
+const Tracer = async () => {
+ const localhost = await getLocalhost();
+
+ const resource = new Resource({
+ [ATTR_SERVICE_NAME]: 'react-native-app',
+ [ATTR_OS_NAME]: Platform.OS,
+ [ATTR_OS_VERSION]: getSystemVersion(),
+ [ATTR_SERVICE_VERSION]: getVersion(),
+ [ATTR_DEVICE_ID]: getDeviceId(),
+ });
+
+ const provider = new WebTracerProvider({
+ resource,
+ spanProcessors: [
+ new BatchSpanProcessor(
+ new OTLPTraceExporter({
+ url: `http://${localhost}:${process.env.EXPO_PUBLIC_FRONTEND_PROXY_PORT}/otlp-http/v1/traces`,
+ }),
+ {
+ scheduledDelayMillis: 500,
+ },
+ ),
+ new SessionIdProcessor(),
+ ],
+ });
+
+ provider.register({
+ propagator: new CompositePropagator({
+ propagators: [
+ new W3CBaggagePropagator(),
+ new W3CTraceContextPropagator(),
+ ],
+ }),
+ });
+
+ registerInstrumentations({
+ instrumentations: [
+ // Some tiptoeing required here, propagateTraceHeaderCorsUrls is required to make the instrumentation
+ // work in the context of a mobile app even though we are not making CORS requests. `clearTimingResources` must
+ // be turned off to avoid using the web-only Performance API
+ new FetchInstrumentation({
+ propagateTraceHeaderCorsUrls: /.*/,
+ clearTimingResources: false,
+ }),
+
+ // The React Native implementation of fetch is simply a polyfill on top of XMLHttpRequest:
+ // https://github.com/facebook/react-native/blob/7ccc5934d0f341f9bc8157f18913a7b340f5db2d/packages/react-native/Libraries/Network/fetch.js#L17
+ // Because of this when making requests using `fetch` there will an additional span created for the underlying
+ // request made with XMLHttpRequest. Since in this demo calls to /api/ are made using fetch, turn off
+ // instrumentation for that path to avoid the extra spans.
+ new XMLHttpRequestInstrumentation({
+ ignoreUrls: [/\/api\/.*/],
+ }),
+ ],
+ });
+};
+
+export interface TracerResult {
+ loaded: boolean;
+}
+
+export const useTracer = (): TracerResult => {
+ const [loaded, setLoaded] = useState(false);
+
+ useEffect(() => {
+ if (!loaded) {
+ Tracer()
+ .catch(() => console.warn('failed to setup tracer'))
+ .finally(() => setLoaded(true));
+ }
+ }, [loaded]);
+
+ return {
+ loaded,
+ };
+};
+```
diff --git a/content/en/docs/demo/services/recommendation.md b/content/en/docs/demo/services/recommendation.md
index 037913e2dda3..6482594d814f 100644
--- a/content/en/docs/demo/services/recommendation.md
+++ b/content/en/docs/demo/services/recommendation.md
@@ -8,7 +8,7 @@ cSpell:ignore: cpython instrumentor NOTSET
This service is responsible to get a list of recommended products for the user
based on existing product IDs the user is browsing.
-[Recommendation service source](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/recommendationservice/)
+[Recommendation service source](https://github.com/open-telemetry/opentelemetry-demo/blob/main/src/recommendation/)
## Auto-instrumentation
diff --git a/content/en/docs/kubernetes/operator/automatic.md b/content/en/docs/kubernetes/operator/automatic.md
index 887273ba3e12..c5c6b53601eb 100644
--- a/content/en/docs/kubernetes/operator/automatic.md
+++ b/content/en/docs/kubernetes/operator/automatic.md
@@ -531,9 +531,6 @@ permissions:
```yaml
securityContext:
- capabilities:
- add:
- - SYS_PTRACE
privileged: true
runAsUser: 0
```
diff --git a/content/en/docs/languages/cpp/getting-started.md b/content/en/docs/languages/cpp/getting-started.md
index d499e7762445..5856aa9df65e 100644
--- a/content/en/docs/languages/cpp/getting-started.md
+++ b/content/en/docs/languages/cpp/getting-started.md
@@ -1,8 +1,8 @@
---
title: Getting Started
description: Get telemetry for your app in less than 5 minutes!
-cSpell:ignore: oatpp rolldice
weight: 10
+cSpell:ignore: oatpp rolldice
---
This page will show you how to get started with OpenTelemetry in C++.
diff --git a/content/en/docs/languages/erlang/_index.md b/content/en/docs/languages/erlang/_index.md
index 5435eb39a8c2..97cef197be2d 100644
--- a/content/en/docs/languages/erlang/_index.md
+++ b/content/en/docs/languages/erlang/_index.md
@@ -5,7 +5,6 @@ description: >
A language-specific implementation of OpenTelemetry in
Erlang/Elixir.
-cSpell:ignore: ecto
cascade:
versions:
otelSdk: 1.3
@@ -14,6 +13,7 @@ cascade:
otelPhoenix: 1.1
otelCowboy: 0.2
otelEcto: 1.2
+cSpell:ignore: ecto
---
{{% docs/languages/index-intro erlang %}}
diff --git a/content/en/docs/languages/go/exporters.md b/content/en/docs/languages/go/exporters.md
index e63e37deb9e0..cd9fb54a4458 100644
--- a/content/en/docs/languages/go/exporters.md
+++ b/content/en/docs/languages/go/exporters.md
@@ -86,7 +86,7 @@ Here's how you can create an exporter with default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp"
"go.opentelemetry.io/otel/sdk/trace"
@@ -106,7 +106,7 @@ Here's how you can create an exporter with default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
"go.opentelemetry.io/otel/sdk/trace"
@@ -142,7 +142,7 @@ Here's how you can create an exporter with default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp"
"go.opentelemetry.io/otel/sdk/metric"
@@ -162,7 +162,7 @@ Here's how you can create an exporter with default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc"
"go.opentelemetry.io/otel/sdk/metric"
@@ -186,7 +186,7 @@ default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/prometheus"
"go.opentelemetry.io/otel/sdk/metric"
@@ -212,7 +212,7 @@ Here's how you can create an exporter with default configuration:
```go
import (
- "context"
+ "context"
"go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp"
"go.opentelemetry.io/otel/sdk/log"
diff --git a/content/en/docs/languages/java/_index.md b/content/en/docs/languages/java/_index.md
index cbfa6a1ba438..2a880adb4df9 100644
--- a/content/en/docs/languages/java/_index.md
+++ b/content/en/docs/languages/java/_index.md
@@ -6,10 +6,10 @@ description: >-
aliases: [/java, /java/metrics, /java/tracing]
cascade:
vers:
- instrumentation: 2.10.0
+ instrumentation: 2.11.0
otel: 1.45.0
- contrib: 1.41.0
- semconv: 1.28.0
+ contrib: 1.42.0
+ semconv: 1.29.0
weight: 18
---
diff --git a/content/en/docs/languages/java/api.md b/content/en/docs/languages/java/api.md
index be8781e027fd..9d8d4fb4b62c 100644
--- a/content/en/docs/languages/java/api.md
+++ b/content/en/docs/languages/java/api.md
@@ -147,7 +147,7 @@ public class ContextUsage {
try (Scope scope = context.makeCurrent()) {
// The current context now contains the added value
// output => context value: value
- System.out.println("context value: " + context.get(exampleContextKey));
+ System.out.println("context value: " + Context.current().get(exampleContextKey));
}
// The local context var still contains the added value
diff --git a/content/en/docs/languages/java/configuration.md b/content/en/docs/languages/java/configuration.md
index f2128bd6e673..62fe0e14a753 100644
--- a/content/en/docs/languages/java/configuration.md
+++ b/content/en/docs/languages/java/configuration.md
@@ -704,6 +704,6 @@ alone dictate SDK configuration. {{% /alert %}}
For additional details, consult the following resources:
-- [Usage documentation](https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/incubator#file-configuration)
-- [Example with Java agent](https://github.com/open-telemetry/opentelemetry-java-examples/tree/main/javaagent#file-configuration)
-- [Example without Java agent](https://github.com/open-telemetry/opentelemetry-java-examples/tree/main/file-configuration)
+- [Usage documentation](https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/incubator#declarative-configuration)
+- [Example with Java agent](https://github.com/open-telemetry/opentelemetry-java-examples/tree/main/javaagent#declarative-configuration)
+- [Example without Java agent](https://github.com/open-telemetry/opentelemetry-java-examples/tree/main/declarative-configuration)
diff --git a/content/en/docs/languages/java/sdk.md b/content/en/docs/languages/java/sdk.md
index cf7b49074622..a3b741eb2263 100644
--- a/content/en/docs/languages/java/sdk.md
+++ b/content/en/docs/languages/java/sdk.md
@@ -435,8 +435,7 @@ Span exporters built-in to the SDK and maintained by the community in
| `InterceptableSpanExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes spans to a flexible interceptor before exporting. |
| `KafkaSpanExporter` | `io.opentelemetry.contrib:opentelemetry-kafka-exporter:{{% param vers.contrib %}}-alpha` | Exports spans by writing to a Kafka topic. |
-**[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation
-details.
+**[1]**: See [OTLP exporters](#otlp-exporters) for implementation details.
The following code snippet demonstrates `SpanExporter` programmatic
configuration:
@@ -767,8 +766,7 @@ Metric exporters built-in to the SDK and maintained by the community in
| `OtlpStdoutMetricExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs metrics to `System.out` in the OTLP [JSON file encoding][] (experimental). |
| `InterceptableMetricExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes metrics to a flexible interceptor before exporting. |
-**[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation
-details.
+**[1]**: See [OTLP exporters](#otlp-exporters) for implementation details.
The following code snippet demonstrates `MetricExporter` programmatic
configuration:
@@ -1095,8 +1093,7 @@ Span exporters built-in to the SDK and maintained by the community in
| `OtlpStdoutLogRecordExporter` | `io.opentelemetry:opentelemetry-exporter-logging-otlp:{{% param vers.otel %}}` | Logs log records to `System.out` in the OTLP [JSON file encoding][] (experimental). |
| `InterceptableLogRecordExporter` | `io.opentelemetry.contrib:opentelemetry-processors:{{% param vers.contrib %}}-alpha` | Passes log records to a flexible interceptor before exporting. |
-**[1]**: See [OTLP exporter sender](#otlp-exporter-senders) for implementation
-details.
+**[1]**: See [OTLP exporters](#otlp-exporters) for implementation details.
**[2]**: `OtlpJsonLoggingLogRecordExporter` logs to JUL, and may cause infinite
loops (i.e. JUL -> SLF4J -> Logback -> OpenTelemetry Appender -> OpenTelemetry
@@ -1362,20 +1359,29 @@ public class IgnoreExportErrorsFilter implements java.util.logging.Filter {
io.opentelemetry.sdk.trace.export.BatchSpanProcessor = io.opentelemetry.extension.logging.IgnoreExportErrorsFilter
```
-### OTLP exporter senders
+### OTLP exporters
The [span exporter](#spanexporter), [metric exporter](#metricexporter), and
-[log exporter](#logrecordexporter) discuss OTLP exporters of the form:
+[log exporter](#logrecordexporter) sections describe OTLP exporters of the form:
-- `OtlpHttp{Signal}Exporter`s export data via OTLP `http/protobuf`.
-- `OtlpGrpc{Signal}Exporter`s export data via OTLP `grpc`.
+- `OtlpHttp{Signal}Exporter`, which exports data via OTLP `http/protobuf`
+- `OtlpGrpc{Signal}Exporter`, which exports data via OTLP `grpc`
The exporters for all signals are available via
-`io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}`.
+`io.opentelemetry:opentelemetry-exporter-otlp:{{% param vers.otel %}}`, and have
+significant overlap across `grpc` and `http/protobuf` versions of the OTLP
+protocol, and between signals. The following sections elaborate on these key
+concepts:
-Internally, these exporters depend on various client libraries to execute HTTP
-and gRPC requests. There is no single HTTP / gRPC client library which satisfies
-all use cases in the Java ecosystem:
+- [Senders](#senders): an abstraction for a different HTTP / gRPC client
+ libraries.
+- [Authentication](#authentication) options for OTLP exporters.
+
+#### Senders
+
+The OTLP exporters depend on various client libraries to execute HTTP and gRPC
+requests. There is no single HTTP / gRPC client library which satisfies all use
+cases in the Java ecosystem:
- Java 11+ brings the built-in `java.net.http.HttpClient`, but
`opentelemetry-java` needs to support Java 8+ users, and this can't be used to
@@ -1403,6 +1409,118 @@ add a dependency on the alternative.
you must also add a dependency on a
[gRPC transport implementations](https://github.com/grpc/grpc-java#transport).
+#### Authentication
+
+The OTLP exporters provide mechanisms for static and dynamic header-based
+authentication, and for mTLS.
+
+If using
+[zero-code SDK autoconfigure](../configuration/#zero-code-sdk-autoconfigure)
+with environment variables and system properties, see
+[relevant system properties](../configuration/#properties-exporters):
+
+- `otel.exporter.otlp.headers` for static header-based authentication.
+- `otel.exporter.otlp.client.key`, `otel.exporter.otlp.client.certificate` for
+ mTLS authentication.
+
+The following code snippet demonstrates programmatic configuration of static and
+dynamic header-based authentication:
+
+
+
+```java
+package otel;
+
+import io.opentelemetry.exporter.otlp.http.logs.OtlpHttpLogRecordExporter;
+import io.opentelemetry.exporter.otlp.http.metrics.OtlpHttpMetricExporter;
+import io.opentelemetry.exporter.otlp.http.trace.OtlpHttpSpanExporter;
+import java.time.Duration;
+import java.time.Instant;
+import java.util.Collections;
+import java.util.Map;
+import java.util.function.Supplier;
+
+public class OtlpAuthenticationConfig {
+ public static void staticAuthenticationHeader(String endpoint) {
+ // If the OTLP destination accepts a static, long-lived authentication header like an API key,
+ // set it as a header.
+ // This reads the API key from the OTLP_API_KEY env var to avoid hard coding the secret in
+ // source code.
+ String apiKeyHeaderName = "api-key";
+ String apiKeyHeaderValue = System.getenv("OTLP_API_KEY");
+
+ // Initialize OTLP Span, Metric, and LogRecord exporters using a similar pattern
+ OtlpHttpSpanExporter spanExporter =
+ OtlpHttpSpanExporter.builder()
+ .setEndpoint(endpoint)
+ .addHeader(apiKeyHeaderName, apiKeyHeaderValue)
+ .build();
+ OtlpHttpMetricExporter metricExporter =
+ OtlpHttpMetricExporter.builder()
+ .setEndpoint(endpoint)
+ .addHeader(apiKeyHeaderName, apiKeyHeaderValue)
+ .build();
+ OtlpHttpLogRecordExporter logRecordExporter =
+ OtlpHttpLogRecordExporter.builder()
+ .setEndpoint(endpoint)
+ .addHeader(apiKeyHeaderName, apiKeyHeaderValue)
+ .build();
+ }
+
+ public static void dynamicAuthenticationHeader(String endpoint) {
+ // If the OTLP destination requires a dynamic authentication header, such as a JWT which needs
+ // to be periodically refreshed, use a header supplier.
+ // Here we implement a simple supplier which adds a header of the form "Authorization: Bearer
+ // ", where is fetched from refreshBearerToken every 10 minutes.
+ String username = System.getenv("OTLP_USERNAME");
+ String password = System.getenv("OTLP_PASSWORD");
+ Supplier