Назад | Перейти на главную страницу

Журнал Apache vhost вращается по дате

У меня Apache 2.2 работает на Debian 7 (на VPS) с виртуальными хостами, определенными для нескольких разных веб-сайтов.

Я установил индивидуальные журналы ошибок и доступа для каждого виртуального хоста, но я не нашел способа повернуть / архивировать журналы по своему вкусу.

Конечно, журналы Apache по умолчанию в Debian вращаются с помощью logrotate, но я не считаю это особенно удовлетворительным по разным причинам - в первую очередь потому, что я хочу, чтобы архивные журналы именовались по дате, и потому что настраивать его отдельно для каждого виртуального хоста кажется громоздким. Я также не уверен в автоматическом удалении старых журналов; Возможно, я захочу сделать это вручную только после загрузки их с сервера.

Мое идеальное решение - делать следующее каждый месяц (а может быть, неделю):

Мне также нужно, чтобы это было легко настроить для нескольких хостов.

В идеале он не должен включать перезапуск apache (хотя постепенный перезапуск - это еще не конец света).

Как лучше всего это настроить? Я уверен, что это было сделано раньше ...

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

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

Я также смог использовать подстановочные знаки, чтобы не создавать новый файл conf для logrotate каждый раз, когда я добавляю vhost в будущем.

Для всех, кто пытался это сделать, я использовал следующую конфигурацию logrotate:

/var/www/*/logs/*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    dateext
    dateformat .%Y%m%d
    extension .log
    olddir old
    create 640 root root
    sharedscripts
    postrotate
        /etc/init.d/apache2 reload > /dev/null
    endscript
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate;
        fi; \
    endscript
}

Я уверен, что изменю это в будущем, но в качестве отправной точки это нормально.

(Обратите внимание olddir необходимо, потому что в противном случае *.log также совпадает с файлом журнала прошлой недели ...)

(Я обнаружил немного Национальные институты здравоохранения США?)

Вот почему вам не следует делать это в одиночку:

  1. Лучше расширять, чем изобретать заново: По сути, то, что вы хотите сделать, уже покрыто logrotate. Если вам не нравится его поведение по умолчанию, вы можете с благодарностью настроить его на другое поведение с помощью это до / после действий, соглашения об именах и т. д..

  2. Решение уже решенной проблемы: Ребята, которые внесли свой вклад в logrotate, уже сталкивались с вашей проблемой раньше, а иногда и с некоторыми. В какой-то момент вы, скорее всего, столкнетесь с теми же проблемами, с которыми они столкнулись, и решили их с гораздо большим опытом и отзывами ... вы действительно хотите тратить свою энергию на их решение снова?

  3. Не удалять старые журналы - это очень плохая идея. Это приводит к ожиданию заполнения вашего раздела журнала - в зависимости от вашей настройки, ваши приложения или даже весь ваш сервер будут останавливаться. Желательно на пике ваших повседневных дел.

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

  4. Поддержка домашнего пивоварения: Если у вас когда-нибудь возникнут проблемы, не у кого больше спросить, так как это решение используете только вы, тогда как logrotate используется многими другими.

  5. Настройка является легко: просто cp и sed ваши конфигурации vhost соответственно. Стремитесь к автоматизации.

Обратите внимание, что приведенные выше причины не являются каменными и применимы не везде. Неплохая идея время от времени подвергать сомнению существующие решения (там мощь будет лучшим решением), но в данном случае я считаю это занятием бесполезным.

Другой альтернативой может быть использование CRON. Вот как я это делаю;

#!/bin/bash

for file in /var/www/*/logs/*.log; do
    # zip and truncate file (dont remove cos apache cannot write on it unless restarted)
    zip $(dirname $file)/$(date +"%Y-%m-%d")-$(basename $file).zip $file && truncate -s 0 $file
done

Этот сценарий создаст заархивированный файл журнала, например /var/www/example.com/logs/2010-01-01-access.log.zip.