Topic starter
19/08/2026 4:04 pm
TL;DR: .NET teams can forward Serilog logs through OpenTelemetry into a centralized telemetry pipeline without rewriting existing sinks, using package updates, collector endpoint configuration, and environment-aware settings, according to Sawmills. The governance issue is not logging mechanics alone, but how teams preserve context, control telemetry sprawl, and keep production configuration auditable.
Editorial analysis by NHI Mgmt Group, based on content published by Sawmills: “Forward Your Serilog Logs to Sawmills via OpenTelemetry: A Complete Guide”.
Key questions
Q: What breaks when Serilog logs are forwarded without stable OpenTelemetry configuration?
A: The main failure is configuration drift.
Q: Why do environment-specific collector settings matter for production logging?
A: Because production logging needs predictable routing and controlled change.
Q: What are the signs that centralized telemetry is losing context?
A: Common signs include missing service names, inconsistent environment labels, and logs that cannot be reliably separated by workload or release version.
Practitioner guidance
- Define a standard OpenTelemetry logging pattern Keep existing Serilog sinks where needed, but add an OpenTelemetry exporter pattern that every .NET service can use consistently.
- Move collector endpoints out of application code Use environment variables or environment-specific configuration files for the collector host and port instead of hard-coded IP addresses.
- Preserve service metadata in every log stream Include service.name, service.version, and deployment.environment in the OpenTelemetry resource attributes so downstream systems can classify logs by workload and stage.
Bottom line: Forwarding Serilog through OpenTelemetry lets .NET teams centralize telemetry without dismantling existing sinks, but the real control problem is governance of the collector path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:38 pm
Telemetry governance now includes transport decisions, not just log content. This article shows that once teams forward Serilog through OpenTelemetry, the meaningful control points move to endpoint selection, resource tagging, and environment handling. That is a governance shift because telemetry quality and routing depend on configuration discipline as much as on logging code. Practitioners should treat observability pipelines as controlled production infrastructure.
A question worth separating out:
Q: Should teams keep Serilog sinks after adding OpenTelemetry forwarding?
A: Yes, if they still need local console or file logging for operational purposes. The key is to treat OpenTelemetry as an additional governed path, not a replacement by default. Keep only the sinks that serve a clear operational need and document why each one exists.
👉 Read our full editorial: OpenTelemetry log forwarding changes telemetry governance for .NET teams