Send PHP logs, metrics, and traces to Bronto

Instrument PHP applications with the OpenTelemetry PHP SDK and auto-instrumentation to send logs, metrics, and traces to Bronto over OTLP/HTTP, via an OTel Collector or directly.

The OpenTelemetry PHP SDK builds its providers from environment variables, so logs, metrics, and traces reach Bronto with almost no code. The opentelemetry extension auto-instruments Laravel, Symfony, Slim, PDO, and HTTP clients, and a Monolog handler bridges your existing log calls into the OTLP logs pipeline.

The application exports to an OpenTelemetry Collector, which forwards to Bronto. If you don’t run a Collector, export directly to Bronto instead — the code is identical, only two environment variables change.

Prerequisites

• PHP 8.1 or later, and Composer
• An OTel Collector reachable from your application, with logs, metrics, and traces pipelines forwarding to Bronto — see Connect OpenTelemetry Collector to Bronto

Install dependencies

The auto-instrumentation extension is a PECL package:

pecl install opentelemetry

Add extension=opentelemetry to your php.ini, then install the SDK and the instrumentation packages for your framework:

composer require \
  open-telemetry/sdk \
  open-telemetry/exporter-otlp \
  open-telemetry/opentelemetry-logger-monolog \
  open-telemetry/opentelemetry-auto-laravel \
  php-http/guzzle7-adapter

Replace opentelemetry-auto-laravel with the package for your framework — -symfony, -slim, -psr18, -pdo, and others. See PHP instrumentation libraries for the full list.

Configure the environment

export OTEL_PHP_AUTOLOAD_ENABLED=true
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_SERVICE_NAME="my-service"
export OTEL_RESOURCE_ATTRIBUTES="service.namespace=my-team,deployment.environment=production"

OTEL_PHP_AUTOLOAD_ENABLED is what builds the tracer, meter, and logger providers from these variables at startup — without it the SDK stays inert. The exporters append the signal path (/v1/logs, /v1/metrics, /v1/traces) to the endpoint automatically.

Two resource attributes determine how Bronto organises your data:

OTel attribute	Bronto concept	Set with
service.name	Dataset	OTEL_SERVICE_NAME
service.namespace	Collection	OTEL_RESOURCE_ATTRIBUTES

http://localhost:4318 is the standard OTLP/HTTP address for a Collector on the same host. Use the address reachable from your application if the Collector runs in another container, pod, or host. No authentication is needed between the application and the Collector — the Collector holds the Bronto API key.

Bridge your logs

Traces and metrics need no code. To route Monolog through the same pipeline, attach the OTel handler to your logger, taking the provider the autoloader already configured:

logging.php

<?php

use Monolog\Level;
use Monolog\Logger;
use OpenTelemetry\API\Globals;
use OpenTelemetry\Contrib\Logs\Monolog\Handler as OtelHandler;

$logger = new Logger('my-service');
$logger->pushHandler(new OtelHandler(Globals::loggerProvider(), Level::Debug));
$logger->pushHandler(new \Monolog\Handler\StreamHandler('php://stdout', Level::Debug));

On Monolog 2, use Logger::DEBUG in place of Level::Debug.

Instrument your application

Existing Monolog calls need no changes. For spans and instruments around your own business logic:

<?php

use OpenTelemetry\API\Globals;

$tracer = Globals::tracerProvider()->getTracer('my-service');
$payments = Globals::meterProvider()->getMeter('my-service')->createCounter('app.payments');

$span = $tracer->spanBuilder('process-payment')->startSpan();
$scope = $span->activate();
try {
    $span->setAttribute('payment.amount', 99.99);
    $payments->add(1);
    $logger->info('Processing payment');  // trace_id and span_id attached automatically
} finally {
    $scope->detach();
    $span->end();
}

Any log emitted inside an active span automatically carries that span’s trace_id and span_id, so you can jump from a log line to its trace in Bronto.

Verify

Run your application, then check each signal in Bronto, filtering by the service.name you set:

• Logs — the Search page, in the dataset named after your service
• Metrics — the Metric Explorer
• Traces — the Explore Traces page

If nothing arrives:

• Confirm OTEL_PHP_AUTOLOAD_ENABLED=true is set in the environment the PHP process actually runs in — under PHP-FPM that means the pool config, not your shell.
• Confirm the Collector is running and reachable at OTEL_EXPORTER_OTLP_ENDPOINT, and that its pipelines include an otlp receiver and the Bronto exporters.
• Check php -m | grep opentelemetry lists the extension — without it, the auto-instrumentation packages do nothing.

For signal-specific reference material, see Send Metrics to Bronto and Send Traces to Bronto.

PHP’s request-per-process model means each request exports its own batch. In high-throughput deployments, point the SDK at a local Collector rather than at Bronto directly so batching and retries happen outside the request lifecycle.

Direct export to Bronto

Without a Collector, the application exports straight to Bronto over OTLP/HTTP. Point the endpoint at your Bronto region and add your API key:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingestion.eu.bronto.io"   # or ingestion.us.bronto.io
export OTEL_EXPORTER_OTLP_HEADERS="x-bronto-api-key=<YOUR_API_KEY>"

Region	Base endpoint
EU	https://ingestion.eu.bronto.io
US	https://ingestion.us.bronto.io

See API Keys for how to create a key with ingestion permissions.

Prefer the Collector for multi-service environments — it batches, filters, and enriches telemetry, and keeps the API key out of every application. Direct export suits single services and simple architectures.

GenAI semantic conventions

If your application calls an LLM, OpenTelemetry’s GenAI semantic conventions define gen_ai.* span attributes for model, token usage, and prompt and response content.

Manual spans

PHP contrib has OpenAI client instrumentation, but it emits openai.* rather than the standard gen_ai.* fields. For portable attributes, set them yourself around each model call:

<?php

$span = $tracer->spanBuilder('chat gpt-4o-mini')->startSpan();
$scope = $span->activate();
try {
    $span->setAttribute('gen_ai.provider.name', 'openai');
    $span->setAttribute('gen_ai.request.model', 'gpt-4o-mini');
    $span->setAttribute('gen_ai.usage.input_tokens', 33);
    $span->setAttribute('gen_ai.usage.output_tokens', 74);
    // Bronto flattens array attributes — this is searchable as finish_reasons.0
    $span->setAttribute('gen_ai.response.finish_reasons', ['stop']);
} finally {
    $scope->detach();
    $span->end();
}

Message content (gen_ai.input.messages / gen_ai.output.messages) is opt-in by convention and off by default in the languages that have auto-instrumentation. Since you are setting attributes by hand, apply the same discipline — gate prompt and response content behind your own config flag rather than always sending it.

See the GenAI span conventions for the full attribute list.

For the recommended attribute set and Bronto search queries, see LLM Observability.