Агент Google Cloud Ops
У меня возникла проблема, когда ведение журнала агента Google Cloud Ops собирает много данных и заполняет весь жесткий диск моего сервера Debian примерно за 3 недели из-за постоянно увеличивающегося размера файла журнала.
Я не хочу увеличивать размер жесткого диска моего сервера.
Кто-нибудь знает, как настроить агент Google Cloud Ops, чтобы он сохранял данные журнала только за предыдущие 7 дней?
Обновлено: файл журнала агента Google Cloud Ops хранится в каталоге ниже
/var/log/google-cloud-ops-agent/subagents/logging-module.log
Каталог агента Google Cloud Ops на сервере Debian содержит один файл журнала, размер которого увеличивается до гигабайт в течение нескольких недель. Единый файл журнала продолжает увеличиваться в размере и заполняет весь жесткий диск.
Не могли бы вы предоставить более подробную информацию о том, как вы настроили агент OPS? Насколько я понимаю, журналы находятся на вашей виртуальной машине Debian. Используете ли вы logrotate или любое другое программное обеспечение для архивирования старых журналов или удаления журналов старше 7 дней?
Я не настраивал ops-агент. Он был установлен из консоли облачной платформы Google одним нажатием кнопки мыши, поэтому это будет конфигурация по умолчанию. Нет, я не использую logrotate или программное обеспечение для архивирования. Журнал агента облачных опций Google увеличивается в размере примерно на 350 МБ в день.
Значит, те журналы, которые заполняют вашу виртуальную машину, — это не журналы вашего приложения, а файл, который занимает все место, — это logging-module.log? Честно говоря, я согласен с ответом guillaume blaquiere, что агент Cloud OPS отправляет журналы в Cloud Logging и не должен создавать такие огромные файлы журналов на вашей виртуальной машине. Не могли бы вы подтвердить, что агент OPS работает правильно, как указано здесь? Из многих приложений вы получаете эти журналы и какой уровень детализации? Это только предупреждение, ошибка, информация и т.д.
Да, один файл logging-module.log, расположенный в каталоге google-cloud-ops-agent, увеличивается примерно на 350 МБ в день, пока в конечном итоге весь жесткий диск сервера не будет полностью заполнен.
Какую версию агента OPS вы используете? Не могли бы вы предоставить вывод sudo systemctl status google-cloud-ops-agent"*"? Также не могли бы вы проверить, нет ли у вас спама 403, такого как упомянутый здесь, или спама с проблемой авторизации, который можно исправить используя это руководство? Вы пытались перезапустить агент OPS?
У меня такая же проблема. Там, кажется, не так много ресурсов о том, как с этим бороться. Я мог бы настроить специальное правило logrotate, чтобы справиться с этим, но похоже, что это не моя ответственность, и в зависимости от внутренностей монитора gcloud ops могут возникнуть проблемы. Этот logging-module.log в /var/log/google-cloud-ops-agent/subagents/consistency заполняется до тех пор, пока диск не будет загружен на 95%.
Да, перезагрузка операционной системы или перезапуск агента Google Cloud Ops не решает проблему. Статистика Systemctrl не сообщает о проблемах, и в журналах нет проблем. Похоже, Google должен решить эту проблему.
@MikeMoy, какой агент Cloud OPS вы используете? Насколько я помню, была проблема с версией 2.7.1. В настоящее время вы можете установить версии 2.8.0 и 2.8.1. Не могли бы вы переустановить агент OPS до новейшей версии 2.8.1, чтобы проверить, возникает ли эта проблема, следуя это документы
У меня есть агент Google Cloud Ops. Версия: 2.8.1~debian10.
Права доступа к файлу журнала: -rw-r--r-- root root
Я не могу воспроизвести вашу проблему. Какое приложение у вас есть на этом Debian-сервере?
@PjoterS спасибо за помощь. Кажется, что если у вас есть старая версия агента google opts и обновлена в какой-то момент времени, как я, ошибка не будет устранена, если вы не знаете, как вручную подключиться к серверу по SSH и удалить фрагменты буфера. Решение ниже.
Ответы 1
Недавно я столкнулся с той же проблемой при использовании агента 2.11.0. И дело не только в огромном лог-файле, но и в нелепом использовании процессора! Посмотри в хтопе. Если вы откроете файл журнала, вы увидите, что он рассылает сообщения об ошибках, связанных с фрагментами буфера. Судя по всему, они испортились smh, поэтому агент не может их прочитать и отправить. Таким образом, высокая загрузка IO и CPU.
Решение состоит в том, чтобы остановить службу:
sudo service google-cloud-ops-agent stop
Затем очистите все фрагменты буфера:
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
И удалите файл журнала, если хотите:
sudo rm -f /var/log/google-cloud-ops-agent/subagents/logging-module.log
Затем запустите агент:
sudo service google-cloud-ops-agent start
Это помогло мне.
Кстати, эта проблема описана здесь, и кажется, что Google «исправил» ее, начиная с версии 2.7.0-1. Что бы они ни подразумевали под этим, поскольку мы все еще сталкивались с этим...
Это безумие, что Google не отправил сообщение всем клиентам облачной платформы Google, информируя их о недостатке в агенте облачных опций Google. Кажется, что если бы у вас была старая версия агента google opts и вы обновили ее в какой-то момент времени, как я, то ошибка не будет устранена, если вы не знаете, как вручную подключиться к серверу по SSH и удалить фрагменты буфера. Очень плохо обрабатывается со стороны Google, это все еще должно влиять на многих других пользователей облачной платформы Google.
Файл журнала теперь не превышает 1 КБ, вместо того, чтобы ранее заполнять весь сервер в ГБ, и да, вы правы, использование ЦП моего сервера снизилось более чем на 30% с помощью вышеуказанного исправления для агента облачных операций Google. Спасибо за исправление.
Используете ли вы какое-либо решение для ротации журналов? Вы уверены, что это не ваше приложение? Не могли бы вы проверить, какие файлы самые большие или у вас есть сотни маленьких файлов? Используете ли вы какое-либо сжатие?