亚马逊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这样的人，因为他们提供更多的钱。\

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