diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md new file mode 100644 index 000000000000..63c825bee4f9 --- /dev/null +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -0,0 +1,21 @@ + diff --git a/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md b/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md deleted file mode 100644 index 0fe4d48c2fb8..000000000000 --- a/.github/PULL_REQUEST_TEMPLATE/DOCS_UPDATE.md +++ /dev/null @@ -1,6 +0,0 @@ -## Docs PR Checklist - - - -- [ ] This PR is for a documentation page whose authoritative copy is in the - opentelemetry.io repository. diff --git a/.github/workflows/auto-update-community-members.yml b/.github/workflows/auto-update-community-members.yml new file mode 100644 index 000000000000..402545a20011 --- /dev/null +++ b/.github/workflows/auto-update-community-members.yml @@ -0,0 +1,45 @@ +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@v3 + 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' + 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/check-links.yml b/.github/workflows/check-links.yml index ebf94483c8a9..15d384f545aa 100644 --- a/.github/workflows/check-links.yml +++ b/.github/workflows/check-links.yml @@ -31,13 +31,22 @@ jobs: cache: npm cache-dependency-path: tmp/package-ci.json - - run: npm install --omit=optional + - run: | + npm install --omit=optional + git restore package.json + + - name: Git submodules properly pinned? + run: | + npm run seq pin:submodule + echo "If the diff check below fails, then update .gitmodules by pinning the named git" + echo "submodule(s); or undo the submodule update(s) if it happened by mistake." + npm run _diff:fail + - run: npm run log:check:links continue-on-error: true - name: Any files need updating? run: | - git restore package.json - echo "If the following fails, then either run 'npm run fix:htmltest-config' locally or '/fix:htmltest-config' in GitHub" + echo "If the diff fails due to .htmltest, then either run 'npm run fix:htmltest-config' locally or '/fix:htmltest-config' in GitHub" npm run _diff:fail - uses: actions/upload-artifact@v4 with: diff --git a/.github/workflows/pr-actions.yml b/.github/workflows/pr-actions.yml index d0c36fc24460..0917cd66f6bb 100644 --- a/.github/workflows/pr-actions.yml +++ b/.github/workflows/pr-actions.yml @@ -69,10 +69,10 @@ jobs: - run: | case $PR_ACTION in - all|refcache) + all|refcache|text) npm install --omit=optional ;& - dict|filenames|format|htmltest-config|markdown|submodule*) + *) npm run fix:$PR_ACTION ;; esac diff --git a/.github/workflows/scripts/update-registry-versions.sh b/.github/workflows/scripts/update-registry-versions.sh index b07947730b13..c6774ca236c9 100755 --- a/.github/workflows/scripts/update-registry-versions.sh +++ b/.github/workflows/scripts/update-registry-versions.sh @@ -3,6 +3,7 @@ UPDATE_YAML="yq eval -i" GIT=git GH=gh +NPM=npm FILES="${FILES:-./data/registry/*.yml}" @@ -16,6 +17,7 @@ elif [[ "$1" != "-f" ]]; then UPDATE_YAML="yq eval" GIT="echo > DRY RUN: git " GH="echo > DRY RUN: gh " + NPM="echo > DRY RUN: npm " else # Local execution with -f flag (force real vs. dry run) shift @@ -59,6 +61,12 @@ for yaml_file in ${FILES}; do hex) curl -s "https://hex.pm/api/packages/$package_name" | jq -r '.releases | max_by(.inserted_at) | .version' ;; + maven) + groupid=$(echo "${package_name}" | cut -d/ -f1) + artifactid=$(echo "${package_name}" | cut -d/ -f2) + #curl -s "https://search.maven.org/solrsearch/select?q=g:com.google.inject+AND+a:guice&core=gav&rows=20&wt=json" | jq -r '.response.docs[0].v' + curl -s "https://search.maven.org/solrsearch/select?q=g:${groupid}+AND+a:${artifactid}&core=gav&rows=20&wt=json" | jq -r '.response.docs[0].v' + ;; *) echo "Registry not supported." ;; @@ -74,9 +82,11 @@ for yaml_file in ${FILES}; do echo "${yaml_file}: Package name and/or registry are missing in the YAML file." else # Get latest version - latest_version=$(get_latest_version "$name" "$registry") + latest_version=$(get_latest_version "$name" "$registry" || echo "Could not fetch version.") - if [ "$latest_version" == "Registry not supported." ]; then + if [ "$latest_version" == "Could not fetch version." ]; then + echo "${yaml_file} ($registry): Registry not supported."; + elif [ "$latest_version" == "Registry not supported." ]; then echo "${yaml_file} ($registry): Registry not supported."; elif [ -z "$latest_version" ]; then echo "${yaml_file} ($registry): Could not get latest version from registry." @@ -110,12 +120,22 @@ if [ "$existing_pr_count" -gt 0 ]; then exit 0 fi -$GIT checkout -b "$branch" -$GIT commit -a -m "$message" -$GIT push --set-upstream origin "$branch" +if [[ -n $(git status --porcelain) ]]; then + echo "Versions have been updated, formatting and pushing changes." + + $NPM run fix:format + + $GIT checkout -b "$branch" + $GIT commit -a -m "$message" + $GIT push --set-upstream origin "$branch" -body_file=$(mktemp) -echo -en "${body}" >> "${body_file}" + body_file=$(mktemp) + echo -en "${body}" >> "${body_file}" -echo "Submitting auto-update PR '$message'." -$GH pr create --title "$message" --body-file "${body_file}" \ No newline at end of file + echo "Submitting auto-update PR '$message'." + $GH pr create --title "$message" --body-file "${body_file}" + +else + echo "No changes detected." + exit 0 +fi \ No newline at end of file diff --git a/.gitmodules b/.gitmodules index a78309399754..db570f1fafb6 100644 --- a/.gitmodules +++ b/.gitmodules @@ -15,11 +15,11 @@ [submodule "content-modules/opentelemetry-proto"] path = content-modules/opentelemetry-proto url = https://github.com/open-telemetry/opentelemetry-proto - otlp-pin = v1.3.2 + otlp-pin = v1.4.0 [submodule "content-modules/semantic-conventions"] path = content-modules/semantic-conventions url = https://github.com/open-telemetry/semantic-conventions - semconv-pin = v1.28.0 + semconv-pin = v1.29.0 [submodule "content-modules/opamp-spec"] path = content-modules/opamp-spec url = https://github.com/open-telemetry/opamp-spec @@ -31,4 +31,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 = 0f736ec + javaexamples-pin = 63cc9b4 diff --git a/.htmltest.yml b/.htmltest.yml index 58ac783f79db..f5e73895ca1a 100644 --- a/.htmltest.yml +++ b/.htmltest.yml @@ -11,31 +11,6 @@ IgnoreDirs: # Ignore blog index pages for all locales and in all blog sections (top-level and years) - ^(../)?blog/(\d+/)?page/\d+ # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^es/docs/concepts/glossary/ - - ^es/docs/concepts/instrumentation/zero-code/ - - ^es/docs/concepts/signals/baggage/ - - ^es/docs/zero-code/php/ - # TODO drop next line after https://github.com/open-telemetry/opentelemetry.io/issues/5423 is fixed for ja pages: - - ^ja/docs/concepts/instrumentation/libraries/ - # TODO drop next lines after https://github.com/open-telemetry/opentelemetry.io/issues/5555 is fixed for these pages: - - ^pt/docs/concepts/components/ - - ^pt/docs/concepts/glossary/ - - ^pt/docs/concepts/signals/baggage/ - - ^pt/docs/languages/erlang/instrumentation/ - - ^pt/docs/languages/erlang/sampling/ - - ^pt/docs/languages/js/instrumentation/ - - ^pt/docs/languages/js/sampling/ - - ^pt/docs/languages/net/instrumentation/ - - ^pt/docs/languages/net/libraries/ - - ^pt/docs/languages/net/shim/ - - ^pt/docs/languages/php/instrumentation/ - - ^pt/docs/languages/python/instrumentation/ - - ^pt/docs/languages/ruby/instrumentation/ - - ^pt/docs/languages/ruby/sampling/ - - ^pt/docs/zero-code/php/ - # TODO drop next line after https://github.com/open-telemetry/opentelemetry.io/issues/5423 is fixed for pt pages: - - ^pt/docs/concepts/instrumentation/libraries/ - # 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/ # DO NOT EDIT! IgnoreDirs list is auto-generated from markdown file front matter. diff --git a/.prettierignore b/.prettierignore index 594a1db36100..c20589189ab7 100644 --- a/.prettierignore +++ b/.prettierignore @@ -7,7 +7,8 @@ !/layouts/shortcodes /layouts/shortcodes/* !/layouts/shortcodes/docs -/layouts/shortcodes/pt +!/layouts/shortcodes/es +!/layouts/shortcodes/pt /content/ja /content/zh diff --git a/.warnings-skip-list.txt b/.warnings-skip-list.txt index 32b3143e5f78..4a3ee4fd0e35 100644 --- a/.warnings-skip-list.txt +++ b/.warnings-skip-list.txt @@ -1 +1,2 @@ _filename-error +The following package was not found and will be installed diff --git a/README.md b/README.md index 3f4e8247d349..c60044ec0eb3 100644 --- a/README.md +++ b/README.md @@ -44,8 +44,8 @@ We, the OTel Communications SIG, meet every two weeks on Monday at 10:00 PT. Check out the [OpenTelemetry community calendar][] for the Zoom link and any updates to this schedule. -Meeting notes are available as a public [Google doc][]. If you have trouble accessing -the doc, get in touch in the `#otel-comms` channel on [Slack][]. +Meeting notes are available as a public [Google doc][]. If you have trouble +accessing the doc, get in touch in the `#otel-comms` channel on [Slack][]. ## Roles @@ -74,8 +74,8 @@ Here is a list of community roles with current and previous members: - [Morgan McLean](https://github.com/mtwo) - [jparsana](https://github.com/jparsana) -Learn more about roles in the [community repository][]. Thanks to [all who have already -contributed][contributors]! +Learn more about roles in the [community repository][]. Thanks to [all who have +already contributed][contributors]! ## Licenses diff --git a/assets/scss/_registry.scss b/assets/scss/_registry.scss index 06ed0693de9f..9b36c1d0ec61 100644 --- a/assets/scss/_registry.scss +++ b/assets/scss/_registry.scss @@ -39,3 +39,26 @@ .registry-entry { @extend .shadow; } + +#searchForm .btn.btn-outline-success, +.btn-outline-danger, +.btn-outline-secondary { + &:hover { + color: var(--bs-white); + } +} + +@include color-mode(dark) { + @media (prefers-color-scheme: dark) { + .border-default { + border-color: #a3a3a3; + } + .card.registry-entry { + box-shadow: 0 20px 50px rgba(0, 0, 0, 0.8) !important; + } + .card.registry-entry, + .list-group > .list-group-item { + background-color: #262d2c; + } + } +} diff --git a/content-modules/opentelemetry-java-examples b/content-modules/opentelemetry-java-examples index 0f736eca6a4b..63cc9b44310f 160000 --- a/content-modules/opentelemetry-java-examples +++ b/content-modules/opentelemetry-java-examples @@ -1 +1 @@ -Subproject commit 0f736eca6a4b6865fb62b00033a53369e69440f7 +Subproject commit 63cc9b44310f1ac2e7b37e6402fe48e9e0efe3ef diff --git a/content-modules/opentelemetry-proto b/content-modules/opentelemetry-proto index 40b3c1b74676..0adf6aac0045 160000 --- a/content-modules/opentelemetry-proto +++ b/content-modules/opentelemetry-proto @@ -1 +1 @@ -Subproject commit 40b3c1b746767cbc13c2e39da3eaf1a23e54ffdd +Subproject commit 0adf6aac004578b28267394514b2e55ee9cc012f diff --git a/content-modules/semantic-conventions b/content-modules/semantic-conventions index 96f8bda9bab3..0edb9e2b42e3 160000 --- a/content-modules/semantic-conventions +++ b/content-modules/semantic-conventions @@ -1 +1 @@ -Subproject commit 96f8bda9bab363cb01e2441820bc83a5dad15801 +Subproject commit 0edb9e2b42e37739fe53e10623d93809269dd300 diff --git a/content/en/blog/2019/opentelemetry-governance-committee-explained/index.md b/content/en/blog/2019/opentelemetry-governance-committee-explained/index.md index 0d57e712b82d..c32b2e24fb2f 100644 --- a/content/en/blog/2019/opentelemetry-governance-committee-explained/index.md +++ b/content/en/blog/2019/opentelemetry-governance-committee-explained/index.md @@ -74,6 +74,7 @@ your questions! Thanks [Sarah Novotny](https://twitter.com/sarahnovotny) for review and feedback! -_A version of this article was [originally posted][] on [medium.com/opentelemetry](https://medium.com/opentelemetry)._ +_A version of this article was [originally posted][] on +[medium.com/opentelemetry](https://medium.com/opentelemetry)._ [originally posted]: {{% param canonical_url %}} diff --git a/content/en/blog/2021/gc-election.md b/content/en/blog/2021/gc-election.md index 3c477b0e8f57..7fad088401b3 100644 --- a/content/en/blog/2021/gc-election.md +++ b/content/en/blog/2021/gc-election.md @@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/announcing-the-2021-opentelemetr --- The OpenTelemetry project is excited to announce the 2021 OpenTelemetry -Governance Committee (GC) election. For all the details, see the [original post][]. +Governance Committee (GC) election. For all the details, see the [original +post][]. [original post]: {{% param canonical_url %}} diff --git a/content/en/blog/2021/womens-day.md b/content/en/blog/2021/womens-day.md index b06df675da78..65966a157fbd 100644 --- a/content/en/blog/2021/womens-day.md +++ b/content/en/blog/2021/womens-day.md @@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/opentelemetry-observes-internati --- Happy International Women’s Day! The OpenTelemetry project would like to extend -our thanks to all our women contributors. For all the details, see the [original post][]. +our thanks to all our women contributors. For all the details, see the [original +post][]. [original post]: {{% param canonical_url %}} diff --git a/content/en/blog/2022/debug-otel-with-otel/index.md b/content/en/blog/2022/debug-otel-with-otel/index.md index fa89614193d5..4a345339cb98 100644 --- a/content/en/blog/2022/debug-otel-with-otel/index.md +++ b/content/en/blog/2022/debug-otel-with-otel/index.md @@ -229,8 +229,8 @@ in the NGINX module and we need to fix that. ### The fix -To fix our problem we [added some checks to the module for NGINX][], that make sure -that the trace headers are only set once. +To fix our problem we [added some checks to the module for NGINX][], that make +sure that the trace headers are only set once. This fix is contained in the [v1.0.1 release of the otel-webserver-module][]. This means you can update the `Dockerfile` to install the NGINX module like the diff --git a/content/en/blog/2022/exponential-histograms/index.md b/content/en/blog/2022/exponential-histograms/index.md index 4630f7b500c8..e5c666358263 100644 --- a/content/en/blog/2022/exponential-histograms/index.md +++ b/content/en/blog/2022/exponential-histograms/index.md @@ -40,12 +40,13 @@ The SDK is used to configure what happens with the data collected by the API. This typically includes processing it and exporting it out of process for analysis, often to an observability platform. -The API entry point for metrics is the [meter provider][]. It provides meters for -different scopes, where a scope is just a logical unit of application code. For example, -instrumentation for an HTTP client library would have a different scope and therefore -a different meter than instrumentation for a database client library. You use meters -to obtain instruments. You use instruments to report measurements, which consist -of a value and set of attributes. This Java code snippet demonstrates the workflow: +The API entry point for metrics is the [meter provider][]. It provides meters +for different scopes, where a scope is just a logical unit of application code. +For example, instrumentation for an HTTP client library would have a different +scope and therefore a different meter than instrumentation for a database client +library. You use meters to obtain instruments. You use instruments to report +measurements, which consist of a value and set of attributes. This Java code +snippet demonstrates the workflow: ```java OpenTelemetry openTelemetry = // declare OpenTelemetry instance @@ -73,7 +74,8 @@ and when the sum of the things is more important than their individual values the distribution of measurements is relevant for analysis. For example, a histogram is a natural choice for tracking response times for HTTP servers, because it's useful to analyze the distribution of response times to evaluate -SLAs and identify trends. To learn more, see the guidelines for [instrument selection][]. +SLAs and identify trends. To learn more, see the guidelines for [instrument +selection][]. I mentioned earlier that the SDK aggregates measurements from instruments. Each instrument type has a default aggregation strategy (or simply [aggregation][]) @@ -125,10 +127,10 @@ request, you can determine: requests resolve quickly but a small number of requests take a long time and bring down the average. -The second type of OpenTelemetry histogram is the [exponential -bucket histogram][]. Exponential bucket histograms have buckets and bucket -counts, but instead of explicitly defining the bucket boundaries, the boundaries -are computed based on an exponential scale. More specifically, each bucket is +The second type of OpenTelemetry histogram is the [exponential bucket +histogram][]. Exponential bucket histograms have buckets and bucket counts, but +instead of explicitly defining the bucket boundaries, the boundaries are +computed based on an exponential scale. More specifically, each bucket is defined by an index _i_ and has bucket boundaries _(base\*\*i, base\*\*(i+1)]_, where _base\*\*i_ means that _base_ is raised to the power of _i_. The base is derived from a scale factor that is adjustable to reflect the range of reported @@ -197,13 +199,14 @@ large range of measurement values. Let's bring everything together with a proper demonstration comparing explicit bucket histograms to exponential bucket histograms. I've put together some -[example code][] that simulates tracking response time to an HTTP server in milliseconds. -It records one million samples to an explicit bucket histogram with the default buckets, -and to an exponential bucket histogram with a number of buckets that produces roughly -the same size of [OTLP][] -encoded, Gzip-compressed payload as the explicit bucket -defaults. Through trial and error, I determined that ~40 exponential buckets produce -an equivalent payload size to the default explicit bucket histogram with 11 buckets. -(Your results may vary.) +[example code][] that simulates tracking response time to an HTTP server in +milliseconds. It records one million samples to an explicit bucket histogram +with the default buckets, and to an exponential bucket histogram with a number +of buckets that produces roughly the same size of [OTLP][] -encoded, +Gzip-compressed payload as the explicit bucket defaults. Through trial and +error, I determined that ~40 exponential buckets produce an equivalent payload +size to the default explicit bucket histogram with 11 buckets. (Your results may +vary.) I wanted the distribution of samples to reflect what we might see in an actual HTTP server, with bands of response times corresponding to different operations. diff --git a/content/en/blog/2022/instrument-apache-httpd-server/index.md b/content/en/blog/2022/instrument-apache-httpd-server/index.md index b5975f6c7c5d..2dffb1d2b64d 100644 --- a/content/en/blog/2022/instrument-apache-httpd-server/index.md +++ b/content/en/blog/2022/instrument-apache-httpd-server/index.md @@ -8,12 +8,13 @@ cSpell:ignore: Centos centos7 Debajit debuggability libmod uncompress webserver --- If you are using Apache HTTP Server and in dire need of some observability tool -to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][] is -the right candidate for you: it enables tracing of incoming requests to the server -and it will capture the response time of many modules (including `mod_proxy`) involved -in such an incoming request. With that you will get hierarchical time consumption -by each module. This article demonstrates the monitoring capabilities of the OpenTelemetry -Module for Apache HTTP Server and quick guide to get started with the module. +to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][] +is the right candidate for you: it enables tracing of incoming requests to the +server and it will capture the response time of many modules (including +`mod_proxy`) involved in such an incoming request. With that you will get +hierarchical time consumption by each module. This article demonstrates the +monitoring capabilities of the OpenTelemetry Module for Apache HTTP Server and +quick guide to get started with the module. ## Getting Started with OpenTelemetry Module diff --git a/content/en/blog/2022/k8s-metadata/index.md b/content/en/blog/2022/k8s-metadata/index.md index 4a343f878c83..013aae54726e 100644 --- a/content/en/blog/2022/k8s-metadata/index.md +++ b/content/en/blog/2022/k8s-metadata/index.md @@ -172,10 +172,11 @@ reducing the scope of the collector service account to a single namespace. ## Using Resource detector processor -As of [recently][pr#832], the [OpenTelemetry operator][] sets the `OTEL_RESOURCE_ATTRIBUTES` -environment variable on the collector container with the K8s pod attributes. This -lets you to use the resource detector processor, which attaches the environment variable -values to the spans. This only works when the collector is deployed in sidecar mode. +As of [recently][pr#832], the [OpenTelemetry operator][] sets the +`OTEL_RESOURCE_ATTRIBUTES` environment variable on the collector container with +the K8s pod attributes. This lets you to use the resource detector processor, +which attaches the environment variable values to the spans. This only works +when the collector is deployed in sidecar mode. For example, if you deploy the following manifest: 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/2022/kubecon-na.md b/content/en/blog/2022/kubecon-na.md index b46d6417835a..0e36d81a3d2c 100644 --- a/content/en/blog/2022/kubecon-na.md +++ b/content/en/blog/2022/kubecon-na.md @@ -8,8 +8,8 @@ cSpell:ignore: Kowall Logz Pothulapati unconference Vineeth The OpenTelemetry project maintainers, and members of the governance committee and technical committee are excited to be at [KubeCon NA][] in a few weeks! Join -in to meet up in person or virtually for [OpenTelemetry](/) activities in Detroit -from October 24 - 28, 2022. +in to meet up in person or virtually for [OpenTelemetry](/) activities in +Detroit from October 24 - 28, 2022. There are talks, workshops, an unconference as well as a project booth where you are welcome to stop by, say Hi! and tell us about how you are using diff --git a/content/en/blog/2022/otel-demo-app-nomad/index.md b/content/en/blog/2022/otel-demo-app-nomad/index.md index e9b513efb822..7f0ff0eb4cf0 100644 --- a/content/en/blog/2022/otel-demo-app-nomad/index.md +++ b/content/en/blog/2022/otel-demo-app-nomad/index.md @@ -350,8 +350,8 @@ Before I wrap this up, I do want to give a HUGE shoutout to [Luiz Aoqui](https://www.linkedin.com/in/luizaoqui/) of HashiCorp, who helped me tweak my Nomad jobspecs, and to [Riaan Nolan](https://www.linkedin.com/in/riaannolan/), for his continued work -on HashiQube. (Aside, both [Luiz] and [Riaan] were my guests on the [On-Call -Me Maybe Podcast]!) +on HashiQube. (Aside, both [Luiz] and [Riaan] were my guests on the [On-Call Me +Maybe Podcast]!) I will now leave you with a picture of Phoebe the rat, peering out of a pink basket. Doesn’t she look cute? 🥰 diff --git a/content/en/blog/2023/contributing-to-otel/index.md b/content/en/blog/2023/contributing-to-otel/index.md index 3746a3153c30..ac910e12b9f0 100644 --- a/content/en/blog/2023/contributing-to-otel/index.md +++ b/content/en/blog/2023/contributing-to-otel/index.md @@ -25,9 +25,9 @@ projects? I don't know about you, but for me, up until last year, the prospect of contributing to open source was just plain _scary_!! I mean, when you open up a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) -(PR), _[you are putting yourself out there]_, to be judged by those little GitHub -avatars that make up the approvers list for the repository you're contributing to. -YIKES! +(PR), _[you are putting yourself out there]_, to be judged by those little +GitHub avatars that make up the approvers list for the repository you're +contributing to. YIKES! But as scary as the thought of opening a PR might be, it's also SO VERY SATISFYING to see your contributions merged into a codebase. And most diff --git a/content/en/blog/2023/ecs-otel-semconv-convergence.md b/content/en/blog/2023/ecs-otel-semconv-convergence.md index fdb3ec523b12..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 @@ -47,12 +47,13 @@ and join the discussion on our - [Announcement from Elastic][] - [OpenTelemetry Semantic Conventions][] -- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic Conventions][] -- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS) - in OpenTelemetry][] +- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic + Conventions][] +- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS) in + OpenTelemetry][] - [OTEP Pull Request 199: Support Elastic Common Schema in OpenTelemetry][] -- [OTEP Pull Request 222: Support Elastic Common Schema (ECS) - in OpenTelemetry][] +- [OTEP Pull Request 222: Support Elastic Common Schema (ECS) in + OpenTelemetry][] [Announcement from Elastic]: https://elastic.co/blog/ecs-elastic-common-schema-otel-opentelemetry-announcement diff --git a/content/en/blog/2023/exponential-histograms.md b/content/en/blog/2023/exponential-histograms.md index 757201196f14..635c0846a8eb 100644 --- a/content/en/blog/2023/exponential-histograms.md +++ b/content/en/blog/2023/exponential-histograms.md @@ -2,17 +2,18 @@ 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 the -basics of histograms and summaries, explaining the tradeoffs, benefits, and limitations -of each. Because they're easy to understand and demonstrate, those posts focused -on so-called explicit bucket histograms. The exponential bucket histogram, also referred -to as native histogram in Prometheus, is a low-cost, efficient alternative to explicit -bucket histograms. In this post, I go through what they are, how they work, and the -problems they solve that explicit bucket histograms struggle with. +Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over +the basics of histograms and summaries, explaining the tradeoffs, benefits, and +limitations of each. Because they're easy to understand and demonstrate, those +posts focused on so-called explicit bucket histograms. The exponential bucket +histogram, also referred to as native histogram in Prometheus, is a low-cost, +efficient alternative to explicit bucket histograms. In this post, I go through +what they are, how they work, and the problems they solve that explicit bucket +histograms struggle with. ## Types of histograms @@ -129,9 +130,8 @@ relative error = (bucketWidth / 2) / bucketMidpoint = 4.329% ``` -For more information regarding histogram errors, see [OTEP 149][] and the [specification -for -exponential histogram aggregations][]. +For more information regarding histogram errors, see [OTEP 149][] and the +[specification for exponential histogram aggregations][]. ## Choosing a scale 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 49f399a8a3eb..bba363717be0 100644 --- a/content/en/blog/2023/kubecon-eu.md +++ b/content/en/blog/2023/kubecon-eu.md @@ -2,14 +2,14 @@ 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 -technical committee are excited to be at [KubeCon EU][] in Amsterdam from April 18 - -21, 2023! +technical committee are excited to be at [KubeCon EU][] in Amsterdam from April +18 - 21, 2023! Read on to learn about all the things related OpenTelemetry during KubeCon. @@ -41,14 +41,15 @@ Come network with OpenTelemetry maintainers and core contributors during the [OpenTelemetry project meeting](https://sched.co/1JWS7), on Tuesday April 18, 2023 from 16:00 - 17:00. You can attend with a _standard in-person pass_. -[Observability Day][] _fosters collaboration, discussion, and knowledge sharing of -cloud-native observability projects_. This event will be held on April 18, 2023 from -9:00 - 17:00. There will be several sessions on OpenTelemetry as well. +[Observability Day][] _fosters collaboration, discussion, and knowledge sharing +of cloud-native observability projects_. This event will be held on April 18, +2023 from 9:00 - 17:00. There will be several sessions on OpenTelemetry as well. > **IMPORTANT access note**: You > need an _in-person all-access_ pass for on-site access to **Observability -> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, -> you will be able to follow **Observability Day** through a live stream. +> Day**. For details, see [KubeCon registration][]. If you have a virtual +> ticket, you will be able to follow **Observability Day** through a live +> stream. ## OpenTelemetry Project Booth @@ -66,9 +67,9 @@ You will find us in the Solutions Showcase in Hall 5, Kiosk Number 20. You can help us improve the project by sharing your thoughts and feedback about your OpenTelemetry adoption, implementation, and usage! We also invite you to -fill out our [community survey][]. We will create action items from your comments -as appropriate. Check [#otel-user-research][] in CNCF's Slack instance for survey -results and action item updates to come after KubeCon EU. +fill out our [community survey][]. We will create action items from your +comments as appropriate. Check [#otel-user-research][] in CNCF's Slack instance +for survey results and action item updates to come after KubeCon EU. Come join us to listen, learn, and get involved in OpenTelemetry. diff --git a/content/en/blog/2023/kubecon-na.md b/content/en/blog/2023/kubecon-na.md index 6a28a41b229f..9fc9aca998b0 100644 --- a/content/en/blog/2023/kubecon-na.md +++ b/content/en/blog/2023/kubecon-na.md @@ -2,14 +2,14 @@ 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 -technical committee are thrilled to be at [KubeCon NA][] in Chicago from November -6 - 9, 2023. +technical committee are thrilled to be at [KubeCon NA][] in Chicago from +November 6 - 9, 2023. Read on to learn about all the things related OpenTelemetry during KubeCon. @@ -78,14 +78,15 @@ OpenTelemetry maintainers in making OpenTelemetry better for everyone during the ## Co-located Events -[Observability Day][] _fosters collaboration, discussion, and knowledge sharing of -cloud-native observability projects_. This event will be held on November 6, 2023 -from 9am - 5pm. There will be several sessions on OpenTelemetry as well. +[Observability Day][] _fosters collaboration, discussion, and knowledge sharing +of cloud-native observability projects_. This event will be held on November 6, +2023 from 9am - 5pm. There will be several sessions on OpenTelemetry as well. > **IMPORTANT access note**: You > need an _in-person all-access_ pass for on-site access to **Observability -> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, -> you will be able to follow **Observability Day** through a live stream. +> Day**. For details, see [KubeCon registration][]. If you have a virtual +> ticket, you will be able to follow **Observability Day** through a live +> stream. ## OpenTelemetry Project Booth @@ -101,9 +102,9 @@ Project Pavilion. If you’re lucky, you may even pick up some OpenTelemetry swa You can help us improve the project by sharing your thoughts and feedback about your OpenTelemetry adoption, implementation, and usage. We also invite you to -fill out our [community survey][]. We will create action items from your comments -as appropriate. Check [#otel-user-research][] in CNCF's Slack instance for survey -results and action item updates to come after KubeCon NA. +fill out our [community survey][]. We will create action items from your +comments as appropriate. Check [#otel-user-research][] in CNCF's Slack instance +for survey results and action item updates to come after KubeCon NA. ## OpenTelemetry Observatory diff --git a/content/en/blog/2023/logs-collection/index.md b/content/en/blog/2023/logs-collection/index.md index 3f3512516462..7408c916fad2 100644 --- a/content/en/blog/2023/logs-collection/index.md +++ b/content/en/blog/2023/logs-collection/index.md @@ -420,8 +420,8 @@ extend Yoda's code to do the following: [transform or attributes processors](/docs/collector/transforming-telemetry/). 1. Add [tracing](/docs/concepts/signals/traces/) support by emitting spans, where it makes sense. -1. Add an Observability backend such as OpenSearch (along with [Data Prepper]) to - the setup, allowing to ingest spans and logs in OTLP format. +1. Add an Observability backend such as OpenSearch (along with [Data Prepper]) + to the setup, allowing to ingest spans and logs in OTLP format. 1. Once you have traces and logs ingested in a backend, try to correlate these two telemetry signal types in the backend along with a frontend such as Grafana. 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/community-awards-winners.md b/content/en/blog/2024/community-awards-winners.md new file mode 100644 index 000000000000..432fca277987 --- /dev/null +++ b/content/en/blog/2024/community-awards-winners.md @@ -0,0 +1,34 @@ +--- +title: Announcing 2024 OpenTelemetry Community Awards Winners +linkTitle: OpenTelemetry Community Awards Winners +date: 2024-11-15 +author: OpenTelemetry Governance Committee +# prettier-ignore +cSpell:ignore: anunarapureddy Anusha avillela codeboten emdneto Narapureddy ozal serkan Serkan Özal +--- + +We are excited to announce the winners of the first-ever **OpenTelemetry +Community Awards**! These awards recognize individuals who have made a notable +impact to OpenTelemetry project over the past year, whether it's through code, +documentation, project management, outreach, adoption, or simply helping others +answer technical questions on our [CNCF Slack](https://slack.cncf.io/). We +received many nominations from the community, and we are delighted to share the +winners with you. + +Let's congratulate our 2024 OpenTelemetry Community Awards winners: + +- [@serkan-ozal](https://github.com/serkan-ozal) (Serkan Özal) +- [@anunarapureddy](https://github.com/anunarapureddy) (Anusha Narapureddy) +- [@avillela](https://github.com/avillela) (Adriana Villela) +- [@codeboten](https://github.com/codeboten) (Alex Boten) +- [@emdneto](https://github.com/emdneto) (Emídio Neto) + +We have collected any attached comments (some of them summarized) from all +received nominations. These demonstrate the great appreciation from the +community towards all nominated individuals. You can find those comments in the +following +[presentation slides](https://docs.google.com/presentation/d/1YaJvAWnNcUJd1RNsqvEYCcqvJUoj0TDd). + +We would like to thank everyone who participated in the nomination process, and +we congratulate the winners for their outstanding contributions to the +OpenTelemetry project. 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/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/java-metric-systems-compared/index.md b/content/en/blog/2024/java-metric-systems-compared/index.md index 6085b3c6907e..69a21fa2c920 100644 --- a/content/en/blog/2024/java-metric-systems-compared/index.md +++ b/content/en/blog/2024/java-metric-systems-compared/index.md @@ -13,7 +13,8 @@ across many popular languages, OpenTelemetry reduces the cognitive load of polyglot teams by providing one vocabulary and one toolkit. While that’s all true, today I’d like to zoom in on a specific signal and -language, and talk about the performance of the [OpenTelemetry Java][] metrics SDK. +language, and talk about the performance of the [OpenTelemetry Java][] metrics +SDK. ## Metrics Primer @@ -472,9 +473,11 @@ benefit every application, but are especially important to applications with high cardinality and with strict performance SLAs. If you’re reading this and considering Java metric systems, I hope you chose -[OpenTelemetry Java][]. It’s a powerful and highly performant tool on its own, but -comes with APIs for other key observability signals, a [rich instrumentation ecosystem](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md), -[implementations in a variety of other languages](/docs/languages/), and a well-supported +[OpenTelemetry Java][]. It’s a powerful and highly performant tool on its own, +but comes with APIs for other key observability signals, a +[rich instrumentation ecosystem](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md), +[implementations in a variety of other languages](/docs/languages/), and a +well-supported [open governance structure](https://github.com/open-telemetry/community). ## Acknowledgements 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 0b6e3742e849..2e6f39776bbb 100644 --- a/content/en/blog/2024/kubecon-eu.md +++ b/content/en/blog/2024/kubecon-eu.md @@ -4,14 +4,15 @@ 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 -technical committee are thrilled to be at [KubeCon + CloudNativeCon Europe][] and -at the co-located [Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/) +technical committee are thrilled to be at [KubeCon + CloudNativeCon Europe][] +and at the co-located +[Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/) in Paris from March 19 - 22, 2024. Read on to learn about all the things related OpenTelemetry during KubeCon. @@ -45,9 +46,9 @@ it again right before KubeCon! ## Observability Day -_[Observability Day][] fosters collaboration, discussion, and knowledge sharing of -cloud-native observability projects_. This event will be held on March 19, 2024 from -9:00 - 17:35. There will be several sessions on OpenTelemetry as well: +_[Observability Day][] fosters collaboration, discussion, and knowledge sharing +of cloud-native observability projects_. This event will be held on March 19, +2024 from 9:00 - 17:35. There will be several sessions on OpenTelemetry as well: - **[Welcome + Project Updates](https://sched.co/1YGT9)**
by Eduardo Silva, FluentBit & Austin Parker, honeycomb.io
Tuesday, March 19th • 09:00 - @@ -89,8 +90,8 @@ cloud-native observability projects_. This event will be held on March 19, 2024 {{% alert title="Important access note" color="danger" %}} You need an _in-person all-access_ pass for on-site access to **Observability -Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, you -will be able to follow **Observability Day** through a live stream. +Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, +you will be able to follow **Observability Day** through a live stream. [kubecon registration]: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/register/ diff --git a/content/en/blog/2024/kubecon-na.md b/content/en/blog/2024/kubecon-na.md index 84cb402881ab..1becdaeda917 100644 --- a/content/en/blog/2024/kubecon-na.md +++ b/content/en/blog/2024/kubecon-na.md @@ -2,14 +2,14 @@ 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 -technical committee are thrilled to be at [KubeCon NA][] in Salt Lake City from November -12 - 15, 2024. +technical committee are thrilled to be at [KubeCon NA][] in Salt Lake City from +November 12 - 15, 2024. Read on to learn about all the things related OpenTelemetry during KubeCon. @@ -78,15 +78,17 @@ first steps: documentation, Collector, Java, JS, Ruby, Python, .NET, and more. ## Observability Day -_[Observability Day][] fosters collaboration, discussion, and knowledge sharing of -cloud-native observability projects_. This event will be held on November 12, 2024 -from 9am to 6pm. [Check the full schedule](https://colocatedeventsna2024.sched.com/overview/type/Observability+Day) +_[Observability Day][] fosters collaboration, discussion, and knowledge sharing +of cloud-native observability projects_. This event will be held on November 12, +2024 from 9am to 6pm. +[Check the full schedule](https://colocatedeventsna2024.sched.com/overview/type/Observability+Day) to find your favorite talks about Observability and OpenTelemetry. > **IMPORTANT access note**: You > need an _in-person all-access_ pass for on-site access to **Observability -> Day**. For details, see [KubeCon registration][]. If you have a virtual ticket, -> you will be able to follow **Observability Day** through a live stream. +> Day**. For details, see [KubeCon registration][]. If you have a virtual +> ticket, you will be able to follow **Observability Day** through a live +> stream. ## OpenTelemetry Observatory diff --git a/content/en/blog/2024/otel-arrow-production/index.md b/content/en/blog/2024/otel-arrow-production/index.md index ac27be966449..c43759e7acf5 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 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/otel-generative-ai/aspire-dashboard-content-capture.png b/content/en/blog/2024/otel-generative-ai/aspire-dashboard-content-capture.png new file mode 100644 index 000000000000..c850316c780f Binary files /dev/null and b/content/en/blog/2024/otel-generative-ai/aspire-dashboard-content-capture.png differ diff --git a/content/en/blog/2024/otel-generative-ai/aspire-dashboard-trace.png b/content/en/blog/2024/otel-generative-ai/aspire-dashboard-trace.png new file mode 100644 index 000000000000..f54909f61b86 Binary files /dev/null and b/content/en/blog/2024/otel-generative-ai/aspire-dashboard-trace.png differ diff --git a/content/en/blog/2024/otel-generative-ai/index.md b/content/en/blog/2024/otel-generative-ai/index.md new file mode 100644 index 000000000000..74b30fb61a03 --- /dev/null +++ b/content/en/blog/2024/otel-generative-ai/index.md @@ -0,0 +1,223 @@ +--- +title: OpenTelemetry for Generative AI +linkTitle: OTel for GenAI +date: 2024-12-05 +author: >- + [Drew Robbins](https://github.com/drewby) (Microsoft), [Liudmila + Molkova](https://github.com/lmolkova) (Microsoft) +issue: https://github.com/open-telemetry/opentelemetry.io/issues/5581 +sig: SIG GenAI Observability +cSpell:ignore: genai liudmila molkova +--- + +As organizations increasingly adopt Large Language Models (LLMs) and other +generative AI technologies, ensuring reliable performance, efficiency, and +safety is essential to meet user expectations, optimize resource costs, and +safeguard against unintended outputs. Effective observability for AI operations, +behaviors, and outcomes can help meet these goals. OpenTelemetry is being +enhanced to support these needs specifically for generative AI. + +Two primary assets are in development to make this possible: **Semantic +Conventions** and **Instrumentation Libraries**. The first instrumentation +library targets the +[OpenAI Python API library](https://pypi.org/project/openai/). + +[**Semantic Conventions**](/docs/concepts/semantic-conventions/) establish +standardized guidelines for how telemetry data is structured and collected +across platforms, defining inputs, outputs, and operational details. For +generative AI, these conventions streamline monitoring, troubleshooting, and +optimizing AI models by standardizing attributes such as model parameters, +response metadata, and token usage. This consistency supports better +observability across tools, environments, and APIs, helping organizations track +performance, cost, and safety with ease. + +The +[**Instrumentation Library**](/docs/specs/otel/overview/#instrumentation-libraries) +is being developed within the +[OpenTelemetry Python Contrib](https://github.com/open-telemetry/opentelemetry-python-contrib) +under +[instrumentation-genai](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation-genai) +project to automate telemetry collection for generative AI applications. The +first release is a Python library for instrumenting OpenAI client calls. This +library captures spans and events, gathering essential data like model inputs, +response metadata, and token usage in a structured format. + +## Key Signals for Generative AI + +The [Semantic Conventions for Generative AI](/docs/specs/semconv/gen-ai/) focus +on capturing insights into AI model behavior through three primary signals: +[Traces](/docs/concepts/signals/traces/), +[Metrics](/docs/concepts/signals/metrics/), and +[Events](/docs/specs/otel/logs/event-api/). + +Together, these signals provide a comprehensive monitoring framework, enabling +better cost management, performance tuning, and request tracing. + +### Traces: Tracing Model Interactions + +Traces track each model interaction's lifecycle, covering input parameters (for +example, temperature, top_p) and response details like token count or errors. +They provide visibility into each request, aiding in identifying bottlenecks and +analyzing the impact of settings on model output. + +### Metrics: Monitoring Usage and Performance + +Metrics aggregate high-level indicators like request volume, latency, and token +counts, essential for managing costs and performance. This data is particularly +critical for API-dependent AI applications with rate limits and cost +considerations. + +### Events: Capturing Detailed Interactions + +Events log detailed moments during model execution, such as user prompts and +model responses, providing a granular view of model interactions. These insights +are invaluable for debugging and optimizing AI applications where unexpected +behaviors may arise. + +{{% alert title="Note" color="info" %}} Note that we decided to use +[events emitted](/docs/specs/otel/logs/api/#emit-an-event) with the +[Logs API](/docs/specs/otel/logs/api/) specification in the Semantic Conventions +for Generative AI. Events allows for us to define specific +[semantic conventions](/docs/specs/semconv/general/events/) for the user prompts +and model responses that we capture. This addition to the API is in development +and considered unstable.{{% /alert %}} + +### Extending Observability with Vendor-Specific Attributes + +The Semantic Conventions also define vendor-specific attributes for platforms +like OpenAI and Azure Inference API, ensuring telemetry captures both general +and provider-specific details. This added flexibility supports multi-platform +monitoring and in-depth insights. + +## Building the Python Instrumentation Library for OpenAI + +This Python-based library for OpenTelemetry captures key telemetry signals for +OpenAI models, providing developers with an out-of-the-box observability +solution tailored to AI workloads. The library, +[hosted within the OpenTelemetry Python Contrib repository](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/opentelemetry-instrumentation-openai-v2%3D%3D2.0b0/instrumentation-genai/opentelemetry-instrumentation-openai-v2), +automatically collects telemetry from OpenAI model interactions, including +request and response metadata and token usage. + +As generative AI applications grow, additional instrumentation libraries for +other languages will follow, extending OpenTelemetry support across more tools +and environments. The current library's focus on OpenAI highlights its +popularity and demand within AI development, making it a valuable initial +implementation. + +### Example Usage + +Here's an example of using the OpenTelemetry Python library to monitor a +generative AI application with the OpenAI client. + +Install the OpenTelemetry dependencies: + +```shell +pip install opentelemetry-distro +opentelemetry-bootstrap -a install +``` + +Set the following environment variables, updating the endpoint and protocol as +appropriate: + +```shell +OPENAI_API_KEY= + +OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 +OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf +OTEL_SERVICE_NAME=python-opentelemetry-openai +OTEL_LOGS_EXPORTER=otlp_proto_http +OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true +# Set to false or remove to disable log events +OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true +``` + +Then include the following code in your Python application: + +```python +import os +from openai import OpenAI + +client = OpenAI() +chat_completion = client.chat.completions.create( + model=os.getenv("CHAT_MODEL", "gpt-4o-mini"), + messages=[ + { + "role": "user", + "content": "Write a short poem on OpenTelemetry.", + }, + ], +) +print(chat_completion.choices[0].message.content) +``` + +And then run the example using `opentelemetry-instrument`: + +```shell +opentelemetry-instrument python main.py +``` + +If you do not have a service running to collect telemetry, you can export to the +console using the following: + +```shell +opentelemetry-instrument --traces_exporter console --metrics_exporter console python main.py +``` + +There is a complete example +[available here](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-openai-v2/example). + +With this simple instrumentation, one can begin capture traces from their +generative AI application. Here is an example from the +[Aspire Dashboard](https://learn.microsoft.com/dotnet/aspire/fundamentals/dashboard/standalone?tabs=bash) +for local debugging. + +To start Jaeger, run the following `docker` command and open your web browser +the `localhost:18888`: + +```shell +docker run --rm -it -d -p 18888:18888 -p 4317:18889 -p 4318:18890 --name aspire-dashboard mcr.microsoft.com/dotnet/aspire-dashboard:9.0 +``` + +![Chat trace in Aspire Dashboard](aspire-dashboard-trace.png) + +Here is a similar trace captured in +[Jaeger](https://www.jaegertracing.io/docs/1.63/getting-started/#all-in-one). + +To start Jaeger, run the following `docker` command and open your web browser +the `localhost:16686`. + +```shell +docker run --rm -it -d -p 16686:16686 -p 4317:4317 -p 4318:4318 --name jaeger jaegertracing/all-in-one:latest +``` + +![Chat trace in Jaeger](jaeger-trace.png) + +It's also easy to capture the content history of the chat for debugging and +improving your application. Simply set the environment variable +`OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT` as follows: + +```shell +export OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=True +``` + +This will turn on content capture which collects OpenTelemetry events containing +the payload: + +![Content Capture Aspire Dashboard](aspire-dashboard-content-capture.png) + +## Join Us in Shaping the Future of Generative AI Observability + +Community collaboration is key to OpenTelemetry's success. We invite developers, +AI practitioners, and organizations to contribute, share feedback, or +participate in discussions. Explore the OpenTelemetry Python Contrib project, +contribute code, or help shape observability for AI as it continues to evolve. + +We now have contributors from [Amazon](https://aws.amazon.com/), +[Elastic](https://www.elastic.co/), [Google](https://www.google.com/), +[IBM](https://www.ibm.com), [Langtrace](https://www.langtrace.ai/), +[Microsoft](https://www.microsoft.com/), [OpenLIT](https://openlit.io/), +[Scorecard](https://www.scorecard.io/), [Traceloop](https://www.traceloop.com/), +and more! + +You are welcome to join the community! More information can be found at the +[Generative AI Observability project page](https://github.com/open-telemetry/community/blob/main/projects/gen-ai.md). diff --git a/content/en/blog/2024/otel-generative-ai/jaeger-trace.png b/content/en/blog/2024/otel-generative-ai/jaeger-trace.png new file mode 100644 index 000000000000..ee56ab3ce9ae Binary files /dev/null and b/content/en/blog/2024/otel-generative-ai/jaeger-trace.png differ 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/scaling-collectors.md b/content/en/blog/2024/scaling-collectors.md index e1ba3028967c..41210f47b890 100644 --- a/content/en/blog/2024/scaling-collectors.md +++ b/content/en/blog/2024/scaling-collectors.md @@ -89,7 +89,7 @@ Create a file named `deploy-opentelemetry.yml` in the same directory as your tasks: - name: Install OpenTelemetry Collector ansible.builtin.include_role: - name: opentelemetry_collectorr + name: opentelemetry_collector vars: otel_collector_receivers: hostmetrics: 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/_index.md b/content/en/blog/_index.md index 07428ffb4bea..4b8d78607c2c 100644 --- a/content/en/blog/_index.md +++ b/content/en/blog/_index.md @@ -3,9 +3,9 @@ title: Blog menu: { main: { weight: 50 } } redirects: # Every January, update the year number in the paths below - - { from: '', to: '2024/ 301!' } + - { from: '', to: '2024/ 302!' } # Workaround to https://github.com/open-telemetry/opentelemetry.io/issues/4440: - - { from: 'index.xml', to: '2024/index.xml 301!' } + - { 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. diff --git a/content/en/community/end-user/slack-channel.md b/content/en/community/end-user/slack-channel.md index fa91be02db9f..cb0534371036 100644 --- a/content/en/community/end-user/slack-channel.md +++ b/content/en/community/end-user/slack-channel.md @@ -6,21 +6,17 @@ description: >- weight: 40 --- -Previously, we had a private channel to provide a space for end users to discuss -adoption and implementation issues while allowing them to maintain a layer of -privacy and to meet compliance concerns. Now that the project and community have -grown, and with the transition of the End User WG to End User SIG, we believe -that this private channel is no longer needed. +Join our Slack channel to connect with other OpenTelemetry end users! -As of April 2024, we will begin shifting all of our communications to the -[`#otel-sig-end-user`](https://cloud-native.slack.com/archives/C01RT3MSWGZ) -channel (previously named the `#otel-user-research` channel), and will be -archiving the private channel by **April 30, 2024**. +First, [request an invitation](https://slack.cncf.io/) to CNCF's Slack instance. +Next, join +[`#otel-sig-end-user`](https://cloud-native.slack.com/archives/C01RT3MSWGZ), and +introduce yourself if you'd like. -We encourage you to join us over at -[`#otel-sig-end-user`](https://cloud-native.slack.com/archives/C01RT3MSWGZ) to -learn about our new charter, what you can expect from us as an end user, and -more. Note the following: +We encourage questions and discussions about adoption and implementation. You +can also hear about upcoming events and get a chance to contribute to the +project by participating in surveys and user feedback sessions. Note the +following: - Troubleshooting or tactical SDK specific questions are still best directed to individual SIG channels or the 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 4fdd376ac18e..0aae375deea3 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.113.0 + vers: 0.115.1 weight: 270 --- diff --git a/content/en/docs/collector/building/connector/otel-collector-after-connector.svg b/content/en/docs/collector/building/connector/otel-collector-after-connector.svg index a6bd7802b339..561951e55d7a 100644 --- a/content/en/docs/collector/building/connector/otel-collector-after-connector.svg +++ b/content/en/docs/collector/building/connector/otel-collector-after-connector.svg @@ -1,235 +1,354 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/content/en/docs/collector/building/connector/otel-collector-before-connector.svg b/content/en/docs/collector/building/connector/otel-collector-before-connector.svg index 662198cd7766..102202599f99 100644 --- a/content/en/docs/collector/building/connector/otel-collector-before-connector.svg +++ b/content/en/docs/collector/building/connector/otel-collector-before-connector.svg @@ -1,6 +1,6 @@ - + diff --git a/content/en/docs/collector/building/receiver.md b/content/en/docs/collector/building/receiver.md index d9f61884ba5f..011ab8c351f4 100644 --- a/content/en/docs/collector/building/receiver.md +++ b/content/en/docs/collector/building/receiver.md @@ -500,8 +500,8 @@ and it requires the following parameters: `receiver.Traces` instance and it requires the following parameters: - `context.Context`: the reference to the Collector's `context.Context` so your trace receiver can properly manage its execution context. -- `receiver.CreateSettings`: the reference to some of the Collector's settings - under which your receiver is created. +- `receiver.Settings`: the reference to some of the Collector's settings under + which your receiver is created. - `component.Config`: the reference for the receiver config settings passed by the Collector to the factory so it can properly read its settings from the Collector config. @@ -514,7 +514,7 @@ Start by adding the bootstrap code to properly implement the code to your `factory.go` file: ```go -func createTracesReceiver(_ context.Context, params receiver.CreateSettings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { +func createTracesReceiver(_ context.Context, params receiver.Settings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { return nil, nil } ``` @@ -564,7 +564,7 @@ func createDefaultConfig() component.Config { } } -func createTracesReceiver(_ context.Context, params receiver.CreateSettings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { +func createTracesReceiver(_ context.Context, params receiver.Settings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { return nil, nil } @@ -775,8 +775,7 @@ as part of the `createTracesReceiver()` function parameters that your receiver actually requires to work properly like its configuration settings (`component.Config`), the next `Consumer` in the pipeline that will consume the generated traces (`consumer.Traces`) and the Collector's logger so the -`tailtracer` receiver can add meaningful events to it -(`receiver.CreateSettings`). +`tailtracer` receiver can add meaningful events to it (`receiver.Settings`). Given that all this information will only be made available to the receiver at the moment it's instantiated by the factory, the `tailtracerReceiver` type will @@ -910,7 +909,7 @@ func createDefaultConfig() component.Config { } } -func createTracesReceiver(_ context.Context, params receiver.CreateSettings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { +func createTracesReceiver(_ context.Context, params receiver.Settings, baseCfg component.Config, consumer consumer.Traces) (receiver.Traces, error) { logger := params.Logger tailtracerCfg := baseCfg.(*Config) @@ -937,7 +936,7 @@ func NewFactory() receiver.Factory { - Added a variable called `logger` and initialized it with the Collector's logger that is available as a field named `Logger` within the - `receiver.CreateSettings` reference. + `receiver.Settings` reference. - Added a variable called `tailtracerCfg` and initialized it by casting the `component.Config` reference to the `tailtracer` receiver `Config`. - Added a variable called `traceRcvr` and initialized it with the 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/agent.md b/content/en/docs/collector/deployment/agent.md index eff8d8df82ef..0bda419b9110 100644 --- a/content/en/docs/collector/deployment/agent.md +++ b/content/en/docs/collector/deployment/agent.md @@ -129,7 +129,7 @@ Cons: [instrumentation]: /docs/languages/ [otlp]: /docs/specs/otel/protocol/ [collector]: /docs/collector/ -[instrument-java-metrics]: /docs/languages/java/api-components/#meterprovider +[instrument-java-metrics]: /docs/languages/java/api/#meterprovider [otlp-exporter]: /docs/specs/otel/protocol/exporter/ [java-otlp-example]: https://github.com/open-telemetry/opentelemetry-java-docs/tree/main/otlp diff --git a/content/en/docs/collector/distributions.md b/content/en/docs/collector/distributions.md index af9e63e425db..9b3c581e6678 100644 --- a/content/en/docs/collector/distributions.md +++ b/content/en/docs/collector/distributions.md @@ -3,9 +3,9 @@ title: Distributions weight: 25 --- -The OpenTelemetry project currently offers [pre-built distributions][] of the collector. -The components included in the [distributions][] can be found by in the `manifest.yaml` -of each distribution. +The OpenTelemetry project currently offers [pre-built distributions][] of the +collector. The components included in the [distributions][] can be found by in +the `manifest.yaml` of each distribution. [pre-built distributions]: https://github.com/open-telemetry/opentelemetry-collector-releases/releases diff --git a/content/en/docs/collector/img/otel-gateway-sdk.svg b/content/en/docs/collector/img/otel-gateway-sdk.svg index 006a96a54949..5279ce7a6be3 100644 --- a/content/en/docs/collector/img/otel-gateway-sdk.svg +++ b/content/en/docs/collector/img/otel-gateway-sdk.svg @@ -1,5 +1,5 @@ - + diff --git a/content/en/docs/collector/installation.md b/content/en/docs/collector/installation.md index 77dea075fe92..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 @@ -10,8 +10,8 @@ systems and architectures. The following instructions show how to download and install the latest stable version of the Collector. If you aren't familiar with the deployment models, components, and repositories -applicable to the OpenTelemetry Collector, first review the [Data Collection][] and -[Deployment Methods][] page. +applicable to the OpenTelemetry Collector, first review the [Data Collection][] +and [Deployment Methods][] page. ## Docker @@ -84,10 +84,10 @@ The previous example is meant to serve as a starting point, to be extended and customized before actual production usage. For production-ready customization and installation, see [OpenTelemetry Helm Charts][]. -You can also use the [OpenTelemetry Operator][] to provision and maintain an OpenTelemetry -Collector instance, with features such as automatic upgrade handling, `Service` configuration -based on the OpenTelemetry configuration, automatic sidecar injection into deployments, -and more. +You can also use the [OpenTelemetry Operator][] to provision and maintain an +OpenTelemetry Collector instance, with features such as automatic upgrade +handling, `Service` configuration based on the OpenTelemetry configuration, +automatic sidecar injection into deployments, and more. For guidance on how to use the Collector with Kubernetes, see [Kubernetes Getting Started](/docs/kubernetes/getting-started/). @@ -113,7 +113,7 @@ To get started on Debian systems run the following commands: ```sh sudo apt-get update -sudo apt-get -y install wget systemctl +sudo apt-get -y install wget wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v{{% param vers %}}/otelcol_{{% param vers %}}_linux_amd64.deb sudo dpkg -i otelcol_{{% param vers %}}_linux_amd64.deb ``` @@ -122,7 +122,7 @@ sudo dpkg -i otelcol_{{% param vers %}}_linux_amd64.deb ```sh sudo apt-get update -sudo apt-get -y install wget systemctl +sudo apt-get -y install wget wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v{{% param vers %}}/otelcol_{{% param vers %}}_linux_arm64.deb sudo dpkg -i otelcol_{{% param vers %}}_linux_arm64.deb ``` @@ -131,7 +131,7 @@ sudo dpkg -i otelcol_{{% param vers %}}_linux_arm64.deb ```sh sudo apt-get update -sudo apt-get -y install wget systemctl +sudo apt-get -y install wget wget https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v{{% param vers %}}/otelcol_{{% param vers %}}_linux_386.deb sudo dpkg -i otelcol_{{% param vers %}}_linux_386.deb ``` diff --git a/content/en/docs/collector/internal-telemetry.md b/content/en/docs/collector/internal-telemetry.md index 823f653a7c7d..3ddbc5adf28e 100644 --- a/content/en/docs/collector/internal-telemetry.md +++ b/content/en/docs/collector/internal-telemetry.md @@ -2,7 +2,7 @@ title: Internal telemetry weight: 25 # prettier-ignore -cSpell:ignore: alloc journalctl kube otecol pprof tracez underperforming zpages +cSpell:ignore: alloc batchprocessor journalctl kube otecol pprof tracez underperforming zpages --- You can inspect the health of any OpenTelemetry Collector instance by checking @@ -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`: @@ -104,6 +121,21 @@ 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: + +```yaml +service: + telemetry: + logs: + processors: + - batch: + exporter: + otlp: + protocol: grpc/protobuf + endpoint: https://backend:4317 +``` + ### Configure internal traces The Collector does not expose traces by default, but it can be configured to. @@ -136,62 +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 and traces 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: localhost:14317 - traces: - processors: - batch: - exporter: - otlp: - protocol: grpc/protobuf - endpoint: 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 @@ -201,43 +177,20 @@ process on the same host. Specific components of the Collector can also emit their own custom telemetry. In this section, you will learn about the different types of observability emitted by the Collector itself. -### Values observable with internal metrics - -The Collector emits internal metrics for the following **current values**: - -- Resource consumption, including CPU, memory, and I/O. -- Data reception rate, broken down by receiver. -- Data export rate, broken down by exporters. -- Data drop rate due to throttling, broken down by data type. -- Data drop rate due to invalid data received, broken down by data type. -- Throttling state, including Not Throttled, Throttled by Downstream, and - Internally Saturated. -- Incoming connection count, broken down by receiver. -- Incoming connection rate showing new connections per second, broken down by - receiver. -- In-memory queue size in bytes and in units. -- Persistent queue size. -- End-to-end latency from receiver input to exporter output. -- Latency broken down by pipeline elements, including exporter network roundtrip - latency for request/response protocols. - -Rate values are averages over 10 second periods, measured in bytes/sec or -units/sec (for example, spans/sec). - -{{% alert title="Caution" color="warning" %}} - -Byte measurements can be expensive to compute. +### Summary of values observable with internal metrics -{{% /alert %}} +The Collector emits internal metrics for at least the following values: -The Collector also emits internal metrics for these **cumulative values**: +- Process uptime and CPU time since start. +- Process memory and heap usage. +- For receivers: Items accepted and refused, per data type. +- For processors: Incoming and outgoing items. +- For exporters: Items the exporter sent, failed to enqueue, and failed to send, + per data type. +- For exporters: Queue size and capacity. +- Count, duration, and size of HTTP/gRPC requests and responses. -- Total received data, broken down by receivers. -- Total exported data, broken down by exporters. -- Total dropped data due to throttling, broken down by data type. -- Total dropped data due to invalid data received, broken down by data type. -- Total incoming connection count, broken down by receiver. -- Uptime since start. +A more detailed list is available in the following sections. ### Lists of internal metrics @@ -274,74 +227,80 @@ files in the repository. #### `basic`-level metrics -| Metric name | Description | Type | -| ------------------------------------------------------ | --------------------------------------------------------------------------------------- | --------- | -| `otelcol_exporter_enqueue_failed_`
`log_records` | Number of logs that exporter(s) failed to enqueue. | Counter | -| `otelcol_exporter_enqueue_failed_`
`metric_points` | Number of metric points that exporter(s) failed to enqueue. | Counter | -| `otelcol_exporter_enqueue_failed_`
`spans` | Number of spans that exporter(s) failed to enqueue. | Counter | -| `otelcol_exporter_queue_capacity` | Fixed capacity of the sending queue, in batches. | Gauge | -| `otelcol_exporter_queue_size` | Current size of the sending queue, in batches. | Gauge | -| `otelcol_exporter_send_failed_`
`log_records` | Number of logs that exporter(s) failed to send to destination. | Counter | -| `otelcol_exporter_send_failed_`
`metric_points` | Number of metric points that exporter(s) failed to send to destination. | Counter | -| `otelcol_exporter_send_failed_`
`spans` | Number of spans that exporter(s) failed to send to destination. | Counter | -| `otelcol_exporter_sent_log_records` | Number of logs successfully sent to destination. | Counter | -| `otelcol_exporter_sent_metric_points` | Number of metric points successfully sent to destination. | Counter | -| `otelcol_exporter_sent_spans` | Number of spans successfully sent to destination. | Counter | -| `otelcol_process_cpu_seconds` | Total CPU user and system time in seconds. | Counter | -| `otelcol_process_memory_rss` | Total physical memory (resident set size). | Gauge | -| `otelcol_process_runtime_heap_`
`alloc_bytes` | Bytes of allocated heap objects (see 'go doc runtime.MemStats.HeapAlloc'). | Gauge | -| `otelcol_process_runtime_total_`
`alloc_bytes` | Cumulative bytes allocated for heap objects (see 'go doc runtime.MemStats.TotalAlloc'). | Counter | -| `otelcol_process_runtime_total_`
`sys_memory_bytes` | Total bytes of memory obtained from the OS (see 'go doc runtime.MemStats.Sys'). | Gauge | -| `otelcol_process_uptime` | Uptime of the process. | Counter | -| `otelcol_processor_accepted_`
`log_records` | Number of logs successfully pushed into the next component in the pipeline. | Counter | -| `otelcol_processor_accepted_`
`metric_points` | Number of metric points successfully pushed into the next component in the pipeline. | Counter | -| `otelcol_processor_accepted_spans` | Number of spans successfully pushed into the next component in the pipeline. | Counter | -| `otelcol_processor_batch_batch_`
`send_size_bytes` | Number of bytes in the batch that was sent. | Histogram | -| `otelcol_processor_dropped_`
`log_records` | Number of logs dropped by the processor. | Counter | -| `otelcol_processor_dropped_`
`metric_points` | Number of metric points dropped by the processor. | Counter | -| `otelcol_processor_dropped_spans` | Number of spans dropped by the processor. | Counter | -| `otelcol_receiver_accepted_`
`log_records` | Number of logs successfully ingested and pushed into the pipeline. | Counter | -| `otelcol_receiver_accepted_`
`metric_points` | Number of metric points successfully ingested and pushed into the pipeline. | Counter | -| `otelcol_receiver_accepted_spans` | Number of spans successfully ingested and pushed into the pipeline. | Counter | -| `otelcol_receiver_refused_`
`log_records` | Number of logs that could not be pushed into the pipeline. | Counter | -| `otelcol_receiver_refused_`
`metric_points` | Number of metric points that could not be pushed into the pipeline. | Counter | -| `otelcol_receiver_refused_spans` | Number of spans that could not be pushed into the pipeline. | Counter | -| `otelcol_scraper_errored_`
`metric_points` | Number of metric points the Collector failed to scrape. | Counter | -| `otelcol_scraper_scraped_`
`metric_points` | Number of metric points scraped by the Collector. | Counter | +| Metric name | Description | Type | +| ------------------------------------------------------- | --------------------------------------------------------------------------------------- | --------- | +| `otelcol_exporter_enqueue_failed_`
`log_records` | Number of logs that exporter(s) failed to enqueue. | Counter | +| `otelcol_exporter_enqueue_failed_`
`metric_points` | Number of metric points that exporter(s) failed to enqueue. | Counter | +| `otelcol_exporter_enqueue_failed_`
`spans` | Number of spans that exporter(s) failed to enqueue. | Counter | +| `otelcol_exporter_queue_capacity` | Fixed capacity of the sending queue, in batches. | Gauge | +| `otelcol_exporter_queue_size` | Current size of the sending queue, in batches. | Gauge | +| `otelcol_exporter_send_failed_`
`log_records` | Number of logs that exporter(s) failed to send to destination. | Counter | +| `otelcol_exporter_send_failed_`
`metric_points` | Number of metric points that exporter(s) failed to send to destination. | Counter | +| `otelcol_exporter_send_failed_`
`spans` | Number of spans that exporter(s) failed to send to destination. | Counter | +| `otelcol_exporter_sent_log_records` | Number of logs successfully sent to destination. | Counter | +| `otelcol_exporter_sent_metric_points` | Number of metric points successfully sent to destination. | Counter | +| `otelcol_exporter_sent_spans` | Number of spans successfully sent to destination. | Counter | +| `otelcol_process_cpu_seconds` | Total CPU user and system time in seconds. | Counter | +| `otelcol_process_memory_rss` | Total physical memory (resident set size) in bytes. | Gauge | +| `otelcol_process_runtime_heap_`
`alloc_bytes` | Bytes of allocated heap objects (see 'go doc runtime.MemStats.HeapAlloc'). | Gauge | +| `otelcol_process_runtime_total_`
`alloc_bytes` | Cumulative bytes allocated for heap objects (see 'go doc runtime.MemStats.TotalAlloc'). | Counter | +| `otelcol_process_runtime_total_`
`sys_memory_bytes` | Total bytes of memory obtained from the OS (see 'go doc runtime.MemStats.Sys'). | Gauge | +| `otelcol_process_uptime` | Uptime of the process in seconds. | Counter | +| `otelcol_processor_batch_batch_`
`send_size` | Number of units in the batch that was sent. | Histogram | +| `otelcol_processor_batch_batch_size_`
`trigger_send` | Number of times the batch was sent due to a size trigger. | Counter | +| `otelcol_processor_batch_metadata_`
`cardinality` | Number of distinct metadata value combinations being processed. | Counter | +| `otelcol_processor_batch_timeout_`
`trigger_send` | Number of times the batch was sent due to a timeout trigger. | Counter | +| `otelcol_processor_incoming_items` | Number of items passed to the processor. | Counter | +| `otelcol_processor_outgoing_items` | Number of items emitted from the processor. | Counter | +| `otelcol_receiver_accepted_`
`log_records` | Number of logs successfully ingested and pushed into the pipeline. | Counter | +| `otelcol_receiver_accepted_`
`metric_points` | Number of metric points successfully ingested and pushed into the pipeline. | Counter | +| `otelcol_receiver_accepted_spans` | Number of spans successfully ingested and pushed into the pipeline. | Counter | +| `otelcol_receiver_refused_`
`log_records` | Number of logs that could not be pushed into the pipeline. | Counter | +| `otelcol_receiver_refused_`
`metric_points` | Number of metric points that could not be pushed into the pipeline. | Counter | +| `otelcol_receiver_refused_spans` | Number of spans that could not be pushed into the pipeline. | Counter | +| `otelcol_scraper_errored_`
`metric_points` | Number of metric points the Collector failed to scrape. | Counter | +| `otelcol_scraper_scraped_`
`metric_points` | Number of metric points scraped by the Collector. | Counter | #### Additional `normal`-level metrics -| Metric name | Description | Type | -| ------------------------------------------------------- | --------------------------------------------------------------- | --------- | -| `otelcol_processor_batch_batch_`
`send_size` | Number of units in the batch. | Histogram | -| `otelcol_processor_batch_batch_`
`size_trigger_send` | Number of times the batch was sent due to a size trigger. | Counter | -| `otelcol_processor_batch_metadata_`
`cardinality` | Number of distinct metadata value combinations being processed. | Counter | -| `otelcol_processor_batch_timeout_`
`trigger_send` | Number of times the batch was sent due to a timeout trigger. | Counter | +There are currently no metrics specific to `normal` verbosity. #### Additional `detailed`-level metrics -| Metric name | Description | Type | -| --------------------------------- | ----------------------------------------------------------------------------------------- | --------- | -| `http_client_active_requests` | Number of active HTTP client requests. | Counter | -| `http_client_connection_duration` | Measures the duration of the successfully established outbound HTTP connections. | Histogram | -| `http_client_open_connections` | Number of outbound HTTP connections that are active or idle on the client. | Counter | -| `http_client_request_size` | Measures the size of HTTP client request bodies. | Counter | -| `http_client_duration` | Measures the duration of HTTP client requests. | Histogram | -| `http_client_response_size` | Measures the size of HTTP client response bodies. | Counter | -| `http_server_active_requests` | Number of active HTTP server requests. | Counter | -| `http_server_request_size` | Measures the size of HTTP server request bodies. | Counter | -| `http_server_duration` | Measures the duration of HTTP server requests. | Histogram | -| `http_server_response_size` | Measures the size of HTTP server response bodies. | Counter | -| `rpc_client_duration` | Measures the duration of outbound RPC. | Histogram | -| `rpc_client_request_size` | Measures the size of RPC request messages (uncompressed). | Histogram | -| `rpc_client_requests_per_rpc` | Measures the number of messages received per RPC. Should be 1 for all non-streaming RPCs. | Histogram | -| `rpc_client_response_size` | Measures the size of RPC response messages (uncompressed). | Histogram | -| `rpc_client_responses_per_rpc` | Measures the number of messages sent per RPC. Should be 1 for all non-streaming RPCs. | Histogram | -| `rpc_server_duration` | Measures the duration of inbound RPC. | Histogram | -| `rpc_server_request_size` | Measures the size of RPC request messages (uncompressed). | Histogram | -| `rpc_server_requests_per_rpc` | Measures the number of messages received per RPC. Should be 1 for all non-streaming RPCs. | Histogram | -| `rpc_server_response_size` | Measures the size of RPC response messages (uncompressed). | Histogram | -| `rpc_server_responses_per_rpc` | Measures the number of messages sent per RPC. Should be 1 for all non-streaming RPCs. | Histogram | +| Metric name | Description | Type | +| ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | --------- | +| `http_client_active_requests` | Number of active HTTP client requests. | Counter | +| `http_client_connection_duration` | Measures the duration of the successfully established outbound HTTP connections. | Histogram | +| `http_client_open_connections` | Number of outbound HTTP connections that are active or idle on the client. | Counter | +| `http_client_request_size` | Measures the size of HTTP client request bodies. | Counter | +| `http_client_duration` | Measures the duration of HTTP client requests. | Histogram | +| `http_client_response_size` | Measures the size of HTTP client response bodies. | Counter | +| `http_server_active_requests` | Number of active HTTP server requests. | Counter | +| `http_server_request_size` | Measures the size of HTTP server request bodies. | Counter | +| `http_server_duration` | Measures the duration of HTTP server requests. | Histogram | +| `http_server_response_size` | Measures the size of HTTP server response bodies. | Counter | +| `otelcol_processor_batch_batch_`
`send_size_bytes` | Number of bytes in the batch that was sent. | Histogram | +| `rpc_client_duration` | Measures the duration of outbound RPC. | Histogram | +| `rpc_client_request_size` | Measures the size of RPC request messages (uncompressed). | Histogram | +| `rpc_client_requests_per_rpc` | Measures the number of messages received per RPC. Should be 1 for all non-streaming RPCs. | Histogram | +| `rpc_client_response_size` | Measures the size of RPC response messages (uncompressed). | Histogram | +| `rpc_client_responses_per_rpc` | Measures the number of messages sent per RPC. Should be 1 for all non-streaming RPCs. | Histogram | +| `rpc_server_duration` | Measures the duration of inbound RPC. | Histogram | +| `rpc_server_request_size` | Measures the size of RPC request messages (uncompressed). | Histogram | +| `rpc_server_requests_per_rpc` | Measures the number of messages received per RPC. Should be 1 for all non-streaming RPCs. | Histogram | +| `rpc_server_response_size` | Measures the size of RPC response messages (uncompressed). | Histogram | +| `rpc_server_responses_per_rpc` | Measures the number of messages sent per RPC. Should be 1 for all non-streaming RPCs. | Histogram | + +{{% alert title="Note" color="info" %}} The `http_` and `rpc_` metrics come from +instrumentation libraries. Their original names use dots (`.`), but when +exposing internal metrics with Prometheus, they are translated to use +underscores (`_`) to match Prometheus' naming constraints. + +The `otelcol_processor_batch_` metrics are unique to the `batchprocessor`. + +The `otelcol_receiver_`, `otelcol_scraper_`, `otelcol_processor_`, and +`otelcol_exporter_` metrics come from their respective `helper` packages. As +such, some components not using those packages may not emit them. {{% /alert %}} ### Events observable with internal logs diff --git a/content/en/docs/collector/quick-start.md b/content/en/docs/collector/quick-start.md index 326f7c2b6f4f..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 --- @@ -57,11 +56,13 @@ preferred shell. ## Generate and collect telemetry -3. Launch the Collector: +3. Launch the Collector, listening on ports 4317 (for OTLP gRPC), 4318 (for OTLP + HTTP) and 55679 (for ZPages): ```sh docker run \ -p 127.0.0.1:4317:4317 \ + -p 127.0.0.1:4318:4318 \ -p 127.0.0.1:55679:55679 \ otel/opentelemetry-collector-contrib:{{% param vers %}} \ 2>&1 | tee collector-output.txt # Optionally tee output for easier search later diff --git a/content/en/docs/concepts/instrumentation/libraries.md b/content/en/docs/concepts/instrumentation/libraries.md index 7ef1ddcf74ff..38a19054ad73 100644 --- a/content/en/docs/concepts/instrumentation/libraries.md +++ b/content/en/docs/concepts/instrumentation/libraries.md @@ -5,8 +5,8 @@ aliases: [../instrumenting-library] weight: 40 --- -OpenTelemetry provides [instrumentation libraries][] for many libraries, which is -typically done through library hooks or monkey-patching library code. +OpenTelemetry provides [instrumentation libraries][] for many libraries, which +is typically done through library hooks or monkey-patching library code. Native library instrumentation with OpenTelemetry provides better observability and developer experience for users, removing the need for libraries to expose @@ -245,8 +245,8 @@ already have OpenTelemetry integration. To find out, see the context on all logs, so users can correlate them. If your language and ecosystem don't have common logging support, use [span -events][] to share additional app details. Events maybe more convenient if you want -to add attributes as well. +events][] to share additional app details. Events maybe more convenient if you +want to add attributes as well. As a rule of thumb, use events or logs for verbose data instead of spans. Always attach events to the span instance that your instrumentation created. Avoid @@ -267,8 +267,8 @@ After you create a span, pass new trace context to the application code (callback or handler), by making the span active; if possible, do this explicitly. The following Java example shows how to add trace context and activate a span. See the -[Context extraction in Java](/docs/languages/java/api-components/#contextpropagators), -for more examples. +[Context extraction in Java](/docs/languages/java/api/#contextpropagators), for +more examples. ```java // extract the context 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/metrics.md b/content/en/docs/concepts/signals/metrics.md index 8e64ae9d86a7..62569d57f920 100644 --- a/content/en/docs/concepts/signals/metrics.md +++ b/content/en/docs/concepts/signals/metrics.md @@ -69,6 +69,9 @@ The instrument kind is one of the following: 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. +- **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. - **Histogram**: A client-side aggregation of values, such as request latencies. A histogram is a good choice if you are interested in value statistics. For example: How many requests take fewer than 1s? diff --git a/content/en/docs/concepts/signals/traces.md b/content/en/docs/concepts/signals/traces.md index a0624d769c01..d4a7942fadf0 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 diff --git a/content/en/docs/contributing/_index.md b/content/en/docs/contributing/_index.md index 4fc089ff9475..d54fc9332104 100644 --- a/content/en/docs/contributing/_index.md +++ b/content/en/docs/contributing/_index.md @@ -43,9 +43,9 @@ The pages in this section describe how to contribute to OpenTelemetry **documentation**. For guidance on how to contribute to the OpenTelemetry project in general, see -the community [OpenTelemetry New Contributor Guide]. Every [OTel repository][org] -for language implementations, the Collector, and conventions have their own project-specific -contributing guides. +the community [OpenTelemetry New Contributor Guide]. Every [OTel +repository][org] for language implementations, the Collector, and conventions +have their own project-specific contributing guides. [OpenTelemetry New Contributor Guide]: https://github.com/open-telemetry/community/blob/main/guides/contributor 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/contributing/localization.md b/content/en/docs/contributing/localization.md index 615669b7ef09..86370e8f4fe9 100644 --- a/content/en/docs/contributing/localization.md +++ b/content/en/docs/contributing/localization.md @@ -6,10 +6,10 @@ weight: 25 cSpell:ignore: shortcodes --- -The OTel website uses Hugo's [multilingual framework] to support page localizations. -English is the default language, with US English as the default (implicit) localization. -A growing number of other localizations are supported, as can be seen from the languages -dropdown menu in the top nav. +The OTel website uses Hugo's [multilingual framework] to support page +localizations. English is the default language, with US English as the default +(implicit) localization. A growing number of other localizations are supported, +as can be seen from the languages dropdown menu in the top nav. ## English language maintainer guidance diff --git a/content/en/docs/contributing/pull-requests.md b/content/en/docs/contributing/pull-requests.md index ac831674f9c7..8f64afb815d4 100644 --- a/content/en/docs/contributing/pull-requests.md +++ b/content/en/docs/contributing/pull-requests.md @@ -384,9 +384,9 @@ close the terminal window. ### Site deploys and PR previews -If you submit a PR, Netlify creates a [deploy preview][] so that you can review your -changes. Once your PR is merged, Netlify deploys the updated site to the production -server. +If you submit a PR, Netlify creates a [deploy preview][] so that you can review +your changes. Once your PR is merged, Netlify deploys the updated site to the +production server. > **Note**: PR previews include _draft pages_, but production builds do not. diff --git a/content/en/docs/demo/architecture.md b/content/en/docs/demo/architecture.md index ab2f2040807b..245ff539c225 100644 --- a/content/en/docs/demo/architecture.md +++ b/content/en/docs/demo/architecture.md @@ -14,12 +14,13 @@ graph TD subgraph Service Diagram accountingservice(Accounting Service):::dotnet adservice(Ad Service):::java -cache[(Cache
(redis))] +cache[(Cache
(Valkey))] cartservice(Cart Service):::dotnet checkoutservice(Checkout Service):::golang currencyservice(Currency Service):::cpp emailservice(Email Service):::ruby -flagd(Flagd-ui):::typescript +flagd(Flagd):::golang +flagdui(Flagd-ui):::typescript frauddetectionservice(Fraud Detection Service):::kotlin frontend(Frontend):::typescript frontendproxy(Frontend Proxy
(Envoy)):::cpp @@ -30,40 +31,52 @@ productcatalogservice(Product Catalog Service):::golang quoteservice(Quote Service):::php recommendationservice(Recommendation Service):::python shippingservice(Shipping Service):::rust -queue[(queue
(Kafka))] +queue[(queue
(Kafka))]:::java -Internet -->|HTTP| frontendproxy -frontendproxy -->|HTTP| frontend -frontendproxy -->|HTTP| flagd -loadgenerator -->|HTTP| frontendproxy -frontendproxy -->|HTTP| imageprovider +adservice ---->|gRPC| flagd -queue -->|TCP| accountingservice -queue -->|TCP| frauddetectionservice - -frontend -->|gRPC| cartservice -frontend -->|gRPC| currencyservice +checkoutservice -->|gRPC| cartservice +checkoutservice --->|TCP| queue +cartservice --> cache +cartservice -->|gRPC| flagd -checkoutservice -->|gRPC| cartservice --> cache -checkoutservice -->|gRPC| productcatalogservice -checkoutservice -->|gRPC| currencyservice -checkoutservice -->|HTTP| emailservice -checkoutservice -->|gRPC| paymentservice checkoutservice -->|gRPC| shippingservice -checkoutservice -->|TCP| queue +checkoutservice -->|gRPC| paymentservice +checkoutservice --->|HTTP| emailservice +checkoutservice -->|gRPC| currencyservice +checkoutservice -->|gRPC| productcatalogservice + +frauddetectionservice -->|gRPC| flagd frontend -->|gRPC| adservice +frontend -->|gRPC| cartservice +frontend -->|gRPC| checkoutservice +frontend ---->|gRPC| currencyservice +frontend ---->|gRPC| recommendationservice frontend -->|gRPC| productcatalogservice -frontend --->|gRPC| checkoutservice -frontend ---->|gRPC| recommendationservice -->|gRPC| productcatalogservice -shippingservice -->|HTTP| quoteservice +frontendproxy -->|gRPC| flagd +frontendproxy -->|HTTP| frontend +frontendproxy -->|HTTP| flagdui +frontendproxy -->|HTTP| imageprovider + +Internet -->|HTTP| frontendproxy + +loadgenerator -->|HTTP| frontendproxy + +paymentservice -->|gRPC| flagd +queue -->|TCP| accountingservice +queue -->|TCP| frauddetectionservice + +recommendationservice -->|gRPC| productcatalogservice +recommendationservice -->|gRPC| flagd + +shippingservice -->|HTTP| quoteservice end classDef dotnet fill:#178600,color:white; classDef cpp fill:#f34b7d,color:white; -classDef erlang fill:#b83998,color:white; classDef golang fill:#00add8,color:black; classDef java fill:#b07219,color:white; classDef javascript fill:#f1e05a,color:black; @@ -80,7 +93,6 @@ graph TD subgraph Service Legend dotnetsvc(.NET):::dotnet cppsvc(C++):::cpp - erlangsvc(Erlang/Elixir):::erlang golangsvc(Go):::golang javasvc(Java):::java javascriptsvc(JavaScript):::javascript @@ -94,7 +106,6 @@ end classDef dotnet fill:#178600,color:white; classDef cpp fill:#f34b7d,color:white; -classDef erlang fill:#b83998,color:white; classDef golang fill:#00add8,color:black; classDef java fill:#b07219,color:white; classDef javascript fill:#f1e05a,color:black; diff --git a/content/en/docs/demo/forking.md b/content/en/docs/demo/forking.md index 6aa882a3f337..e3f4930d5078 100644 --- a/content/en/docs/demo/forking.md +++ b/content/en/docs/demo/forking.md @@ -3,8 +3,8 @@ title: Forking the demo repository linkTitle: Forking --- -The [demo repository][] is designed to be forked and used as a tool to show off what -you are doing with OpenTelemetry. +The [demo repository][] is designed to be forked and used as a tool to show off +what you are doing with OpenTelemetry. Setting up a fork or a demo usually only requires overriding some environment variables and possibly replacing some container images. diff --git a/content/en/docs/demo/kubernetes-deployment.md b/content/en/docs/demo/kubernetes-deployment.md index b6a5ddb494ef..dbaddf428ee1 100644 --- a/content/en/docs/demo/kubernetes-deployment.md +++ b/content/en/docs/demo/kubernetes-deployment.md @@ -32,8 +32,20 @@ command: helm install my-otel-demo open-telemetry/opentelemetry-demo ``` -> **Note** The OpenTelemetry Demo Helm chart version 0.11.0 or greater is -> required to perform all usage methods mentioned below. +{{% alert title="Note" color="info" %}} + +The OpenTelemetry Demo Helm chart does not support being upgraded from one +version to another. If you need to upgrade the chart, you must first delete the +existing release and then install the new version. + +{{% /alert %}} + +{{% alert title="Note" color="info" %}} + +The OpenTelemetry Demo Helm chart version 0.11.0 or greater is required to +perform all usage methods mentioned below. + +{{% /alert %}} ## Install using kubectl @@ -44,8 +56,20 @@ cluster. kubectl apply --namespace otel-demo -f https://raw.githubusercontent.com/open-telemetry/opentelemetry-demo/main/kubernetes/opentelemetry-demo.yaml ``` -> **Note** These manifests are generated from the Helm chart and are provided -> for convenience. It is recommended to use the Helm chart for installation. +{{% alert title="Note" color="info" %}} + +The OpenTelemetry Demo Kubernetes manifests do not support being upgraded from +one version to another. If you need to upgrade the demo, you must first delete +the existing resources and then install the new version. + +{{% /alert %}} + +{{% alert title="Note" color="info" %}} + +These manifests are generated from the Helm chart and are provided for +convenience. It is recommended to use the Helm chart for installation. + +{{% /alert %}} ## Use the Demo @@ -63,10 +87,14 @@ To expose the frontendproxy service use the following command (replace kubectl port-forward svc/my-otel-demo-frontendproxy 8080:8080 ``` -> **Note**: `kubectl port-forward` will proxy the port until the process -> terminates. You may need to create separate terminal sessions for each use of -> `kubectl port-forward`, and use Ctrl-C to terminate the process -> when done. +{{% alert title="Note" color="info" %}} + +`kubectl port-forward` proxies the port until the process terminates. You might +need to create separate terminal sessions for each use of +`kubectl port-forward`, and use Ctrl-C to terminate the process when +done. + +{{% /alert %}} With the frontendproxy port-forward set up, you can access: @@ -84,9 +112,13 @@ options. {{% /alert %}} #### Configure ingress resources -> **Note** Kubernetes clusters may not have the proper infrastructure components -> to enable LoadBalancer service types or ingress resources. Verify your cluster -> has the proper support before using these configuration options. +{{% alert title="Note" color="info" %}} + +Kubernetes clusters might not have the proper infrastructure components to +enable LoadBalancer service types or ingress resources. Verify your cluster has +the proper support before using these configuration options. + +{{% /alert %}} Each demo component (ie: frontendproxy) offers a way to have its Kubernetes service type configured. By default, these will not be created, but you can @@ -144,23 +176,6 @@ components: value: http://otel-demo.my-domain.com/otlp-http/v1/traces ``` -#### Installation with a values file - -To install the Helm chart with a custom `my-values-file.yaml` values file use: - -```shell -helm install my-otel-demo open-telemetry/opentelemetry-demo --values my-values-file.yaml -``` - -With the frontendproxy and Collector exposed, you can access the demo UI at the -base path for the frontendproxy. Other demo components can be accessed at the -following sub-paths: - -- Web store: `/` (base) -- Grafana: `/grafana` -- Load Generator UI: `/loadgen/` (must include trailing slash) -- Jaeger UI: `/jaeger/ui` - ## Bring your own backend Likely you want to use the web store as a demo application for an observability diff --git a/content/en/docs/kubernetes/collector/components.md b/content/en/docs/kubernetes/collector/components.md index 51bd7749bd68..59384c698ffd 100644 --- a/content/en/docs/kubernetes/collector/components.md +++ b/content/en/docs/kubernetes/collector/components.md @@ -283,77 +283,13 @@ filelog: exclude: # Exclude logs from all containers named otel-collector - /var/log/pods/*/otel-collector/*.log - start_at: beginning + start_at: end include_file_path: true include_file_name: false operators: - # Find out which format is used by kubernetes - - type: router - id: get-format - routes: - - output: parser-docker - expr: 'body matches "^\\{"' - - output: parser-crio - expr: 'body matches "^[^ Z]+ "' - - output: parser-containerd - expr: 'body matches "^[^ Z]+Z"' - # Parse CRI-O format - - type: regex_parser - id: parser-crio - regex: - '^(?P