Агент журналов AWS Clouwatch (awslogs) сходит с ума и записывает ГБ в файл журнала - PullRequest
0 голосов
/ 03 сентября 2018

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

2018-09-03 17:51:17,251 - cwlogs.push.reader - WARNING - 18880 - Thread-333 - Fall back to previous event time: {'timestamp': 1535992848000, 'start_position': 12956454L, 'end_position': 12956574L}, previousEventTime: 1535992848000, reason: timestamp could not be parsed from message.
2018-09-03 17:51:17,251 - cwlogs.push.reader - WARNING - 18880 - Thread-333 - Fall back to previous event time: {'timestamp': 1535992848000, 'start_position': 12956574L, 'end_position': 12956705L}, previousEventTime: 1535992848000, reason: timestamp could not be parsed from message.

... При ритме 10 на миллисекунду, так что это 10 000 записей журнала в секунду (то есть ~ 36 миллионов строк кода всего за один час, учитывая размер строки, это не удивительно, я получал только несколько ГБ журналов только несколько часов ...

У кого-нибудь была такая же проблема и есть какое-то объяснение / решение для противодействия этой ошибке?

Я не знаю, связано ли это еще, но какая-то другая ошибка приводит к тому, что мой DD достигает своего предела инода, поэтому я, вероятно, получаю целую кучу ошибок во многих приложениях и процессах, полагающихся на запись новых файлов ... этого будет достаточно, чтобы свести агента awslogs с ума?

1 Ответ

0 голосов
/ 23 октября 2018

Может быть, это поможет, не уверен, но я видел то же самое и понял, что это, вероятно, из-за исключительных ситуаций Java, многострочных записей sic, которые не совпадают с отметкой времени в конфигурации. Я добавил multi_line_start_pattern = {datetime_format}, и это, похоже, помогло. Я нашел эту ссылку довольно хорошим ресурсом для справки: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html

НТН, JP

...