Notifications
Clear all
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.
NHIMG editorial — based on content published by Sawmills: Forward Your Serilog Logs to Sawmills via OpenTelemetry: A Complete Guide
Questions worth separating out
Q: How should security teams govern OpenTelemetry agents in production?
A: Treat OpenTelemetry agents as production infrastructure with change control, role-based ownership, and approval paths for instrumentation changes.
Q: Why do telemetry endpoints need identity-style controls?
A: Telemetry endpoints behave like machine-managed access points because they decide where operational data is sent and which service context it carries.
Q: What breaks when environment-specific telemetry configuration is inconsistent?
A: Inconsistent configuration breaks routing consistency, environment separation, and incident investigation.
Practitioner guidance
- Inventory telemetry destinations Catalog every collector, backend, and environment-specific endpoint used by Serilog and OpenTelemetry so routing changes are visible to platform and security teams.
- Protect routing variables as controlled configuration Restrict who can modify SAWMILLS_COLLECTOR_HOST, SAWMILLS_COLLECTOR_PORT, and similar deployment variables, and require change review for production updates.
- Standardise resource attributes across services Define required values for service.name, service.version, service.instance.id, and deployment.environment so telemetry can be reliably filtered and investigated.
What's in the full article
Sawmills' full guide covers the operational implementation details this post intentionally leaves at the governance level:
- Exact Serilog and OpenTelemetry package configuration for .NET projects
- Collector endpoint discovery steps in Kubernetes environments
- Code-first and appsettings-based setup examples for OTLP forwarding
- Environment-variable patterns for production-safe endpoint management
👉 Read Sawmills' guide to forwarding Serilog logs through OpenTelemetry →
Serilog to OpenTelemetry in production: what should teams change?
Explore further
19/08/2026 4:38 pm
Telemetry pipelines now carry identity-like control points. The article is about log forwarding, but the real governance lesson is that collector endpoints, environment variables, and resource attributes behave like machine-managed access controls. Once telemetry crosses application and platform boundaries, teams need the same discipline they apply to workload identity and secrets handling. That means observability architecture should be governed as part of identity and access control, not left to application defaults.
A question worth separating out:
Q: How do teams know whether log forwarding is actually under control?
A: Teams know log forwarding is under control when collector destinations are inventoried, endpoint changes are reviewed, service attributes are standardised, and test results match expected routing in each environment. If those signals are missing, the pipeline may work technically while still operating outside governance boundaries.
👉 Read our full editorial: OpenTelemetry log forwarding changes telemetry governance for .NET teams
