Merge branch 'main' into credential-test-failure

.chloggen/awsxrayexporter-fix-segment-gen.yaml

@@ -0,0 +1,27 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
+component: awsxrayexporter
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: "Generate url section in xray segment when `net.peer.name` is available"
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [35375]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext:
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

.chloggen/deprecate-routing-processor.yaml

@@ -0,0 +1,27 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: deprecation
+
+# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
+component: routingprocessor
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Deprecated in favor of the routing connector.
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [36616]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext:
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user, api]

.chloggen/k8sattributes-k8s-client-init-log.yaml

@@ -0,0 +1,29 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: bug_fix
+
+# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
+component: k8sattributesreceiver
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Log any errors encountered during kube client initialisation
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [35879]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: | 
+  This addresses an issue where the collector, due to an error encountered during the kubernetes client initialisation,
+  was reporting an 'unavailable' status via the health check extension without any further information to be found in the logs.
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: []

connector/routingconnector/README.md

@@ -133,10 +133,10 @@ connectors:
     default_pipelines: [logs/other]
     table:
       - context: request
-        condition: reqeust["X-Tenant"] == "acme"
+        condition: request["X-Tenant"] == "acme"
         pipelines: [logs/acme]
       - context: request
-        condition: reqeust["X-Tenant"] == "ecorp"
+        condition: request["X-Tenant"] == "ecorp"
         pipelines: [logs/ecorp]
 
 service:
@@ -263,10 +263,10 @@ connectors:
         condition: severity_number < SEVERITY_NUMBER_ERROR
         pipelines: [logs/cheap]
       - context: request
-        condition: reqeust["X-Tenant"] == "acme"
+        condition: request["X-Tenant"] == "acme"
         pipelines: [logs/acme]
       - context: request
-        condition: reqeust["X-Tenant"] == "ecorp"
+        condition: request["X-Tenant"] == "ecorp"
         pipelines: [logs/ecorp]
 
 service:
@@ -285,10 +285,6 @@ service:
       exporters: [file/ecorp]
 ```
 
-## Differences between the Routing Connector and Routing Processor
-
-- The connector routes to pipelines, not exporters as the processor does.
-
 [Connectors README]:https://github.com/open-telemetry/opentelemetry-collector/blob/main/connector/README.md
 
 [OTTL]: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md

exporter/awsxrayexporter/internal/translator/http.go

@@ -92,6 +92,7 @@ func makeHTTP(span ptrace.Span) (map[string]pcommon.Value, *awsxray.HTTPData) {
 			hasHTTPRequestURLAttributes = true
 		case conventions.AttributeNetPeerName:
 			urlParts[key] = value.Str()
+			hasHTTPRequestURLAttributes = true
 		case conventions.AttributeNetPeerPort:
 			urlParts[key] = value.Str()
 			if len(urlParts[key]) == 0 {

exporter/awsxrayexporter/internal/translator/http_test.go

@@ -88,6 +88,7 @@ func TestClientSpanWithPeerAttributes(t *testing.T) {
 
 	assert.NotNil(t, httpData)
 	assert.NotNil(t, filtered)
+	assert.NotNil(t, httpData.Request.URL)
 
 	assert.Equal(t, "10.8.17.36", *httpData.Request.ClientIP)
 

pkg/ottl/CONTRIBUTING.md

@@ -6,20 +6,52 @@ This guide is specific to the OpenTelemetry Transformation Language.  All guidel
 
 - Changes to the OpenTelemetry Transformation Language should be made independent of any component that depend on the package.  Whenever possible, try not to submit PRs that change both the OTTL and a dependent component.  Instead, submit a PR that updates the OTTL and then, once merged, update the component as needed.
 
-## New Values
+## Adding New Editors/Converters
 
-When adding new values to the grammar you must:
+Before raising a PR with a new Editor or Converter, raise an issue to verify its acceptance. While acceptance is strongly specific to a specific use case, consider these guidelines for early assessment.
 
-1. Update the `Value` struct with the new value.  This may also mean adding new token(s) to the lexer.
-2. Update `NewFunctionCall` to be able to handle calling functions with this new value.
-3. Update `NewGetter` to be able to handle the new value.
-4. Add new unit tests.
+Your proposal likely will be accepted if:
+
+- The proposed functionality is missing,
+- The proposed solution significantly improves user experience and readability for very common use cases,
+- The proposed solution is more performant in cases where it is possible to achieve the same result with existing options.
+
+It will be up for discussion if your proposal solves an issue that can be achieved in another way but does not improve user experience or performance.
+
+Your proposal likely won't be accepted if:
+
+- User experience is worse and assumes a highly technical user,
+- The performance of your proposal very negatively affects the processing pipeline.
+
+As with code, OTTL aims for readability first. This means:
 
-## New Functions
+- Using short, meaningful, and descriptive names,
+- Ensuring naming consistency across Editors and Converters,
+- Avoiding deep nesting to achieve desired transformations,
+- Ensuring Editors and Converters have a single responsibility.
+
+### Implementation guidelines
 
 All new functions must be added via a new file.  Function files must start with `func_`.  Functions must be placed in `ottlfuncs`.
 
 Unit tests must be added for all new functions.  Unit test files must start with `func_` and end in `_test`.  Unit tests must be placed in the same directory as the function.  Functions that are not specific to a pipeline should be tested independently of any specific pipeline. Functions that are specific to a pipeline should be tests against that pipeline. End-to-end tests must be added in the `e2e` directory.
 
-Function names should follow the [Function Syntax Guidelines](ottlfuncs/README.md#function-syntax)
+#### Naming and Parameter Guidelines
+
+Functions should be named and formatted according to the following standards.
+
+- Function names MUST start with a verb unless it is a Factory that creates a new type.
+- Converters MUST be UpperCamelCase.
+- Function names that contain multiple words MUST separate those words with `_`.
+- Functions that interact with multiple items MUST have plurality in the name. Ex: `truncate_all`, `keep_keys`, `replace_all_matches`.
+- Functions that interact with a single item MUST NOT have plurality in the name. If a function would interact with multiple items due to a condition, like `where`, it is still considered singular. Ex: `set`, `delete`, `replace_match`.
+- Functions that change a specific target MUST set the target as the first parameter.
 
+## New Values
+
+When adding new values to the grammar you must:
+
+1. Update the `Value` struct with the new value.  This may also mean adding new token(s) to the lexer.
+2. Update `NewFunctionCall` to be able to handle calling functions with this new value.
+3. Update `NewGetter` to be able to handle the new value.
+4. Add new unit tests.

pkg/ottl/ottlfuncs/README.md

@@ -2127,35 +2127,3 @@ The returned type is `int64`.
 Examples:
 
 - `Year(Now())`
-
-## Function syntax
-
-Functions should be named and formatted according to the following standards.
-
-- Function names MUST start with a verb unless it is a Factory that creates a new type.
-- Converters MUST be UpperCamelCase.
-- Function names that contain multiple words MUST separate those words with `_`.
-- Functions that interact with multiple items MUST have plurality in the name. Ex: `truncate_all`, `keep_keys`, `replace_all_matches`.
-- Functions that interact with a single item MUST NOT have plurality in the name. If a function would interact with multiple items due to a condition, like `where`, it is still considered singular. Ex: `set`, `delete`, `replace_match`.
-- Functions that change a specific target MUST set the target as the first parameter.
-
-## Adding New Editors/Converters
-
-Before raising a PR with a new Editor or Converter, raise an issue to verify its acceptance. While acceptance is strongly specific to a specific use case, consider these guidelines for early assessment.
-
-Your proposal likely will be accepted if:
-- The proposed functionality is missing,
-- The proposed solution significantly improves user experience and readability for very common use cases,
-- The proposed solution is more performant in cases where it is possible to achieve the same result with existing options.
-
-It will be up for discussion if your proposal solves an issue that can be achieved in another way but does not improve user experience or performance.
-
-Your proposal likely won't be accepted if:
-- User experience is worse and assumes a highly technical user,
-- The performance of your proposal very negatively affects the processing pipeline.
-
-As with code, OTTL aims for readability first. This means:
-- Using short, meaningful, and descriptive names,
-- Ensuring naming consistency across Editors and Converters,
-- Avoiding deep nesting to achieve desired transformations,
-- Ensuring Editors and Converters have a single responsibility.