通过Azure命令行(加Glimpse)获取流诊断跟踪日志


[原文发表地址]  Streaming Diagnostics Trace Logging from the Azure Command Line (plus Glimpse!)

[原文发表时间]  2013-04-05

image

正如我一直所说的“当你心存怀疑时,就打开追踪”。有时候“got here”-debugging是很好的工具。我往往
我的代码中使用很多System.Diagnostics.Trace。然后使用ELMAH或者Glimpse来了解更多。

最近尽管,我已经在一些Azure的网站上追踪想要的数据,时而也通过Azure 命令行获取。

我将这样来部署(或者通过Visual Studio来部署): 

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

接着如果我想重启,启动,停止跟踪网站等等,我当然都可以。
azure site restart mysite

除此之外,我曾经和一位 dev谈论过并且说我真的初衷

azure site log tail mysite

他们做到了!看看这个。你现在就可以试一下。

添加跟踪到你的应用程序

首先,做一个带些跟踪的应用程序。以下是我的。任何ASP.NET的应用程序都可以,MVC、 Web Forms或者

Web Pages,都没关系。但注意追踪方式。

   1: public class HomeController : Controller
   2: {
   3:     public ActionResult Index()
   4:     {
   5:         ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
   6:         System.Diagnostics.Trace.TraceError("ZOMG THIS IS BAD");
   7:         return View();
   8:     }
   9:  
  10:     public ActionResult About()
  11:     {
  12:         ViewBag.Message = "Your app description page.";
  13:         System.Diagnostics.Trace.TraceInformation("Just chillin.");
  14:         return View();
  15:     }
  16: }

然后,把它上传到Azure。在这种情况下我直接通过VS发布,只要右键选择Publish并且导入你从入口下载

的Publish Profile。你就可以随意发布了。

Download Publish Profile

Trace.axd进行本地追踪

你可能知道通过在你的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>

因此如果我访问本地的trace.axd,我就可以看到我的追踪:

Tracing shown via trace.axd

如果你真得想要启用远程跟踪你也可以这么做: 

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

Azure命令行获取流日志

当我的应用程序在Azure上,我也一样可以获得追踪信息。从管理入口我能看见日志文件的位置,对吧?

The locations of my logging files

正如以往一样,同时我可以在用FTP 登录进去查看它们。注意我正在使用Explorer来登录FTP 。我只要把相应

的URL黏贴到Explorer中,然后输入我的部署凭据。

You can FTP in and get the logs with Explorer. Does anyone do that anymore?

我也可以用我最喜欢的FTP应用程序来做这个,或者用浏览程序。且仅需要知道追踪文件存放的地方就行。

通过命令行我这么做,日志就传给我了。

C:\>azure site log tail mysite

info: Executing command site log tail

2013-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

顺便提一下,这种方式对.NET apps和nodejs apps也工作。所有的日志都实时的写入LogFiles文件夹中。

应用程序的追踪日志默认被收集在LogFiles/Application文件夹下。你也可以得到IIS日志在

LogFiles/Http文件夹。任何被创建在自定义文件夹中的文件例如LogFiles/<Custom>也将定稿对应的内容。

我也可以用过滤器过滤特殊字符,这样:

C:\>azure site log tail loggingtest –filter ZOMG

info: Executing command site log tail

2013-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

我也可以开启Web Server日志:

Turning on Web Server Logging

如果你使用的是节点.js,你需要在iisnode.yml中开启日志。确保日志在iisnode.yml中已经开启:

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

流的原始IIS 日志!

C:\>azure site log tail loggingtest -p http
info:    Executing command site log tail
2013-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-d872e
31a2f2e 80 - 166.147.88.43 Mozilla/5.0+(Windows+NT+6.2;+WOW64)+AppleWebKit/537.3
1+(KHTML,+like+Gecko)+Chrome/26.0.1410.43+Safari/537.31 ARRAffinity=edd1561bc28b
b0ea9133780b878994b30ed4697656295364ebc8aadc14f54d2;+WAWebSiteSID=57051e6cd07a4

我也可以通过命令行直接下载日志到硬盘中。

C:\>azure site log download loggingtest
info:    Executing command site log download
+ Downloading diagnostic log
info:    Writing to diagnostics.zip
info:    site log download command OK

今天在Azure中这个特性的UI在几天内也会出现在管理入口。它看起来像这样。这个UI的最好部分是它允许你开

启和关闭它再加上修改日志等级而无需回收应用程序域

修改web.config会引起应用程序重启。由于你经常想要修改你的日志等级而无需重启,这些Azure-sprcific追踪

设置存放在你的实例中的/site/diagnostics/settings.json. 当你想看的时候你可以通过FTP in查阅。

除这些被 重写的设置外,Azure将使用你的已存在的web.config追踪设置。

The new Application Diagnostics logging switch

记住,你可以使用Windows Azure PowerShell(Windows)或者Windows Azure Cross Platform 

Command Line Interface(Windows, MacLinux)来查看这些流的日志。

要注意的问题

日志开启后将会只启动12个小时。你通常不会永远得想要日志。方便得是,如果你连上了一个带流的客

户端,然后日志会自动开启。

默认情况下日志文件被拆分成128k同时保持你的应用程序日志在1MB内并且所有的日志文件夹总容量在

30MB下。如果你需要更多,你可以直接在入口那重写一些高等的设置。

在这里我设置日志文件拆分成10k和应用程序最大日志为5MB。

Overriding configuration settings in the Azure Portal

这儿是一些你可以重写的高等的设置 :

  • 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.     

  • DIAGNOSTICS_LOGGINGSETTINGSFILE – "..\diagnostics\settings.json"
    • The settings file, relative to the web app root.
  • DIAGNOSTICS_TEXTTRACELOGDIRECTORY – "..\..\LogFiles\Application"
    • The log folder, relative to the web app root.
  • DIAGNOSTICS_TEXTTRACEMAXLOGFILESIZEBYTES – 128 * 1024 (bytes)
    • Default: 128 kb log file
  • DIAGNOSTICS_TEXTTRACEMAXLOGFOLDERSIZEBYTES – 1024 * 1024 (bytes)
    • Default: 1 MB Application Folder (30 MB entire Logs Folder)

在将来,我期望我们会有简单的方法在Azure表存储上来放置日志和命令行一样查询通过时间,pid,等等。

这会是非常高兴的可以从Visual Studio内部来获取这些日志。

更多的数据路由跟踪用Glimpse

如果你还没有使用过Glimpse,你可赚大了。我将针对Glimpse下周发表博文。Glimpse是一款用于调试你的

网络应用程序的客户端框架。

我使用NuGet来引入“Glimpse.Mvc4”(确定一个合适你的 ,像Glimpse.Mvc3,或者Glimpse.EF5,等等。

参阅http://getglimpse.com查看更多的信息) 。

Glimpse不做任何事情直到你开启它。本地的我点击http://localhost:xxxx/Glimpse.axd来开启它。现在,

我访问Trace标签并且之前的Trace就在那。

There's my tracing in the Glimpse Trace tab

但是如果我到TimeLine标签,我有办法获取更多信息,包括所有我感兴趣的ASP.NET事件。这些关于之前

和之后“bracketing”事件经过System.Diagnostics.Trace显示是非常有用的。

Holy crap that Glimpse Timeline is full of good debugging info

我该怎么通过追踪查看时间轴信息呢?简单。我将查看Glimpse Timeline和route!

   1: using Glimpse.Core.Extensibility;
   2: using Glimpse.Core.Message;
   3:  
   4: public class TimelineTracer : IInspector
   5: {
   6:     public void Setup(IInspectorContext context) {
   7:         context.MessageBroker.Subscribe<ITimelineMessage>(TraceMessage);
   8:     }
   9:  
  10:     private void TraceMessage(ITimelineMessage message) {
  11:         var output = string.Format(
  12:             "{0} - {1} ms from beginning of request. Took {2} ms to execute.",
  13:             message.EventName,
  14:             message.Offset.Milliseconds,
  15:             message.Duration.Milliseconds);
  16:  
  17:         System.Diagnostics.Trace.TraceInformation(output, message.EventCategory.Name);
  18:     }
  19: }

现在我在我的追踪日志中也获得了很多很好的Glimpse-supplied计时信息,它们当然也可以通过命令行输

出来。

C:\>azure site log tail loggingtest
info:    Executing command site log tail
2013-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 BAD
2013-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.

我非常激动它是如此得简单让分系统像ASP.NET,Glimpse和现在的Web Site在Azure上很好得一起工作和

共享信息。

我不确定我最终会以何种方式结束使用,但是我确信计划检测我的代码和更多得调用

System.Diagnostics.Trace因为我可以如此简单得路由结果。

最后,值得提一下以防你不知道,就是所有的Azure SDK是开源的而且在后端调用网络服务时你可以调用自己的。如果你想挖掘更多的日志流特性,你是否知道你可以通过监视去检查三个月来的 Pull Request来获知日志流情况?狂热。它是在微软的善良的,温柔的死星。


Comments (0)

Skip to main content