Архивирование протоколов, логов при превышении размера


Содержание

архивация логов

есть каталог /var/log .

как с помощью с скрипта заархивировать логи старше, чем вчера, в папку /var/log/archive ?

логи имеют формат yyyy_mm_dd_name.log

2 ответа 2

главные трудности, видимо, следующие:

  1. отобрать только те файлы в текущем каталоге, имена которых соответствуют шаблону yyyy_mm_dd_name.log , где name — произвольный набор символов, не содержащий символа _
  2. исключить из отобранных те файлы, в именах которых часть yyyy_mm_dd соответствует сегодняшней или вчерашней дате
  3. что-то сделать с найденными файлами (например, переместить куда-нибудь)

решение:

отобрать в текущем каталоге такие файлы можно, например, так:

проверим, создав тестовые файлы (один содержит сегодняшнюю дату, один — вчерашнюю, один — позавчерашнюю, и один, контрольный, не содержит даты в имени):

чтобы исключить файлы, в имени которых содержится сегодняшняя или вчерашняя дата, надо добавить к опциям программы find такую примерно конструкцию:

тогда в вывод попадает только позавчерашний файл:

но завтра ведь даты будут другие. как привязаться к текущему дню?

с помощью программы date, например. сегодняшняя дата:

заключаем вызовы date в «операторные скобки» $(. ) , подставляем в нужные места, и получаем длинную команду:

для того, чтобы переместить найденные программой find файлы в каталог, например, /var/log/archive , можно добавить к опциям той же программы такую, например, конструкцию:

итого полный текст команды будет таким:

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

Не нужно писать собственное решение, когда уже есть различные готовые.

Автоматическая ротация и архивация логов

Предположим, вы хотите ротировать и архивировать логи приложения name

Конфигурация в файле /etc/logrotate.d/name :

Logrotate исключает необходимость приложению самостоятельно записывать дату в имя файла. Приложение может писать логи в один и тот же файл, который в момент ротации будет заменяться на новый. Если приложение самостоятельно не переоткрывает файл при записи каждой новой строки, то будет полезна опция copytruncate . С ней logrotate не пересоздает файлы логов, а вырезает содержимое и пишет его в новый файл.

Если по соображениям места на диске или полезности вы хотите хранить логи за последние N периодов ротации, то добавьте опцию rotate N . Например, за последнюю неделю:

Централизованное хранение логов.

Хранить важные логи прямо на хосте — это плохо, и вот почему:

  1. Там может быть недостаточно места. У меня был случай, когда логи заняли всё место и парализовали хост (к счастью, тестовый).
  2. Если всё совсем сломается, то логи будут очень нужны, а вы на них не посмотрите.
  3. Читать логи в текстовом редакторе или анализировать grep’ом — неэффективно.
  4. У этого способа масштабируемость хуже линейной. То есть чтобы следить за логами на вдвое большем количестве хостов вам понадобится более чем вдвое больше ресурсов (человекочасов и т.п.).

Логи должны храниться централизованно и в базе данных. Тогда:

  1. Вы можете получать оперативную аналитику
  2. Вы можете легко сравнивать логи между разными хостами, приложениями, периодами времени
  3. В случае поломки все или почти все логи будут вам доступны
  4. Масштабируемость примерно логарифмическая.

Есть ряд решений, одно из них — стек ELK (Elasticsearch, Logstash, Kibana).

Возможно, в данный момент для ваших задач достаточно простой ротации. Но, пожалуйста, ориентируйтесь на централизованное хранение.

Настройка параметров журнала событий

Вы можете управлять размером журналов событий, а также тем, как выполняется протоколирование. По умолчанию файлам журналов событий назначается максимальный размер. Когда журнал вырастает до этого предела, события начинают перезаписываться.

Чтобы задать параметры журнала, выполните следующие действия:

1. В диспетчере сервера разверните узлы Диагностика (Diagnostics) и Просмотр событий (Event Viewer).

2. Разверните узел Журналы Windows (Windows Logs) или Журналы приложений и службы (Applications And Services Logs).

3. Щелкните правой кнопкой журнал событий, параметры которого хотите изменить, и выберите в контекстном меню команду Свойства (Properties). Откроется диалоговое окно.

4. Введите максимальный размер журнала в килобайтах в поле Макс, размер журнала (Maximum Log Size). Убедитесь, что на диске ОС достаточно свободного пространства для заданного вами размера. По умолчанию файлы журналов хранятся в каталоге %SystemRoot%\System32\Winevt\Logs.

5. Задайте способ перезаписи журнала. Возможны следующие варианты:

Переписывать события при необходимости (Overwrite Events As Needed (OldestEvents First)) События в журнале перезаписываются при достижении максимального размера файла. Как правило, это оптимальный вариант для системы с невысоким приоритетом.

• Архивировать заполненный журнал, не переписывая события (Archive The Log When Full, Do Not Overwrite Events) При достижении максимального размера файла Windows архивирует события, сохраняя копию текущего журнала в панке по умолчанию. Затем создается новый журнал для сохранения текущих событий.

• Не переписывать события (очистить журнал вручную) (Do Not Overwrite Events (Clear Logs Manually)) При достижении максимального размера файла система пылает сообщение об ошибке с информацией о том, что журнал событий заполнен,

База знаний wiki

Продукты

Статьи

Содержание

logrotate — утилита для архивации log-файлов

Задача:

Решение:

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

При ротации логов — текущий log-файл с которым работает программа — удаляется или перемещается, поэтому после ротации лога, будет правильным перезапустить программу/сервис, чей log-файл был удален. Нужно это, что бы программе был сообщен новый дискриптор файла. Хотя это ситуация может разрулится автоматически и без перезагрузки — если такую ситуацию предусмотрели разработчики. Каждому архивному файлу присваивается номер, чем больше номер тем ‘старее’ архив.

Параметры запуска

Параметр Описание
-d debug — отладочный режим.
В режиме отладки не будут производиться изменения в log-файле и файле состояния
-f
–force
Принудительно произвести ротацию, даже если в данный момент она не требуется
-m
–mail
Указать команду для отправки почты.
Команда должна принимать два аргумента: тема сообщения и адрес получателя.
Текст письма передается стандартным вводом (stdin).
По умолчанию /usr/bin/mail -s
-s
–state
Указать куда записать файл состояния.
Что — то типа лога, показывает последнюю дату когда производилась ротация
(если создания архива не требуется правилами, то дата все ровно обновляется)
По умолчанию /var/lib/logrotate/status

Описание секции начинается с указания файлов над которыми будет производится ротация, а параметры указываются в фигурных скобах. Можно указывать по маске: или конкретные файлы Ротацию можно производить по расписанию (ежедневно, еженедельно …) или по достижению определенного размера log-файлом — это взаимоисключающие параметры.

Атоматическая ротация логов с помощью утилиты logrotate

Суббота, 3 января 2015


Некоторое время назад настроил на своем VPS один скрипт, который периодически выводит некоторую информацию из логов на существующий сайт… Что за скрипт и из каких именно журналов он читает информацию, я расписывать не буду — это не суть важно. Зато важно то, что через некоторое время сервер начал жесточайшим образом уходить в своп, и как следствие, заметно тормозить. Оказалось, что файл журнала (тот, из которого читалась информация) разрастался до многомегабайтных размеров, а скрипт отъедал заметные ресурсы ресурсы, то и дело считывая из него информацию…

Таким образом, мне пришлось настраивать logrotate в Линукс…

Чаще всего, разработчики той или иной программы под Linux сами заботятся о том, чтобы лог-файлы, создаваемые их программой сами чистили и архивировали свои журналы ежедневно (либо еженедельно/ежемесячно, либо в зависимости от размеров этих лог-файлов). И делают это обычно настройкой logrotate для своей программы.

Делается это для того, чтобы логи не разрастались до гигабайтных размеров и не забивали собой дисковое пространство. Ведь чаще всего необходимость рыться в журналах приходит в ближайшие часы или дни, или максимум недели, после некой поломки или проблемы. И кстати, как видно из моего примера, иногда большие размеры файлов могут не только занимать место на диске, но и вызывать торможение всей системы.

Таким образом, для этих целей и придумана утилита logrotate. Как, вероятно, сразу же понятно из названия, служит она для того, чтобы ротировать логи. Работает это так, что при определенных в конфигурационных файлах условиях (например, время или размер файла) файлы журналов, для которых эти условия прописаны, архивируются и журнал начинает писаться уже в новый файл. Также можно указывать количество хранимых архивов логов, после достижения которого старые файлы будут просто удаляться. При желании можно даже отправлять логи на почту…

Практически во всех готовых дистрибутивах logrotate уже установлен и включен, если же нет, то он точно доступен в основном репозитории.

Чаще всего, первичные настройки уже храняться в файле /etc/logrotate.conf . Также могут присутствовать специальные настройки для конкретных программ в директории /etc/logrotate.d/ . Для того, чтобы файлы из этой папки подхвативались утилитой logrotate, в основном файле должна иметься строчка:

Она указывает, что файлы из этой директории как бы прикрепляются к основному файлу настроек (так сказать, «инклюдятся»). Такой подход позволяет не лезть каждый раз в главный файл конфигурации и не выискивать там директивы для нужной программы среди множества других, а просто открывать нужный файл для нее и редактировать. Чтобы создать настройки для той или иной программы, нужно создать файл в этой директории, а чтобы отменить ротацию логов для конкретной программы, стоит всего лишь удалить файл (ну или сделать его недоступным для чтения).

Пример файла /etc/logrotate.conf :

# Запускаем ротацию еженедельно weekly # Оставляем три последних файла жирналов rotate 3 # Создаеем новый файл вместо архивированного create # Используем сжатие для устаревшего лог-файла compress # Подключаем файлы из указанной директории include /etc/logrotate.d # no packages own wtmp, or btmp — we’ll rotate them here /var/log/wtmp < missingok monthly create 0664 root utmp rotate 1 >/var/log/btmp

Пример файла /etc/logrotate.d/programma, где programma — имя программы, для журналов которой нужно произвести настройки:

Опции утилиты logrotate:

-d — (debug) активирует режим отладки, в котором включена также и опция -v; однако, в режиме отладки файлы системных сообщений, а также файл состояния logrotate, не подвергаются изменениям со стороны утилиты.

-v — (verbose) активирует режим вывода подробной информации о каждом действии утилиты.

-f — (force) принуждает logrotate произвести обращение журналов, даже если сама утилита не считает это необходимым. Иногда это полезно после добавления новых записей в logrotate или если старый файл журнала был удалён вручную; таким образом будут созданы новые файлы и журналирование будет корректно продолжено.

-m — (mail) указывает утилите, какую команду использовать для отправки журналов по электронной почте. Эта команда может принять два аргумента: тема письма и получатель. Команда должна читать сообщение со стандартного входа и отсылать его электронной почтой получателю. Командой по умолчанию является /bin/mail -s.

-s — (state) предписывает утилите использовать альтернативный файл состояния. Это полезно, если logrotate запускается от имени разных пользователей для разных наборов файлов системных сообщений. Файл состояния по умолчанию — /var/lib/logrotate/status.

-? — выводит краткую справку.

—usage — выводит информацию об использовании.

Далее представлена информация о директивах, которые могут быть указаны в конфигурационном файле logrotate (отсюда):

compress
Старые версии файлов журналов будут сжаты (по умолчанию gzip). См. также nocompress.

compresscmd
Позволяет указать команду для сжатия файлов журналов. По умолчанию gzip. См. также compress.

uncompresscmd
Директива позволяет указать команду для декомпрессии файлов журналов. По умолчанию gunzip.

compressext
Если используется сжатие, определяет расширение сжатых файлов журналов. По умолчанию определяется из настроек команды сжатия.

compressoptions
Программе сжатия может быть передана опция командной строки, если та их использует. Стандартно для gzip применяется «-9» (максимальное сжатие).

copy
Создать копию файла журнала, не изменяя оригинал вовсе. Этот параметр может быть использован, например, для создания моментального снимка (среза) текущего файла журнала, или когда некоторой другой утилите требуется обрезать или подчистить файл. При использовании этого параметра не имеет силы директива create, так как старый файл журнала остаётся на своём месте.

copytruncate
После создания копии, обрезать исходный файл журнала взамен перемещения старого файла журнала и создания нового. Это может найти применение в том случае, когда некоторой программе нельзя указать закрыть её журнал, и таким образом можно постоянно продолжать запись (добавление) в существующий файл журнала. Примите во внимание, что хотя между копированием файла и его обрезанием очень маленький промежуток времени, некоторая часть журналируемых данных может быть потеряна. При использовании этого параметра, не имеет силы директива create, так как старый файл журнала остаётся на своём месте.

create режим владелец группа
Непосредственно после обращения (перед выполнением скрипта postrotate) создать файл журнала (с тем же именем, что и только что сдвинутый журнал). Аргумент режим определяет режим доступа к файлу журнала в восьмеричном виде (единообразный с chmod(2)), владелец определяет имя пользователя, владеющего создаваемым файлом журнала, и группа определяет группу, к которой будет принадлежать файл журнала. Любые из этих атрибутов могут быть опущены; в этом случае вместо них для нового файла будут использованы атрибуты, имеющие те же значения, что и первоначальный файл журнала. Этот параметр может быть отключен использованием директивы nocreate.

daily
Ежедневное обращение файлов журналов.

delaycompress
Отложить сжатие предыдущего файла журнала до следующего циклического сдвига. Эта директива имеет силу только в комбинации с compress. Это может быть использовано в том случае, если некой программе нельзя указать закрыть её файл журнала, и таким образом, можно некоторое время продолжать запись в предыдущий файл журнала.

extension расширение
Файлы журналов после обращение получат заданное расширение. Если используется сжатие, то после указанного расширения программа сжатия добавит ещё одно (обычно .gz).

ifempty
Сдвигать файл журнала, даже если он пустой; это поведение можно изменить, применив директиву notifempty (по умолчанию активна ifempty).

include файл_или_каталог
Читает файл, переданный в качестве аргумента, так, как будто он включен построчно в тело конфигурационного файла с того места, где указана директива include. Если задан каталог, то содержащиеся в нём файлы будут прочитаны в алфавитном порядке, прежде чем переданы на обработку для включения. Файлы, не являющиеся обычными (такие как каталоги и именованные каналы), а также файлы, оканчивающиеся запрещёнными расширениями (определёнными параметром tabooext) — будут проигнорированы. Директива include не может использоваться внутри определения файла журнала.

mail адрес
По окончании цикла обращения журнал будет отправлен электронной почтой на адрес. Если для отдельных журналов это не требуется, то можно применить директиву nomail.

mailfirst
При использовании команды mail, посылать только что сдвинутый файл, а не закончивший цикл обращения файл журнала.

maillast
При использовании команды mail, посылать не только что сдвинутый файл, а закончивший цикл обращения файл журнала (это задано по умолчанию).

missingok
В случае отсутствия файла журнала перейти к обработке следующего не выдавая сообщения об ошибке. См. также nomissingok.

monthly
logrotate будет сдвигать файлы журналов раз в месяц (обычно первого числа каждого месяца).

nocompress
Не сжимать с помощью gzip старые версии файлов журналов. См. также compress.

nocopy
Не копировать исходный файл журнала и оставить его в штатном местоположении (это переопределяет параметр copy).

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

nocreate
Не создавать новый файл журнала (это переопределяет директиву create).

nodelaycompress
Не откладывать сжатие сдвинутого файла журнала до следующего цикла обращения (это переопределяет директиву delaycompress).

nomail
Не отправлять старые файлы журналов почтой.

nomissingok
Если файл журнала не существует, выдать ошибку. Это установлено по умолчанию.

noolddir
После обращения, журналы остаются в том же каталоге, где расположены текущие журналы (это переопределяет директиву olddir).

nosharedscripts
Выполнять скрипты prerotate и postrotate для каждого обработанного журнала (это поведение задано по умолчанию, его можно переопределить параметром sharedscripts).

notifempty
Не сдвигать журнал, если он пуст (это переопределяет параметр ifempty).

olddir directory
Переместить сдвинутые журналы в каталог. Заданный каталог должен размещаться на том же физическом устройстве, что и обращаемый файл журнала. При использовании этого параметра все старые версии журнала будут попадать в каталог. Этот параметр может быть переопределён параметром noolddir.

postrotate/endscript
Строки с директивами, находящиеся между postrotate и endscript (которые сами должны располагаться на отдельных строках), будут выполнены после обращения журнала. Эти директивы могут находиться только внутри определения файла журнала. См. также prerotate.

prerotate/endscript
Строки с директивами, находящиеся между prerotate и endscript (которые сами должны располагаться на отдельных строках), будут выполнены перед обращением журнала и только в случае если журнал действительно будет сдвинут. Эти директивы могут находиться только внутри определения файла журнала. См. также postrotate.

rotate раз
Файл журнала будет сдвинут заданное количество раз, прежде чем будет удалён или послан по электронной почте на адрес, указанный в директиве mail. Если указано 0 раз, то старый журнал вместо обращения будет удалён.

size размер
Файлы журналов будут сдвинуты, когда станут больше указанного размера в байтах. Если размер оканчивается символом M, то размер интерпретируется в мегабайтах. Если использовать k, то можно задать размер в килобайтах. Таким образом, директивы size 100, size 100k, и size 100M являются верными.

sharedscripts
Обычно скрипты prescript и postscript выполняются для каждого обрабатываемого журнала; это значит, что один и то же скрипт может выполняться несколько раз для одной конфигурационной записи, которая охватывает множество файлов (как в примере /var/log/news/*). Если параметр sharedscript указан, то скрипты будут выполнены только один раз, вне зависимости от количества журналов, подходящих под заданный шаблон. Однако если ни один из журналов, соответствующих шаблону, не требует обращения, то скрипты не будут выполнены вовсе. Этот параметр переопределяет директиву nosharedscripts.

start число
Заданное число — то, с которого начнётся счёт обращений. Например, если указать 0, после первого обращения (сдвига оригинального файла журнала) журналам будет присвоено расширение .0. Если указать 9, файлы журналов будут создаваться с расширением .9, пропустив 0-8. Файлы по-прежнему будут обращаться (сдвигаться) столько раз, сколько указано в директиве count.

tabooext [+] список_расширений
Изменяет текущий список запрещённых расширений (см. include). Если списку расширений предшествует знак +, то этот список прибавится к текущему, иначе заместит его. При первоначальном запуске список содержит следующие расширения: .rpmorig, .rpmsave, ,v, .swp, .rpmnew и

weekly
Файлы журналов будут сдвинуты, если текущий день недели меньше дня недели, в который произошло последнее обращение журнала, или если с тех пор прошло больше недели. Это почти то же самое, что и обращение журналов по понедельникам, но работает лучше, если logrotate не запускается каждую ночь.

PS: После внесения изменений для их применения рекомендуется выполнить в терминале от имени суперпользователя:

forum.lissyara.su

И один в поле воин, если он по-русски скроен

SQU >Проблемы с установкой, настройкой и работой системных и сетевых программ.

Модераторы: GRooVE, alexco


  • Отправить тему по email
  • Версия для печати

SQU > Пожаловаться на это сообщение
  • Цитата
  • Услуги хостинговой компании Host-Food.ru

    Re: SQU > Пожаловаться на это сообщение
  • Цитата
  • Re: SQU > Пожаловаться на это сообщение
  • Цитата
  • Универсальная ротация логов (может и не очень к месту, но может пригодиться):

    в /etc/newsyslog.conf добавить строку

    и перезагрузить newsyslog. Сохраняет файлы логов там же, просто меняет имя. (пример /var/log/messages)

    P.S. подправил пути файлов (может тоже неправильно, просто у меня сквида небыло)

    Re: SQU > Пожаловаться на это сообщение
  • Цитата
  • Re: SQU > Пожаловаться на это сообщение
  • Цитата
  • 30 — это сигнал USR1 (вроде 30)
    J — это указывает на то что старые логи должны сжиматься с использованием bzip2 (для gzip — Z)

    мой бэкапный демон берет логи (сжатые) по своему расписанию.

    Настройка Logrotate

    В Linux, большинство сервисов и программ, которые работают в фоне, таких как Apache, Nginx, Postfix и других записывают информацию о своем состоянии, результатах работы и ошибках в лог файлы. Стандартное расположение логов или как их еще называют — журналов — в папке /var/log.

    С помощью анализа логов вы можете понять что работает не так, почему произошла ошибка и как решить возникшую проблему. Но тот кроется одна проблема. Размер логов постоянно растет и они занимают все больше и больше места на диске, поэтому необходимо вовремя чистить логи и удалять устаревшие записи, чтобы они не мешали нормально работать. Это можно делать вручную время от времени или настроить скрипты Cron, но есть еще более простой вариант — утилита logrotate. В этой статье будет рассмотрена настройка logrotate и ее использование.

    Как работает Logrotate?

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

    Проверку условий можно настроить ежедневно, еженедельно или ежемесячно. Это позволяет создать схему ротации логов, удобную именно для вас и вашего сервера. Также ротация логов может быть полезна на домашнем компьютере, но здесь она не так важна как на серверах, где только в логи Apache могут записываться до сотен тысяч строк ежедневно.

    Настройка Logrotate

    Logrotate — это популярная утилита, поэтому в большинстве дистрибутивов она поставляется по умолчанию. Вы можете убедиться, что программа установлена в вашем дистрибутиве, попытавшись ее установить. Например, в CentOS:

    sudo yum install logrotate

    Или в Ubuntu и основанных на ней дистрибутивах:

    sudo apt install logrotate

    Теперь, даже если утилита не была установлена, вы ее установите. Все основные настройки программы находятся в файле /etc/logrotate.conf, дополнительные настройки, касаемо правил и других возможностей могут быть размещены в папке /etc/logroate.d/. Вы можете размещать все настройки logroatae прямо в основном конфигурационном файле, будет более правильно, если настройки для каждого отдельного сервиса будут находиться в отдельном файле, в папке /etc/logrotate.d/.

    Чтобы конфигурационные файлы из этой папки загружались программой, необходимо добавить в основной конфигурационный файл такую строчку:

    Просто убедитесь что она там уже есть. Сначала давайте рассмотрим основные директивы, которые мы будем применять во время настройки. Здесь директивы выглядят не совсем обычно, сама директива и определяет что и когда нужно делать, а уже если нужно, ей передаются дополнительные параметры. Чтобы указать как часто нужно выполнять проверку совпадению условий используются такие директивы:

    • hourly — каждый час;
    • daily — каждый день;
    • weekly — каждую неделю;
    • monthly — каждый месяц;
    • yearly — каждый год.

    Основные директивы управления и обработки логов:

    • rotate — указывает сколько старых логов нужно хранить, в параметрах передается количество;
    • create — указывает, что необходимо создать пустой лог файл после перемещения старого;
    • dateext — добавляет дату ротации перед заголовком старого лога;
    • compress — указывает, что лог необходимо сжимать;
    • delaycompress — не сжимать последний и предпоследний журнал;
    • extension — сохранять оригинальный лог файл после ротации, если у него указанное расширение;
    • mail — отправлять Email после завершения ротации;
    • maxage — выполнять ротацию журналов, если они старше, чем указано;
    • missingok — не выдавать ошибки, если лог файла не существует;
    • olddir — перемещать старые логи в отдельную папку;
    • postrotate/endscript — выполнить произвольные команды после ротации;
    • start — номер, с которого будет начата нумерация старых логов;
    • size — размер лога, когда он будет перемещен;

    Это те основные директивы, которые мы будем использовать. В главном конфигурационном файле находится глобальная конфигурация, директивы, которые будут распространяться на все логи если не было отменено их действие. Каждый лог, который подлежит ротации описывается таким образом:

    адрес_файла_лога <
    директивы
    >

    Теперь давайте создадим файл rsyslog.conf в папке /etc/logrotate.d/ и поместим в него настройки для ротации этого лога:

    /var/log/messages <
    daily
    rotate 3
    size 10M
    compress
    delaycompress
    >

    Эти настройки означают, что ротация журналов будет выполняться ежедневно, и мы будем хранить три последних журнала, более старые копии будут автоматически удаляться. Минимальный размер для ротации — 10 мегабайт, ротация не будет выполнена, если лог не занимает более 10 мегабайт. Будет использоваться сжатие, для всех журналов кроме последнего и предпоследнего. Точно по такому же принципу вы можете настроить ротацию логов для любого из журналов. Нужно создать такую секцию для каждого из логов, которыми вы хотите управлять.

    Теперь осталось протестировать как работает наша конфигурация. Для этого запустим утилиту logrotate с опцией -d. Она выведет все, что планируется сделать, но не будет изменять файлы на диске. У нас есть файл /var/log/messages, размером 40 Мегабайт, посмотрим что будет делать утилита:

    logrotate -d /etc/logrotate.d/rsyslog.conf

    Как видите, программа обнаруживает файл лога и разделяет его на несколько частей. Вы можете убедиться, что logrotate будет запускаться как положено проверив расписание cron:

    Настройка Logrotate завершена, а вам осталось всего лишь расписать как будет выполняться ротация логов для каждого из журналов, которые занимают много места.

    Выводы

    В этой статье мы рассмотрели как выполняется настройка logrotate centos или в любом другом дистрибутиве Linux. Работа утилиты не сильно отличается в зависимости от дистрибутивов. Если у вас есть сервер с большой нагрузкой, вам обязательно необходимо настроить ротацию логов. Надеюсь, эта информация была полезной для вас. На завершение видео, о том как выполняется ротация логов в Ubuntu от LPIC:


    Архивирование протоколов, логов при превышении размера

    Postgres Pro поддерживает несколько методов протоколирования сообщений сервера: stderr , csvlog и syslog . На Windows также поддерживается eventlog . В качестве значения log_destination указывается один или несколько методов протоколирования, разделённых запятыми. По умолчанию используется stderr . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

    Если в log_destination включено значение csvlog , то протоколирование ведётся в формате CSV (разделённые запятыми значения). Это удобно для программной обработки журнала. Подробнее об этом в Подразделе 18.8.4. Для вывода в формате CSV должен быть включён logging_collector.

    Примечание

    В большинстве систем Unix потребуется изменить конфигурацию системного демона syslog для использования варианта syslog в log_destination . Для указания типа протоколируемой программы (facility), Postgres Pro может использовать значения с LOCAL0 по LOCAL7 (см. syslog_facility). Однако, на большинстве платформ, конфигурация syslog по умолчанию не учитывает сообщения подобного типа. Чтобы это работало, потребуется добавить в конфигурацию демона syslog что-то подобное:

    Для использования eventlog в log_destination на Windows, необходимо зарегистрировать источник событий и его библиотеку в операционной системе. Тогда Windows Event Viewer сможет отображать сообщения журнала событий. Подробнее в Разделе 17.11.

    Параметр включает сборщик сообщений ( logging collector). Это фоновый процесс, который собирает отправленные в stderr сообщения и перенаправляет их в журнальные файлы. Такой подход зачастую более полезен чем запись в syslog , поскольку некоторые сообщения в syslog могут не попасть. (Типичный пример с сообщениями об ошибках динамического связывания, другой пример — ошибки в скриптах типа archive_command .) Для установки параметра требуется перезапуск сервера.

    Примечание

    Можно обойтись без сборщика сообщений и просто писать в stderr . Сообщения будут записываться в место, куда направлен поток stderr . Такой способ подойдёт только для небольших объёмов протоколирования, потому что не предоставляет удобных средств для организации ротации журнальных файлов. Кроме того, на некоторых платформах отказ от использования сборщика сообщений может привести к потере или искажению сообщений, так как несколько процессов, одновременно пишущих в один журнальный файл, могут перезаписывать информацию друг друга.

    Примечание

    Сборщик спроектирован так, чтобы сообщения никогда не терялись. А это значит, что при очень высокой нагрузке, серверные процессы могут быть заблокированы при попытке отправить сообщения во время сбоя фонового процесса сборщика. В противоположность этому, syslog предпочитает удалять сообщения, при невозможности их записать. Поэтому часть сообщений может быть потеряна, но система не будет блокироваться.

    При включённом logging_collector , определяет каталог, в котором создаются журнальные файлы. Можно задавать как абсолютный путь, так и относительный от каталога данных кластера. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. Значение по умолчанию pg_log . log_filename ( string )

    При включённом logging_collector задаёт имена журнальных файлов. Значение трактуется как строка формата в функции strftime , поэтому в ней можно использовать спецификаторы % для включения в имена файлов информации о дате и времени. (При наличии зависящих от часового пояса спецификаторов % будет использован пояс, заданный в log_timezone.) Поддерживаемые спецификаторы % похожи на те, что перечислены в описании strftime спецификации Open Group. Обратите внимание, что системная функция strftime напрямую не используется. Поэтому нестандартные, специфичные для платформы особенности не будут работать. Значение по умолчанию postgresql-%Y-%m-%d_%H%M%S.log .

    Если для задания имени файлов не используются спецификаторы % , то для избежания переполнения диска, следует использовать утилиты для ротации журнальных файлов. В версиях до 8.4, при отсутствии спецификаторов % , PostgreSQL автоматически добавлял время в формате Epoch к имени файла. Сейчас в этом больше нет необходимости.

    Если в log_destination включён вывод в формате CSV, то к имени журнального файла будет добавлено расширение .csv . (Если log_filename заканчивается на .log , то это расширение заменится на .csv .)

    Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_file_mode ( integer )

    В системах Unix задаёт права доступа к журнальным файлам, при включённом logging_collector . (В Windows этот параметр игнорируется.) Значение параметра должно быть числовым, в формате команд chmod и umask . (Для восьмеричного формата, требуется задать лидирующий 0 (ноль).)

    Права доступа по умолчанию 0600 , т. е. только владелец сервера может читать и писать в журнальные файлы. Также, может быть полезным значение 0640 , разрешающее чтение файлов членам группы. Однако, чтобы установить такое значение, нужно каталог для хранения журнальных файлов (log_directory) вынести за пределы каталога данных кластера. В любом случае нежелательно открывать для всех доступ на чтение журнальных файлов, так как они могут содержать конфиденциальные данные.

    Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_rotation_age ( integer )

    Определяет максимальное время жизни отдельного журнального файла, при включённом logging_collector . После того как прошло заданное количество минут, создаётся новый журнальный файл. Для запрета создания нового файла по прошествии определённого времени, нужно установить значение 0. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. log_rotation_size ( integer )

    Определяет максимальный размер отдельного журнального файла, при включённом logging_collector . После того как заданное количество килобайт записано в текущий файл, создаётся новый журнальный файл. Для запрета создания нового файла при превышении определённого размера, нужно установить значение 0. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_truncate_on_rotation ( boolean )

    Если параметр logging_collector включён, Postgres Pro будет перезаписывать существующие журнальные файлы, а не дописывать в них. Однако, перезапись при переключении на новый файл возможна только в результате ротации по времени, но не при старте сервера или ротации по размеру файла. При выключенном параметре всегда продолжается запись в существующий файл. Например, включение этого параметра в комбинации с log_filename равным postgresql-%H.log , приведёт к генерации 24-х часовых журнальных файлов, которые циклически перезаписываются. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

    Пример: для хранения журнальных файлов в течение 7 дней, по одному файлу на каждый день с именами вида server_log.Mon , server_log.Tue и т. д., а также с автоматической перезаписью файлов прошлой недели, нужно установить log_filename в server_log.%a , log_truncate_on_rotation в on и log_rotation_age в 1440 .

    Пример: для хранения журнальных файлов в течение 24 часов, по одному файлу на час, с дополнительной возможностью переключения файла при превышения 1ГБ, установите log_filename в server_log.%H%M , log_truncate_on_rotation в on , log_rotation_age в 60 и log_rotation_size в 1000000 . Добавление %M в log_filename позволит при переключении по размеру указать другое имя файла в пределах одного часа. syslog_facility ( enum )

    При включённом протоколировании в syslog , этот параметр определяет значение « facility » . Допустимые значения LOCAL0 , LOCAL1 , LOCAL2 , LOCAL3 , LOCAL4 , LOCAL5 , LOCAL6 , LOCAL7 . По умолчанию используется LOCAL0 . Подробнее в документации на системный демон syslog . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. syslog_ident ( string )

    При включённом протоколировании в syslog , этот параметр задаёт имя программы, которое будет использоваться в syslog для идентификации сообщений относящихся к Postgres Pro . По умолчанию используется postgres . Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. event_source ( string )

    При включённом протоколировании в event log , этот параметр задаёт имя программы, которое будет использоваться в журнале событий для идентификации сообщений относящихся к Postgres Pro . По умолчанию используется Postgres Pro . Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера.

    18.8.2. Когда протоколировать

    Управляет минимальным уровнем сообщений, записываемых в журнал сервера. Допустимые значения DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . Каждый из перечисленных уровней включает все идущие после него. Чем дальше в этом списке уровень сообщения, тем меньше сообщений будет записано в журнал сервера. По умолчанию используется WARNING . Обратите внимание, позиция LOG здесь отличается от принятой в client_min_messages. Только суперпользователи могут изменить этот параметр. log_min_error_statement ( enum )

    Управляет тем, какие SQL-операторы, завершившиеся ошибкой, записываются в журнал сервера. SQL-оператор будет записан в журнал, если он завершится ошибкой с указанным уровнем важности или выше. Допустимые значения: DEBUG5 , DEBUG4 , DEBUG3 , DEBUG2 , DEBUG1 , INFO , NOTICE , WARNING , ERROR , LOG , FATAL и PANIC . По умолчанию используется ERROR . Это означает, что в журнал сервера будут записаны все операторы, завершившиеся сообщением с уровнем важности ERROR , LOG , FATAL и PANIC . Чтобы фактически отключить запись операторов с ошибками, установите для этого параметра значение PANIC . Изменить этот параметр могут только суперпользователи. log_min_duration_statement ( integer )

    Записывает в журнал продолжительность выполнения всех команд, время работы которых равно или превышает указанное количество миллисекунд. Значение 0 (ноль) заставляет записывать продолжительность работы всех команд. Значение -1 (по умолчанию) запрещает регистрировать продолжительность выполнения операторов. Например, при значении 250ms , все команды, которые выполняются за 250 миллисекунд и дольше будут записаны в журнал сервера. Включение параметра полезно для выявления плохо оптимизированных запросов в приложении. Только суперпользователи могут изменить этот параметр.

    Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.

    Примечание

    При использовании совместно с log_statement, текст SQL-операторов будет записываться только один раз (от использования log_statement ) и не будет задублирован в сообщении о длительности выполнения. Если не используется вывод в syslog , то рекомендуется в log_line_prefix включить идентификатор процесса или сессии. Это позволит связать текст запроса с записью о продолжительности выполнения, которая появится позже.

    В Таблице 18.1 поясняются уровни важности сообщений в Postgres Pro . Также в этой таблице показано, как эти уровни транслируются в системные при использовании syslog или eventlog в Windows.

    Таблица 18.1. Уровни важности сообщений

    Уровень Использование syslog eventlog
    DEBUG1..DEBUG5 Более детальная информация для разработчиков. Чем больше номер, тем детальнее. DEBUG INFORMATION
    INFO Неявно запрошенная пользователем информация, например вывод команды VACUUM VERBOSE . INFO INFORMATION
    NOTICE Информация, которая может быть полезной пользователям. Например, уведомления об усечении длинных идентификаторов. NOTICE INFORMATION
    WARNING Предупреждения о возможных проблемах. Например, COMMIT вне транзакционного блока. NOTICE WARNING
    ERROR Сообщает об ошибке, из-за которой прервана текущая команда. WARNING ERROR
    LOG Информация, полезная для администраторов. Например, выполнение контрольных точек. INFO INFORMATION
    FATAL Сообщает об ошибке, из-за которой прервана текущая сессия. ERR ERROR
    PANIC Сообщает об ошибке, из-за которой прерваны все сессии. CRIT ERROR

    18.8.3. Что протоколировать

    application_name это любая строка, не превышающая NAMEDATALEN символов (64 символа при стандартной сборке). Обычно устанавливается приложением при подключении к серверу. Значение отображается в представлении pg_stat_activity и добавляется в журнал сервера, при использовании формата CSV. Для прочих форматов, application_name можно добавить в журнал через параметр log_line_prefix. Значение application_name может содержать только печатные ASCII символы. Остальные символы будут заменены знаками вопроса ( ? ). debug_print_parse ( boolean )
    debug_print_rewritten ( boolean )
    debug_print_plan ( boolean )

    Эти параметры включают вывод различной отладочной информации. А именно: вывод дерева запроса, дерево запроса после применения правил или плана выполнения запроса, соответственно. Все эти сообщения имеют уровень LOG . Поэтому, по умолчанию, они записываются в журнал сервера, но не отправляются клиенту. Отправку клиенту можно настроить через client_min_messages и/или log_min_messages. По умолчанию параметры выключены. debug_pretty_print ( boolean )

    Включает выравнивание сообщений, выводимых debug_print_parse , debug_print_rewritten или debug_print_plan . В результате сообщения легче читать, но они значительно длиннее, чем в формате « compact » , который используется при выключенном значении. По умолчанию включён. log_checkpoints ( boolean )

    Включает протоколирование выполнения контрольных точек и точек перезапуска сервера. При этом записывается некоторая статистическая информация. Например, число записанных буферов и время, затраченное на их запись. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. По умолчанию выключен. log_connections ( boolean )

    Включает протоколирование всех попыток подключения к серверу, в том числе успешного завершения аутентификации клиентов. Изменить его можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off .

    Примечание

    Некоторые программы, например psql , предпринимают две попытки подключения (первая для определения, нужен ли пароль). Поэтому дублирование сообщения « connection received » не обязательно говорит о наличии проблемы.

    Включает протоколирование завершения сеанса. В журнал выводится примерно та же информация, что и с log_connections , плюс длительность сеанса. Изменить этот параметр можно только в начале сеанса и сделать это могут только суперпользователи. Значение по умолчанию — off . log_duration ( boolean )

    Записывает продолжительность каждой завершённой команды. По умолчанию выключен. Только суперпользователи могут изменить этот параметр.

    Для клиентов, использующих расширенный протокол запросов, будет записываться продолжительность фаз: разбор, связывание и выполнение.

    Примечание

    Включение этого параметра не равнозначно установке нулевого значения для log_min_duration_statement. Разница в том, что при превышении значения log_min_duration_statement в журнал записывается текст запроса, а при включении данного параметра — нет. Таким образом при log_duration = on и положительном значении log_min_duration_statement в журнал записывается длительность всех команд, а текст запросов — только для команд с длительностью, превысившей предел. Такое поведение может оказаться полезным при сборе статистики в условиях большой нагрузки.

    Управляет количеством детальной информации, записываемой в журнал сервера для каждого сообщения. Допустимые значения: TERSE , DEFAULT и VERBOSE . Каждое последующее значение добавляет больше полей в выводимое сообщение. Для TERSE из сообщения об ошибке исключаются поля DETAIL , HINT , QUERY и CONTEXT . Для VERBOSE в сообщение включается код ошибки SQLSTATE (см. Приложение A), а также имя файла с исходным кодом, имя функции и номер строки сгенерировавшей ошибку. Только суперпользователи могут изменить этот параметр. log_hostname ( boolean )

    По умолчанию, сообщения журнала содержат лишь IP-адрес подключившегося клиента. При включении этого параметра, дополнительно будет фиксироваться и имя сервера. Обратите внимание, что в зависимости от применяемого способа разрешения имён, это может отрицательно сказаться на производительности. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера. log_line_prefix ( string )

    Строка, в стиле функции printf , которая выводится в начале каждой строки журнала сообщений. С символов % начинаются управляющие последовательности, которые заменяются статусной информацией, описанной ниже. Неизвестные управляющие последовательности игнорируются. Все остальные символы напрямую копируются в журнальную строку. Некоторые управляющие последовательности используются только для пользовательских процессов и будут игнорироваться фоновыми процессами, например основным процессом сервера. Подставляемая информация может быть выровнена по ширине влево или вправо указанием числа после % и перед кодом последовательности. Отрицательное число дополняет значение пробелами справа, а положительное число дополняет пробелами слева. Выравнивание можно использовать для улучшения читаемости. Параметр можно задать только в конфигурационных файлах или в командной строке при запуске сервера. По умолчанию используется пустая строка.

    Спецсимвол Назначение Только для пользовательского процесса
    %a Имя приложения (application_name) да
    %u Имя пользователя да
    %d Имя базы данных да
    %r Имя удалённого узла или IP-адрес, а также номер порта да
    %h Имя удалённого узла или IP-адрес да
    %p Идентификатор процесса нет
    %t Штамп времени, без миллисекунд нет
    %m Штамп времени, с миллисекундами нет
    %i Тег команды: тип текущей команды в сессии да
    %e Код ошибки SQLSTATE нет
    %c Идентификатор сессии. Подробности ниже нет
    %l Номер строки журнала для каждой сессии или процесса. Начинается с 1 нет
    %s Штамп времени начала процесса нет
    %v Идентификатор виртуальной транзакции (backendID/localXID) нет
    %x Идентификатор транзакции (0 если не присвоен) нет
    %q Ничего не выводит. Непользовательские процессы останавливаются в этой точке. Игнорируется пользовательскими процессами нет
    %% Выводит % нет

    %c выводит псевдоуникальный номер сессии, состоящий из двух 4-х битных шестнадцатеричных чисел (без лидирующих нулей), разделённых точкой. Эти числа представляют собой время старта процесса и идентификатор процесса, поэтому %c можно использовать для экономии места при записи этих значений. Например, для получения идентификатора сессии из pg_stat_activity , используйте запрос:

    Подсказка

    Последним символом в log_line_prefix лучше оставлять пробел, чтобы отделить от остальной строки. Можно использовать и символы пунктуации.

    Подсказка

    Syslog также формирует штамп времени и идентификатор процесса, поэтому вероятно нет смысла использовать соответствующие управляющие последовательности при использовании syslog .

    Определяет, нужно ли фиксировать в журнале события, когда сеанс ожидает получения блокировки дольше, чем указано в deadlock_timeout. Это позволяет выяснить, не связана ли низкая производительность с ожиданием блокировок. По умолчанию отключено. Только суперпользователи могут изменить этот параметр. log_statement ( enum )

    Управляет тем, какие SQL-команды записывать в журнал. Допустимые значения: none (отключено), ddl , mod и all (все команды). ddl записывает все команды определения данных, такие как CREATE , ALTER , DROP . mod записывает все команды ddl , а также команды изменяющие данные, такие как INSERT , UPDATE , DELETE , TRUNCATE и COPY FROM . PREPARE , EXECUTE и EXPLAIN ANALYZE также записываются, если вызваны для команды соответствующего типа. Если клиент использует расширенный протокол запросов, то запись происходит на фазе выполнения и содержит значения всех связанных переменных (если есть символы одиночных кавычек, то они дублируются).

    По умолчанию none . Только суперпользователи могут изменить этот параметр.


    Примечание

    Команды с синтаксическими ошибками не записываются, даже если log_statement = all , так как сообщение формируется только после выполнения предварительного разбора, определяющего тип команды. При расширенном протоколе запросов, похожим образом не будут записываться команды, неуспешно завершившиеся до фазы выполнения (например, при разборе или построении плана запроса). Для включения в журнал таких команд установите log_min_error_statement в ERROR (или ниже).

    Включает запись в журнал сервера всех команд репликации. Подробнее о командах репликации можно узнать в Разделе 50.3. Значение по умолчанию — off . Изменить этот параметр могут только суперпользователи. log_temp_files ( integer )

    Управляет включением в журнал информации об именах и размерах временных файлов. Временные файлы могут использоваться для сортировок, хеширования и временного хранения результатов запросов. На каждый временный файл, при его удалении, в журнал записывается отдельное сообщение. Значение 0 говорит о том, что нужно записывать информацию о всех временных файлах. Положительное значение задаёт размер временных файлов в килобайтах, при достижении или превышении которого, информация о временном файле будет записана. Значение по умолчанию -1, что отключает запись информации о временных файлах. Только суперпользователи могут изменить этот параметр. log_timezone ( string )

    Устанавливает часовой пояс для штампов времени при записи в журнал сервера. В отличие от TimeZone, это значение одинаково для всех баз данных кластера, поэтому для всех сессий используются согласованные значения штампов времени. Встроенное значение по умолчанию GMT , но оно переопределяется в postgresql.conf : initdb записывает в него значение, соответствующее системной среде. Подробнее об этом в Подразделе 8.5.3. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

    18.8.4. Использование вывода журнала в формате CSV

    Добавление csvlog в log_destination делает удобным загрузку журнальных файлов в таблицу базы данных. Строки журнала представляют собой значения разделённые запятыми (CSV формат) со следующими полями: штамп времени с миллисекундами; имя пользователя; имя базы данных; идентификатор процесса; клиентский узел:номер порта; идентификатор сессии; номер строки каждой сессии; тег команды; время начала сессии; виртуальный идентификатор транзакции; идентификатор транзакции; уровень важности ошибки; код ошибки SQLSTATE; сообщение об ошибке; подробности к сообщению об ошибке; подсказка к сообщению об ошибке; внутренний запрос, приведший к ошибке (если есть); номер символа внутреннего запроса, где произошла ошибка; контекст ошибки; запрос пользователя, приведший к ошибке (если есть и включён log_min_error_statement ); номер символа в запросе пользователя, где произошла ошибка; расположение ошибки в исходном коде Postgres Pro (если log_error_verbosity установлен в verbose ) и имя приложения. Вот пример определения таблицы, для хранения журналов в формате CSV:

    Для загрузки журнального файла в такую таблицу можно использовать команду COPY FROM :

    Для упрощения загрузки журналов в CSV формате используйте следующее:

    Установите для log_filename и log_rotation_age значения, гарантирующие согласованную и предсказуемую схему именования журнальных файлов. Зная, какие имена будут у журнальных файлов, можно определить, когда конкретный файл заполнен и готов к загрузке.

    Установите log_rotation_size в 0, чтобы запретить ротацию файлов по достижении определённого размера, так как это делает непредсказуемой схему именования журнальных файлов.

    Установите log_truncate_on_rotation в on , чтобы новые сообщения не смешивались со старыми при переключении на существующий файл.

    Определение таблицы содержит первичный ключ. Это полезно для предотвращения случайной повторной загрузки данных. Команда COPY фиксирует изменения один раз, поэтому любая ошибка приведёт к отмене всей загрузки. Если сначала загрузить неполный журнальный файл, то его повторная загрузка (по заполнении) приведёт к нарушению первичного ключа и, следовательно, к ошибке загрузки. Поэтому необходимо дожидаться окончания записи в журнальный файл перед началом загрузки. Похожим образом предотвращается случайная загрузка частично сформированной строки сообщения, что также приведёт к сбою в команде COPY .

    18.8.5. Заголовок процесса

    Эти параметры управляют тем, как команда ps будет видеть заголовок процесса. За подробностями обратитесь к Разделу 27.1.

    Задаёт имя кластера, которое отображается в заголовке процесса для всех процессов данного кластера. Это имя может быть любой строкой не длиннее NAMEDATALEN символов (64 символа в стандартной сборке). В строке cluster_name могут использоваться только печатаемые ASCII-символы. Любой другой символ будет заменён символом вопроса ( ? ). Если этот параметр содержит пустую строку » (это значение по умолчанию), никакое имя не выводится. Этот параметр можно задать только при запуске сервера.

    Заголовок процесса обычно можно наблюдать в программах типа ps , а в Windows — в Process Explorer . update_process_title ( boolean )

    Включает изменение заголовка процесса при получении сервером каждой очередной команды SQL. Заголовок процесса виден в выводе команды ps , а в Windows он показывается в Диспетчере задач . Изменить этот параметр могут только суперпользователи.

    Архивация логов

    Windows Batch file
    Windows Batch file
    24.08.2015, 17:18

    Запись логов
    Привет. Есть скрипт: проверка наличия VPN каждые 5 мин. в случае отсутствия оного -.

    Очистка логов Windows
    Можно ли очистить логи Windows через батник ?

    Просмотр логов печати.
    Здравствуйте, интересует такой вопрос, возможно ли где нибудь проглядеть файлы которые были.

    Выполнение tracert и запись логов
    Добрый день. Нужна помощь в написании bat файла. Что должно д.б.: 1. проверка, есть файл.

    Запись логов подключения к сетям
    Доброго времени суток, уважаемые. Недавно на нашем маленьком захалустно-провинциальном.

    Архивирование протоколов, логов при превышении размера

    Ключ -ILOG[имя] — записывать протокол ошибок в файл

    Записывать сообщения произошедших при работе ошибок в файл rar.log , создаваемый в папке WinRAR. Вы можете просмотреть содержимое этого файла командой » Просмотр протокола » в меню «Параметры». Вместо принимаемого по умолчанию файла rar.log вы можете указать другое имя файла, например:

    Если в указанном имени не содержится путь, файл с протоколом будет создан в папке %APPDATA%\WinRAR.

    Как посмотреть логи?

    Пользователям доступны следующие логи:

    Логи доступа (access_log)

    Включить данные логи можно в разделе «Log файлы» Панели управления аккаунтом. В этих логах содержится информация о посещениях сайта пользователями сети Интернет.

    • domen.ru — имя домена, т.е имя сервера, записанное в формате, определенным директивой UseCanonicalName;
    • 127.0.0.1 — удаленный хост, т.е. IP-адрес посетителя;
    • «-» — идентификатор клиента (записывается, если включена директива IndentyCheck и клиент предоставил данные для идентификации);
    • «-» — имя удаленного пользователя, если запрос требовал аутентификации HTTP;
    • [07/Aug/2013:23:04:22 +0000] — дата и время запроса;
    • GET /index.html HTTP/1.1 — первая строка запроса;
    • 200 — последний статус ответа сервера, если имели место внутренние перенаправления запроса (в данном случае успешное обращение);
    • 198 — размер ответа сервера в байтах, исключая HTTP-заголовки (если ответ сервера равнялся 0 байтов, то вместо 0 записывается прочерк «-«);
    • «http://domen.ru/» «Mozilla/5.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1) — значение заголовка с именем header в запросе;
    • 16143 — PID процесса apache, выполняющего запрос.
    • 0 — время работы процесса apache.

    Обращаем внимание, что параметры, не имеющие значения, обозначаются в логах в виде «-«

    Логи ошибок (error_log)

    Включить данные логи можно в разделе «Log файлы» Панели управления аккаунтом.
    В данные логи записываются ошибки Apache и всех его модулей, например, ошибки доступа или отсутствия файла на аккаунте, или же ошибки обработки mod_rewrite.

    В логах указывается имя домена, к которому было зафиксировано обращение, время обращения, IP-адрес, с которого была произведена попытка доступа и, непосредственно, текст ошибки.

    Для того, чтобы в логах ошибок выводились ошибки php, необходимо прописать в файл .htaccess аккаунта следующие директивы:

    Путь к файлу логов можно увидеть в разделе «Log файлы» Панели управления аккаунтом. Имеет вид:
    ► /home/d/domen/error_log

    FTP логи

    FTP логи могут быть предоставлены по запросу в службу технической поддержки. В них отражены действия с аккаунтом, которые производились по FTP. Логи помещаются в корневую папку аккаунта и состоят из двух файлов с именами вида vsftpd.log и xferlog.

    • В файле vsftpd.log содержатся логи FTP-сессий (вход/выход).
    • В файле xferlog содержится информация о действиях, которые производились с файлами.

    Пример записи в файле vsftpd.log:

    Здесь указавается три основных параметра:

    • Sun Jan 19 15:17:05 2014 — дата и время входа пользователя;
    • login — логин пользователя;
    • 100.0.0.2 — IP-адрес, с которого осуществлялся доступ.

    Обращаем внимание, что запись с IP-адресом 192.168.1.254 означает, что вход осуществлялся через файловый менеджер из Панели управления аккаунтом.

    Пример записи в файле xferlog:

    • Tue Jan 21 15:56:06 2014 — дата и время;
    • 34181 — размер файла;
    • test.txt — имя файла;
    • b _ o r — операции, произведенные с файлами;
    • login — логин пользователя, который выполнял действия.

    Операции с файлами («b _ o r») имеют четыре параметра:

    1. Тип передачи: a – текстовый (ascii) b – бинарный. В данном случае b.
    2. Метка особых действий, С – файл был сжат (compressed), U – файл был распакован (uncompressed), T – файл был заархивирован (в tar), «_» особых действий не было. На данном примере: «_» – особых действий не было.
    3. Направление: o – исходящее, i – входящее, d – удаление. На данном примере: o – исходящее, т.е файл загружался с сервера.
    4. Pежим доступа: a – анонимный, r – с регистрацией. На данном примере: r – с регистрацией, был осуществлён вход по логину и паролю.

    Логи операций Панели управления

    В разделе «Логи операций» Панели управления аккаунтом можно просмотреть действия, которые совершались в ПУ аккаунта, а также с каких IP-адресов производился доступ. Данные логи доступны за весь период существования аккаунта.

    В записи указывается номер операции в нашей системе, описание, имя пользователя и дата.

    Анализ логов при превышении нагрузки

    Если причина превышения не очевидна — можно попробовать произвести анализ имеющихся логов запросов к сайту. Например, для определения страниц сайта, на которые производилось самое большое количество запросов за текущий день, подключиться к серверу по протоколу SSH и выполнить такую команду:

    Похожим образом можно выявить аномально большое количество запросов с какого-либо одного IP-адреса:

    Для просмотра данных за прошлые числа в командах необходимо заменить подстроку :

    Если на аккаунте не было включено ведение логов access_log, то можно включить их запись в разделе «Log файлы», а логи запросов за прошедшие дни можно получить по заявке в отдел технической поддержки.

    Не нашли ответ на свой вопрос? Позвоните нашим специалистам по бесплатному телефону 8-800-100-16-15.

    Илон Маск рекомендует:  Что такое код asp notifyendofnetsession
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL