Oqtane Logging

[bvillers-jr]

I am learning my way through Azure Log Analytics and Azure App Insights. It was originally my understanding that by building on .Net, we basically got very advanced logging, analytics, dashboards and alerting capability within Azure by basically flipping a switch.

As I dig in further, I've become a bit more perplexed as to whether or not this applies to Oqtane or if Oqtane circumvents that benefit of .Net all or perhaps part of the time.

It seems Oqtane logging is not purely separate from Azure/.NET logging. Oqtane’s ILogManager is its own abstraction, but the concrete LogManager constructor takes an ILogger, and Oqtane also has a FileLoggerProvider that creates Microsoft ILogger instances for startup scenarios. That strongly suggests Oqtane is at least partly built on top of the standard .NET logging pipeline rather than living entirely outside it.

At the same time, Oqtane also has its own Event Log feature and log model, with a built-in UI for filtering/viewing events and retention management. That means some logs are definitely handled as Oqtane-managed event records, not just “whatever Azure sees.”

Things I could use some clarification on:

I am not sure that Oqtane ILogManager logs are automatically excluded from Azure.

I am also not sure that all Oqtane ILogManager logs automatically flow to Azure.

What I can say with confidence is that if your ASP.NET Core host is configured with Application Insights, Application Insights collects ASP.NET Core ILogger logs by default, and those logs appear as traces in Application Insights and AppTraces in Log Analytics. Microsoft also notes that for ASP.NET Core you usually do not need to separately add the logger provider once the SDK is enabled.

That means if Oqtane’s ILogManager ultimately emits through its injected ILogger for a given log event, those events can absolutely end up in Azure. But if a given Oqtane log entry is only persisted to Oqtane’s own event-log/database path and not re-emitted through the .NET logging provider, Azure would not see it automatically.

I have a greater use for the log analysis and alerting features of Azure than I do for the Oqtane event viewer as it exists today and by using the Azure capabilities I am also able to include SQL Azure logs and performance in the dashboards and alerts.

Does anyone have experience with Oqtane logging on Azure or know the details and intention of Oqtane logging for the future?

[sbwalker]

@bvillers-jr you are correct that the logging capability in Oqtane was not designed for Azure... in fact Oqtane's logging infrastructure was created prior to many of the Azure features you mentioned above. At the time when logging was added to Oqtane there were a few primary goals in mind:

1. It needed to support a consistent logging approach for both client-side and server-side workloads (at the time there was no approach defined by Microsoft for logging in client-side Blazor components)
2. It needed to support multi-tenancy, as each Oqtane installation can have many different tenants. This was the most critical requirement, and the requirement which required a custom approach as none of the popular logging solutions at that time (ie. Serilog, etc...) supported mult-tenancy.

The FileLogger was introduced later specifically for startup as during startup there is no concept of a "tenant", as tenant resolution happens later in the pipeline.

If you want to create a deeper dependency on Azure logging in your installation you will need to do some customization to the framework, as this is not a high priority for the current roadmap.

[bvillers-jr]

Thank you for the clarification.

[sbwalker]

@bvillers-jr you could probably use the Azure Monitor Logs Ingestion API to send data from Oqtane to App Insights

[markdav-is]

I have a new requirement to log to our agencies GrayLog server. I was hoping to hook into ILoggingService and add some middleware to make that happen. anyone here extended the logging before?

Something similar might be the path to open telemetry. I'll be sure and share my approach and maybe publish it as a module.

[sbwalker]

@bvillers-jr and @markdav-is I believe Oqtane could be enhanced to include the ability to broadcast log events using ILogger. The following logic could be added in the Log method in LogManager. Basically, this would allow Oqtane to support its own multi-tenant logging for the client and server... but also send events to any ILogger providers you might register in your infrastructure. It would be controlled by an appsettings switch so that it does not impact performance in environments which do not need it.

            var broadcast = false;
            section = _config.GetSection("Logging:LogLevel:Broadcast");
            if (section.Exists())
            {
                broadcast = bool.Parse(section.Value);
            }
            if (broadcast)
            {
                // use ILogger to broadcast the event to any registered providers (e.g. Application Insights)
                // the SiteId will be passed as an EventId
                var eventId = new EventId((log.SiteId.HasValue) ? log.SiteId.Value : -1, "SiteId");
                var exception = (!string.IsNullOrEmpty(log.Exception) ? new Exception(log.Exception) : null);
                _logger.Log(GetLogLevel(log.Level), eventId, exception, log.Message);
            }

[leigh-pointer]

But not managed in appsettings, but host control.

[sbwalker]

@leigh-pointer I was thinking the actual configuration would be stored in appsettings.json with the other other logging settings:

  "Logging": {
    "FileLogger": {
      "LogLevel": {
        "Default": "Error"
      }
    },
    "LogLevel": {
      "Default": "Information",
      "Notify": "Error",
      "Broadcast": "Information"
    }
  }

The management of this setting could be exposed in System Info with the other Logging options:

[sbwalker]

#6234 adds the ability for log events to be broadcast to other registered logging providers. The option is available in System Info and is disabled by default (None). Note that the native Oqtane logging provides far more context than what the generic ILogger interface supports... so the Event Log should continue to be your primary source for log information. Broadcasting log information to other providers allows for secondary storage and integration with other log services which may be useful depending on your situation.