Merge branch 'main' into main

Author: chalin

.github/workflows/fossa.yml

@@ -0,0 +1,20 @@
+name: FOSSA scanning
+
+on:
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  fossa:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
+
+      - uses: fossas/fossa-action@93a52ecf7c3ac7eb40f5de77fd69b1a19524de94 # v1.5.0
+        with:
+          api-key: ${{secrets.FOSSA_API_KEY}}
+          team: OpenTelemetry

.gitmodules

@@ -8,7 +8,7 @@
 [submodule "content-modules/opentelemetry-specification"]
 	path = content-modules/opentelemetry-specification
 	url = https://github.com/open-telemetry/opentelemetry-specification.git
-	spec-pin = v1.41.0
+	spec-pin = v1.42.0
 [submodule "content-modules/community"]
 	path = content-modules/community
 	url = https://github.com/open-telemetry/community

.markdownlint.json

@@ -1,5 +1,6 @@
 {
   "emphasis-style": false,
+  "first-line-h1": false,
   "line-length": false,
   "link-fragments": false,
   "list-marker-space": false,

content-modules/opentelemetry-specification

@@ -1,5 +1,4 @@
 ---
-title: # bogus entry for markdownlint
 ---
 
 <i class="fa-solid fa-circle-info" style="margin-left: -1.5rem"></i> You are

content/en/_includes/_index.md

@@ -183,7 +183,7 @@ Here’s what the setup looks like:
        semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
    )
 
-   func JaegerTraceProvider()(*sdktrace.TracerProvider, error) {
+   func JaegerTracerProvider()(*sdktrace.TracerProvider, error) {
        exp, err: = jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint("http://localhost:14268/api/traces")))
        if err != nil {
            return nil, err
@@ -201,11 +201,11 @@ Here’s what the setup looks like:
    ```
 
 4. Go back to the main.go file and modify our code to use the
-   JaegerTraceProvider function we just created
+   JaegerTracerProvider function we just created
 
    ```go
    func main() {
-       tp, tpErr: = tracing.JaegerTraceProvider()
+       tp, tpErr: = tracing.JaegerTracerProvider()
        if tpErr != nil {
            log.Fatal(tpErr)
        }
@@ -322,7 +322,7 @@ Here’s what the setup looks like:
 
    func main() {
        //Export traces to Jaeger
-       tp, tpErr: = tracing.JaegerTraceProvider()
+       tp, tpErr: = tracing.JaegerTracerProvider()
        if tpErr != nil {
            log.Fatal(tpErr)
        }

content/en/_includes/page-not-translated-msg.md

@@ -0,0 +1,141 @@
+---
+title: Announcing the OpenTelemetry Demo 2.0
+linkTitle: OTel Demo 2.0
+date: 2025-02-21
+author: >
+  [Juliano Costa](https://github.com/julianocosta89) (Datadog)
+sig: OpenTelemetry Demo
+cSpell:ignore: Abhishek Veeramalla's
+---
+
+We're thrilled to announce that OpenTelemetry Demo 2.0 is here! We've been busy
+behind the scenes, polishing up the demo to make it more complete, robust, and
+user-friendly. We believe these exciting features and improvements deserve a
+major release!
+
+But before we jump in, let's take a look at some of the project stats.
+
+## Statistics
+
+With a total of 140 contributors, the OpenTelemetry Demo has been starred
+**2048** times. On October 26, 2022 — two days after General Availability
+— we had a record 40 stars in a single day. If you use the Demo, consider
+leaving us a star to help promote the project.
+
+There are a total of 1.8K forks of the Demo. Notably, [Abhishek Veeramalla's
+fork][1] stands out with 142 stars and has been forked 425 times.
+
+The Demo containers have been pulled over **12 million times** (11.8M times from
+`ghcr.io` plus 433K times from `hub.docker`).
+
+The OpenTelemetry Demo includes the following CNCF projects:
+
+- [OpenTelemetry](/), of course
+- [Envoy][2]
+- [OpenFeature/Flagd][3]
+- [Jaeger][4]
+- [Prometheus][5]
+- [Valkey][6]
+
+## What's new in 2.0?
+
+This release is packed with exciting upgrades and changes. The following list is
+a quick rundown of the highlights:
+
+- **Flagd-ui introduced**: One of our most missed features since version 1.9.0
+  is back! You can again manage feature flags directly in the Demo. For more
+  details, see the [Feature Flags](/docs/demo/feature-flags/) page.
+- **Image-provider introduced**: Since release 1.10.0, we've introduced a new
+  service called Image Provider, which delivers static product images. This
+  service, built on NGINX, returns images for every product and demonstrates how
+  to instrument OpenTelemetry with an NGINX proxy using the NGINX Native
+  OpenTelemetry module.
+- **Redis replaced with Valkey**: Since version 1.11.0, we've replaced the Redis
+  service with Valkey, introducing another CNCF project to the OTel Demo.
+- **Build args moved to `.env` file**: If you forked the Demo and were using any
+  custom image, keeping your fork in sync with upstream was always a hassle. To
+  make things easier, we've moved most configurations to the `.env` file. We've
+  also added a `_DOCKERFILE` environment variable, which allows you to specify
+  the location of your build instructions.
+- **Services renamed**: If you've been using the OTel Demo since its inception,
+  you're probably accustomed to the verbose naming of every service. For 2.0,
+  we've streamlined things by dropping the `-service` suffix from all service
+  names. Now, instead of `ad-service`, `cart-service`, and `checkout-service`,
+  you'll simply see `Ad`, `Cart`, and `Checkout`.
+- **Accounting rewritten in .NET**: We wanted to showcase OTel's .NET
+  auto-instrumentation in the Demo without adding an extra service. Since the
+  Accounting service was originally written in Go—and we already had another
+  service in that language—we decided to rewrite it in .NET. Now, the Demo
+  features both the `Accounting` and `Cart` services, each demonstrating a
+  different way to instrument .NET applications.
+- **Added exemplars**: `Cart` service now records exemplars for `GetCart` and
+  `AddItem` operations, allowing correlation between metrics and spans. See the
+  [Exemplars section of the Cart documentation](/docs/demo/services/cart/#exemplars)
+  to learn more.
+- **React Native example app**: One of the most significant additions to this
+  release is the brand new React Native app example. It can be built for Android
+  or iOS (currently executable locally only). For instructions on how to run and
+  test it, see the
+  [React Native App documentation page](/docs/demo/services/react-native-app/).
+- **Span links for messaging spans**: Following OTel's recommendation to always
+  link producer and consumer spans
+  ([Messaging spans - Trace structure](/docs/specs/semconv/messaging/messaging-spans/#trace-structure)),
+  the Demo now demonstrates this best practice. Consumer spans for `Accounting`
+  and `Fraud-Detection` are linked to the producer span
+  (`Checkout/orders publish`).
+- **Multi-arch builds**: To ensure that a variety of users can run the Demo
+  locally, we've introduced new `make` targets to support building multiplatform
+  images (for both `arm64` and `amd64` architectures).
+- **Configured Dependabot**: We were falling behind on some dependencies, but
+  now Dependabot is configured to keep the Demo up-to-date automatically.
+
+## Current challenges
+
+Of course, with great updates come a few growing pains. Here's what we're
+currently tackling:
+
+- **Grafana dashboards**: As semantic conventions and tools evolve with new
+  releases, ensuring that our Grafana dashboards remain fully functional is a
+  challenge. If you're experienced with Grafana, we'd love your help!
+- **Dependabot PR testing**: While Dependabot helps keep all service
+  dependencies up-to-date, we haven't yet implemented automated tests to ensure
+  that updates don't cause crashes. This testing is still a manual process.
+- **Demo scalability**: Balancing the expansion of demo scenarios while keeping
+  the Demo easily runnable locally is one of our biggest challenges. With 19
+  different services and new ideas emerging weekly, we're continuously working
+  to maintain this balance.
+
+## What's next?
+
+We're not stopping here! Here are some of the next steps we're excited about,
+and we'd love your help:
+
+- **Bring Erlang/Elixir back**: In March 2024, we removed the initial Feature
+  Flag service written in Elixir in favor of OpenFeature and Flagd. Since then,
+  the Demo hasn't included a service in that language, but we're aiming to
+  reintroduce Erlang/Elixir. Any help in this area would be much appreciated!
+- **Remote access for React Native app**: We plan to enable the React Native app
+  to access a remotely running Demo, expanding its usability.
+- **Better automation and testing**: We're working to improve our automation and
+  testing processes—especially for Dependabot PRs—to streamline our development
+  workflow.
+
+## Get involved!
+
+Your feedback and contributions are what make this project thrive. If you're
+interested in helping out—whether it's polishing up the dashboards, automating
+tests, or bringing Erlang/Elixir back—please jump in and join the discussion on
+our [GitHub repository][7] / SIG meetings ([calendar-demo][8]) or hop into the
+[#otel-community-demo slack channel][9].
+
+Thank you for your continued support, and happy demoing!
+
+[1]: https://github.com/iam-veeramalla/ultimate-devops-project-demo
+[2]: https://www.envoyproxy.io/
+[3]: https://flagd.dev/
+[4]: https://www.jaegertracing.io/
+[5]: https://prometheus.io/
+[6]: https://valkey.io/
+[7]: https://github.com/open-telemetry/opentelemetry-demo
+[8]: https://groups.google.com/a/opentelemetry.io/g/calendar-demo-app
+[9]: https://cloud-native.slack.com/archives/C03B4CWV4DA

content/en/blog/2022/go-web-app-instrumentation/index.md

@@ -0,0 +1,150 @@
+---
+title: OTTL contexts just got easier with context inference
+linkTitle: OTTL contexts just got easier
+date: 2025-02-20
+author: '[Edmo Vamerlatti Costa](https://github.com/edmocosta) (Elastic)'
+issue: 6289
+sig: Collector SIG
+cSpell:ignore: OTTL Vamerlatti
+---
+
+Selecting the right OTTL context for running statements can be challenging, even
+for experienced users. Choosing the correct option impacts both accuracy and
+efficiency, as using higher-level OTTL contexts can avoid unnecessary iterations
+through nested lower-level contexts.
+
+To simplify this process, the OpenTelemetry community is excited to announce
+OTTL
+[context inference](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md#context-inference)
+support for the
+[transform processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor).
+This feature removes the need for users to understand the underlying context
+concept of OTTL, allowing them to focus solely on their data. It also improves
+statement processing efficiency by automatically selecting the most appropriate
+OTTL context. This optimization ensures that data transformations are both
+accurate and performant.
+
+## How does it work?
+
+Starting with version `0.120.0`, the transform processor supports two new
+context-inferred configuration styles. The first one offers a simpler and
+flatter approach, while the second closely resembles the existing configuration
+format.
+
+### Basic configuration
+
+The
+[basic configuration](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md#basic-config)
+style simplifies configuration by allowing users to list all statements
+together, without worrying about OTTL contexts or extra configuration
+structures. This style support statements from multiple OTTL contexts and does
+not require grouping them separately.
+
+To illustrate this, compare the following configuration:
+
+```yaml
+metric_statements:
+  - context: resource
+    statements:
+      - keep_keys(attributes, ["host.name"])
+  - context: metric
+    statements:
+      - set(description, "Sum") where type == "Sum"
+      - convert_sum_to_gauge() where name == "system.processes.count"
+  - context: datapoint
+    statements:
+      - limit(attributes, 100, ["host.name"])
+```
+
+With the new basic configuration style, the same logic is expressed more
+concisely by simply providing a list of statements:
+
+```yaml
+metric_statements:
+  - keep_keys(resource.attributes, ["host.name"])
+  - set(metric.description, "Sum") where metric.type == "Sum"
+  - convert_sum_to_gauge() where metric.name == "system.processes.count"
+  - limit(datapoint.attributes, 100, ["host.name"])
+```
+
+This streamlined approach enhances readability and makes configuration more
+intuitive. To use this configuration style, all paths in the statements must be
+prefixed with their respective OTTL contexts. These prefixes are required for
+all context-inferred configurations and serve as hints for selecting the best
+match. It also makes statements unambiguous and portable between components
+using OTTL.
+
+### Advanced configuration
+
+The context-inferred
+[advanced configuration](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md#advanced-config)
+style closely resembles the existing format and allows users to leverage the
+benefits of context inference while providing granular control over statement
+configurations, such as `error_mode` and `conditions`. For example, consider the
+following configuration:
+
+```yaml
+metric_statements:
+  - context: datapoint
+    conditions:
+      - resource.attributes["service.name"] == "my.service"
+    statements:
+      - set(metric.description, "counter") where attributes["my.attr"] == "some"
+```
+
+The above can now be written as:
+
+<!-- prettier-ignore -->
+```yaml
+metric_statements:
+  - conditions:
+      - resource.attributes["service.name"] == "my.service"
+    statements:
+      - set(metric.description, "counter") where datapoint.attributes["my.attr"] == "some"
+```
+
+In this example, the `context` value is omitted and is automatically inferred to
+`datapoint`, as it is the only OTTL context present in the statements that
+supports parsing both `datapoint` and `metric` data.
+
+If we update the above configuration removing the `datapoint` usage:
+
+```yaml
+metric_statements:
+  - conditions:
+      - resource.attributes["service.name"] == "my.service"
+    statements:
+      - set(metric.description, "counter")
+```
+
+The context inferrer would select the `metric` OTTL context instead, since no
+data points are accessed. Although it would be possible to run the statements
+using the `datapoint` OTTL context, `metric` is the most efficient option.
+
+### Which configuration style should I choose?
+
+The [basic configuration](#basic-configuration) style is best suited for
+scenarios where simplicity and ease of use are paramount. It is ideal for simple
+use cases where your configuration needs are straightforward and do not require
+the use of additional configurations keys, allowing you to quickly set up your
+statements with minimal effort and without needing to understand the underlying
+concept of OTTL contexts.
+
+The [advanced configuration](#advanced-configuration) style is more detailed and
+allows the use of additional configuration keys such as `error_mode` and
+`conditions`. It supports statements from multiple OTTL contexts. However,
+unlike the basic configuration style, it may require splitting them into
+separate configuration groups (see
+[advanced config](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor#advanced-config)).
+In terms of performance, the advanced configuration is slightly faster than the
+basic configuration, making it a better choice for complex scenarios or
+configurations with a high number of statements.
+
+## Try it out
+
+As we wrap up, we encourage users to explore this new functionality and take
+advantage of its benefits in their telemetry pipelines!
+
+If you have any questions or suggestions, we’d love to hear from you! Join the
+conversation in the `#otel-collector` channel on the
+[CNCF Slack workspace](https://slack.cncf.io/).

content/en/blog/2025/otel-demo-2.md

@@ -3,7 +3,7 @@ title: Collector
 description: Vendor-agnostic way to receive, process and export telemetry data.
 aliases: [./about]
 cascade:
-  vers: 0.119.0
+  vers: 0.120.0
 weight: 270
 ---
 

content/en/blog/2025/ottl-contexts-just-got-easier.md

@@ -350,7 +350,7 @@ touch tailtracer/factory.go
 ```
 
 Now let's follow the convention and add a function named `NewFactory()` that
-will be responsible to instantiate the `tailtracer` factory. Go ahead the add
+will be responsible to instantiate the `tailtracer` factory. Go ahead and add
 the following code to your `factory.go` file:
 
 ```go