Неправильное время события в событиях журнала CloudWatch

Question

Нашли решение после поиска, но оставив это здесь, если кто-то случайно столкнулся с подобным путаницей. См. Резолюцию в конце.

Я пытаюсь понять, почему служба журнала AWS CloudWatch не понимает правильную временную метку для моих событий журнала. В настоящее время все мои события сохраняются в Time 2017-01-01 независимо от того, какова фактическая временная метка в событии.

Я кормлю бревно из системного журнала, где докер спасает регистрируемые события и я настроил докер поставить метку времени в формате:

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 

в общих настройках, но он не меняет ошибок.

У меня заканчиваются идеи - кому-нибудь удалось настроить awslogger таким образом, чтобы правильно использовать datetime_format?

Edit:

Я в настоящее время взлома больше журналов консоли для локального python2.7 push.py, чтобы увидеть, что происходит :)

---

ПОСТАНОВИЛИ:

Хорошо, проблема что я пришел в этот проект после того, как была создана первоначальная настройка, и у меня создалось впечатление, что регистратор настроен на использование файла .conf в местоположении:

/etc/awslogs/awslogs.conf 

, который был динамично населен.

В среде был сценарий, который дал этому местоположению awslogs-agent-setup.py, который пытался заставить агента понять, что конфигурация должна быть прочитана здесь.

Однако этот сценарий не на самом деле делать то, что он должен был сделать, и, когда началась служба, он на самом деле читать конфигурации из

/var/awslogs/etc/awslogs.conf 

, которые содержали значения по умолчанию.

Таким образом, фактическое разрешение было изменить параметр datetime_format в конфигурации по умолчанию и забыть о конфигурации, которую, как я думал, использовался службой.

Answer 1

Добавить регистрацию в /var/awslogs/lib/python2.7/site-packages/cwlogs/push.py и посмотреть, как интерпретируются фактические параметры конфигурации.

Вы, вероятно, обнаружите, что сервис на самом деле использует конфигурационный файл в папку по умолчанию:

/var/awslogs/etc/awslogs.conf

и, следовательно, вы должны изменить параметры конфигурации там для них чтобы быть действительно прочитанным.