Serverless init

Active contributors: Ivan Topolcic, Nicholas Hulston, Aleksandr Pasechnik

Purpose

serverless-init is the Agent flavor for serverless runtimes — AWS Lambda extensions, Google Cloud Run, Azure App Service, and similar environments where the Agent runs alongside a single short-lived application rather than as a long-lived daemon.

The challenges for serverless are different from a host Agent:

• Cold start must be fast — the Agent is part of the cold-start critical path.
• Lifetime is short — the process may run for milliseconds to seconds.
• No system-probe / eBPF — sandbox-restricted runtimes can't load kernel modules.
• Single application — there's no need for autodiscovery or workloadmeta.

serverless-init is the result of stripping the Agent down to a minimum and re-arranging the remaining pieces around the constraints of serverless.

Directory layout

cmd/serverless-init/
├── main.go              # Linux entrypoint
├── main_windows.go      # Windows entrypoint
├── cloudservice/        # Provider detection (Lambda, Cloud Run, App Service, …)
├── enhanced-metrics/    # Provider-specific extra metrics
├── exitcode/            # Exit code reporting
├── log/                 # Lightweight logger
├── mode/                # Run modes (init, extension, …)
├── tag/                 # Auto-tag injection
└── trace/               # Trace agent helpers

pkg/serverless/          # Shared serverless primitives (also used by the Lambda extension)

Cloud provider detection

cloudservice/ detects which provider the binary is running on by inspecting environment variables and metadata services. Providers handled include:

• AWS Lambda (cloudservice/lambda.go)
• AWS App Runner
• Google Cloud Run, Cloud Functions
• Azure App Service
• Azure Container Apps

Each detected provider contributes its own tag set and "enhanced metrics" that capture provider-specific telemetry like memory limits or invocation counts.

Modes

mode/ selects how the binary behaves at startup:

• Init: run before the customer application, populating tags and starting trace receivers.
• Sidecar / extension: run alongside the customer app for the full request lifecycle.

The Lambda extension (which lives partially in pkg/serverless/) is the most elaborate example.

Trace forwarding

A serverless trace agent runs as part of the same process. It uses much of the same code as the standalone Trace Agent (pkg/trace/) but with serverless-specific configuration: smaller queues, faster flushes, no concentrator (the backend assumes a single short-lived app).

Exit codes

Cloud Run and similar runtimes signal failure via the exit code. exitcode/ propagates the customer process's exit code through the Agent wrapper so platform-level health checks see the right value.

Key abstractions

Type / package	Location	Purpose
cloudservice.CloudService	cmd/serverless-init/cloudservice/cloudservice.go	Provider abstraction
mode.Mode	cmd/serverless-init/mode/mode.go	Run mode
Tagger	cmd/serverless-init/tag/tag.go	Provider-specific tag injection
pkg/serverless/	pkg/serverless/	Shared logic (used by Lambda extension and serverless-init)

Entry points for modification

• New provider: implement CloudService under cmd/serverless-init/cloudservice/ and register it.
• New enhanced metric: extend enhanced-metrics/.
• Lambda extension changes: most logic is in pkg/serverless/.

Related pages

• Apps: Trace Agent — the trace pipeline used in serverless mode.
• Apps: OTel Agent — alternative serverless deployment shape.