我们在App Service Environment下运行的9个实例上部署了一个Continuous WebJob。如果我们浏览到" D:\ home \ data \ jobs \ continuous {webjobname} "在Kudu网站上,我们可以看到名为" status_ {hash} "的9个文件。此名称中的哈希值表示我们可以在资源浏览器中为该WebApp看到的实例名称的前6个字符。
有趣的是,其中一些文件包含:
{"Status":"Running"}
而其他人包含
{"Status":"Stopped"}
我可能认为这意味着WebJob在某些实例上运行(例如在5个实例上)并在其他实例中停止(例如在4上)。但这是预期的吗? (我们的WebApp AlwaysOn ,WebJob NOT 设置为单身)
但是,在查看" job_log.txt "时,我们可以看到与该实例相关的当前活动。 " status_ {hash} "文件ModifiedOn早于" job_log.txt"上的活动日志。文件。
[11/30/2016 03:39:20 > {hash}: INFO] Executed: 'Functions.{name}' (Succeeded)
有谁知道这些文件的目的以及我们应该如何解释它们?
[UPDATE]
来自" job_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}'.'
WebApp位于AEDT TimeZone,所以,
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
此处有相应 status_ {hash} 文件的详细信息
File Modified
status_d6e0f6 11/30/2016, 6:29:00 AM
内容:
{"Status":"Stopped"}
因此,当WebJob停止时,我们可以看到 status_ {hash} 文件是如何更新的,但是当WebJob重新启动时它没有更新。
答案 0 :(得分:0)
以防其他人有同样的问题或遇到类似的问题:
D:\ home \ data \ jobs \ continuous {webjobname}中的“status_ {hash}”文件旨在包含该特定实例上连续WebJob的状态。显然,在某些情况下,您不应期望此状态始终准确。
如果要检查在多个实例上运行的连续WebJob的状态,最好的方法是使用Azure Portal Process Explorer并检查该实例下的WebJob进程是否正在运行。
如果你不够运气(就像我一样)并且您的Portal Process Explorer没有响应,您可以使用Kudu Process Explorer并通过连接到该特定实例来检查该特定实例。
This post总结了如何获取实例ID以及如何连接到相应的Kudu站点实例。但是,有更简单的方法可以做到这一点。
要获取实例ID,您可以从资源浏览器中获取它们,例如
https://resources.azure.com/subscriptions/ {subscription_id} / resourceGroups / {rg_name} /providers/Microsoft.Web/sites/ {app_service_name} /实例
然后,在浏览Kudu并进入其Process Explorer之前,您需要在浏览器上编辑相应的ARRAffinity cookie。您可以通过检查Kudu站点中显示的环境变量“WEBSITE_INSTANCE_ID”来验证您是否正在连接到正确的实例。
HTH