我们在应用服务环境下运行的9个示例上部署了一个连续的webjob。如果我们在kudu站点上浏览到“d:\home\data\jobs\continuous{webjobname}”,我们可以看到9个名为“status{hash}”的文件。此名称中的哈希值表示我们可以在该webapp的资源管理器中看到的示例名称的前6个字符。
有趣的是,其中一些文件包含:
{"Status":"Running"}
而其他人
{"Status":"Stopped"}
我可能认为这意味着webjob在某些示例上运行(例如在5个示例上),而在其他示例上停止(例如在4个示例上)。但这是意料之中的吗(我们的webapp是alwayson,webjob没有设置为singleton)
但是,在查看“job_log.txt”时,我们可以看到与该示例相关的当前活动。并且“status{hash}”文件modifiedon早于“job{log.txt”文件中的活动日志。
[11/30/2016 03:39:20 > {hash}: INFO] Executed: 'Functions.{name}' (Succeeded)
有没有人知道这些文件的用途以及我们应该如何解释它们?
[更新]
“job\u log.txt”摘录:
[11/29/2016 19:28:59 > d6e0f6: SYS INFO] Status changed to Stopped
[11/29/2016 19:29:28 > d6e0f6: INFO] Found the following functions:
[11/29/2016 19:29:28 > d6e0f6: INFO] Func1
[11/29/2016 19:29:28 > d6e0f6: INFO] Func2
[11/29/2016 19:29:28 > d6e0f6: INFO] Func3
[11/29/2016 19:29:51 > d6e0f6: INFO] Job host started
[11/29/2016 23:11:47 > d6e0f6: INFO] Executing: 'Functions.{name}' - Reason: 'New ServiceBus message detected on 'Tiers/Subscriptions/{name}'.'
网络应用程序在aedt时区,所以,
11/29/2016 19:28:59 UTC = 11/30/2016 06:28:59 AEDT
11/29/2016 23:11:47 UTC = 11/30/2016 10:11:47 AEDT
下面是相应状态{hash}文件的详细信息
File Modified
status_d6e0f6 11/30/2016, 6:29:00 AM
内容:
{"Status":"Stopped"}
因此,我们可以看到当webjob停止时,状态{hash}文件是如何更新的,但是当webjob重新启动时,状态{hash}文件没有更新。
1条答案
按热度按时间mklgxw1f1#
以防其他人有同样的问题或面临类似的问题:
d:\home\data\jobs\continuous{webjobname}中的“status{hash}”文件意味着包含该特定示例上的连续webjob的状态。然而,显然,在某些情况下,您不应该期望此状态总是准确的。
如果要检查在多个示例上运行的连续webjob的状态,最好的方法是使用azureportalprocessexplorer并检查该示例下的webjob进程是否正在运行。
如果您(作为我)运气不好,并且门户process explorer没有响应,您可以使用kudu process explorer并通过连接到特定示例来检查该示例。
这篇文章总结了如何获取示例id以及如何连接到相应的kudu站点示例。然而,有一些新的更简单的方法可以做到这一点。
要获取示例ID,可以从资源管理器获取,例如。
https://resources.azure.com/subscriptions/{subscription\u id}/resourcegroups/{rg\u name}/providers/microsoft.web/sites/{app\u service\u name}/instances
然后,在浏览kudu并进入其processexplorer之前,需要在浏览器上编辑相应的arraffinity cookie。通过检查kudu站点中显示的环境变量“website\u instance\u id”,可以验证是否连接到了正确的示例。
hth公司