我正在为CloudFront日志文件设置处理pipe道。 阅读文档,我的理解是,CF将每个分发每小时创build一个日志文件,但这不是我看到的。 每个发行版(每小时)我得到多个文件:
E39O6KS6J8MIZW.2015-10-09-23.083b2c12.gz E39O6KS6J8MIZW.2015-10-09-23.1a96bb61.gz E39O6KS6J8MIZW.2015-10-09-23.4cd34dd8.gz E39O6KS6J8MIZW.2015-10-09-23.50c7b5b1.gz
我错过了什么? 基本上,我想了解的是驱动程序创build新的日志文件。
您可能知道,CloudFront是一个全球分布式系统,其configuration是集中的,但是一旦将configuration推送给它们,则50多个边缘位置将独立运行。
日志大概是在每个边缘或区域本地收集的,然后定期收集并组合成合并日志并发布到日志桶中。
embedded在日志文件名中的时间戳大约表示包含事件发生的时间。 因此,一个小时的日志通常不会在一个小时内到达,甚至在一个小时之后也不会到达。
如果有任何事情阻止了某些边缘的日志被及时收集(正如全球分布式平台所期望的那样),他们通常会在几个小时内到达一个倒退的日志文件,日志最初被logging。
日志文件传送的时间
CloudFront每个小时提供多次访问日志。 通常,日志文件包含有关在给定时间段内CloudFront收到的请求的信息。 CloudFront通常会在日志中显示的事件发生后一小时内将该时间段的日志文件传送到Amazon S3存储桶。 但是,请注意,某些时间段的某些或全部日志文件条目有时可能会延迟达24小时。 当日志条目被延迟时,CloudFront将它们保存在日志文件中,文件名包括发生请求的时间段的date和时间,而不是文件传送的date和时间。
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html#access-logs-timing
因此,从本质上讲,CloudFront将在每个小时至less创build一个日志文件,以便您的分发包含任何stream量,但是日志可能随时都会到达,因此您无法有效地轮询查找基于当前时间,前一小时的时间等
一种尽可能迅速地处理这些事件的方法 (不用投票)是S3事件通知 。
在任何情况下,您都需要做好准备,处理任何时间戳,每当它被写入时,不要假设重复,也不要忽视日志,因为它的时间戳比预期的要旧。