在Azure表存储中存储应用程序日志的策略

时间:2015-02-19 11:34:53

标签: azure azure-storage azure-table-storage

我将确定一个在Azure表存储中存储日志记录信息的好策略。我有以下内容:

  

PartitionKey:日志的名称。

     

RowKey:反转日期时间刻度,

这里唯一的问题是分区可能会变得非常大(数百万个实体),并且大小会随着时间的推移而增加。

但话虽如此,正在执行的查询类型将始终包括PartitionKey(无扫描)和RowKey过滤器(次要扫描)。

例如(用自然语言):

where `PartitionKey` = "MyApiLogs" and
where `RowKey` is between "01-01-15 12:00" and "01-01-15 13:00"

如果查询是在PartitionKeyRowKey上完成的,我理解分区的大小并不重要。

2 个答案:

答案 0 :(得分:7)

看看我们的新Table Design Patterns Guide - 特别是日志数据反模式,因为它讨论了这个场景和替代方案。通常,当人们编写日志文件时,他们会使用PK的日期,这会导致分区变热,因为所有写入都会转到单个分区。通常,Blob最终成为日志数据的更好目的地 - 因为人们通常最终会批量处理日志 - 指南会将此作为一种选择。

答案 1 :(得分:0)

添加我自己的答案,以便人们可以内联某些东西而无需外部链接。

您希望分区键为时间戳加上消息的哈希码。在大多数情况下,这已经足够了。您也可以根据需要将任何其他键/值对的哈希码添加到消息的哈希码中,但是我发现这并不是必须的。

示例:

string partitionKey = DateTime.UtcNow.ToString("o").Trim('Z', '0') + "_" + message.GetHashCode();
string rowKey = logLevel.ToString();
DynamicTableEntity entity = new DynamicTableEntity { PartitionKey = partitionKey, RowKey = rowKey };
// add any additional key/value pairs from the log call to the entity, i.e. entity["key"] = value;
// use InsertOrMerge to add the entity

查询日志时,可以使用带有分区键的查询,该查询是您要检索日志的开始时间,通常距当前日期/时间1分钟或1小时左右。然后,您可以使用不同的日期/时间戳向后滚动另一分钟或一小时。这样可以避免从建议从DateTime.MaxValue中减去日期/时间戳记的奇怪的日期/时间修改。

如果您特别喜欢将搜索服务放在Azure表存储之上,则可以快速查找键/值对。

如果您正在使用Azure功能(我建议禁用此功能),这将比应用程序见解便宜得多。如果您需要多个日志名称,只需添加另一个表。