Add OTLP logs pipeline for application signals

[jj22ee]

Description of the issue

Application Signals currently supports traces and metrics pipelines, but has no built-in support for forwarding OTLP logs to CloudWatch. ADOT-instrumented applications (Java, Node.js, Python) may emit telemetry as OTLP log records to the CWAgent's existing OTLP receiver (ports 4315/4316), but without a logs pipeline these records are silently dropped.

Customers must manually configure an otelConfig with otlphttp exporter, sigv4auth, and header injection to route OTLP logs to the CloudWatch Logs OTLP endpoint — a complex setup that should be handled natively by the Application Signals pipeline.

Description of changes

Adds a built-in logs/application_signals pipeline that receives OTLP logs on the existing Application Signals OTLP receiver (4315/4316) and forwards them to the CloudWatch Logs OTLP endpoint via otlphttp exporter with SigV4 authentication.

Activation: Customers add application_signals under logs.logs_collected in the CWAgent JSON config:

{
  "logs": {
    "logs_collected": {
      "application_signals": {
        "log_group_name": "/test/telemetry",
        "log_stream_name": "default"
      }
    }
  }
}

Changes:

• translator/translate/otel/translate_otel.go — Registers applicationsignals.NewTranslator(pipeline.SignalLogs) alongside existing traces/metrics translators.
• translator/translate/otel/pipeline/applicationsignals/translator.go — Adds SignalLogs branch that creates a logs pipeline that reuses existing AppSignals OTLP receivers (4315/4316), and uses otlphttp/application_signals (new Exporter) with sigv4auth & agenthealth Extensions. No processors.
• translator/translate/otel/exporter/otlphttp/translator.go — New translator that creates an otlphttp exporter config pointing to https://logs.<region>.amazonaws.com with sigv4auth authentication.
• translator/cmdutil/translatorutil.go — Adds injectAppSignalsLogsHeaders() workaround to restore x-aws-log-group and x-aws-log-stream headers after mapstructure marshal. These headers are nil'd during serialization because configopaque.String treats all header values as secrets, but log group/stream names are not sensitive and must survive the YAML round-trip.
• translator/config/schema.json — Adds application_signals (and app_signals fallback) under logs_collected with log_group_name and log_stream_name properties.
• translator/translate/otel/common/common.go — Adds AppSignalsLogs and AppSignalsLogsFallback config key constants, and registers pipeline.SignalLogs in AppSignalsConfigKeys.
• translator/translate/otel/pipeline/applicationsignals/translator_test.go — Adds TestTranslatorLogs with test cases for: missing config key, enabled logs pipeline, and enabled with debug exporter.

License

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Tests

1. Deployed Java sample application on EKS with CW Observability add-on, patched add-on to use custom image for CWAgent containing my changes

2. Configured logs.logs_collected.application_signals with /test/telemetry log group and default stream

{
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  },
  "logs": {
    "metrics_collected": {
      "application_signals": {}
    },
    "logs_collected": {
      "application_signals": {
        "log_group_name": "/test/telemetry",
        "log_stream_name": "default"
      }
    }
  }
}

3. Verified that OTLP logs from an implemented OtlpEmitter in ADOT Java SDK will flow through the logs/application_signals pipeline to CloudWatch Logs OTLP endpoint
   • Confirmed logs appear in /test/telemetry log group with correct default log stream

Also added TestTranslatorLogs in translator_test.go covering cases where (1) application_signals is not configured under logs_collected, (2) create pipeline with expected receivers, extensions, and exporter (which includes otlphttp/application_signals), and (3) includes debug/application_signals exporter when agent debug mode is enabled

Requirements

Before commiting your code, please do the following steps.

1. Run make fmt and make fmt-sh
2. Run make lint

---

Integration Tests

To run integration tests against this PR, add the ready for testing label.