Azure-webjobs-sdk: Continuous job not showing Functions in Dashboard

[stylesm]

We have an Azure WebJob (3.x) running under an API App in Azure, all Core 2.1. It publishes fine, and runs, but doesn't show any Functions or list the Function Invocations on the dashboard. Which is odd, because the console output for the job does show it detecting a function:

[10/17/2018 09:26:19 > fa7c81: SYS INFO] Run script 'run.cmd' with script host - 'WindowsScriptHost'
[10/17/2018 09:26:19 > fa7c81: SYS INFO] Status changed to Running
[10/17/2018 09:26:19 > fa7c81: INFO] 
[10/17/2018 09:26:19 > fa7c81: INFO] D:\local\Temp\jobs\continuous\SubmissionJob\43ucb4rv.ipc>dotnet SubmissionJob.dll  
[10/17/2018 09:26:21 > fa7c81: INFO] dbug: Microsoft.Extensions.Hosting.Internal.Host[1]
[10/17/2018 09:26:21 > fa7c81: INFO]       Hosting starting
[10/17/2018 09:26:21 > fa7c81: INFO] info: Microsoft.Azure.WebJobs.Hosting.JobHostService[0]
[10/17/2018 09:26:21 > fa7c81: INFO]       Starting JobHost
[10/17/2018 09:26:21 > fa7c81: INFO] info: Host.Startup[0]
[10/17/2018 09:26:21 > fa7c81: INFO]       Found the following functions:
[10/17/2018 09:26:21 > fa7c81: INFO]       SubmissionJob.Functions.ProcessQueueMessageAsync
[10/17/2018 09:26:21 > fa7c81: INFO]       
[10/17/2018 09:26:21 > fa7c81: INFO] Application started. Press Ctrl+C to shut down.
[10/17/2018 09:26:21 > fa7c81: INFO] Hosting environment: QA

The Program.cs Program class looks like this:

public static async Task Main(string[] args)
    {
        var builder = new HostBuilder()
            .UseEnvironment(Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT"))
            .ConfigureWebJobs(b =>
            {
                b.AddAzureStorageCoreServices()
                    .AddAzureStorage()
                    .AddServiceBus()
                    .AddEventHubs();
            })
            .ConfigureAppConfiguration(b =>
            {
                // Adding command line as a configuration source
                b.AddCommandLine(args);
            })
            .ConfigureLogging((context, b) =>
            {
                b.SetMinimumLevel(LogLevel.Debug);
                b.AddConsole();

                // If this key exists in any config, use it to enable App Insights
                var appInsightsKey = context.Configuration["APPINSIGHTS_INSTRUMENTATIONKEY"];
                if (!string.IsNullOrEmpty(appInsightsKey))
                {
                    b.AddApplicationInsights(o => o.InstrumentationKey = appInsightsKey);
                }
            })
            .ConfigureServices((context, services) =>
            {
                services.AddAutoMapper();

                services.AddMemoryCache();

                services.AddDbContext<SubmissionsDbContext>(opts =>
                    opts.UseSqlServer(context.Configuration.GetConnectionString("DefaultConnection")));

                // cloud services
                services.AddTransient(s =>
                    CloudStorageAccount.Parse(
                        context.Configuration.GetConnectionString("AzureQueueConnectionString")));
                services.AddTransient<IBlobReadService, AzureBlobReadService>();
                services.AddSingleton<IBlobWriteService, AzureBlobWriteService>();
                services.AddSingleton<IQueueWriteService, AzureQueueWriteService>();

                // submission services
                services.AddScoped<ISubmissionStatusService, SubmissionStatusService>();

                services.AddSingleton<Functions, Functions>();

                // job activator, required in webjobs sdk 3+
                services.AddSingleton<IJobActivator>(new WebJobsActivator(services.BuildServiceProvider()));
            })
            .UseConsoleLifetime();;

        var host = builder.Build();
        using (host)
        {
            await host.RunAsync();
        }
    }

The Functions.cs has a method with the following signature:
public async Task ProcessQueueMessageAsync([QueueTrigger("operations")] CloudQueueMessage incomingMessage, TextWriter log)

...scm.azurewebsites.net/azurejobs/#/jobs/continuous/SubmissionJob shows

Continuous WebJob Details SubmissionJob
Running
Run command: run.cmd

But there's no list of function invocations below it, and the job remains permanently in a Running state. If I go to the 'Functions' link in Kudu, it says there are no functions/function invocations to display.

Any thoughts?

The bulk of this worked fine in Framework 4.7, though the app builder was clearly different.

[giorgos07]

@stylesm I have the exact same problem with you and i could not make it work. There is an extension method called AddDashboardLogging - check here - which is deprecated but is supposed to work. Had no effect when i used it though. When you call ConfigureWebJobs method there is a AddWebJobs method which is called internally here. Inside this method there is a line with the following code:

services.TryAddSingleton<IDashboardLoggingSetup, NullDashboardLoggingSetup>(); 

I am not sure, but maybe this causes this issue. There is no documentation so we may have to wait until it is available. I have also seen that this DashboardLoggingSetup is not used at all and we also cannot register it on our own since it is internal

[mathewc]

You're supposed to be able to call builder.AddDashboardLogging and that should enable DashboardLogging, e.g.:

var builder = new HostBuilder()
    .ConfigureWebJobs(b =>
    {
        b.AddDashboardLogging()
        .AddAzureStorageCoreServices()
        .AddAzureStorage()
    })
    ...

However, I agree with you that it looks like this may have regressed. Even after calling bAddDashboardLogging(), the non-null implementation of IDashboardLoggingSetup here doesn't appear to be registered.

[stylesm]

@mathewc @giorgos07 I should've said in original issue, I had tried the AddDashboardLogging() extension method, but it didn't resolve the issue; presumably for the reason mentioned - the only service registered is the NullDashboardLoggingSetup, which disables everything. Do we know if the WebJobs.Host.Storage.Logging.DashboardLoggingSetup service is meant to be registered in v3?

[giorgos07]

@stylesm i do not know if DashboardLoggingSetup service is meant to be registered in v3 of the SDK. I have not found any official documentation until now, so i just have to wait.

[mathewc]

Bubbling up from discussion of these internals, as I mentioned above, I've confirmed that AddDashboardLogging does NOT wire things up properly, so Dashboard logging is not currently supported in v3.

[stylesm]

Sure, I think the question though, is should it be? The Kudu Dashboard is super convenient, and quite a few other Issues mention this.

Is the AddDashboardLoggin() extension method, which registers the NullDashboardLoggingSetup service only there for backwards compatibility - intentionally?

[jonsing]

We are experiencing the same problems with our webjob implementation. since upgrade to 3.0. Even if everything works the dashboard is very handy and miss it every second.

The dashboard also give you the message "Host is not running" which can cause some confusion.

[cyrilcathala]

The AddDashboardLoggin() depreciation suggests that it still works, but it doesn't, it is quite misleading. And pointing to App Insights is not enough of an explanation.

After some digging, I found that the doc for App Insights Integration was updated for WebJobs 3.x:

The experience that you'll get when using Application Insights with WebJobs is almost identical to the experience with Azure Functions.

So I searched for a way to monitor functions through App Insights - check here for details - and ended up reproducing the history of executions with this request:

| project timestamp, id, name, success, totimespan(duration), resultCode, operation_Id, cloud_RoleName 
| where cloud_RoleName =~ "my-instance" and name =~ 'FunctionName'
| order by timestamp desc

I hope this will help!

[AlexandreArpin]

Is there any news on whether this is gonna be addressed or not in a future release?

We've have some Webjobs configured to be manually triggered in the Dashboard but the new jobs no longer show up in the Kudu Dashboard.

[kspearrin]

Any update here? This is making it impossible for us to upgrade to SDK v3.

[sehcheese]

@mathewc Since Azure Application Insights is the way this is supposed to be done in v3, how can I use Application Insights to see invocation by invocation results for a v3 WebJob like I used to in the Kudu dashboard?

[OskarKlintrot]

Every run will be logged as a request and if the webjob fails it will be logged as a failed request.

[cbrianball]

@OskarKlintrot Quick question about that. I get alerts about slow performance and it's because the web jobs are considered requests. Is there a way to categorize webjobs as something other than a request?

[OskarKlintrot]

Good question @cbrianball , unfortunately I don't know. With the v2 of the SDK I logged each run myself as dependencies instead of requests. I just started to update to the v3 so I'm still new at this.

[stylesm]

As an update on this.

It's been 5 months and I must say that I prefer the App Insights view much more.

It is better at graphing / visualizations, and it automatically categories issues by problem area and parses the stack traces.

I don't think there's been an awful lot of support on GitHub or what I can see on StackOverflow which warrants retaining the dashboard logging, so I'm fine with closing the issue. Others may disagree.

I'm closing this one as, as it has been pointed out, the functionality was moved and deprecated and my original issue is resolved.

[rochapablo]

Is there any news on whether this is gonna be addressed or not in a future release?

We've have some Webjobs configured to be manually triggered in the Dashboard but the new jobs no longer show up in the Kudu Dashboard.

So... no update on this?

[LingaMuthu555]

I disagree just to rely on AppInsight as we have to use Webjob for our long running tasks instead on function, seems AppInsight not giving enough information to replay any functional call or to track success and failure..

Please do not compare with Azure function based implementation with Webjob implementation, it creates lot of confusion