Skip to content

README.md

Latest commit

 

History

History
89 lines (70 loc) · 3.32 KB

README.md

File metadata and controls

89 lines (70 loc) · 3.32 KB
Raw

Routing Logs to Different Destinations

This example shows how to route logs from a single ILogger to different OTLP endpoints using a custom processor. This follows the Routing pattern described in the OpenTelemetry specification supplementary guidelines.

Overview

In some scenarios you need all application code to use the same ILogger pipeline, yet send certain logs to one backend and the rest to another. For example:

  • Logs from payment components should go to a dedicated collector endpoint (OTLP2).
  • All other logs should go to the default endpoint (OTLP1).

The routing decision is made at the processor level by inspecting the CategoryName of each LogRecord. A custom processor checks whether the category name starts with a configured prefix and forwards the record to the appropriate export pipeline.

Architecture

ILogger (single pipeline)
   |
   v
LoggerProvider
   |
   v
RoutingProcessor (custom)
   +-- CategoryName starts with prefix --> ExportProcessor -> OtlpLogExporter (OTLP2)
   +-- otherwise --------------------------> ExportProcessor -> OtlpLogExporter (OTLP1)

How it works

  1. Two OtlpLogExporter instances are created, each pointing at a different endpoint.
  2. Each exporter is wrapped in a BatchLogRecordExportProcessor.
  3. A custom RoutingProcessor extends BaseProcessor<LogRecord> and overrides OnEnd. It checks if the log record's CategoryName starts with a configured prefix to decide which inner processor receives the record.
  4. The routing processor is registered on the LoggerProvider via AddProcessor.

Running the example

cd docs/logs/routing
dotnet run

Note

The example targets http://localhost:4317 and http://localhost:4318 as the two OTLP endpoints. You can start two local collectors (or use the OpenTelemetry Collector) listening on those ports to observe the routing behavior. The console exporter is also enabled so you can see all logs locally regardless of the OTLP endpoints.

Key considerations

  • Routing condition is evaluated per log record. Keep the logic fast -- it runs synchronously on every log emit.
  • Lifecycle management. The routing processor delegates ForceFlush, Shutdown, and Dispose to both inner processors so that both export pipelines are properly drained and cleaned up.

Files

File Description
Program.cs Console app demonstrating the routing
RoutingProcessor.cs Custom routing processor

Alternatives

This example achieves routing at the processor level, which means a single ILoggerFactory and LoggerProvider can send logs to different destinations. This is typically what is needed because most applications use a single ILoggerFactory provided by dependency injection.

If your application can create multiple ILoggerFactory instances, routing can be achieved at the ILogger level instead -- each factory is configured with its own export pipeline, and callers pick the appropriate logger. See the dedicated pipeline example for that approach.