pmlogger_daily - Интернет в облаке

ПРОГРАММА:

ИМЯ

pmlogger_check, pmlogger_daily, pmlogger_merge - администрация Performance Co-Pilot
архивировать файлы журнала

СИНТАКСИС

$ PCP_BINADM_DIR / pmlogger_check [-ЦНСТВ] [-c контроль] [-l журнальный файл]
$ PCP_BINADM_DIR / pmlogger_daily [-НорВ] [-c контроль] [-k отбрасывать] [-l журнальный файл] [-m
адреса] [-s размер] [-t хотеть] [-x сжимать] [-X программа] [-Y регулярное выражение]
$ PCP_BINADM_DIR / pmlogger_merge [-fNV] [ввод-базовое имя ... имя вывода]

ОПИСАНИЕ

Эта серия сценариев оболочки и связанные файлы управления могут использоваться для создания
настраиваемый режим администрирования и управления для Performance Co-Pilot (см.
PCPintro(1)) архивировать файлы журнала.

pmlogger_daily предназначен для запуска один раз в день, предпочтительно ранним утром, так как
вскоре после полуночи, насколько это возможно. Его задача - агрегировать и вращать один или несколько наборов
архивов PCP. По прошествии некоторого времени старые архивы PCP удаляются. Этот период 14
дней по умолчанию, но их можно изменить с помощью -k вариант. Признаны две особые ценности
на период (отбрасывать), а именно 0 не хранить архивы, кроме текущего, и навсегда
чтобы предотвратить сброс любых архивов.

Файлы архивных данных могут быть дополнительно сжаты через некоторое время для экономии места на диске.
Это особенно полезно для большого количества pmlogger процессы под контролем
pmlogger_check. По умолчанию сжатие не выполняется. В -x опция включает сжатие и
задает количество дней, по истечении которых необходимо сжимать файлы архивных данных, а -X вариант
указывает программу, используемую для сжатия - по умолчанию это xz(1). Использование -Y
опция позволяет указать регулярное выражение, вызывая файлы в наборе файлов
сопоставлено для сжатия, которое следует опустить - это позволяет сжимать только файл данных,
а также предотвращает попытки программы сжать его более одного раза. По умолчанию
регулярное выражение есть ". (meta | index | Z | gz | bz2 | zip | xz | lzma | lzo | lz4) $" - такие файлы фильтруются с помощью
-v вариант задать расширенное(1).

Чтобы приспособиться к эволюции PMDA и изменениям в производственных средах ведения журналов,
pmlogger_daily интегрирован с pmlogпереписать(1), чтобы разрешить необязательный и автоматический
перезапись архивов перед объединением. Если применяются глобальные правила перезаписи
во всех архивах, упомянутых в контрольном файле (ах), затем создайте каталог
$ PCP_SYSCONF_DIR / pmlogrewrite и разместить любой pmlogпереписать(1) правила переписывания в этом
каталог. Для правил перезаписи, относящихся только к одному семейству архивов, используйте
имя каталога из управляющего файла (ов) - т.е. четвертый поле - и создайте файл, или
каталог или символическая ссылка с именем pmlogпереписать в этом каталоге и поместите
требуемые правила перезаписи в pmlogпереписать файл или в файлах внутри pmlogпереписать
подкаталог. pmlogger_daily выберет правила перезаписи из каталога архива, если
они существуют, иначе правила переписываются из $ PCP_SYSCONF_DIR / pmlogrewrite если этот каталог
существует, иначе попытки перезаписи не предпринимаются.

Команда -r опция командной строки действует как переопределение и предотвращает перезапись всех архивов с помощью
pmlogпереписать(1) независимо от наличия каких-либо файлов или каталогов правил перезаписи.

По умолчанию все возможные архивы будут объединены. В -o вариант восстанавливает старый
поведение, при котором только вчерашние архивы будут рассматриваться как кандидаты на слияние.

В особом случае, когда нужно объединить только один входной архив, pmlogmv(1)
используется для переименования архива, а не для копирования входного архива с помощью pmlogger_merge.

Команда -M опция может использоваться для отключения слияния (или переименования) архивов и перезаписи (-M
подразумевает -r). Это наиболее полезно в тех случаях, когда архивы постепенно обновляются.
скопировано в удаленный репозиторий, например, используя Rsync(1). Слияние, переименование и перезапись всего
рискуют увеличить синхронизирующую нагрузку, особенно сразу после pmlogger_daily
бежал, так что -M может быть полезно в этих случаях.

Чтобы помочь с отладкой или диагностикой периодических отказов, -t опция может быть использована.
Это включит очень подробную трассировку (-ВВ) и записать вывод трассировки в файл с именем
$ PCP_LOG_DIR / pmlogger / daily.штамп с датой.след, в котором штамп с датой это время pmlogger_daily
был запущен в формате ГГГГММДД.ЧЧ.ММ. В дополнение хотеть аргумент будет гарантировать, что
файлы трассировки, созданные с помощью -t будет сохранен для хотеть дней, а затем выбросили.

Кроме того, если PCP `` извещает '' файл ($ PCP_LOG_DIR / УВЕДОМЛЕНИЯ) больше 20480
байты, pmlogger_daily переименует файл с суффиксом `` .old '' и начнет новый
файл `` уведомления ''. Порог поворота может быть изменен с 20480 на размер байтов с использованием
-s опцию.

Использование -m Вариант причины pmlogger_daily для создания резюме файла `` уведомлений ''
записи, которые были созданы за последние 24 часа, и отправьте это резюме по электронной почте в группу
разделенные пробелами адреса. Эта ежедневная сводка хранится в файле
$ PCP_LOG_DIR / NOTICES.daily, который будет пустым, если не было сделано новых `` уведомлений ''
за предыдущий 24-часовой период.

Сценарий $ PCP_BINADM_DIR / pmlogger_daily можно скопировать и изменить для реализации
специфическая для места процедура ведения в конце недели и / или в конце месяца для набора PCP
архивы.

pmlogger_check может быть запущен в любое время и предназначен для проверки того, что желаемый набор
pmlogger(1) процессы запущены, а если не перезапустить какие-либо вышедшие из строя регистраторы. Использование
-s опция обеспечивает обратную функциональность, позволяя набор pmlogger процессы, которые будут
чисто отключение. Использование -C опция запрашивает информацию об уровне запуска системной службы
для pmlogger, и использует это, чтобы определить, запускать или останавливать процессы.

Команда -T вариант обеспечивает более сжатую форму вывода для pmlogger_check это наиболее подходит
для pmlogger `` ферма '', где много экземпляров pmlogger ожидается, что они будут запущены.

pmlogger_merge сценарий-оболочка для pmlogextract(1), который объединяет все архивные журналы
соответствие ввод-базовое имя аргументы и создает новый архив, используя имя вывода как
базовое имя физических файлов, составляющих архивный журнал. В ввод-базовое имя
аргументы могут содержать метасимволы в стиле sh(1). Если указано, -f вариант
вызывает удаление всех входных файлов после создания выходного архива.

pmlogger_merge используется pmlogger_daily.

Оба формата pmlogger_daily и pmlogger_check контролируются управляющим файлом (ами) регистратора PCP, который
указывает на pmlogger экземпляры для управления. Контрольный файл по умолчанию -
$ PCP_PMLOGGERCONTROL_PATH, но можно указать альтернативный вариант с помощью -c вариант. Если
каталог $ PCP_PMLOGGERCONTROL_PATH.d (или контроль.d из -c вариант) существует, то
содержимое любых дополнительных управляющих файлов в нем будет добавлено к основному управляющему файлу.
(который должен существовать).

Предупреждение: $ PCP_PMLOGGERCONTROL_PATH и $ PCP_PMLOGGERCONTROL_PATH.d файлы не должны быть
доступен для записи любым пользователем, кроме root.

Контрольные файлы должны быть настроены в соответствии со следующими правилами, которые определяют для
текущая версия (1.1) формата управляющего файла.

1. Строки, начинающиеся с символа «#», являются комментариями.
2. Строки, начинающиеся с символа «$», считаются присвоениями переменных среды в
стиль sh(1), и весь текст после символа `` $ '' будет Evalпо сценарию
чтение управляющего файла и соответствующая переменная, экспортированная в
среда. Это особенно полезно для установки и экспорта переменных в
среда административных скриптов, например
$ PMCD_CONNECT_TIMEOUT = 20
3. Там должен быть строкой версии в исходном контрольном файле формы:
$ version = 1.1
4. В контрольном файле (файлах) должна быть одна строка для каждого pmlogger экземпляр
форма:

кашель y|n y|n каталог арг

5. Поля в строке контрольного файла (ов) обычно разделяются одним или несколькими
пробелы или табуляции (хотя см. описание каталог поле для некоторых
важные исключения).
6. первый поле - это имя хоста, который является источником показателей производительности.
для этого pmlogger пример.
7. второй поле указывает, является ли это первичный pmlogger пример (y) или нет (n).
Поскольку основной регистратор должен работать на локальном хосте, и может быть не более одного
первичный регистратор для конкретного хоста, это поле может быть y не более одного pmlogger
экземпляр, и в этом случае имя хоста должно быть именем локального хоста.
8. в третьих поле указывает, если это pmlogger экземпляр должен быть запущен под
контроль носки(1) для подключения к пмкд через брандмауэр (y or n).
9. четвертый поле - это имя каталога. Все файлы, связанные с этим pmlogger
экземпляр будет создан в этом каталоге, и это будет текущий каталог для
выполнение любых программ, необходимых для обслуживания этих архивов. Полезный
соглашение заключается в том, что первичные архивы регистратора для локального хоста с именем хоста MyHost
хранится в каталоге $ PCP_LOG_DIR / pmlogger /MyHost (здесь по умолчанию
pmlogger сценарий запуска в $ PCP_RC_DIR / pcp создаст архивы), а архивы
для удаленного хоста бормотать поддерживаются в $ PCP_LOG_DIR / pmlogger /бормотать.
10. Поле каталога может содержать встроенный синтаксис оболочки, который будет оцениваться sh(1)
для создания реального имени каталога, которое будет использоваться. Разрешенные конструкции:
· Любой текст (включая пробелы), заключенный в $( и ).
· Любой текст (включая пробелы), заключенный в ` и ` (обратные цитаты).
· Любой текст (включая пробелы), заключенный в " и " (двойные кавычки).
· Любое слово, содержащее $ (предполагается, что вводится имя переменной окружения).
11. Все остальные поля интерпретируются как аргументы, передаваемые в pmlogger(1) и / или
pmnewlog(1). Чаще всего это -c опцию.

В следующих образцах управляющих строк указывается основной регистратор на локальном хосте (бозо), а также расширение
неосновные регистраторы для сбора и регистрации показателей производительности с хостов шаткий и
Boing.

$ version = 1.1
bozo yn $ PCP_LOG_DIR / pmlogger / bozo -c config.default
wobbly nn "/ store / wobbly / $ (дата +% Y)" -c ./wobbly.config
boing nn $ PCP_LOG_DIR / pmlogger / boing -c ./pmlogger.config

типичный кронтаб(5) записи для периодического выполнения pmlogger_daily и pmlogger_check
приведены в $ PCP_SYSCONF_DIR / pmlogger / crontab (если не установлен по умолчанию в /etc/cron.d
уже) и показано ниже.

# ежедневная обработка архивных логов
14 0 * * * $ PCP_BINADM_DIR / pmlogger_daily
# каждые 30 минут проверять, запущены ли экземпляры pmlogger
25,55 * * * * $ PCP_BINADM_DIR / pmlogger_check

Чтобы гарантировать, что почта не будет случайно отправлена, когда эти сценарии запускаются из
крон(8) диагностика всегда отправляется в файл журнала. По умолчанию это файл
$ PCP_LOG_DIR / pmlogger / pmlogger_daily.log or $ PCP_LOG_DIR / pmlogger / pmlogger_check.log но
это можно изменить с помощью -l вариант. Если этот файл журнала уже существует, когда скрипт
начинается, он будет переименован с .пред суффикс (перезапись любого ранее сохраненного файла журнала)
перед диагностикой в ​​файл журнала. В -l и -t опции не могут быть использованы
одновременно.

Выход из крон выполнение скриптов может быть расширено с помощью -V вариант
скрипты, которые позволят детально отслеживать их действия. По умолчанию скрипты
не генерировать никаких выходных данных, если не возникнет какая-либо ошибка или условие предупреждения.

Используйте pmlogger_daily в Интернете с помощью сервисов onworks.net