feat: Lambdas behind an Application Load Balancer get HTTP attributes on their spans

[RaphaelManke]

TL;DR

• What & why: Lambdas behind an Application Load Balancer now get HTTP attributes on their spans, where before they got none.
• Implementation: The existing API Gateway extraction grew an ALB branch that reads the fields ALB actually sends.
• Notable: ALB spans carry no http.route, because the event has no route in it to read.

Notable changes

Details

• http.route and network.protocol.version are absent for ALB. The event carries no route template and no protocol field, so the extension omits them rather than guessing. It does not fall back to url.path as the route, since that value is high cardinality.
• Under the existing DASH0_ENABLE_API_GATEWAY_SPAN_NAME, the extension names an ALB span after the bare method, such as GET. That is the HTTP semconv fallback when no route is available.
• The four DASH0_API_GATEWAY_* variables now gate ALB capture too. Their names stay as they are so nothing breaks for current users, and the README notes it.
• Internal renames follow the widened scope. ApiGatewayVersion becomes HttpEventKind, and the InvocationEntry fields lose their api_gateway_ prefix. No env var or attribute name changes.

Feature: HTTP attributes for ALB-triggered invocations

Details

What & Why:

• The extension recognized ALB events only well enough to keep them out of the API Gateway path. They carry a requestContext and a top-level httpMethod, so without that guard the extension would have reported them as REST API v1. Nothing picked them back up afterwards, so an ALB-triggered invocation got no HTTP attributes and no response status code.
• Extraction runs off the raw invoke event inside the extension, so this works on every runtime and also when auto-instrumentation is off.

Implementation:

• Detection now reports which of the three shapes an event has. The ALB check runs first, since its top-level httpMethod would otherwise match the v1 branch.
• The ALB branch omits attributes ALB has no source for. What it does have comes from the forwarding headers. url.scheme reads x-forwarded-proto, server.address and server.port read host with x-forwarded-port as the port fallback, and client.address takes the first x-forwarded-for hop.
• That branch reads url.scheme rather than hardcoding https as the API Gateway branches do, because ALB listeners serve plain HTTP as well.
• Target groups with lambda.multi_value_headers.enabled send multiValueHeaders and multiValueQueryStringParameters instead of their single-value counterparts, in both directions. Reading only headers returns nothing at all on those target groups, so the code resolves either shape. A header sent more than once becomes one comma-joined value, which keeps the attribute a string in both configurations.
• Health check invocations arrive with a user-agent and nothing else, so each attribute is optional on its own rather than all-or-nothing.

flowchart LR
    E[invoke event] --> D{requestContext.elb?}
    D -->|yes| A[ALB]
    D -->|no| V{rawPath and<br/>requestContext.http?}
    V -->|yes| V2[API Gateway v2]
    V -->|no| V1{httpMethod?}
    V1 -->|yes| R[API Gateway v1]
    V1 -->|no| N[not HTTP, no attributes]

Loading

Verification:

• 17 unit tests cover the ALB shapes, including both header configurations, the health check event, an IPv6 host header, and a multi-hop x-forwarded-for.
• A temporary load balancer checked the event shapes against real traffic rather than the documentation alone. One default and one multi-value target group confirmed that:
  • requestContext holds only elb.targetGroupArn, with no route information anywhere in the event
  • the multi-value shape replaces the single-value fields instead of supplementing them
  • header names arrive lower-cased
  • ALB appends the client IP to an existing x-forwarded-for
  • query strings arrive without URL-decoding
  • a health check carries only user-agent
• That load balancer is deleted.