I’ve long said when in doubt, turn on tracing. Sometimes "got here"-debugging is a great tool. I tend to use System.Diagnostics.Trace a lot in my code. Then I'll use ELMAH or Glimpse to get more insight.

我已经很久没说了，如果有疑问，请打开跟踪。 有时，“进入此处”-调试是一个很好的工具。 我倾向于在代码中大量使用System.Diagnostics.Trace。 然后，我将使用ELMAH或Glimpse获得更多的见解。

Lately though, I've been doing a lot of Azure sites and have been wanting to get at trace data, sometimes at the Azure command line.

不过，最近我一直在做很多Azure站点，并且一直想获取跟踪数据，有时是在Azure命令行。

I'll do this to deploy (or deploy from Visual Studio):

我将这样做以进行部署(或从Visual Studio进行部署)：

azure site create mysite --gitgit add .git commit -m "initial deploy"git push azure master

Then later if I want to restart, start, stop, etc I can certainly

然后，如果我想重新启动，启动，停止等，我当然可以

azure site restart mysite

But I was talking to one of the devs a while back and said I really wanted

但是我前一段时间正在和一位开发人员交谈，说我真的很想要

azure site log tail mysite

And they made it! Check this out. You can try it right now.

他们做到了！ 看一下这个。 您可以立即尝试。

将跟踪添加到您的应用 (Add Tracing to your App)

First, make an app that has some tracing. Here's mine. Any ASP.NET app is fine, MVC or Web Forms or Web Pages, doesn't matter. Note the Traces.

首先，制作一个具有跟踪功能的应用程序。 这是我的。 任何ASP.NET应用都可以，MVC或Web窗体或网页都没关系​​。 注意痕迹。

public class HomeController : Controller{    public ActionResult Index()    {        ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";        System.Diagnostics.Trace.TraceError("ZOMG THIS IS BAD");        return View();    }

    public ActionResult About()    {        ViewBag.Message = "Your app description page.";        System.Diagnostics.Trace.TraceInformation("Just chillin.");        return View();    }}

Then, upload it to Azure. I did a Publish directly from VS in this case, just right click, Publish and Import the Publish Profile that you download from the portal. You can publish however you like.

然后，将其上传到Azure。 在这种情况下，我直接从VS进行了发布，只需右键单击，发布并导入您从门户网站下载的发布配置文件。 您可以随意发布。

使用Trace.axd进行本地跟踪 (Local Tracing with Trace.axd)

You likely know that you can enable tracing locally with trace.axd in your ASP.NET app (and MVC apps) by adding trace listeners to your web.config:

您可能知道，可以通过在Web.config中添加跟踪侦听器来在ASP.NET应用程序(和MVC应用程序)中使用trace.axd在本地启用跟踪：

<system.diagnostics>  <trace>    <listeners>      <add name="WebPageTraceListener"           type="System.Web.WebPageTraceListener, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>    </listeners>  </trace></system.diagnostics>

So if I visit trace.axd locally, I see my traces:

因此，如果我在本地访问trace.axd，则会看到我的踪迹：

If you really wanted this remotely you could say so also:

如果您真的想远程这样做，也可以这样说：

<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true" pageOutput="false" />

从Azure命令行流式传输日志 (Streaming Logs from the Azure Command Line)

When my app is in Azure, I can get to the tracing info as well. From the management portal, I can see where the log files are, right?

当我的应用程序在Azure中时，我也可以获取跟踪信息。 从管理门户，我可以看到日志文件在哪里，对吗？

And I can FTP in and see them, as I always could. Notice I am using Explorer to FTP in. I can just copy paste the URL into Explorer itself, then enter my deployment credentials.

我可以像以往一样通过FTP进入并查看它们。 注意，我使用的是Explorer到FTP。我可以将URL复制粘贴到Explorer本身，然后输入我的部署凭据。

I can also do this with my favorite FTP app, or the browser. Inside the Application Folder is where the tracing files are.

我也可以使用我最喜欢的FTP应用程序或浏览器来执行此操作。 在应用程序文件夹中是跟踪文件所在的位置。

From the command line, I can do this, and the logs are streamed to me.

在命令行中，我可以执行此操作，然后将日志流式传输给我。

C:\>azure site log tail mysiteinfo:    Executing command site log tail2013-04-05T19:45:10  Welcome, you are now connected to log-streaming service.2013-04-05T19:45:13  PID[2084] Error       ZOMG THIS IS BAD

This works with both .NET apps and nodejs apps, by the way. All logs written to the  LogFiles folder can be streamed in real time. The Application trace logs collected under the LogFiles/Application folder are streamed out by default. you can also get at IIS logs written to the LogFiles/Http folder. Any files created in a custom folder e.g. LogFiles/<Custom> will have their contents streamed as well.

顺便说一下，这适用于.NET应用程序和nodejs应用程序。 写入LogFiles文件夹的所有日志都可以实时流式传输。 默认情况下，在LogFiles / Application文件夹下收集的Application跟踪日志是流出的。 您还可以获取写入LogFiles / Http文件夹的IIS日志。 在自定义文件夹中创建的任何文件(例如LogFiles / <Custom>)也将流传输其内容。

I can also filter for specific characters with --filter, so:

我还可以使用--filter过滤特定字符，因此：

C:\>azure site log tail loggingtest --filter ZOMGinfo:    Executing command site log tail2013-04-05T19:45:10  Welcome, you are now connected to log-streaming service.2013-04-05T19:45:13  PID[2084] Error       ZOMG THIS IS BAD

I can also turn on Web Server Logging:

我还可以打开Web服务器日志记录：

# For security reasons, logging, dev errors, and debugging
# should be disabled in production deployments:
loggingEnabled: false
debuggingEnabled: false
devErrorsEnabled: false
node_env: production

# For security reasons, logging, dev errors, and debugging
# should be disabled in production deployments:
loggingEnabled: false
debuggingEnabled: false
devErrorsEnabled: false
node_env: production

And stream the raw IIS logs as well!

并流原始IIS日志！

C:\>azure site log tail loggingtest -p httpinfo:    Executing command site log tail2013-04-05T20:03:59  Welcome, you are now connected to log-streaming service.2013-04-05 20:04:15 LOGGINGTEST GET / X-ARR-LOG-ID=5a267b3f-6c0e-4a1d-9cb6-d872e31a2f2e 80 - 166.147.88.43 Mozilla/5.0+(Windows+NT+6.2;+WOW64)+AppleWebKit/537.31+(KHTML,+like+Gecko)+Chrome/26.0.1410.43+Safari/537.31 ARRAffinity=edd1561bc28bb0ea9133780b878994b30ed4697656295364ebc8aadc14f54d2;+WAWebSiteSID=57051e6cd07a4

I can also just download the logs directly to disk from the command line.

我也可以直接从命令行将日志直接下载到磁盘。

C:\>azure site log download loggingtestinfo:    Executing command site log download+ Downloading diagnostic loginfo:    Writing to diagnostics.zipinfo:    site log download command OK

This feature is in Azure today, and in a few days the UI will appear in the management portal as well. It will look like this. The best part of this UI is that it will allow you to turn it on and off plus change the logging level without recycling the app domain.

今天，此功能已在Azure中使用，几天后，UI也将出现在管理门户中。 它看起来像这样。 此UI的最好部分是，您可以打开和关闭它，还可以更改日志记录级别，而无需回收应用程序域。

Changing the web.config causes an app restart. Since you often want to change your log levels without a restart, these Azure-specific trace settings are stored in /site/diagnostics/settings.json within your instance. You can FTP in and see if you like.

更改web.config会导致应用重启。 由于您通常希望在不重新启动的情况下更改日志级别，因此这些特定于Azure的跟踪设置存储在实例中的/site/diagnostics/settings.json中。 您可以输入FTP并查看是否喜欢。

Azure will use your existing trace settings from web.config unless these overriding settings exist.

除非这些覆盖设置存在，否则Azure将使用web.config中的现有跟踪设置。

Remember, you can view these streamed logs on the client using Windows Azure PowerShell (Windows) or Windows Azure Cross Platform Command Line Interface (Windows, Mac and Linux).

请记住，您可以使用Windows Azure PowerShell( Windows )或Windows Azure跨平台命令行界面( Windows ， Mac和Linux )在客户端上查看这些流式日志。

要注意的事情 (Things to be aware of)

Turning logging on will turn it on only for 12 hours. You don't usually want logs on forever. Conveniently, if you connect a streaming client, then logging gets auto enabled.

打开日志记录只会将其打开12个小时。 您通常不希望永久登录。 方便地，如果您连接流客户端，则日志记录将自动启用。

The defaults are to split log files at 128k and keep your app logs under 1MB and the whole logs folder under 30MB. If you need more, you can override some advanced settings directly in the portal.

默认设置是将日志文件拆分为128k，并将应用日志保留在1MB以下，整个日志文件夹保留在30MB以下。 如果需要更多功能，可以直接在门户中覆盖一些高级设置。

Here I'm setting the log file splits to 10k and the max Application log to 5MB.

在这里，我将日志文件拆分为10k，最大应用程序日志为5MB。

Here's some advanced settings you can override:

您可以覆盖以下一些高级设置：

• DIAGNOSTICS_LASTRESORTFILE - "logging-errors.txt"

  DIAGNOSTICS_LASTRESORTFILE-“ logging-errors.txt”

  • The name (or relative path to the LogDirectory) of the file where internal errors are logged, for troubleshooting the listener.记录内部错误的文件的名称(或LogDirectory的相对路径)，用于对侦听器进行故障排除。

• DIAGNOSTICS_LOGGINGSETTINGSFILE - "..\diagnostics\settings.json"

  DIAGNOSTICS_LOGGINGSETTINGSFILE-“ .. \ diagnostics \ settings.json”

  • The settings file, relative to the web app root.相对于Web应用程序根目录的设置文件。

• DIAGNOSTICS_TEXTTRACELOGDIRECTORY - "..\..\LogFiles\Application"

  DIAGNOSTICS_TEXTTRACELOGDIRECTORY-“ .. \ .. \ LogFiles \ Application”

  • The log folder, relative to the web app root.相对于Web应用程序根目录的日志文件夹。

• DIAGNOSTICS_TEXTTRACEMAXLOGFILESIZEBYTES - 128 * 1024 (bytes)

  DIAGNOSTICS_TEXTTRACEMAXLOGFILESIZEBYTES-128 * 1024(字节)

  • Default: 128 kb log file 默认值：128 kb日志文件

• DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES - 1024 * 1024 (bytes)

  DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES-1024 * 1024(字节)

  • Default: 1 MB Application Folder (30 MB entire Logs Folder)默认值：1 MB应用程序文件夹(整个30 MB日志文件夹)

In the future, I expect we'll see easy ways to put logs in Azure table storage as well as command line querying by time, pid, etc. It would also be nice to be able to get to these logs from inside of Visual Studio.

将来，我希望我们会看到将日志放入Azure表存储的简单方法，以及按时间，pid等进行命令行查询。能够从Visual Studio内部获取这些日志也很好。

路由更多数据以快速浏览 (Routing More Data to Tracing with Glimpse)

If you haven't used Glimpse, you're in for a treat. I'll post again about Glimpse next week. Glimpse is a client side debugging framework for your web app.

如果您还没有使用过Glimpse ，那就一定要请客。 下周我将再次发布有关Glimpse的信息。 Glimpse是您的Web应用程序的客户端调试框架。

I used NuGet to bring in "Glimpse.Mvc4" (Be sure to get the right one for you, like Glimpse.Mvc3, or Glimpse.EF5, etc. Check out http://getglimpse.com for more details).

我用NuGet引入了“ Glimpse.Mvc4”(请确保为您找到合适的，例如Glimpse.Mvc3或Glimpse.EF5，等等。有关更多详细信息，请访问http://getglimpse.com )。

Glimpse doesn't do anything until you turn it on. Locally I hit http://localhost:xxxx/Glimpse.axd and turn it on. Now, I visit the Trace tab and the Trace from earlier is there.

除非您将其打开，否则Glimpse不会执行任何操作。 在本地，我点击了http：// localhost：xxxx / Glimpse.axd并将其打开。 现在，我访问“跟踪”选项卡，那里有以前的跟踪。

But if I go to the Timeline Tab, I get way more information, including all the ASP.NET events that are interesting to me. These "bracketing" events about befores and afters could be super useful if they were routed to System.Diagnostics.Trace.

但是，如果我去到时间轴选项卡，我收获更多信息，包括所有那些让我感兴趣的ASP.NET的事件。 如果将这些前后的“包围”事件路由到System.Diagnostics.Trace，它们可能会非常有用。

How do I get this timeline view information routed to Tracing? Easy. I'll watch the Glimpse Timeline and route!

如何获得此时间轴视图信息以路由到“跟踪”？ 简单。 我将看一看时间表和路线！

using Glimpse.Core.Extensibility;using Glimpse.Core.Message;

public class TimelineTracer : IInspector{    public void Setup(IInspectorContext context) {        context.MessageBroker.Subscribe<ITimelineMessage>(TraceMessage);    }

    private void TraceMessage(ITimelineMessage message) {        var output = string.Format(            "{0} - {1} ms from beginning of request. Took {2} ms to execute.",            message.EventName,            message.Offset.Milliseconds,            message.Duration.Milliseconds);

        System.Diagnostics.Trace.TraceInformation(output, message.EventCategory.Name);    }}

Now I get lots of great Glimpse-supplied timing info in my Trace log as well that I can stream from the command line.

现在，我在跟踪日志中也获得了许多出色的Glimpse提供的时序信息，并且可以从命令行中进行流式传输。

C:\>azure site log tail loggingtestinfo:    Executing command site log tail2013-04-05T20:22:51  Welcome, you are now connected to log-streaming service.2013-04-05T20:23:32  PID[1992] Information Start Request - 0 ms from beginning of request. Took 0 ms to execute.2013-04-05T20:23:32  PID[1992] Information Authorization - Home:Index - 224 ms from beginning of request. Took 0 ms to execute.2013-04-05T20:23:32  PID[1992] Information Action:Executing - Home:Index - 239 ms from beginning of request. Took 0 ms to execute.2013-04-05T20:23:32  PID[1992] Error       ZOMG THIS IS BAD2013-04-05T20:23:32  PID[1992] Information InvokeActionMethod - Home:Index - 289 ms from beginning of request. Took 29 ms to execute.2013-04-05T20:23:32  PID[1992] Information Action:Executed - Home:Index - 320 ms from beginning of request. Took 0 ms to execute.

I'm pretty stoked that it's was so easy to get subsystems like ASP.NET, Glimpse and now Web Sites on Azure to work together and share information.

我很高兴地发现，使ASP.NET，Glimpse等子系统以及Azure上的现在的Web站点能够协同工作并共享信息非常容易。

I'm not sure which way I'll finally end up using them, but I'm definitely planning on instrumenting my code and calling System.Diagnostics.Trace more often since I can so easily route the results.

我不确定最终将以哪种方式使用它们，但是我肯定会计划对我的代码进行检测并更频繁地调用System.Diagnostics.Trace，因为我可以轻松地路由结果。

Finally, it's worth mentioning in case you didn't know, that all the Azure SDK is open source and is calling web services on the backend that you can call yourself. If you dig this log streaming feature, did you know you could have watched it get checked in from a Pull Request 3 months ago? Madness. It's a kinder, gentler Death Star over here at Microsoft.

最后，值得一提的是，如果您不知道，则所有的Azure SDK都是开源的，并且正在您可以调用的后端调用Web服务。 如果您使用此日志流功能，您是否知道您可以看到3个月前的“拉取请求”中将其签入了吗？ 疯狂。 在微软这里，它是一个更友好，更温柔的死亡之星。

翻译自: https://www.hanselman.com/blog/streaming-diagnostics-trace-logging-from-the-azure-command-line-plus-glimpse