amazon s3 访问日志文件的可靠性如何？

Question

我们正在迁移到 s3 以开始为我们的网络应用提供一些静态生成的内容。我们一直在寻找一种机制来构建关于我们网站使用情况的度量系统，并且我们计划通过传递要记录在内容 GET 请求上的附加信息来解析 S3 的访问日志。我们碰巧遇到了以下entry in the developers guide：

尽力而为的服务器日志传递

服务器访问记录功能是 旨在尽最大努力。你可以 期望大多数针对 正确配置的存储桶 日志记录将导致交付的日志 记录，并且大多数日志记录将 几小时内送达 他们被记录的时间。

但是，服务器日志记录功能是 尽最大努力提供。这 服务器的完整性和及时性 不保证日志记录。日志 特定请求的记录可能 在请求之后很久才交付 实际处理过，或者它可能 根本不送。目的 服务器日志是给桶的 所有者对交通性质的想法 靠在他或她的桶上。它不是 意味着是一个完整的会计 所有请求。

我们想知道其他人在交付访问日志方面有什么经验？我们的替代方案是构建一个 HTTP 服务器并尝试通过不同的调用自己测量指标，但我们认为解析日志文件可能会证明工作量较小。我们想知道人们是否见过没有交付的情况，以试图衡量我们希望达到的准确度，因为我们收集的一些指标用于我们的一些业务流程。

Answer 1

我很惊讶我在 S3 上的日志文件不到一个月就变得如此庞大。我的应用程序没有必要解析亚马逊上的日志，但我喜欢你的方法。从我所见，您可以期望日志文件准确且完整。根据他们的 CYA 警告，日志不应用于任何重要的事情。

Answer 2

我们一直在使用 S3 记录相对大量的数据（大约 100M 行）。我们需要依赖 S3 访问日志来实现特定目的，并且我们发现了一些可能对访问日志的潜在用户来说很重要的问题：

• 我们看到（很少）日志条目在应该创建的很多天后出现
• 我们看到记录单个 S3 事务的重复条目（目前正在调查）
• 似乎也存在实际上未创建日志条目的情况（目前正在调查）

如果数据的准确性和完整性至关重要，我的建议是避免依赖 S3 访问日志。

Answer 3

我知道这不是您问题的答案，但是...

除非您的静态文件需要某种授权（下载的签名 URL 等），否则我认为使用 S3 提供静态内容没有好的用例。

它不是 CDN，也不打算用作一个 CDN。 ;-)

至少，我建议使用 cloudfront，但恕我直言，它太贵了（与其他人相比表现不佳）。我会推荐像 edgecast 或 cachefly 这样的人，因为他们提供更多的钱。\

它们还为您提供（或多或少）广泛的静态数据和许多不错的功能，例如轻松清除缓存和使缓存失效。