Build logs are one of the most underutilized data sources in software development. Every time your CI/CD pipeline runs, it generates a wealth of information about your build process: compilation times, warnings, errors, project dependencies and target execution order. Yet in most organizations, these logs just sit there in the pipeline run history, only viewed when something breaks.
During last week, I built Botello to change that. Botello stands for Build Open Telemetry Logger and it is an open source .NET library which captures MSBuild events and forwards them as distributed traces and structured logs into any OpenTelemetry-compatible system, such as Azure’s Application Insights.
Why Should You Care About Build Logs?
Think about how much data your builds produce. Every dotnet build or msbuild invocation emits information about which projects were built, how long each target took, what warnings appeared and what failed. This data is incredibly valuable, but it is locked inside your CI/CD agent’s console output where it’s hard to query, aggregate or analyze.
If we get our build logs out from CI/CD agents, we can:
- Build statistics about build performance over time. Which projects are getting slower? What warnings keep recurring?
- Feed them to AI Agents that can analyze patterns, predict failures and suggest optimizations/fixes.
- Create dashboards that give your team real-time visibility into the health of your build process (Ok many CI/CD tools already provides this, but not in a detailed build level).
- Set up alerts when build times degrade or error rates spike.
- Correlate build data with deployment success rates, test results and production incidents.
The key insight is that build logs should not be treated as throwaway console output. They are telemetry data, and they deserve the same treatment as your application logs and metrics.
What is OpenTelemetry and Why Does It Matter?
OpenTelemetry is a vendor-neutral, open source observability framework for collecting, processing and exporting telemetry data (that’s a mouthful). It provides a single set of APIs, libraries, agents and instrumentation to capture distributed traces, metrics and logs from your applications.
Before OpenTelemetry, every observability vendor had its own SDK and its own data format. If you wanted to switch from one monitoring tool to another, you had to rewrite your instrumentation code. OpenTelemetry solves this by providing a standard that all vendors can support.
Botello: How It Works
Botello is a custom MSBuild logger. MSBuild has a well-defined extensibility point for loggers. You simply pass the logger DLL path to your build command and MSBuild takes care of the rest. No code changes to your projects are required.
When MSBuild loads Botello, it subscribes to build lifecycle events: build started, project started, target started, messages, warnings, errors and their corresponding “finished” events. Each event is mapped to either an OpenTelemetry span or a structured log entry.
The trace hierarchy looks like this:
build -- project: MyApp.csproj -- target: Build -- target: Compile -- project: MyLib.csproj -- target: Build
Spans are marked as `Ok` on success and `Error` on failure. When a build error is raised, the nearest active span is also marked as failed, so you can immediately see which project or target caused the problem.
Getting Started
To use the Botello you can start by cloning the project from GitHub. I will later provide the ready build release, but as of now, you can just clone it and build it by running dotnet build on project folder.
dotnet build Botello.sln -c Release
After building the project you get punch of DLL’s. Botello has some dependencies on other NuGet packages, so you will need all of those to use the Botello. You don’t have to copy them under your own project (or copy them inside CI/CD). Just use the absolute or relative path which point into Botello.dll when passing the logger for MSBuild/dotnet. You can easily pass the Application Insights connection string as a build parameter, or use an environment variable. The GitHub project contains sample of both of these configuration options.
This is how you do it with Environment variables:
# Linux/macOS export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=..." dotnet build MyApp.sln -logger:/path/to/Botello.dll # Windows $env:APPLICATIONINSIGHTS_CONNECTION_STRING = "InstrumentationKey=..." dotnet build MyApp.sln -logger:"C:\tools\Botello\Botello.dll"
That’s it. Within seconds of the build completing, you will see traces and logs in Application Insights.
Configuration
Botello supports configuration through appsettings.json, environment variables (BOTELLO__*) and inline CLI parameters. The inline parameters have the highest priority, so you can override anything on the command line:
dotnet build MyApp.sln \ -logger:"Botello.dll;ServiceName=my-app;MinimumLevel=Warning;IncludeTargetEvents=true"
You can control exactly what gets emitted: messages, warnings, errors, project events and target events all have individual toggles. For large solutions where target-level telemetry would be too noisy, you can simply turn it off.
The AI Agent Angle: Why This Matters Now
We are at a point where AI Agents are becoming a real part of our development workflows. These agents can read pull requests, fix bugs, generate code and now, with the right data, they can also understand your build process.
It is critical to build our systems so that we can feed data from various systems into AI Agents that are running somewhere in the cloud. These agents need access to structured, queryable data to be effective. A wall of console text is not useful to an AI agent. But structured OpenTelemetry traces with rich metadata? That’s something an agent can reason about.
Imagine an AI agent that:
- Monitors your build telemetry in Application Insights and notices that builds on the `main` branch have been getting 5% slower each week.
- Correlates the slowdown with specific projects that had the most code changes.
- Creates a GitHub issue with a detailed analysis and suggests which projects would benefit from build optimization.
- Or even submits a pull request that parallelizes independent build targets.
You need three things to achieve this: structured telemetry data (Botello gives you this), an observability platform to store and query it (Application Insights, Grafana, etc.) and an AI agent with access to that platform (Kilo Code, GitHub Copilot agents, or your own custom agent).
CI/CD Integration
Botello integrates with any CI/CD system that runs dotnet build or msbuild. Here are examples for the two most common platforms.
GitHub Actions
- name: Build
env:
APPLICATIONINSIGHTS_CONNECTION_STRING: ${{ secrets.APPINSIGHTS_CONNECTION_STRING }}
run: |
dotnet build MyApp.sln \
-logger:"${{ github.workspace }}/tools/Botello/Botello.dll;ServiceName=my-app;MinimumLevel=Warning"
Azure Pipelines
- task: DotNetCoreCLI@2 displayName: Build inputs: command: build arguments: > MyApp.sln -logger:"$(Agent.ToolsDirectory)/Botello/Botello.dll;ServiceName=$(Build.DefinitionName)" env: APPLICATIONINSIGHTS_CONNECTION_STRING: $(AppInsightsConnectionString)
The setup is minimal. Drop the Botello DLL’s onto your build agent, set the connection string as a secret and add the -logger parameter to your build command. From that point on, every build will emit telemetry.
Open Source
Botello is open source under the MIT license. The project lives at https://github.com/panuoksala/Botello. Contributions, issues and feedback are welcome.
The codebase depends on Microsoft.Build.Framework for MSBuild integration, Azure.Monitor.OpenTelemetry.Exporter for sending data to Application Insights and OpenTelemetry.Extensions.Hosting for the OTel pipeline. If you want to extend it to support other exporters or add custom enrichment logic, the architecture makes that possible.
Summary
Build logs contain valuable data that most teams ignore. By exporting them as OpenTelemetry traces and structured logs, we unlock the ability to build dashboards, create alerts, run statistical analysis and, most importantly, feed this data into AI agents that can help us improve our development process.
Botello makes this easier for .NET projects. Drop the DLL onto your build, set a connection string and you’re done. The project is open source, vendor-neutral through OpenTelemetry and ready for the AI-driven software development.
If you want to try it out, head to Botellos Github project page and give it a spin. If you run into issues or have ideas for improvements, open an issue. I am very grateful for all the help with the project.