搜索后找到解决方案，但如果有人碰巧遇到类似的混乱，请留在此处。最后请参阅决议。
我试图弄清楚为什么AWS CloudWatch日志服务无法理解我的日志事件的正确时间戳。目前，无论事件的实际时间戳是什么，我的所有活动都将在2017-01-01时间内保存。
我正在从syslog中提供日志，其中docker正在保存已记录的事件，我配置了docker以将格式设置为时间戳：
170105/103242 (%y%m%d/%H%M%S)
我使用参数配置了awslogs服务：
datetime_format = %y%m%d/%H%M%S
我重新启动了服务并点击了服务器，但是当我转到CloudWatch并查看日志条目时，即使以时间戳170105/103242开头的条目实际上也会保存为属于包含日期2017-01-01的事件01-01和01-05之间的所有事件
当我查看awslogs.log时，我可以看到以下几行：
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Missing or invalid value for use_gzip_http_content_encoding config. Defaulting to using gzip encoding.
2017-01-05 11:05:28,633 - cwlogs.push - INFO - 29223 - MainThread - Using default logging configuration.
这让我觉得配置可能实际上并没有读取/使用datetime_format，但我不明白它为什么决定最终使用默认值。我试着把
use_gzip_http_content_encoding = true
在常规设置下，但不会更改错误。
我的想法已经用完 - 有没有人设法以实际正确使用datetime_format的方式配置awslogger？
编辑：
我正在攻击更多的控制台日志到本地python2.7 push.py以查看发生了什么：）
解决：
好的，问题是我在创建初始设置后进入了这个项目，我觉得记录器配置为在位置使用.conf文件：
/etc/awslogs/awslogs.conf
动态填充。
环境中有一个脚本将此位置提供给awslogs-agent-setup.py，该脚本试图让代理了解应该从这里读取配置。
然而，这个脚本实际上没有做它应该做的事情，当服务启动时，它实际上是从
读取配置/var/awslogs/etc/awslogs.conf
其中包含默认值。
所以实际的解决方案是更改默认配置中的datetime_format参数，忘记我认为该服务正在使用的配置。
答案 0 :(得分：0)
将日志记录添加到/var/awslogs/lib/python2.7/site-packages/cwlogs/push.py，并查看如何解释实际的配置参数。
您可能会发现该服务实际上是在默认位置使用配置文件：
/var/awslogs/etc/awslogs.conf
因此你必须在那里编辑配置值，以便实际读取它们。