CloudWatch журналы действуют weird

Question

У меня есть два файла журнала с многострочными лог-операциями. Оба они имеют одинаковый формат даты и времени в начале каждого оператора журнала. Конфигурация выглядит следующим образом:

state_file = /var/lib/awslogs/agent-state 

[/opt/logdir/log1.0] 
datetime_format = %Y-%m-%d %H:%M:%S 
file = /opt/logdir/log1.0 
log_stream_name = /opt/logdir/logs/log1.0 
initial_position = start_of_file 
multi_line_start_pattern = {datetime_format} 
log_group_name = my.log.group 


[/opt/logdir/log2-console.log] 
datetime_format = %Y-%m-%d %H:%M:%S 
file = /opt/logdir/log2-console.log 
log_stream_name = /opt/logdir/log2-console.log 
initial_position = start_of_file 
multi_line_start_pattern = {datetime_format} 
log_group_name = my.log.group 

журналы cloudwatch агент отправляет журналы log1.0 правильно в мой лог группы по cloudwatch, однако, его не отправлять лог-файлы для log2-console.log.

awslogs.log говорит:

2016-11-15 08:11:41,308 - cwlogs.push.batch - WARNING - 3593 - Thread-4 - Skip event: {'timestamp': 1479196444000, 'start_position': 42330916L, 'end_position': 42331504L}, reason: timestamp is more than 2 hours in future. 
2016-11-15 08:11:41,308 - cwlogs.push.batch - WARNING - 3593 - Thread-4 - Skip event: {'timestamp': 1479196451000, 'start_position': 42331504L, 'end_position': 42332092L}, reason: timestamp is more than 2 hours in future. 

Хотя сервер времени правильно. Также странно, что номера строк, упомянутые в start_position, и end_position не существуют в текущем файле журнала.

Кто-нибудь еще испытывает эту проблему?

Answer 1

Я смог исправить это.

Состояние awslogs было сломано. Состояние хранится в базе данных sqlite в/var/awslogs/state/agent-state. Вы можете получить к нему доступ через

sudo sqlite3 /var/awslogs/state/agent-state 

sudo необходим для доступа на запись.

Список всех потоков с

select * from stream_state; 

Посмотрите свой поток журнала и обратите внимание на source_id, которая является частью структуры данных JSON в об колонке.

Затем список всех записей с этой SOURCE_ID (в моем случае это был 7675f84405fcb8fe5b6bb14eaa0c4bfd) в push_state стола

select * from push_state where k="7675f84405fcb8fe5b6bb14eaa0c4bfd"; 

Полученная запись имеет структуру данных JSON в клиновых колонке, которая содержит batch_timestamp. И это batch_timestamp швов, чтобы быть неправильным. Это было в прошлом, и все более новые (более 2 часов) записи журнала больше не обрабатывались.

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

update push_state set v='... insert new value here ...' where k='7675f84405fcb8fe5b6bb14eaa0c4bfd'; 

перезапустить службу с

sudo /etc/init.d/awslogs restart 

Я надеюсь, что это работает для Вас!

Answer 2

У нас была такая же проблема, и следующие шаги исправили проблему.

Если группы журналов не обновляется с последними событиями: Выполнить следующие действия:

1. Остановил обслуживание awslogs
2. Удаляется файл /вар/awslogs/состояние/агент состояния

3. Обновлено /var/awslogs/etc/awslogs.Conf конфигурации из hostaname в ID экземпляра Ex:

   log_stream_name = {hostname} to log_stream_name = {instance_id} 
   

4. работа awslogs обслуживания.

Answer 3

Я был в состоянии решить эту проблему на Amazon Linux по:

1. Sudo ням переустанавливать awslogs
2. Судо сервис awslogs RESTART

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

Примечание: В моем устранении неполадок я также удалил мой Log Group через консоль AWS. Перезагрузка полностью перезагрузила все исторические журналы, но на текущей временной отметке, которая имеет меньшее значение. Я не уверен, что удаление группы журналов было необходимо, чтобы этот метод работал. Возможно, вам захочется взглянуть на настройку конфигурации initial_position на end_of_file перед перезагрузкой.