诊断/日志存储表在哪里？
我在将 WebRole（WCF 服务）部署到 Azure 时遇到问题。我的 WebRole 持续显示忙碌状态至少 30 分钟，直到我中止它。我通过 Visual Studio 2010 进行部署。我正在寻找一些跟踪信息，并且有一些博客向我指出了名为 WADInfrastructureLogsTable 和 WADLogsTable 的存储表。
我已经使用我的存储帐户设置了如下配置设置：
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=sandsofttestservice;AccountKey=HgPjkzx+mjqgoDTO8SBNB3B4hdARuibWTOHrXg4BpxRKJfRZ/s4abVIoD5lOIW0LkoD0CoMb0i0GiTXA483MDQ==" />
</ConfigurationSettings>
我的存储帐户中根本没有表。即使在我成功部署Hello World应用程序之后也没有。我的 Blob 容器包含一个 vsdeploy 和一个 wad-control-容器，并且我有 4 个队列。
这些表将如何创建？
public override bool OnStart()
{
var dm = DiagnosticMonitor.GetDefaultInitialConfiguration();
dm.Logs.ScheduledTransferPeriod = TimeSpan.FromSeconds(5);
dm.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
DiagnosticMonitor.Start("DiagnosticsConnectionString", dm);
Trace.WriteLine("OnStart");
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
RoleEnvironment.Changing += RoleEnvironmentChanging;
return base.OnStart();
}
I have a problem deploying a WebRole (WCF service) to Azure. My WebRole keeps showing buzy for at least 30 minutes, until I abort it. I deploy through Visual Studio 2010. I’m looking for some trace information and there is a few blogs that have pointed me towards storage tables called WADInfrastructureLogsTable and WADLogsTable.
I have set up the configuration settings with my storage account like this:
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=sandsofttestservice;AccountKey=HgPjkzx+mjqgoDTO8SBNB3B4hdARuibWTOHrXg4BpxRKJfRZ/s4abVIoD5lOIW0LkoD0CoMb0i0GiTXA483MDQ==" />
</ConfigurationSettings>
I have no tables at all in my storage account. Not even after I have deployed Hello World apps successfully. My Blob container holds a vsdeploy- and a wad-control-container, and I have 4 queues.
How will these tables be created?
public override bool OnStart()
{
var dm = DiagnosticMonitor.GetDefaultInitialConfiguration();
dm.Logs.ScheduledTransferPeriod = TimeSpan.FromSeconds(5);
dm.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;
DiagnosticMonitor.Start("DiagnosticsConnectionString", dm);
Trace.WriteLine("OnStart");
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
RoleEnvironment.Changing += RoleEnvironmentChanging;
return base.OnStart();
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我有类似的问题。我将“转移”时间设置为 1 分钟，但它不会转移。然而，在我将其更新到 5 分钟后，我开始在 WADLogsTable 中看到跟踪消息。不知道为什么这会产生影响，也没有找到任何关于最短转会时间的文档，但 5 分钟对我来说很有效。
还要确保您的 web/worker 角色中有适当的 Trace.Writeline() 语句。
I had a similar problem. I had the 'transfer' period set to 1 minute and it would not transfer. However, after I updated it to 5 minutes, I started seeing trace messages in the WADLogsTable. Not sure why that made a difference and haven't found any documentation that talks about a minimum transfer period, but 5 minutes worked for me.
Also make sure you have appropriate Trace.Writeline() statements in your web/worker role.
您是否为日志表设置了传输计划？也就是说，所有日志记录都会缓存在每个实例中，并且您需要明确要求定期将该数据保留在表存储中。下面是 WADLogsTable 的一个简单示例：
设置完成后，您应该会看到 WADLogsTable 表在一段时间后出现。
您还需要为其他每种类型设置传输周期和过滤器：
Have you set up a transfer schedule for the Logs table? That is, all logging gets cached in each instance, and you need to explicitly ask for that data to be persisted in table storage on a periodic basis. Here's a trivial example for WADLogsTable:
Once this is set up, you should see the WADLogsTable table appear after a while.
You'll need to set up the transfer period and filter for each of the other types as well:
Soren - 如果您还没有这样做，您可能应该重新生成存储帐户访问密钥。它与您的配置详细信息一起列在您的原始帖子中。
帮助诊断问题的另一个选项是 Intellitrace。如果您使用的是 Visual Studio 2010 Utimate，则可以在部署中启用 Intellitrace。这将允许您下载 Intellitrace 日志文件，并从这些文件中您可以看到一些与应用程序的部署和启动相关的非常详细的信息。可能会生成一些异常或其他错误，从而导致长时间的“忙碌”状态。
Soren - If you haven't already, you should probably regenerate your storage account access key. It is listed in your original post with your configuration details.
Another option to help diagnose your problem is Intellitrace. If you are using Visual Studio 2010 Utimate, you can enable Intellitrace with your deployment. This will let you download the Intellitrace log files, and from those you can see some pretty detailed information pertaining to the deployment and startup of your application. There might be some exceptions or other errors being generated that could be causing the prolonged "Busy" state.