Журналы CloudWatch ведут себя странно

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

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 не существуют в фактическом отправляемом файле журнала.

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


amazon-web-services amazon-cloudwatch amazon-cloudwatchlogs cloudwatch
person Furhan S.    schedule 15.11.2016    source источник
comment
У меня такой же эффект, но я все еще ищу решение. Перезапуск службы не помог. Кстати: start_position и end_position - это не номера строк, а позиции байтов.   -  person Björn Weinbrenner    schedule 14.12.2016

Ответы (4)


arrow_upward
18
arrow_downward

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

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

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

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

Перечислить все потоки с помощью

select * from stream_state;

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

Затем перечислите все записи с этим source_id (в моем случае это было 7675f84405fcb8fe5b6bb14eaa0c4bfd) в таблице push_state

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

Результирующая запись имеет структуру данных json в столбце v, которая содержит 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

Надеюсь, у вас это сработает!

person Björn Weinbrenner    schedule 14.12.2016
comment
В моем случае таблица push_state пуста - что мне делать? - person Andrey; 31.07.2017
comment
Но вы получаете предупреждение ... причина: метка времени больше 2 часов в будущем.? Помогает ли перезапуск службы с помощью sudo /etc/init.d/awslogs restart? - person Björn Weinbrenner; 02.08.2017
comment
Привет, у вас есть способ принудительно сбросить журналы облачных часов? Кажется, у меня есть эта проблема на нескольких машинах, и я действительно не могу позволить себе входить в каждую машину и делать это для каждого экземпляра. Я нормально отношусь к потере ранее не синхронизированных журналов. Когда возникают такие проблемы, мое дисковое пространство, кажется, заполняется на 1 ГБ каждый час, поэтому мой веб-сервис просто умирает в одночасье ... - person Cyril Duchon-Doris; 07.03.2018
comment
Это происходит снова и снова. Не могу делать это каждый раз вручную - person Reyansh Kharga; 06.07.2020

arrow_upward
6
arrow_downward

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

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

  1. Остановлен сервис awslogs
  2. Удален файл / var / awslogs / state / agent-state

  3. Обновлена ​​конфигурация /var/awslogs/etc/awslogs.conf с имени хоста на идентификатор экземпляра Ex:

    log_stream_name = {hostname} to log_stream_name = {instance_id}
  4. Запущен сервис awslogs.
person Rajasekhar Vesangi    schedule 30.08.2017
comment
Я не знаю, элегантен ли это, но он работает для меня, и я считаю, что это быстрее и проще сделать, чем принятый ответ. Я хотел бы добавить, что для меня состояние агента находится в / var / lib / awslogs / state /. Вы можете увидеть, где находится этот файл в вашем файле /etc/awslogs/awslogs.conf - person Simon Ernesto Cardenas Zarate; 16.08.2018
comment
Это помогает и перезапускает процесс, но эта проблема возникает время от времени, и мне приходится сталкиваться с ней снова и снова. Меня беспокоит, как мне вообще предотвратить это? - person Affan Shahab; 14.05.2020
comment
У меня это работает. Думаю, шаг 3 не требуется. Согласно журналу awslogs, агент не отправляет записи журнала старше 14 дней, когда мы выполняем шаг 4. - person t_motooka; 21.03.2021

arrow_upward
0
arrow_downward

Мне удалось решить эту проблему в Amazon Linux следующим образом:

  1. sudo yum переустановите awslogs
  2. sudo service awslogs перезапуск

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

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

person johnsampson    schedule 31.10.2017

arrow_upward
0
arrow_downward

Я нашел причину. Часовой пояс в моем контейнере докеров не соответствует часовому поясу моего хост-компьютера. После установки согласованности двух часовых поясов проблема решена.

person simon    schedule 01.09.2020