Azure webjob日志-查找详细介绍SDK的日志'；s对队列触发项目的处理

如我的堆栈溢出问题所示，我正在排除一个问题，尽管我将MaxDequeueCount属性设置为1，但有些项目在中毒之前会多次出列（事实上，有些项目可能根本不会中毒，只是出列、失败、重试和无休止地失败）

Webjobs SDK自动处理队列触发消息的重试和中毒，我正在查找包含该处理细节的日志

例如，我可以通过位于

https://myappengine.scm.azurewebsites.net/vfs/data/jobs/continuous/StuffProcessor/job_log.txt

（顺便问一下，如果我在web应用程序上启用了Azure存储的详细日志记录，我可以在Blob中获得相同的信息吗？）

在web应用程序上启用azure存储的详细日志记录后，我还可以通过查看

azure作业主机存档

容器中的日志来获取有关项目出列计数的一些信息：

{
      "Type": "FunctionCompleted",
      "EndTime": "2017-02-22T00:07:40.8133081+00:00",
      "Failure": {
        "ExceptionType": "Microsoft.Azure.WebJobs.Host.FunctionInvocationException",
        "ExceptionDetails": "Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: ItemProcessor.ProcessQueueMessage ---> MyApp.Exceptions.MySpecialAppExceptionType: Exception of type 'MyApp.Exceptions.MySpecialAppExceptionType' was thrown.
      },
      "ParameterLogs": {},
      "FunctionInstanceId": "1ffac7b0-1290-4343-8ee1-2af0d39ae2c9",
      "Function": {
        "Id": "MyApp.Processors.ItemProcessor.ProcessQueueMessage",
        "FullName": "MyApp.Processors.ItemProcessor.ProcessQueueMessage",
        "ShortName": "ItemProcessor.ProcessQueueMessage",
        "Parameters": [
          {
            "Type": "QueueTrigger",
            "AccountName": "MyStorageAccount",
            "QueueName": "stuff-processor",
            "Name": "sourceFeedItemQueueItem"
          },
          {
            "Type": "BindingData",
            "Name": "dequeueCount"
          },
          {
            "Type": "ParameterDescriptor",
            "Name": "logger"
          }
        ]
      },
      "Arguments": {
        "sourceFeedItemQueueItem": "{\"SourceFeedUpdateID\":437530,\"PodcastFeedID\":\"2d48D2sf2\"}",
        "dequeueCount": "96",
        "logger": null
      },
      "Reason": "AutomaticTrigger",
      "ReasonDetails": "New queue message detected on 'stuff-processor'.",
      "StartTime": "2017-02-22T00:07:40.6017341+00:00",
      "OutputBlob": {
        "ContainerName": "azure-webjobs-hosts",
        "BlobName": "output-logs/1ffd3c7b012c043438ed12af0d39ae2c9.txt"
      },
      "ParameterLogBlob": {
        "ContainerName": "azure-webjobs-hosts",
        "BlobName": "output-logs/1cf2c1b012sa0d3438ee12daf0d39ae2c9.params.txt"
      },
      "LogLevel": "Info",
      "HostInstanceId": "d1825bdb-d92a-4657-81a4-36253e01ea5e",
      "HostDisplayName": "ItemProcessor",
      "SharedQueueName": "azure-webjobs-host-490daea03c70316f8aa2509438afe8ef",
      "InstanceQueueName": "azure-webjobs-host-d18252sdbd92a4657d1a436253e01ea5e",
      "Heartbeat": {
        "SharedContainerName": "azure-webjobs-hosts",
        "SharedDirectoryName": "heartbeats/490baea03cfdfd0416f8aa25aqr438afe8ef",
        "InstanceBlobName": "zd1825bdbdsdgga465781a436q53e01ea5e",
        "ExpirationInSeconds": 45
      },
      "WebJobRunIdentifier": {
        "WebSiteName": "myappengine",
        "JobType": "Continuous",
        "JobName": "ItemProcessor",
        "RunId": ""
      }
    }

但我找不到的是显示特定队列项目的详细信息的日志，其中由于异常而导致处理失败，并将其放在有毒队列中。我寻找这些是为了进一步解决明显忽略MaxDequeueCount属性的问题。这有记录吗

更新：我找到了这篇文章，其中包含以下截图：

---

该屏幕截图显示了标准的“检测到新队列消息…”消息（我在Azure上看到并在模拟器中本地运行），还显示了“消息已达到X的MaxDequeueCount…将消息移动到队列‘xyz poison’”，我仅在模拟器中本地看到。基于Azure的运行时是否出于某种原因未显示此信息？在控制台窗口中本地运行或通过webjobs仪表板运行或在Azure上运行时，我从未看到与中毒相关的消息。

在上一篇文章中，您具有如下触发功能

public void ProcessQueueMessage([QueueTrigger("azurewejobtestingqueue")] string item, TextWriter logger)
{
   if ( item == "exception" )
   {
      throw new Exception();
   }
}

您写入记录器的任何内容都应显示在WebJobs仪表板上的日志中。我的建议是：

将“if（item==“exception”）”更改为“if（item.ToLower（）.StartsWith（“exception”）”。然后在测试时向异常消息追加一个数字。将队列消息的文本记录到TextWriter，以便您可以确保查看的是您认为正在检查的相同消息

您可以将消息的出列计数作为函数的参数。请参阅。查看示例中的FailAlways方法。将此记录到TextWriter

尝试在本地运行此操作。所有输出都将写入控制台窗口。查看是否得到相同的行为

---

我真的很想找到导致这种行为的原因，因此，如果您破解了它，请务必告诉我们！

您使用的是Azure Storage version 8.*？它包含一个突破性的更改

当队列消息对象插入Azure Storage 8中的消息队列时，原始队列消息对象的消息Id将被新插入消息的唯一消息Id覆盖

这意味着它失去了对毒药消息的引用，无法再删除它

对于日志记录，有两个选项：

创建您自己的QueueProcessorFactory和QueueProcessor-您可以覆盖处理有害消息的方法以生成更多调试输出。如果您希望继续使用Azure Storage 8。*，您还可以在那里完全解决此问题

注册跟踪监视器

---

仍在尝试让它在本地运行-我认为你的建议很好。我没有问题将所有内容发送到日志记录器-我目前正在这样做。我正在寻找的是查看SDK正在做什么-对我希望看到SDK尝试毒害（或不毒害）消息的行为进行故障排除。我的

if（item==“exception”）

只是伪代码，而不是文字代码。它只是用来引用队列中可能导致异常的项目。我当前将该项目的出列计数作为参数（我添加了它）我可以在我的日志中看到一些项目的出列次数越来越高。只需添加第二条注释-我很容易捕获异常-问题是我无法了解sdk为什么在MaxDequeueCount次数之后没有中毒消息。测试时，您是否有一个实例在Azure和hi中运行正在设置也在Azure中的存储队列？是。webjob/网站的单个实例，并且BatchSize为1。使用Azure存储队列。（队列必须在Azure中才能使用sdk队列触发功能。）答对了！你答对了-这正是我的问题。同时我要回到7.x。不是吹毛求疵，但我不认为这是一个突破性的改变；我认为这是一个bug。突破性的改变是当行为改变时，它与以前的代码不向后兼容。也许这也是真的，但这显然看起来像是一个“bug”类别我…？关于日志记录，您能否澄清我是否确实应该在“标准”中看到webjob队列触发的项目中毒消息是否在Azure中运行webjob仪表板输出？正如我所说，我只在本地看到它们。我不认为这是一个bug。这一更改对存储团队来说是有意义的。它类似于ORM实体在使用DB生成的Id字段将Id字段存储到DB后如何填充它的Id字段。不太确定您对日志记录的意思，但在kudu中仪表板输出（yoursite.scm.azurewebsites.net/azurejobs/#/jobs/continuous/YourWebJob）我确实看到了将某些内容移动到毒药队列中的条目：

[03/08/2017 00:39:46>730f59:INFO]消息已达到MaxDequeueCount 2。正在将消息移动到队列“队列中毒”。

现在我知道为什么我看不到该消息；这是因为我的中毒被破坏，因为我在8.x上…关于“破坏性更改”

public void ProcessQueueMessage([QueueTrigger("azurewejobtestingqueue")] string item, TextWriter logger)
{
   if ( item == "exception" )
   {
      throw new Exception();
   }
}

var traceMonitor = new TraceMonitor()
.Filter(p => true, "Trace Handler")
.Subscribe(TraceHandler.Process);

config.Tracing.Tracers.Add(traceMonitor);