fge*_*enc 6 logging azure azure-storage azure-diagnostics asp.net-web-api
我正在开发一个将在Azure中托管的web api.我想使用Azure诊断程序将错误记录到Azure表存储.在Classic门户中,我可以将日志配置为Azure表存储.
但是在新的Azure门户中,我唯一的存储选项是使用Blob存储:
似乎如果我要使用Web角色,我可以配置数据存储以进行诊断,但是当我正在开发web api时,我不想为每个api创建一个单独的Web角色,这样我就可以登录到天蓝色的桌子.
有没有办法以编程方式配置azure诊断,以便在不使用Web角色的情况下将日志消息传播到特定数据存储？有没有理由为什么新的Azure门户只有blob存储的诊断设置而不是表存储？
我现在可以通过使用经典门户解决该问题,但我担心诊断的表存储最终会被弃用,因为它尚未包含在新门户的诊断设置中.
小智 2
我们通常不建议使用表来存储日志数据 - 它可能会导致仅追加模式，而这种模式在规模上无法有效地用于表存储。请参阅本指南中的日志数据反模式表设计指南。我们经常看到，尽管人们认为日志数据是结构化的，但他们通常查询日志数据的方式使 Blob 更加高效。
\n\n设计指南摘录：
\n\n\n\n日志数据反模式
\n\n通常，您应该使用 Blob 服务而不是表服务来存储日志数据。
\n\n背景和问题
\n\n日志数据的一个常见用例是检索特定日期/时间范围内的一系列日志条目：例如，您想要查找应用程序在 15:04 到 15:06 之间记录的所有错误和关键消息。具体日期。您不想使用日志消息的日期和时间来确定保存日志实体的分区：这会导致热分区，因为在任何给定时间，所有日志实体将共享相同的 PartitionKey 值（请参阅前置/附加反模式）。\n ...
\n\n解决方案
\n\n上一节重点介绍了尝试使用表服务存储日志条目的问题，并提出了两种不令人满意的设计。一种解决方案会导致热分区，并存在写入日志消息的性能不佳的风险；另一种解决方案导致查询性能较差，因为需要扫描表中的每个分区以检索特定时间跨度的日志消息。Blob 存储为此类场景提供了更好的解决方案，这就是 Azure 存储分析存储其收集的日志数据的方式。
\n\n本部分概述存储分析如何在 Blob 存储中存储日志数据，作为此存储通常按范围查询的数据的方法的说明。
\n\n存储分析以分隔格式将日志消息存储在多个 blob 中。分隔格式使客户端应用程序可以轻松解析日志消息中的数据。
\n\n存储分析使用 Blob 命名约定，使您能够找到包含要搜索的日志消息的 Blob（或多个 Blob）。例如，名为“queue/2014/07/31/1800/000001.log”的 blob 包含与 2014 年 7 月 31 日 18:00 开始的一小时内的队列服务相关的日志消息。“000001”表示此是该时期的第一个日志文件。存储分析还记录存储在文件中的第一条和最后一条日志消息的时间戳，作为 blob\xe2\x80\x99s 元数据的一部分。Blob 存储 API 使您能够根据名称前缀在容器中定位 Blob：要查找包含从 18:00 开始的一小时内的队列日志数据的所有 Blob，您可以使用前缀“queue/2014/07/31” /1800。”
\n\n存储分析在内部缓冲日志消息，然后定期更新相应的 blob 或使用最新一批日志条目创建新的 blob。这减少了必须对 blob 服务执行的写入次数。
\n\n如果您在自己的应用程序中实现类似的解决方案，则必须考虑如何在可靠性（在发生时将每个日志条目写入 blob 存储）与成本和可扩展性（在应用程序中缓冲更新并将其写入到 blob 存储）之间进行权衡。批量 blob 存储）。
\n\n问题和考虑因素
\n\n在决定如何存储日志数据时请考虑以下几点：
\n\n\n
\n- \n
如果您创建避免潜在热分区的表设计，您可能会发现无法有效地访问日志数据。
- \n
为了处理日志数据，客户端通常需要加载许多记录。
- \n
尽管日志数据通常是结构化的，但 blob 存储可能是更好的解决方案。
