搜索后找到了解决方案，但如果有人碰巧遇到类似的困惑，请留在这里。最后看分辨率。
我试图弄清楚为什么 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 参数，而忘记我认为服务正在使用的配置。