> For the complete documentation index, see [llms.txt](https://brightercommand.gitbook.io/paramore-brighter-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brightercommand.gitbook.io/paramore-brighter-documentation/health-checks-and-observability/logging.md).

# Logging

Brighter writes its diagnostics through Microsoft.Extensions.Logging, and takes its ILoggerFactory from a single static holder rather than from your container.

> **Reference** · Applies to **Brighter V10** · Prerequisites: [Basic Configuration](/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration.md)

Brighter writes its diagnostics through `Microsoft.Extensions.Logging`, and takes its `ILoggerFactory` from a single static holder rather than from your container.

That one design decision explains everything else on this page, including why Brighter can appear to log nothing at all.

## How Brighter Gets Its Logger

Every Brighter type that logs holds its logger in a static field, built once from `Paramore.Brighter.Logging.ApplicationLogging`:

```csharp
using Microsoft.Extensions.Logging;
using Paramore.Brighter.Logging;

public class CommandProcessor
{
    private static readonly ILogger s_logger = ApplicationLogging.CreateLogger<CommandProcessor>();
    // ...
}
```

`ApplicationLogging` is a static holder with a settable factory:

```csharp
using Microsoft.Extensions.Logging;

namespace Paramore.Brighter.Logging;

public static class ApplicationLogging
{
    public static ILoggerFactory LoggerFactory { get; set; } = new LoggerFactory();
    public static ILogger CreateLogger<T>() => LoggerFactory.CreateLogger<T>();
}
```

**The default is a `LoggerFactory` with no providers**, which accepts every call and writes nothing. Brighter is never silent because logging is switched off; it is silent because nothing has been given somewhere to write to.

Because `CreateLogger<T>()` is called with the type, the **category name is the full type name** — `Paramore.Brighter.CommandProcessor`, `Paramore.Brighter.ServiceActivator.Dispatcher`. Filtering on the `Paramore.Brighter` prefix therefore catches all of it.

## Logging with Dependency Injection

If you use the DI extensions, Brighter installs your container's factory for you. The command processor `AddBrighter` registers, and the Dispatcher `AddConsumers` registers, each resolve `ILoggerFactory` from the container when they are built — the first time the container resolves them — and hand it to `ApplicationLogging`:

```csharp
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Paramore.Brighter.Extensions.DependencyInjection;

var builder = Host.CreateApplicationBuilder(args);

// The generic host registers ILoggerFactory, so Brighter finds one.
builder.Services.AddBrighter()
    .AutoFromAssemblies([typeof(GreetingCommand).Assembly]);

var host = builder.Build();
```

The resolution is `GetService<ILoggerFactory>()`, not `GetRequiredService`, so a container with no factory registered is not an error — Brighter keeps the empty default and writes nothing.

**Until then, Brighter's types log to the empty default.** A type that logs before the command processor or the Dispatcher is first resolved — a producer you send through at startup, say — keeps that logger for the life of the process, and none of its lines reach your providers.

## Logging Without Dependency Injection

If you build a Command Processor by hand, assign the factory yourself:

```csharp
using Microsoft.Extensions.Logging;
using Paramore.Brighter;
using Paramore.Brighter.Logging;

ApplicationLogging.LoggerFactory = LoggerFactory.Create(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Information);
});

// subscriberRegistry and handlerFactory are yours: they register and create your handlers
var commandProcessor = CommandProcessorBuilder.StartNew()
    .Handlers(new HandlerConfiguration(subscriberRegistry, handlerFactory))
    .DefaultResilience()
    .NoExternalBus()
    .NoInstrumentation()
    .RequestContextFactory(new InMemoryRequestContextFactory())
    .RequestSchedulerFactory(new InMemorySchedulerFactory())
    .Build();
```

**Assign it before you build anything.** Each type caches its logger in a `static readonly` field the first time that type is used, so a factory installed afterwards is never seen by the types that have already initialised.

## What Brighter Logs

Log methods are source-generated with `[LoggerMessage]`, so the messages are structured rather than interpolated. The Command Processor declares its own in a `Log` class nested inside it (`src/Paramore.Brighter/CommandProcessor.cs`, in the 10.8.1 release). Here is one of them, with `Log` written as a top-level `internal` class, the form it takes in your own code; the generator writes the method's body:

```csharp
using System;
using Microsoft.Extensions.Logging;

internal static partial class Log
{
    [LoggerMessage(LogLevel.Information, "Building send pipeline for command: {CommandType} {Id}")]
    public static partial void BuildingSendPipelineForCommand(ILogger logger, Type commandType, string id);
}
```

`{CommandType}` and `{Id}` reach a structured sink as named fields, so you can query on them.

Across the Brighter source the levels divide roughly as:

| Level         | Used for                                                  |
| ------------- | --------------------------------------------------------- |
| `Trace`       | the finest pipeline detail                                |
| `Debug`       | pipeline construction and message pump steps              |
| `Information` | dispatch, handler counts, connection lifecycle            |
| `Warning`     | recoverable faults — a missing mapper, a retried delivery |
| `Error`       | a failure Brighter could not handle for you               |

`Information` is a reasonable production level for Brighter's categories; `Debug` is verbose, because a pipeline logs as it is built for every request.

## Logging Common Pitfalls

* **Nothing appears.** No provider is registered, or the factory was assigned after a Brighter type had already initialised its static logger. Check the order: under DI, resolve the command processor before you use a producer directly.
* **Logs stop when you move off DI.** The DI extensions were doing the assignment for you; the manual path does not.
* **Setting `ApplicationLogging.LoggerFactory` in a test affects the whole process.** It is static and shared, so set it once in fixture setup rather than per test.
* **Logging is not tracing.** For distributed traces across message boundaries, use [Telemetry](/paramore-brighter-documentation/health-checks-and-observability/telemetry.md); Brighter's logs are not a substitute for spans.

## Further Reading

* [Telemetry](/paramore-brighter-documentation/health-checks-and-observability/telemetry.md)
* [Configuring OpenTelemetry](/paramore-brighter-documentation/health-checks-and-observability/telemetry/configuringopentelemetry.md)
* [Monitoring](/paramore-brighter-documentation/health-checks-and-observability/monitoring.md)
* [Basic Configuration](/paramore-brighter-documentation/brighter-configuration/brighterbasicconfiguration.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://brightercommand.gitbook.io/paramore-brighter-documentation/health-checks-and-observability/logging.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.