如何在尝试为侦听器设置 Azure 接收器时跟踪异常源答案

【问题标题】：How can I track the source of exception on trying to set Azure sink for a listener如何在尝试为侦听器设置 Azure 接收器时跟踪异常源
【发布时间】：2016-07-01 08:49:55
【问题描述】：

我正在尝试使用Semantic Logging Application Block 将日志存储到Azure Table Storage。设置：

ObservableEventListener listener1 = new ObservableEventListener();
var conString =
    $"DefaultEndpointsProtocol={CloudStorageAccount.DevelopmentStorageAccount.TableEndpoint.Scheme};" +
    $"AccountName={CloudStorageAccount.DevelopmentStorageAccount.Credentials.AccountName};" +
    $"AccountKey={Convert.ToBase64String(CloudStorageAccount.DevelopmentStorageAccount.Credentials.ExportKey())}";
    
listener1.LogToWindowsAzureTable( // <---- EXCEPTION HERE
        instanceName: "instName",
        connectionString: conString);

我遇到了一个奇怪的异常：

抛出异常：Microsoft.Practices.EnterpriseLibrary.SemanticLogging.WindowsAzure.dll 中的“System.MissingMethodException”

附加信息：找不到方法：'Void Microsoft.WindowsAzure.Storage.Table.CloudTableClient.set_RetryPolicy(Microsoft.WindowsAzure.Storage.RetryPolicies.IRetryPolicy)'。

我在使用真实帐户时遇到了同样的问题。包版本（均来自 NuGet）：

EnterpriseLibrary.SemanticLogging — 2.0.1406.1
EnterpriseLibrary.SemanticLogging.WindowsAzure — 2.0.1406.1
WindowsAzure.Storage — 7.0.0

如何跟踪异常的来源？Google 对未找到的方法只字未提。在你的机器上测试的项目是here。

【问题讨论】：

请注意，将日志上传到 Azure Tables 很好，但将它们上传到 Application Insights (AI) 更好：github.com/fidmor89/SLAB_AppInsights。如果您有标准或高级层，则可以配置连续导出到表存储并免费获得...

标签： .net azure azure-table-storage semantic-logging slab

【解决方案1】：

您收到此错误的原因是因为SLAB 依赖于存储客户端库 3.0.2.0 (source) 并且在客户端上设置 Retry Policies（例如CloudTableClient）在版本 4.0 中已弃用。 0.0 (source) 并在某些更高版本中删除（不确定是哪一个）。

因为您使用的是 7.x 版本的存储客户端库，所以在 CloudTableClient 上设置 RetryPolicy 的方法不存在，因此您会收到此错误。

【讨论】：

它在 7.0.0 中被弃用（在 6.2.2-preview 中仍然存在）

【解决方案2】：

就像 Guarav 所说，SLAB 是针对非常旧的 Microsoft.WindowsAzure.Storage 版本构建的。问题是this line，使用client.RetryPolicy 而不是client.DefaultRequestOptions.RetryPolicy。我尝试更新 NuGet 包并对其进行更改，但它似乎破坏了一些测试，并且修复它们似乎并不容易。此外，似乎不存在 4.6 支持：https://github.com/mspnp/semantic-logging/issues/64。

这里有一个缺陷：https://github.com/mspnp/semantic-logging/issues/81，但我怀疑它很快就会发生任何事情（如果有的话）。我可能最终会编写一些简单的接收器，将日志重定向到 Azure 的跟踪侦听器（包括Table Storage upload）。

编辑这里的代码（尚未测试）：

public class SystemDiagnosticsTraceSink : IObserver<EventEntry>
{
    public void OnNext(EventEntry entry)
    {
        if (entry == null) return;
        using (var writer = new StringWriter())
        {
            new EventTextFormatter().WriteEvent(entry, writer);
            var eventText = writer.ToString();
            switch (entry.Schema.Level)
            {
                case EventLevel.LogAlways:
                case EventLevel.Critical:
                case EventLevel.Error:
                    Trace.TraceError(eventText);
                    return;
                case EventLevel.Warning:
                    Trace.TraceWarning(eventText);
                    return;
                case EventLevel.Informational:
                case EventLevel.Verbose:
                    Trace.TraceInformation(eventText);
                    return;
                default:
                    Trace.TraceError("Unknown event level: " + entry.Schema.Level);
                    Trace.TraceInformation(eventText);
                    return;
            }
        }
    }
    public void OnError(Exception error)
    {} //you might want to do something here
    public void OnCompleted()
    {} //nothing to do
}

以及扩展类：

public static class SystemDiagnosticsTraceSinkExtensions
{
    public static SinkSubscription<SystemDiagnosticsTraceSink> LogToSystemDiagnosticsTrace
      (this IObservable<EventEntry> eventStream)
    {
        if (eventStream == null) throw new ArgumentNullException(nameof(eventStream));

        var sink = new SystemDiagnosticsTraceSink();
        return new SinkSubscription<SystemDiagnosticsTraceSink>(
                       eventStream.Subscribe(sink), sink);
    }
}

【讨论】：