Merge branch 'main' into avillela-ta-troubleshooting-2

.github/CODEOWNERS

@@ -41,8 +41,13 @@ content/en/docs/languages/rust/          @open-telemetry/docs-approvers @open-te
 content/en/docs/languages/swift/         @open-telemetry/docs-approvers @open-telemetry/swift-approvers
 content/en/docs/security/                @open-telemetry/docs-approvers @open-telemetry/sig-security-maintainers
 content/en/docs/specs/                   @open-telemetry/docs-approvers @open-telemetry/specs-approvers
+content/en/docs/zero-code/go             @open-telemetry/docs-approvers @open-telemetry/go-approvers @open-telemetry/go-instrumentation-approvers
 content/en/docs/zero-code/java/          @open-telemetry/docs-approvers @open-telemetry/java-approvers @open-telemetry/java-instrumentation-approvers
 content/en/docs/zero-code/js/            @open-telemetry/docs-approvers @open-telemetry/javascript-approvers
 content/en/docs/zero-code/net/           @open-telemetry/docs-approvers @open-telemetry/dotnet-approvers @open-telemetry/dotnet-instrumentation-approvers
+content/en/docs/zero-code/python/        @open-telemetry/docs-approvers @open-telemetry/python-approvers
+content/en/docs/zero-code/php/           @open-telemetry/docs-approvers @open-telemetry/php-approvers
 content/en/ecosystem/demo/               @open-telemetry/demo-approvers @open-telemetry/demo-approvers
 content/zh/                              @open-telemetry/docs-maintainers @open-telemetry/docs-zh-approvers
+content/ja/                              @open-telemetry/docs-maintainers @open-telemetry/docs-ja-approvers
+

.github/component-label-map.yml

@@ -26,6 +26,7 @@ sig:go:
   - changed-files:
       - any-glob-to-any-file:
           - content/en/docs/languages/go/**
+          - content/en/docs/zero-code/go/**
 sig:java:
   - changed-files:
       - any-glob-to-any-file:

.textlintrc.yml

@@ -8,8 +8,8 @@ filters:
     enablingComment: prettier-ignore-end
   allowlist:
     allow:
-      # Don't check registry .yml file fields for language, repo and tags:
-      - '/^\s*(?:language|repo|name|docs): .*$/m'
+      # Don't check registry .yml file fields for language, repo, url and tags:
+      - '/^\s*(?:language|repo|name|docs|url): .*$/m'
       - /^(?:tags):(\s*-.+$)*/m
       # Hugo template syntax:
       - /{{.*?}}/

content/en/blog/2022/debug-otel-with-otel/index.md

@@ -261,4 +261,4 @@ COPY opentelemetry_module.conf /etc/nginx/conf.d
   https://github.com/open-telemetry/opentelemetry-cpp-contrib/releases/tag/webserver%2Fv1.0.1
 [java]:
   /docs/zero-code/java/agent/configuration/#capturing-http-request-and-response-headers
-[python]: /docs/languages/python/automatic/
+[python]: /docs/zero-code/python/

content/en/blog/2023/end-user-discussions-03.md

@@ -190,7 +190,7 @@ agent to the host metrics receiver for infrastructure monitoring.
   maturing in OTel; for example, the Java JAR agent takes care of instrumenting
   [most libraries](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks)
   that are used by applications. Auto-instrumentation is also available for
-  [Python](/docs/languages/python/automatic/), [.NET](/docs/zero-code/net/), and
+  [Python](/docs/zero-code/python/), [.NET](/docs/zero-code/net/), and
   [Node.js](/docs/zero-code/js/).
 - If you’re using Kubernetes, they can use the
   [OTel operator](https://github.com/open-telemetry/opentelemetry-operator),

content/en/blog/2023/end-user-q-and-a-01.md

@@ -169,7 +169,7 @@ They are hoping to leverage
 [OpenTelemetry’s Exemplars](/docs/specs/otel/metrics/data-model/#exemplars) to
 link traces and metrics.
 
-### How is the organization sending telemetry data to various observability back-ends?
+### How is the organization sending telemetry data to various observability backends?
 
 J’s team uses a combination of the proprietary backend agent and the
 OpenTelemetry Collector (for metrics). They are one of the primary users of

content/en/blog/2023/php-auto-instrumentation/index.md

@@ -153,7 +153,7 @@ We have all necessary components in place:
   and frameworks.
 - Development tools that can help lower barrier for users and developers
   interested in instrumenting arbitrary code.
-- [Documentation](/docs/languages/php/automatic/)
+- [Documentation](/docs/zero-code/php/)
 
 One of our goals is to increase awareness of this work and involve more people
 that will help us improve it, extend coverage and fix bugs.

content/en/blog/2024/otel-get-started-survey/index.md

@@ -0,0 +1,101 @@
+---
+title: Insights from the OpenTelemetry Getting Started Survey
+linkTitle: OpenTelemetry Getting Started Survey
+date: 2024-06-19
+author: '[Ana Margarita Medina](https://github.com/AnaMMedina21) (ServiceNow)'
+issue: 4662
+sig: End User SIG
+---
+
+Getting started with new technologies can be hard, which is why we try to meet
+our end-users where they are. As a part of that goal,
+[the OpenTelemetry End-User SIG](/community/end-user/) recently surveyed the
+community to find out how we can best help our users get started with
+OpenTelemetry. The 104 responses we received will help drive improvements in
+enablement content from the community as well as vendors.
+
+Check out the results!
+
+## Key takeaways
+
+- No matter their level of OTel experience, folks would like to see the
+  following:
+  1. Comprehensive documentation (67.3% of respondents).
+  2. Reference implementations for instrumentation (65.3% of respondents).
+  3. Detailed tutorials (63.4% of respondents).
+- Respondents are mostly working with containerization technologies, with 79.8%
+  of respondents using Kubernetes and 63.5% of respondents using Docker.
+- Over 83% of respondents stated that the Traces Specification, Instrumentation
+  APIs and SDKs, and Metrics Specification are the most important aspects of
+  their OTel journey.
+
+## Detailed insights
+
+### Q: What technologies are you using when setting up your observability journey?
+
+Out of 104 respondents, most are working with containers: 79.8% are using
+Kubernetes and 63.5% are using Docker.
+
+![Chart showing what technologies are being used](1-technologies-used.png)
+
+### Q: Where in your observability journey is your organization?
+
+Out of 104 respondents:
+
+- 25% are beginners and they are learning about observability or have used
+  monitoring tools.
+- 49% are intermediates and are setting up observability practice.
+- 26% are experts and have a well-established observability practice.
+
+![Chart showing where in their observability journey they are](2-level.png)
+
+### Q: What languages are you using in your organization?
+
+[JavaScript](/docs/languages/js/), [Java](/docs/languages/java/),
+[Go](/docs/languages/go/), and [Python](/docs/languages/python/) are the most
+widely used languages. They are being utilized by over 50% of the respondents.
+
+[Other languages](/docs/languages/other/) used included Scala, TypeScript,
+[Erlang/Elixir](/docs/languages/erlang/), Perl, R, Lua, Matlab, Julia, Haskell,
+COBOL, Kotlin, and SAS.
+
+![Chart showing what languages are being used](3-languages.png)
+
+### Q: What resources do you wish you had when getting started with OpenTelemetry?
+
+Depending on where in their observability journey they are, respondents prefer
+different resources:
+
+- Those who are learning about observability and those who are setting up an
+  observability practice would like to see comprehensive documentation and
+  detailed tutorials and videos.
+- Those who have a well-established observability practice prefer reference
+  implementations for instrumentation as well as comprehensive documentation.
+
+![Chart showing what resources folks want](4-resources.png)
+
+### Q: What part of the project is most important to you in your OTel journey?
+
+Most respondents stated that
+[Traces Specification,](/docs/specs/otel/trace/api/)
+[Instrumentation APIs and SDKs](/docs/languages/), and
+[Metrics Specification](/docs/specs/otel/metrics/api/) are most important to
+them.
+
+![Chart showing what aspects are the most important](5-importance.png)
+
+## Learn more
+
+For a more detailed look at the survey results, you can check out the
+[results](https://github.com/open-telemetry/sig-end-user/tree/main/end-user-surveys/getting-started).
+
+## Keep in touch
+
+Thanks to everyone who participated in the survey! We rely on your feedback to
+help guide the future development of OpenTelemetry and to ensure it continues to
+meet your evolving needs. We will post upcoming surveys in the following
+avenues:
+
+- [#otel-sig-end-user Slack channel](https://cloud-native.slack.com/archives/C01RT3MSWGZ)
+  – you can also reach out to us here!
+- [End user resources page](/community/end-user/).

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.102.1
+  vers: 0.103.0
 weight: 270
 ---
 

content/en/docs/collector/management.md

@@ -90,7 +90,7 @@ We will set up a simple OpAMP control plane consisting of an example OpAMP
 server and let an OpenTelemetry Collector connect to it via an example OpAMP
 supervisor.
 
-First, clone the `open-telemetry/opamp-go` repo:
+First, clone the `open-telemetry/opamp-go` repository:
 
 ```sh
 git clone https://github.com/open-telemetry/opamp-go.git
@@ -159,7 +159,7 @@ service:
 ```
 
 Now it's time to launch the supervisor (which in turn will launch your
-OpenTelemetry collector):
+OpenTelemetry Collector):
 
 ```console
 $ go run .

content/en/docs/collector/troubleshooting.md

@@ -2,7 +2,7 @@
 title: Troubleshooting
 description: Recommendations for troubleshooting the Collector
 weight: 25
-cSpell:ignore: pprof tracez zpages
+cSpell:ignore: confmap pprof tracez zpages
 ---
 
 On this page, you can learn how to troubleshoot the health and performance of
@@ -359,3 +359,21 @@ container, producing the error message
 the `NO_WINDOWS_SERVICE=1` environment variable must be set to force the
 Collector to start as if it were running in an interactive terminal, without
 attempting to run as a Windows service.
+
+### Collector is experiencing configuration issues
+
+The Collector might experience problems due to configuration issues.
+
+#### Null maps
+
+During configuration resolution of multiple configs, values in earlier configs
+are removed in favor of later configs, even if the later value is null. You can
+fix this issue by
+
+- Using `{}` to represent an empty map, such as `processors: {}` instead of
+  `processors:`.
+- Omitting empty configurations such as `processors:` from the configuration.
+
+See
+[confmap troubleshooting](https://github.com/open-telemetry/opentelemetry-collector/blob/main/confmap/README.md#null-maps)
+for more information.

content/en/docs/concepts/instrumentation/zero-code.md

@@ -45,7 +45,8 @@ Other configuration options are available, including:
 Automatic instrumentation is available for the following languages:
 
 - [.NET](/docs/zero-code/net/)
+- [Go](/docs/zero-code/go)
 - [Java](/docs/zero-code/java/)
 - [JavaScript](/docs/zero-code/js/)
-- [PHP](/docs/languages/php/automatic/)
-- [Python](/docs/languages/python/automatic/)
+- [PHP](/docs/zero-code/php/)
+- [Python](/docs/zero-code/python/)

content/en/docs/contributing/development.md

@@ -3,7 +3,6 @@ title: Development
 description:
   Learn how to set up a development environment for the opentelemetry.io site.
 weight: 60
-cSpell:ignore: chalin
 ---
 
 The following instructions explain how to set up a development environment for
@@ -122,77 +121,6 @@ within a submodule, set the environment variable `GET=no`. You also need to run
 `git fetch --unshallow` the submodule before you can submit a PR. Alternatively,
 set `DEPTH=100` and re-fetch submodules.
 
-## Approver and maintainer practices
-
-This last section includes guidelines and some common practices used by
-approvers and maintainers while doing code reviews:
-
-- PRs with changes to documentation co-owned by a SIG (collector, demo,
-  language-specific...) should aim for two approvals: one by a docs approver and
-  one by a SIG approver:
-  - Doc approver label such PRs with `sig:<name>` and tag the SIG `-approvers`
-    group on that PR
-  - After a doc approver has reviewed and approved the PR, they can add the
-    label
-    [`sig-approval-missing`](https://github.com/open-telemetry/opentelemetry.io/labels/sig-approval-missing).
-    This signals to the SIG that they need to handle the PR
-  - If no SIG approval is given within a certain grace period (two weeks in
-    general, but may be less in urgent cases), docs maintainer may use their own
-    judgement to merge that PR
-- PRs created by bots can be merged by the following practice:
-  - PRs that auto-update versions in the registry can be fixed, approved and
-    merged immediately
-  - PRs that auto-update the versions of SDKs, zero-code instrumentations or the
-    collector can be approved and merged except the corresponding SIG signals
-    that merging should be postponed
-  - PRs that auto-update the version of any specification often require updates
-    to scripts for the CI checks to pass. In that case often
-    [@chalin](https://github.com/chalin/) will handle that PR. Otherwise those
-    PRs can as well be approved and merged except the corresponding SIG signals
-    that merging should be postponed.
-- PRs with changes to translations should aim for two approvals: one by a docs
-  approver and one by a translation approver. Similar practices apply as
-  suggested for the co-owned PRs.
-- If the PR branch is `out-of-date with the base branch`, they do not need to be
-  updated continuously: every update triggers all the PR CI checks to be run!
-  It's often enough to update them before merging.
-- A PR by non-maintainers should **never** update git sub modules. This happens
-  by accident from time to time. Let the PR author know that they should not
-  worry about it, we will fix this before merging, but in the future they should
-  make sure that they work from an up-to-date fork.
-- If the contributor is having trouble signing the CLA or used the wrong email
-  by mistake in one of their commits, ask them to fix the issue or rebase the
-  pull request. Worst case scenario, close and re-open the PR to trigger a new
-  CLA check.
-- Words unknown to cspell should be added to the cspell ignore list per page by
-  PR authors. Only approvers and maintainers will add commonly used terms to the
-  global list.
-- Approvers and maintainers have different work schedules and circumstances.
-  That's why all communication is assumed to be asynchronously and they should
-  not feel obligated to reply outside of their normal schedule.
-- When an approver or maintainer won't be available to contribute for an
-  extended period of time (more than a few days or a week) or won't be available
-  in that period of time, they should communicate this using the
-  [#otel-comms](https://cloud-native.slack.com/archives/C02UN96HZH6) channel and
-  updating the GitHub status.
-- Approver and maintainer adhere to the
-  [OTel Code of Conduct](https://github.com/open-telemetry/community/?tab=coc-ov-file#opentelemetry-community-code-of-conduct)
-  and are friendly and helpful towards contributors. In the case of a conflict,
-  misunderstanding or any other kind of situation that makes an
-  approver/maintainer feel uncomfortable they can step back from a conversation,
-  issue or PR and ask another approver/maintainer to step in.
-
-The following workflow can be applied by maintainers to merge PRs:
-
-- Make sure that a PR has all approvals and all CI checks pass
-- If the branch is out-of-date, rebase update it via the GitHub UI.
-- The update will trigger all CI checks to run again, wait for them to pass or
-  execute a script like the following to make it happen in the background:
-
-  ```shell
-  export PR=<ID OF THE PR>; gh pr checks ${PR} --watch && gh pr merge ${PR} --squash
-  ```
-
 [clone]:
   https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
 [fork]: https://docs.github.com/en/get-started/quickstart/fork-a-repo