Azure Service、Azure Web、Azure Storm日志机制
兵马未动，粮草先行。程序未果，日志先成。
在学习Azure平台，并用之进行项目托管的过程中，深深感叹程序日志记录的重要性。通过日志，可以知道程序运行情况，发现隐含bug；通过日志，可以挖掘产品的访问情况，进一步提升产品质量。云平台不能很好断点调试，所幸Azure提供了一套完整的日志解决方案。
Service日志机制和Azure Web日志机制是记录程序里System.Diagnostics.Trace的信息。(C#代码)
如：System.Diagnostics.Trace.TraceInformation("If you see this, something good will happen!");
Storm的日志机制是记录Context.Logger的信息。（C#代码）
如：Context.Logger.Info("If you see this, something good will happen!");
Azure Service日志机制
我的理解中，Azure Service/Cloud Serivce对应于线下的一个应用程序。每个Service可以是包含若干个Worker Role，或者包含若干个Web Role，Web Role的功能就有点类似于Azure Web了。但不管是Web Role还是Worker Role，他们的日志机制是相同的。
在记录Azure Service日志之前，需要在你的Azure账号下创建一个存储Storage，Azure Service的日志就是存在Storage下的Table中。同时我也假定你已经在Visual Studio中创建了Cloud Service程序了。要想启动Azure Service的日志功能，主要是在发布的时候设置。
双击Service下面对应的WorkerRole/WebRole，下图中，LogCleanUpService下包含一个Role，LogCleanUpWorkerRole
在弹出的配置窗口中，勾选Enable Diagnostics前的复选框，并在方框中输入你的Storage的链接字符串。顺便说一下，这个窗口也能设置Service核大小、程序配置参数。同时，你也可以管理创建多个发布配置文件（下图椭圆框处）
点击上图的Configure按钮，选择日志记录等级。Errors Only表示只记录错误信息，All information表示记录所有的程序信息。还有一些日志大小配额信息，可以只取默认值。
另外还有一些其他设置，如日志写入频率等。一般默认即可，也可以手动设置。设置完毕之后，点击ok按钮。
右键项目，点击发布。
如图中，选择存储账号，然后再进行发布即可。
Cloud Service的日志就是记录在了设置的Storage账户下的WADLogsTable中。多个Role可以记录在同一个存储账户中，可以通过表的Role属性来进行区分。
注意Cloud Serivce日志的Partition Key的含义。这个PartitionKey是19位日志产生时间的Ticks，通过这个信息，我们能很快的取到任何时间区间的日志。
Azure Web日志机制
Web的日志机制与Serivce的稍有不同。我的理解中，Azure Web是比Cloud Service更高一层封装，在设置日志的时候也更方便。（除了PartitionKey的选择有点不好外）
在Azure Potal中进入Azure Web的配置界面，你会看到应用程序诊断区域。可以看到，Azure Web有三种日志记录方案：文件系统、存储表、Blob。不同存储方案有不同的优缺点。表存储更方便程序处理日志，但每条记录长度有限制；而文件系统和Blob存储比较适合人工查看，不限定每条记录的字符长度，Blob存储时，还自带删除旧日志的功能。可以同时打开多个日志记录方案。推荐Blob和Table结合使用
在表存储和blob存储中，还需要设置存储账号，并指定表名/blob容器名
Blob日志存储方案，程序自动按时间每小时一个blob。blob的内容是以逗号分隔符存储的。
Table日志存储中的PartitionKey是日志产生的时间的字符串yyyyMMddHH形式。（这会存在严重的性能问题，即热分区问题）
Azure Storm的日志机制
Azure Storm属于Azure HDInsight的一部分。其日志记录与上述情况具有较大的差异性。在创建Storm的时候，会指定一个存储账号，在存储账号的Table中，存有所有的日志信息，包括Storm平台自己的跟踪信息。
日志存储表名：u+storm名称+创建时间+hadoopservicelog，如：uruiyuanteststorm21mar2016at125425139hadoopservicelog
Storm日志的PartitionKey很奇怪，分成两部分，前半部分为0000000000000000000 到 0000000000000000100之间，后半部分是日志产生的Ticks。前半部分的含义询问了Azure的技术团队，仍然没有获得一个比较准确的回答。因此在取得特定时间段的日志时，情况比较复杂，但还是可以获得的，一种方法是取100次，然后再进行时间排序即可。
0 条评论