OpenTelemetry agent not included in Staticfile buildpack

Products

VMware Tanzu Platform Core

Issue/Introduction

Customers may want OpenTelemetry metrics from a static application deployed with the Staticfile buildpack, such as CPU usage, memory usage, request latency, or request count.

The Staticfile buildpack does not include an OpenTelemetry agent by default.

The Staticfile buildpack is designed to serve static assets such as HTML, JavaScript, CSS, images, and other static content. In Tanzu Application Service, Staticfile applications are served by NGINX rather than by an application runtime such as Java, Node.js, or .NET.

Because of this, OpenTelemetry instrumentation for Staticfile applications works differently from runtime-based applications.

Environment

Tanzu Application Service for VMs / Elastic Runtime
Staticfile buildpack

Cause

The Staticfile buildpack is intentionally minimal and opinionated. It is intended to serve static assets through NGINX, not to provide application runtime instrumentation.

Because of this, the Staticfile buildpack does not automatically emit application-level OpenTelemetry telemetry such as HTTP latency, request count, application traces, or custom application metrics.

The OpenTelemetry Collector deployed with TAS/ERT is not an application agent and is not injected into the Staticfile buildpack. It runs as a platform component on TAS/ERT VMs.

For Staticfile applications, telemetry is produced by the TAS/ERT platform rather than by an OpenTelemetry agent inside the application container. Request and latency-related data is produced by the routing layer when Gorouter handles traffic for the app. Container-level metrics, such as CPU, memory, and disk usage, are produced by the platform components responsible for running and monitoring app instances, such as Diego/rep.

These logs and metrics are sent into Loggregator. The Loggregator Forwarder then sends the telemetry to the local OpenTelemetry Collector, which exports the signals enabled in its configuration.

In simplified form:

Staticfile app receives traffic
        |
        v
TAS/ERT platform components produce telemetry:
  - Gorouter: request/routing/latency data
  - Diego/rep: container metrics such as CPU, memory, disk
        |
        v
Loggregator
        |
        v
Loggregator forwarder
        |
        v
OpenTelemetry Collector
        |
        v
Configured external telemetry backend

Therefore, latency, routing data, CPU, memory, and disk metrics for a Staticfile app should be obtained from TAS/ERT platform telemetry, not from OpenTelemetry instrumentation inside the Staticfile buildpack.

Resolution

For platform-level observability, configure the OpenTelemetry Collector integration provided by TAS/ERT System Logging. This allows TAS/ERT Loggregator telemetry to be exported to an external OpenTelemetry endpoint. The model is following: Loggregator Forwarder Agent forwards platform and application telemetry to the OTel Collector, which then exports traces, metrics, and logs through configured pipelines.

For a static application, the recommended approach is usually to collect observability from the TAS/ERT platform layer, especially:

Gorouter/RTR logs for request-level data such as route, status code, response_time, and gorouter_time.
Diego/rep container metrics for app instance/container-level data such as CPU, memory, disk, and instance health.

Find an example configuration for OTEL collector for TAS/ERT 2.10.x -> System Logging/OTEL -> OpenTelemetry Collector Configuration - Metrics, Application Logs and Traces

exporters:
  otlp/http:
    endpoint: "http://###.###.###.###:4318" 
    tls:
      insecure: true
service:
  pipelines:
    metrics:
      exporters: [otlp/http]
    traces:          # <-- Added
      exporters: [otlp/http]
    logs:            # <-- Added
      exporters: [otlp/http]