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

Question

我将确定一种在Azure Table Storage中存储日志记录信息的好策略。我有以下内容：

PartitionKey：日志名称。

RowKey：倒置的DateTime刻度，

这里唯一的问题是分区可能会变得非常大（数以百万计的实体），并且大小会随着时间而增加。

但是，正在执行的查询类型将始终包括PartitionKey（不扫描）和RowKey过滤器（次要扫描）。

例如（使用自然语言）：

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

提供了对PartitionKey和RowKey的查询，我知道分区的大小无关紧要。

Answer 1

[看看我们新的Table Design Patterns Guide-特别是日志数据反模式，因为它讨论了这种情况和替代方案。人们通常在写日志文件时会在PK上使用日期，这会导致分区变热，因为所有写操作都进入单个分区。通常，Blob最终会成为更好的日志数据目的地-因为人们通常最终无论如何都要分批处理日志-指南将此作为一种选择。

Answer 2

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

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

示例：

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功能，则建议禁用此功能，这比应用程序见解要便宜得多。如果需要多个日志名称，只需添加另一个表。