Varför saknas Azure Function Information Logs i Logs Workspace?

Felsökning av saknade Azure-funktionsloggar i Application Insights

Att arbeta med Azure Functions känns ofta som att bygga en väloljad automationsmotor. Men vad händer när några viktiga loggar försvinner från din Application Insights-arbetsyta? 🤔 Det är en utmaning som jag nyligen ställdes inför när jag utvecklade en Timer Trigger Azure Function. Mina loggar på informationsnivå, som fungerade perfekt i Azure Portal-loggkonsolen, var mystiskt frånvarande i Logs-arbetsytan.

Först antog jag att allt var rätt konfigurerat. När allt kommer omkring hade jag ställt in Application Insights under skapandet av min funktionsapp, och telemetriinställningen verkade fungera direkt. Som utvecklare finns det inget mer förbryllande än att se Varning och Fel-loggar visas korrekt medan informationsloggar inte finns att hitta. Var gömde de sig?

Det här problemet påminde mig om ett liknande ögonblick när jag felsökte en webbapplikation. Felloggarna skrek "Åtgärda mig!" medan de subtila loggarna på informationsnivå gled under radarn. Det är lite som att söka efter en saknad pusselbit – att veta att den finns men inte riktigt se den i högen. 🧩 Azures host.json och telemetriinställningar spelar ofta en roll här.

I den här artikeln kommer jag att bryta ner grundorsaken till detta problem och hur man löser det steg för steg. Från host.json-konfigurationer till att verifiera loggnivåtrösklar, jag guidar dig genom lösningen. Låt oss se till att de saknade informationsloggarna hittar tillbaka till din loggarbetsyta.

Förstå saknade Azure-funktionsloggar och hur du löser det

Skripten som tillhandahållits tidigare syftar till att lösa ett vanligt problem där Loggar på informationsnivå som genereras av en Azure-funktion visas inte i Logs-arbetsytan, även om de visas i Azure Portal-loggkonsolen. Denna avvikelse uppstår ofta på grund av felaktig konfiguration i filen host.json, otillräckliga telemetriinställningar eller problem med Application Insights-integrering. Genom att använda kommandon som ConfigureFunctionsWorkerDefaults() och AddApplicationInsightsTelemetryWorkerService(), ser vi till att Application Insights fångar loggarna som förväntat. Dessa skript skapar en stark grund för att samla in och hantera telemetridata.

Först ställer `HostBuilder` i Program.cs upp Azure Function-arbetsmiljön. Metoden ConfigureFunctionsWorkerDefaults() säkerställer att all nödvändig mellanprogramvara för Azure Functions initieras. Det tillåter också anpassad loggning och konfiguration av beroendeinjektion. Därefter registrerar vi uttryckligen Application Insights med AddApplicationInsightsTelemetryWorkerService(). Det här steget säkerställer att telemetrisamling är korrekt konfigurerad för icke-HTTP-utlösta Azure-funktioner. Tänk dig till exempel att felsöka en Timertrigger-funktion: Utan Application Insights blir spårning av prestanda och identifiering av problem en manuell och tidskrävande process. 🔧

Filen host.json spelar en nyckelroll för att kontrollera vilka loggnivåer som registreras. Genom att ställa in "LogLevel" till Information i både standard- och Application Insights-sektionerna, definierar vi uttryckligen att loggar på informationsnivå måste bearbetas. Egenskapen samplingSettings kan dock ibland filtrera bort loggar, vilket leder till att poster saknas i Logs-arbetsytan. Genom att inaktivera sampling ("isEnabled": false") säkerställer vi att all telemetridata, inklusive informationsloggar, samlas in. Detta är särskilt viktigt vid felsökning av produktionsproblem där även mindre detaljer kan avslöja grundorsaken. Jag stötte en gång i en situation där ett litet LogInformation-meddelande hjälpte till att avslöja en felkonfigurerad schemaläggare. 🎯

Slutligen verifierar enhetstestskriptet att loggar på olika nivåer – information, varning och fel – sänds ut och registreras korrekt. Använder SetMinimumLevel(), ser vi till att loggern bearbetar alla loggar vid eller över det önskade tröskelvärdet. I vårt exempel validerade vi att informationsloggar visas när de är explicit konfigurerade. Att skriva enhetstester som detta säkerställer att loggningsbeteendet är konsekvent i alla miljöer, vilket förhindrar överraskningar under driftsättning. Tillsammans ger dessa skript en heltäckande lösning för att felsöka saknade Azure Function-loggar och optimera telemetriinsamling i dina molnapplikationer.

// Solution 1: Proper Host Configuration and Log Filtering
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
public class Program
{
    public static void Main(string[] args)
    {
        var host = new HostBuilder()
            .ConfigureFunctionsWorkerDefaults()
            .ConfigureServices(services =>
            {
                services.AddApplicationInsightsTelemetryWorkerService();
                services.Configure<LoggerFilterOptions>(options =>
                {
                    options.MinLevel = LogLevel.Information;
                });
            })
            .Build();
        host.Run();
    }
}

// host.json Configuration
{
  "version": "2.0",
  "logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Function": "Information"
    },
    "applicationInsights": {
      "LogLevel": {
        "Default": "Information"
      },
      "samplingSettings": {
        "isEnabled": false
      }
    }
  }
}

using Microsoft.Extensions.Logging;
public class MyFunction
{
    private readonly ILogger _logger;
    public MyFunction(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger<MyFunction>();
    }
    public void Run()
    {
        _logger.LogInformation("Executing Information level log.");
        _logger.LogWarning("This is a Warning level log.");
        _logger.LogError("This is an Error level log.");
    }
}

using Xunit;
using Microsoft.Extensions.Logging;
public class LogTests
{
    [Fact]
    public void VerifyInformationLogsAreCaptured()
    {
        var loggerFactory = LoggerFactory.Create(builder =>
        {
            builder.AddConsole();
            builder.SetMinimumLevel(LogLevel.Information);
        });
        var logger = loggerFactory.CreateLogger("TestLogger");
        logger.LogInformation("This is a test Information log.");
        Assert.True(true, "Information log captured successfully.");
    }
}

Lösning av saknade Azure-funktionsloggar genom att utforska telemetridata

En annan kritisk aspekt av Azure Function-loggar som inte visas i Logs-arbetsytan involverar konfigurationen telemetrikanal som används av Application Insights. Som standard använder Azure Functions Application Insights SDK, som buffertar loggar innan de skickas till telemetrislutpunkten. Denna buffring kan dock försena eller utelämna vissa loggposter som loggar på informationsnivå på grund av sampling eller felaktig spolning av telemetridata. Att säkerställa korrekt telemetrikanalbeteende är avgörande för att upprätthålla konsekventa loggar.

En ofta förbisedd faktor är samplingsinställningar konfiguration i host.json. När sampling är aktiverat skickas endast en bråkdel av loggarna till Application Insights för att minska datamängden och kostnaderna. Men om informationsloggar är kritiska för felsökning måste du antingen inaktivera sampling helt ("isEnabled": false") eller justera samplingslogiken för att säkerställa att alla nödvändiga loggar fångas. Till exempel stötte jag på ett problem där att aktivera sampling orsakade slumpmässiga nedgångar i icke-kritiska informationsloggar, vilket ledde till frustration under produktionsfelsökning. 💻

Dessutom använder man Spola kommandon säkerställer att all buffrad telemetri skickas omedelbart, vilket undviker dataförlust. I scenarier där Azure Functions körs under högbelastningsutlösare som HTTP-förfrågningar eller timerutlösare, kan telemetribuffring ackumuleras snabbt, vilket orsakar förseningar. Genom att uttryckligen anropa TelemetryClient.Flush() eller verifiera telemetrislutpunktens anslutning, kan utvecklare minska logginkonsekvenser och upprätthålla en korrekt övervakningsmiljö. I slutändan möjliggör balansering av provtagning, buffring och spolning optimal loggsynlighet samtidigt som kostnaderna minimeras.

Säkra loggsynlighet i Azure Function Logs