Apache2 rotatelogs не обрезает файл
У меня есть настройки rotatelogs, как я считаю, это должно соответствовать моим требованиям. Ниже приведены соответствующие строки:
Насколько я понимаю, еженедельно я должен видеть новый файл журнала, созданный с другим суффиксом. -n 4 будет хранить журналы за три недели плюс текущий файл, в который выполняется запись. Я вижу только ssl.access_log.1 , а затем текущий файл журнала. Однако файл журнала без суффикса огромен, и, просматривая его содержимое, я вижу, что есть сообщения ДАВНО.
Я просто не понимаю, как работает rotatelogs?
Я начинаю задаваться вопросом, относится ли аргумент rotationtime к rotatelogs к времени выполнения процесса, а не ко времени существования файла журнала. logrotate запускается ежедневно с помощью задания cron, которое в конечном итоге выбирает файл конфигурации logrotate по умолчанию для apach2, который меняет файлы журнала по умолчанию, а также перезагружает apache2 каждое утро в 06:25. Мне интересно, является ли эта перезагрузка причиной моего аргумента rotationtime из 604800 (7 дней) практически никогда не будет достигнуто, что приведет к тому, что файл журнала никогда не будет меняться. На правильном пути?
1 ответ
Я наблюдаю точно такое же поведение rotatelogs: файл без суффикса никогда не усекается, но все равно добавляет строки. В отличие от tczx3, я не перезапускаю процессы регулярно. Я также не манипулирую временными метками. Поведение в моем понимании явно не похоже на задокументированное. И rotatelogs не может считать до 5, кажется. Он запускается с -n 5, но поддерживает только 4 файла (без суффикса, .1, .2 и .3). Я вручную удалил устаревшие строки из файлов без суффикса и буду наблюдать в течение следующих недель. Согласно тому, что я увижу, я открою отчет об ошибке.
Apache access log почему не обрезается
Журналирование и ротация логов Apache на сервере Ubuntu
Веб-сервер Apache может предоставлять администратору много полезной информации о своей работе, а также о проблемах и ошибках, которые нужно устранить.
Вовремя настроенное журналирование позволяет в дальнейшем избежать неожиданных проблем с веб-сервером. Информация, хранящаяся в логах (или журналах) сервера, помогает быстро оценить ситуацию и устранить ошибки. Apache предоставляет очень гибкий механизм журналирования.
Данное руководство знакомит с возможностями журналирования Apache и предназначенными для этого инструментами.
Примечание: В данном руководстве используется Apache2 на сервере Ubuntu 12.04, но инструкции подойдут и для других дистрибутивов.
Уровни логирования
Apache делит все уведомляющие сообщения на категории в зависимости от важности соощения.
Для этого существуют уровни логирования. К примеру, наиболее важные сообщения, уведомляющие о критических ошибках и сбоях, существует уровень emerg. А сообщения уровня info просто предоставляют полезные подсказки.
Существуют следующие уровни логирования:
- emerg: критическая ситуация, аварийный сбой, система находится в нерабочем состоянии.
- alert: сложная предаварийная ситуация, необходимо срочно принять меры.
- crit: критические проблемы, которые необходимо решить.
- error: произошла ошибка.
- warn: предупреждение; в системе что-то произошло, но причин для беспокойства нет.
- notice: система в норме, но стоит обратить внимание на её состояние.
- info: важная информация, которую следует принять к сведению.
- Debug: информация для отладки, которая может помочь определить проблему.
- trace[1-8]: Трассировка информации различных уровней детализации.
При настройке логирования задаётся наименее важный уровень, который нужно вносить в лог. Что это значит? Логи фиксируют указанный уровень логирования, а также все уровни с более высоким приоритетом. К примеру, если выбрать уровень error, логи будут фиксировать уровни error, crit, alert и emerg.
Для настройки уровня логирования существует директива LogLevel. Уровень логирования по умолчанию задан в стандартном конфигурационном файле:
sudo nano /etc/apache2/apache2.conf
. . .
LogLevel warn
. . .
Как видите, по умолчанию Apache вносит в лог сообщения уровня warn (и более приоритетных уровней).
Где находятся логи Apache?
Apache может разместить свои логи, используя общесерверные настройки ведения логов. Также можно настроить индивидуальное логирование для каждого отдельного виртуального хоста.
Общесерверные настройки логирования
Чтобы узнать, где находятся стандартные логи сервера, откройте конфигурационный файл. В Ubuntu это /etc/apache2/apache2.conf:
sudo nano /etc/apache2/apache2.conf
Найдите в файле строку:
Данная директива указывает на расположение лога, в котором Apache хранит сообщения об ошибках. Как видите, для получения префикса пути к каталогу используется переменная среды APACHE_LOG_DIR.
Чтобы узнать значение переменной APACHE_LOG_DIR, откройте файл envvars:
sudo nano /etc/apache2/envvars
. . .
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
. . .
Согласно этому файлу, переменная APACHE_LOG_DIR настроена на каталог /var/log/apache2. Это означает, что Apache соединит это значение с директивой в конфигурационном файле apache2.conf и будет вносить данные в лог /var/log/apache2/error.log.
sudo ls /var/log/apache2
access.log error.log other_vhosts_access.log
Как видите, тут находится лог ошибок error.log и несколько других логов.
Логирование виртуальных хостов
Файл access.log, упомянутый в конце предыдущего раздела, не настраивается в файле apache2.conf. Вместо этого разработчики поместили соответствующую директиву в файл виртуального хоста.
Откройте и просмотрите стандартный виртуальный хост:
sudo nano /etc/apache2/sites-available/default
Пролистайте файл и найдите следующие три значения, связанные с логированием:
Местонахождение ErrorLog совпадает с его определением в стандартном конфигурационном файле. Эта строка не обязательно должна находиться в двух отдельных файлах; при изменении местонахождения этого лога в одном из файлов ошибки не возникнет.
Пользовательские логи
В предыдущем разделе строка, описывающая access.log, использует не такую директиву, как предыдущие строки для настройки логов. Она использует CustomLog:
Эта директива имеет такой синтаксис:
CustomLog log_location log_format
В данном случае log_format (формат логов) является комбинированным (combined). Эта спецификация не является внутренней спецификацией Apache; она задаёт пользовательский формат, который определен в конфигурационном файле по умолчанию.
Снова откройте конфигурационный файл по умолчанию и найдите строку, определяющую формат combined:
Команда LogFormat определяет пользовательский формат логов, вызываемых директивой CustomLog.
Этот формат называется комбинированным (combined).
Примечание: Подробнее о доступных форматах можно узнать здесь.
Существует еще несколько распространённых форматов, которые можно использовать в определении виртуальных хостов. Можно также создавать свои собственные форматы.
Ротация логов Apache
Ротация логов – это процесс, подразумевающий отключение устаревших или слишком объёмных лог-файлов и их архивирование (на установленный период времени). Apache может вносит в лог довольно большие объёмы данных, следовательно, во избежание заполнения дискового пространства необходимо настроить ротацию логов.
Ротация логов может быть очень простой (как, например, отключение слишком больших логов), а может иметь и более сложную конфигурацию (то есть, функционировать как система архивирования и хранения старых логов).
Рассмотрим методы настройки ротации логов Apache.
Ротация логов вручную
Перемещать логи во время работы Apache нельзя. То есть, чтобы переместить в архив устаревшие или заполненные логи и заменить их новыми, нужно перезапустить сервер.
Это можно сделать вручную. Для этого нужно переместить устаревшие файлы, а затем, перезапустив Apache, обновить настройки веб-сервера и заставить его использовать новые логи.
Ниже приведён пример из документации Apache. Возможно, понадобится добавить в начало этих команд sudo.
mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
[post-processing of log files]
Эти команды переместят файлы, перезапустят сервер и скажут ему подождать 600 секунд. Таким образом Apache сможет использовать старые лог-файлы, чтобы завершить регистрацию старых запросов. В течение этого времени новые запросы будут записаны в новые лог-файлы.
Имейте в виду: ротация логов вручную очень ненадёжна в больших серверных средах.
Утилита logrotate
По умолчанию система Ubuntu настраивает ротацию логов при помощи утилиты logrotate.
Данная программа может выполнять ротацию логов при соблюдении определенных критериев. Просмотреть события, включающие Logrotate для ротации логов, можно в файле /etc/logrotate.d/apache2:
sudo nano /etc/logrotate.d/apache2
В нём находится несколько параметров logrotate. Обратите внимание на первую строку:
Это значит, что logrotate будет выполнять ротацию только тех логов, которые находятся в /var/log/apache2. Имейте это в виду, если вы выбрали другой каталог для хранения в конфигурации Apache.
Как видите, логи ротируются еженедельно. Также тут есть раздел кода, перезапускающий Apache после ротации:
postrotate
/etc/init.d/apache2 reload > /dev/null
endscript
Эти строки автоматически перезапускают веб-сервер Apache после завершения ротации.
Примечание: К сожалению, настройки данного файла не охвачены в данном руководстве.
Ротация логов по каналам
Использование каналов вместо файлов – простой способ передать обработку вывода программе логирования. Это также решает проблему ротации логов, поскольку ротация может выполняться с помощью программы на серверной стороне (а не самим сервером Apache).
Чтобы логи обрабатывались программой логирования, принимающей стандартный вывод, замените следующую строку следующим образом:
CustomLog «| logging_program logging_program_parameters» combined
Apache запустит программу логирования во время загрузки и перезапустит её в случае ошибки или сбоя.
Для ротации логов можно использовать разные программы, но по умолчанию Apache поставляется с rotatelogs. Чтобы настроить эту программу, используйте:
CustomLog «| /path/to/rotatelog /path/of/log/to/rotate number_of_seconds_between_rotations» log_level
Аналогичную конфигурацию можно создать и для других программ.
Заключение
Конечно, это руководство охватывает только основы логирования Apache.
Правильная настройка механизмов логирования и разумное управление лог-файлами сэкономят немало времени и сил в случае возникновения проблем с сервером. Имея быстрый доступ к информации, которая поможет определить проблемы, можно в кратчайшие сроки исправить все ошибки.
Также очень важно следить за логами сервера, чтобы случайно не подвергнуть опасности конфиденциальную информацию.
Log Files
In order to effectively manage a web server, it is necessary to get feedback about the activity and performance of the server as well as any problems that may be occurring. The Apache HTTP Server provides very comprehensive and flexible logging capabilities. This document describes how to configure its logging capabilities, and how to understand what the logs contain.
- Overview
- Security Warning
- Error Log
- Per-module logging
- Access Log
- Log Rotation
- Piped Logs
- Virtual Hosts
- Other Log Files
See also
Overview
- mod_log_config
- mod_log_forensic
- mod_logio
- mod_cgi
The Apache HTTP Server provides a variety of different mechanisms for logging everything that happens on your server, from the initial request, through the URL mapping process, to the final resolution of the connection, including any errors that may have occurred in the process. In addition to this, third-party modules may provide logging capabilities, or inject entries into the existing log files, and applications such as CGI programs, or PHP scripts, or other handlers, may send messages to the server error log.
In this document we discuss the logging modules that are a standard part of the http server.
Security Warning
Anyone who can write to the directory where Apache httpd is writing a log file can almost certainly gain access to the uid that the server is started as, which is normally root. Do NOT give people write access to the directory the logs are stored in without being aware of the consequences; see the security tips document for details.
In addition, log files may contain information supplied directly by the client, without escaping. Therefore, it is possible for malicious clients to insert control-characters in the log files, so care must be taken in dealing with raw logs.
Error Log
- core
- ErrorLog
- ErrorLogFormat
- LogLevel
The server error log, whose name and location is set by the ErrorLog directive, is the most important log file. This is the place where Apache httpd will send diagnostic information and record any errors that it encounters in processing requests. It is the first place to look when a problem occurs with starting the server or with the operation of the server, since it will often contain details of what went wrong and how to fix it.
The error log is usually written to a file (typically error_log on Unix systems and error.log on Windows and OS/2). On Unix systems it is also possible to have the server send errors to syslog or pipe them to a program.
The format of the error log is defined by the ErrorLogFormat directive, with which you can customize what values are logged. A default is format defined if you don’t specify one. A typical log message follows:
[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico
The first item in the log entry is the date and time of the message. The next is the module producing the message (core, in this case) and the severity level of that message. This is followed by the process ID and, if appropriate, the thread ID, of the process that experienced the condition. Next, we have the client address that made the request. And finally is the detailed error message, which in this case indicates a request for a file that did not exist.
A very wide variety of different messages can appear in the error log. Most look similar to the example above. The error log will also contain debugging output from CGI scripts. Any information written to stderr by a CGI script will be copied directly to the error log.
Putting a %L token in both the error log and the access log will produce a log entry ID with which you can correlate the entry in the error log with the entry in the access log. If mod_unique_id is loaded, its unique request ID will be used as the log entry ID, too.
During testing, it is often useful to continuously monitor the error log for any problems. On Unix systems, you can accomplish this using:
tail -f error_log
Per-module logging
The LogLevel directive allows you to specify a log severity level on a per-module basis. In this way, if you are troubleshooting a problem with just one particular module, you can turn up its logging volume without also getting the details of other modules that you’re not interested in. This is particularly useful for modules such as mod_proxy or mod_rewrite where you want to know details about what it’s trying to do.
Do this by specifying the name of the module in your LogLevel directive:
This sets the main LogLevel to info, but turns it up to trace5 for mod_rewrite .
Access Log
- mod_log_config
- mod_setenvif
- CustomLog
- LogFormat
- SetEnvIf
The server access log records all requests processed by the server. The location and content of the access log are controlled by the CustomLog directive. The LogFormat directive can be used to simplify the selection of the contents of the logs. This section describes how to configure the server to record information in the access log.
Storing the information in the access log is only the start of log management. The next step is to analyze this information to produce useful statistics. Log analysis in general is beyond the scope of this document, and not really part of the job of the web server itself.
Various versions of Apache httpd have used other modules and directives to control access logging, including mod_log_referer, mod_log_agent, and the TransferLog directive. The CustomLog directive now subsumes the functionality of all the older directives.
The format of the access log is highly configurable. The format is specified using a format string that looks much like a C-style printf(1) format string. Some examples are presented in the next sections. For a complete list of the possible contents of the format string, see the mod_log_config format strings.
Common Log Format
A typical configuration for the access log might look as follows.
This defines the nickname common and associates it with a particular log format string. The format string consists of percent directives, each of which tell the server to log a particular piece of information. Literal characters may also be placed in the format string and will be copied directly into the log output. The quote character ( » ) must be escaped by placing a backslash before it to prevent it from being interpreted as the end of the format string. The format string may also contain the special control characters » \n » for new-line and » \t » for tab.
The CustomLog directive sets up a new log file using the defined nickname. The filename for the access log is relative to the ServerRoot unless it begins with a slash.
The above configuration will write log entries in a format known as the Common Log Format (CLF). This standard format can be produced by many different web servers and read by many log analysis programs. The log file entries produced in CLF will look something like this:
127.0.0.1 — frank [10/Oct/2000:13:55:36 -0700] «GET /apache_pb.gif HTTP/1.0» 200 2326
Each part of this log entry is described below.
127.0.0.1 ( %h ) This is the IP address of the client (remote host) which made the request to the server. If HostnameLookups is set to On , then the server will try to determine the hostname and log it in place of the IP address. However, this configuration is not recommended since it can significantly slow the server. Instead, it is best to use a log post-processor such as logresolve to determine the hostnames. The IP address reported here is not necessarily the address of the machine at which the user is sitting. If a proxy server exists between the user and the server, this address will be the address of the proxy, rather than the originating machine. — ( %l ) The «hyphen» in the output indicates that the requested piece of information is not available. In this case, the information that is not available is the RFC 1413 identity of the client determined by identd on the clients machine. This information is highly unreliable and should almost never be used except on tightly controlled internal networks. Apache httpd will not even attempt to determine this information unless IdentityCheck is set to On . frank ( %u ) This is the userid of the person requesting the document as determined by HTTP authentication. The same value is typically provided to CGI scripts in the REMOTE_USER environment variable. If the status code for the request (see below) is 401, then this value should not be trusted because the user is not yet authenticated. If the document is not password protected, this part will be » — » just like the previous one. [10/Oct/2000:13:55:36 -0700] ( %t ) The time that the request was received. The format is:
[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+’ | `-‘) 4*digit
It is possible to have the time displayed in another format by specifying %
Русские Блоги
2019 Unicorn Enterprise Стандарт набора для тяжелых инженеров Python >>> 
1. Журнал доступа не записывает статические файлы:
Большинство элементов сайта являются статическими файлами, такими как картинки, css, js и т. Д., Эти элементы не могут быть записаны.
1. Измените файл конфигурации виртуального хоста: /usr/local/apache2.4/conf/extra/httpd-vhosts.conf
Определите все запросы на доступ к формату изображения в качестве переменной img и исключите часть img в журнале доступа.
2. Перезагрузите файл конфигурации:
curl -x127.0.0.1:80 111.com/xxxxx -I
curl -x127.0.0.1:80 111.com/xxxxx.jpg -I
Выполните две вышеупомянутые команды, при нормальных обстоятельствах в /usr/local/apache2.4/logs/111.com-access.log журнале будут существовать только записи доступа xxxxx, доступ xxxxx.jpg не будет записан в журнал.
Во-вторых, доступ к журналу резки
Журнал всегда записывается, всегда будет время, когда диск заполнен, поэтому вы должны позволить журналу автоматически вырезать и удалить старый файл журнала.
1. Отредактируйте файл конфигурации виртуального хоста: /usr/local/apache2.4/conf/extra/httpd-vhosts.conf
2. Перезагрузите файл конфигурации:
3. Сотрудничайте с cron, чтобы регулярно удалять длинные журналы
В-третьих, время истечения статического элемента
Когда браузер обращается к веб-сайту, он кэширует статические файлы (такие как файлы изображений, файлы CSS, JS и т. Д.) На локальном компьютере, поэтому при следующем посещении вам не нужно загружать удаленно, вы можете настроить время для очистки кэша, то есть Установите время истечения статических элементов. Этот параметр можно использовать для оптимизации веб-сайтов, особенно интрасетей.
1. Отредактируйте файл конфигурации виртуального хоста: /usr/local/apache2.4/conf/extra/httpd-vhosts.conf
2. Проверьте, включен ли модуль expires, и перезагрузите файл конфигурации:
How can I limit the size of Apache's access_log, and limit the number of archived logs it keeps?
Apache’s access_log file rotates out into an archived copy around 1GB every few days. Where are the settings to control this? I’d like to be able to control both the max size and the number of archived logs it keeps around. Is this part of apache’s configuration, or do I need to write cron jobs ( et al ) to deal with this? I’m running pre-forked httpd.
5 Answers 5
On most Linux distributions, the system is set up to run logrotate on a daily basis. You won’t see it in the crontab for root or for any particular user.