пятница, 2 августа 2013 г.

Мониторинг веб-сервера Nginx c помощью zabbix trapper



   Рассмотрим случай, когда требуется настроить мониторинг сервера по множеству однотипных или динамических метрик, которые отсутствуют в zabbix-агенте.
   В такой ситуации в zabbix-агенте можно создавать ключи для проверки с помощью параметра конфигурации - UserParameter. Для каждого параметра в zabbix_agentd.conf создаётся строка вида:

UserParameter=<key>,<shell command>


   Однако, если значений слишком много, такой способ может оказаться не удобным.
Второй способ заключается в использовании элемента данных zabbix типа trapper (zabbix-ловушки). Принцип очень простой: в zabbix-сервере создаются элементы данных этого типа с произвольным именем ключа. Затем, с помощью утилиты zabbix_sender формируется специальный запрос, в котором указывается ключ ловушки, значение параметра и имя хоста. Если параметров много, то можно сформировать файл в формате zabbix_sender и отправить все значения из файла за одно соединение с сервером.
Строки в файле должны быть оформлены в таком виде:
- <ключ> <значение> (дефис в начале строки обязателен)
или
<имя_хоста> <ключ> <значение>


   Рассмотрим, как использовать эту возможность на примере мониторинга популярного веб-сервера Nginx.  Для этого веб-сервера есть возможнось использовать модуль stub_status, который показывает в цифрах текущую нагрузку на Nginx примерно в таком виде:
Active connections: 26
server accepts    handled     requests
1344375             1344375    3208201
Reading: 0 Writing: 2 Waiting: 24


   Из этих данных мы можем получить, например, такие метрики для мониторинга:
  • nginx_status.active   -  количество всех открытых соединений
  • nginx_status.reading -  количество запросов, у которых nginx читает заголовки запроса
  • nginx_status.writing - количество запросов, у которых в данный момент сервер читает тело запроса, обрабатывает запрос или пишет ответ клиенту
  • nginx_status.waiting  -  количество неактивных(keep-alive) соединений
  • nginx_status.accepts - количество принятых запросов в секунду
  • nginx_status.handled - количество обрабатываемых запросов в секунду
  • nginx_status.requests  - количество запросов в секунду
   Благодаря этим параметрам можно оценить нагрузку на сервер (в течении дня, недели и т.д.) , а также оценить узкие места в его работе (медленный ли канал у сервера, медленные ли каналы у клиентов, медленно ли обрабабатываются запросы и т.д.).


   Скрипт, формирующий файл для zabbix_sender-а и запускающий zabbix_sender, может запускаться zabbix-агентом.
   Для этого в конфигурационном файле агента zabbix_agentd.conf создадим ключ nginx_status:
UserParameter=nginx_status,/home/zabbix/nginx.sh 127.0.0.1


   Содержимое /home/zabbix/nginx.sh примерно такое:
#!/bin/sh

# this script tries to collect nginx data

########################################
# Active connections: 768              #
# server accepts handled requests      #
#  133844 133844 601894                #
# Reading: 63 Writing: 21 Waiting: 684 #
########################################

WGET="/usr/local/bin/wget"
ZBX_STATS_FILE="/var/log/zabbix/ZabbixStats.txt"
ZBX_SENDER="/home/zabbix/bin/zabbix_sender"
ZBX_CONFIG="/home/zabbix/conf/zabbix_agentd.conf"
ZBX_HOSTNAME=`grep "^Hostname" ${ZBX_CONFIG} | cut -f2 -d"="`

NGX_STATS_FILE="/var/log/zabbix/NginxStats.txt"
if [ -z $1 ]; then
   NGX_HOSTNAME="localhost"
else
   NGX_HOSTNAME="${1}"
fi

$WGET -q -O ${NGX_STATS_FILE} -t3 -T5 http://${NGX_HOSTNAME}/nginx-status

if [ $? == 0 ]; then
       cat ${NGX_STATS_FILE} | awk -v myhost=$ZBX_HOSTNAME '/Active connections/ {active = int($NF)}
                      /\W*([0-9]+)\W*([0-9]+)\W*([0-9]+)/ {accepts = int($1); handled = int($2); requests = int($3)}
                      /Reading:/ {reading = int($2); writing = int($4); waiting = int($NF)}
                      END {
                      print myhost, "nginx_status.active", active;
                      print myhost, "nginx_status.reading", reading;
                      print myhost, "nginx_status.writing", writing;
                      print myhost, "nginx_status.waiting", waiting;

                      print myhost, "nginx_status.accepts", accepts;
                      print myhost, "nginx_status.handled", handled;
                      print myhost, "nginx_status.requests", requests;
                      }' > ${ZBX_STATS_FILE}

       ${ZBX_SENDER} -i ${ZBX_STATS_FILE} -c ${ZBX_CONFIG} >/dev/null
       echo 1;
       exit 0
else
       echo "0"
       exit 1
fi
При запросе сервером zabbix ключа nginx_status, скрипт вышлет данные серверу.


   Создаем в zabbix-сервере шаблон - Template App Nginx.
   Создаём в шаблоне элемент данных типа zabbix agent, запускающий скрипт /home/zabbix/nginx.sh (Рис. 1).
Рисунок. 1 Элемент данных, запускающий скрипт /home/zabbix/nginx.sh


   Скрипт в случае успешного получения страницы nginx-status возвращает 1 и 0 - в противном случае. Полезно создать триггер отслеживающий эту ситуацию (Рис. 2).
Рисунок 2. Тригер, отслеживаюший возможность получения статуса с Nginx.


   Далее для каждого параметра создаем элемент данных типа zabbix trapper. На Рис.2  пример для метритки nginx active connections.
Рисунок 3. Создание элемента данных для метрики nginx active connections.


   По аналогии делаем элементы для остальных метрик. Изменяется только название элемента данных (Name) и ключ (Key).


   После объединения графиков в группы получаются графики как на Рис. 4 и Рис. 5.
Рисунок 4. Статус соединений.


Рисунок 5. Нагрузка на сервер.


   Шаблон для мониторинга nginx можно скачать отсюда: http://forum.itrm.ru/t/94/

понедельник, 3 июня 2013 г.

Мониторинг и управление ИТ


Общий взгляд на ИТ-мониторинг

Для понимания, какое место занимает ИТ-мониторинг в управлении ИТ, необходимо понимать, как вообще управляются технические (и не только) системы. А для управления ими, как правило, используются либо замкнутый, либо разомкнутый контур передачи воздействия. Тут все зависит от того, какой информацией о системе мы уже обладаем или можем получить в процессе  управления.

Если у нас есть статистическая информация по ИТ-системе, что за квартал объем данных возрастает на 10 Тб, и данные надо собирать и хранить год, а в течение этого времени у нас не будет возможности контролировать дисковое пространство, мы можем заранее купить и установить диски на 40 Тб, чтобы система работала стабильно в требуемом временном интервале. Это пример управления ИТ при помощи разомкнутого контура на основе заранее собранной и проанализированной информации.

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

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

ИТ-Мониторинг с точки зрения ITIL

В ITIL (библиотека, описывающая лучшие практики управления IT) ИТ-Мониторинг играет одну из ключевых ролей в управлении ИТ-услугами.

Из глоссария ITIL:
Мониторинг -  это постоянное наблюдение за Конфигурационной единицей, ИТ-услугой или Процессом с целью обнаружения Событий и обеспечения информированности о текущем состоянии.
 
А вот управление Событиями, о которых информирует ИТ-мониторинг уже является основным процессом в управлении ИТ-услугами. ITIL классифицирует События в зависимости от значимости на Инциденты, Проблемы и Изменения и далее по каждому из видов Событий рекомендует использовать соответственно процессы управления Инцидентами, управления Проблемами и управления Изменениями, что в конечном итоге позволяет значительно повысить качество ИТ-услуг.


ИТ-Мониторинг с точки зрения COBIT

В COBIT Мониторинг выведен в отдельный домен "Мониторинг и оценка". Всего доменов в последней 5-ой версии пять, они схематически изображены на рисунке ниже.  

Рисунок 1. Домены процессов в COBIT 5

Домен "Мониторинг и оценка"состоит из 4-х процессов:

- Мониторинг и оценка эффективности ИТ;

- Мониторинг и оценка системы внутреннего контроля

- Обеспечение соответствия внешним требованиям

- Обеспечение корпоративного управления ИТ

 
По COBIT Мониторинг необходим для уверенности в том, что все делается правильно, в соответствии с принятыми направлениями и политиками.
 
Так как COBIT специализируется на контроле и аудите ИТ, то в отличии от ITIL, специализирующегося в основном на управлении ИТ,  для COBIT более важное значение имеют не События, а статистическая информация. Этот вид информации, который Мониторинг собирает и хранит в базе, позволяет руководству компании делать текущие выводы на основе исторических данных, принимать стратегические управленческие решения, прогнозировать затраты и эффективность информационных технологий для организации.  


Какую систему мониторинга выбрать
 
Когда ставится вопрос о системе мониторинга, то выбор стоит между системами с открытым программным обеспечением (Open Source Software) и  платным (требующим оплату за лицензии). В большинстве случаев выбор сводится к четырем вариантам.
 
Две системы c открытым исходным кодом:
Nagios
Zabbix
 
И две, требующие оплаты за использование ПО:
IBM Tivoli
HP Software (в прошлом HP OpenView)

Платные системы мониторинга имеет смысл использовать, если есть наличие промышленных приложений уровня SAP, Oracle, возможность интеграции с системами поддержки и управления ИТ-услугами (ServiceDesk), системами управления бизнес-услугами (Business Service Management, BSM), требование гарантированной технической поддержки от разработчиков данного программного обеспечения, а также возможность платить за лицензии.
 
Open Source системы мониторинга можно использовать в тех случаях, когда вы готовы своими силами дописывать скрипты для мониторинга каких-либо специфических метрик, нет необходимости в короткие сроки настроить мониторинг редких промышленных приложений, так как под них вы скорее всего не найдете готовых шаблонов, и придется их разрабатывать самостоятельно. А также у вас нет необходимости интеграции с ServisDesk, BSM, и в случае возникновения проблем с системой мониторинга вы готовы решать их самостоятельно.
 
Большой плюс систем мониторинга с открытым программным обеспечением в том, что, в принципе, вы можете самостоятельно настроить мониторинг практически любых метрик при возможности их получения каким-либо способом.

C уважением,
Андрей
Компания ITRM

понедельник, 20 мая 2013 г.

Автоматизация мониторинга доступности динамического списка серверов и сетевых устройств в системе мониторинга Zabbix


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


В данной статье мы решили описать решение этой задачи при помощи системы мониторинга Zabbix.


В Zabbix-е начиная с версии 2.0 доступна новая функция: низкоуровневое обнаружение.
Низкоуровневое обнаружение предоставляет возможность автоматического создания элементов данных, триггеров и графиков для разных ресурсов на компьютере. Так, в дистрибутив включена возможность автоматического обнаружения сетевых интерфейсов и дисков на сервере. Рассмотрим, как ещё можно применять данную возможность.


Есть задача осуществлять мониторинг доступности серверов - порядка 200-300 единиц. Допустим, что требуется раз в 2 минуты с серверов клиента проверять их доступность по сети, время отклика и потери пакетов. По всем параметрам должна собираться и графически отображаться статистика. При этом список серверов обновляется динамически в текстовом файле выглядящем следующим образом::
имя_сервера1 192.168.1.11
имя_сервера2 192.168.2.22
и т.д.


Для решения этой задачи удобно использовать низкоуровневое обнаружение.
Создаем скрипт, который будет запрашиваться с сервера, где работает система мониторинга Zabbix. Его результатом будет текст в формате json, который требуется для низкоуровневого обнаружения:


#!/usr/bin/perl

$latest_file=`ip.servers.lst`;  # Текстовый файл с динамическим списком узлов

print "{\n";
print "\t\"data\":[\n\n";

for (`cat $latest_file`)
{
    ($clname, $clip) = m/\S_(\S+) (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/; # $clname - имя сервера, $clip - его IP-адрес

   print "\t{\n";
   print "\t\t\"{#CLNAME}\":\"$clname\",\n";
   print "\t\t\"{#CLIP}\":\"$clip\"\n";
   print "\t},\n";
}

print "\t]\n";
print "}\n";


Вывод этого скрипта будет примерно таким:
{
       "data":[
       {
               "{#CLNAME}":"server_name1",
               "{#CLIP}":"192.168.1.11"
       },
       {
               "{#CLNAME}":"server_name2",
               "{#CLIP}":"192.168.2.22"
       },



       ]
}


Добавляем скрипт в конфигурацию агента Zabbix zabbix_agentd.conf  в разделе UserParameter:
UserParameter=cl.discovery,/home/zabbix/cl.discovery.pl


В web-интерфейсе Zabbix-сервера создаем правило “create discovery rule” (Рис. 1) для хоста, с которого осуществляется мониторинг серверов и сети:
  • Name discovery clients
  • Type zabbix agent
  • Key такой же, что указан в UserParameter (cl.discovery)
  • Keep lost resources period (in days) 0 (если не хотим хранить информацию о серверах, которые не требуется мониторить)

     
Рисунок 1. Правило “create discovery rule”


В разделе Item prototypes (Рис. 2) создаем прототипы требуемых элементов данных (create item prototype):
Для времени отклика:
  • Name ICMP ping response time to {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingsec[{#CLIP}]
  • Type of information Numeric(float)
  • Units ms

Рисунок 2. Раздел Item prototypes.


Для потерь пакетов:
  • ICMP ping percentage of loss packets {#CLNAME} {#CLIP}
  • Type Zabbix trapper
  • Key cl.icmppingloss[{#CLIP}]
  • Type of information Numeric(float)
  • Units %


В разделе Graph prototypes (Рис. 3) создаем (create graph prototype) прототип графиков привязанные к созданным прототипаv элементов данных.


Рисунок 3. Разделе Graph prototypes.


В разделе Trigger prototypes создаём прототипы тригеров к созданным прототипам элементов данных.


Теперь при изменении списка с серверами в zabbix-сервере автоматически будут создаваться и удаляться соответствующие элементы данных и графики (Рис. 4).


Рисунок 4. Графики по задержкам и потерям пакетов в канале до определенного узла.

C уважением,
Компания ITRM

пятница, 22 июня 2012 г.

Облачные вычисления

Облачные вычисления

Сейчас очень много говорят о вычислениях в “облаках”. Попробую высказать свою точку зрения на это. Если где-то ошибусь - буду рад, если меня поправят.

Во-первых, облачные вычисления - это не какая-то новая идея, и даже не новая технология. Пользуюсь облачными сервисами уже больше 10 лет - это и электронная почта, онлайн-переводчик, сервисы создания и редактирования документов, онлайн-мониторинга и многое другое. Даже блог нашей компании создан и размещается в облаке.Что касается технологий, то и тут нет ничего нового. Провайдеры предоставляющие облачные услуги используют известные уже давно технологии виртуализации: XEN, KVM, VirtualBox, VmWare.

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

Попробуем разобраться.

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


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

Со временем и развитием ИТ эта жесткая модель уступила место сперва персональным компьютерам, когда каждый человек мог позволить себе иметь дома свой небольшой вычислительный ресурс и иметь к нему доступ в любое удобное время.

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

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

Облака - это возможность использования майнфреймов при помощи клиент-серверной архитектуры с большей эффективностью и удобством.

Этой возможности послужили три фактора. Перечислю их по мере значимости.

Первый и, по моему, основной - пропускная способность каналов связи за последние годы значительно возросла, стала стабильнее и дешевле. Это позволило выносить из частных сетей в публичные большие объемы информации с небольшими затратами, но еще важнее - иметь стабильный и скоростной доступ в любое время для работы с этой информацией.
Второй фактор - появились технологии виртуализации позволяющие просто и эффективно ограничивать ресурсы потребляемые пользователями, расширять и уменьшать их при необходимости. Причем этот фактор также повысил безопасность и SLA.
И в третий - сами вычислительные ресурсы бысто растут при уменьшении стоимости на них и, например, сегодня обычный персональный компьютер по мощности можно сравнить с сервером 2-3 летней давности. Это позволило снизить стоимость владения и, соответственно, использования ресурсов супер-компьютеров для пользователей.

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


C уважением,
Андрей

понедельник, 4 июля 2011 г.

SRV-записи для Jabber-сервера

Настройки ДНС для Jabber-сервера:

_xmpp-server._tcp.your_domain.ru. 3600 SRV 20 0 5269 jabber.your_domain.ru.
_xmpp-client._tcp.your_domain.ru. 3600 SRV 20 0 5222 jabber.your_domain.ru.
_jabber._tcp.your_domain.ru. 3600 SRV 20 1 5269 jabber.your_domain.ru.

Данные SRV записи нужны для связи вашего jabber-сервера с другими, например gtalk.

среда, 16 июня 2010 г.

HP ANM - Automated Network Management

HP ANM

Новый программный продукт от компании HP - Automated Network Management (HP ANM) представляет из себя интеграцию новой версии NNM - NNMi 9 с Network Automation (NA), а также с нескольких SPI:

- iSPI Performance for Quality Assurance 9
- iSPI Performance for Metrics 9
- iSPI Performance for Traffic 9
- iSPI NET

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

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

В NA также присутствует возможность автоматического обнаружение физических и виртуальных сетевых устройств, помимо этого реализована возможность импорта устройств из NNMi9. NA автоматизирует изменения на тысячах устройств, а также передачу информации об изменениях в NNMi9, например SNMP community string. Автоматизирует операции с сетевыми устройствами, хранит конфигурацию устройств в базе и генерирует сообщения об изменениях в конфигурации на основе правил и политик.

Перечисленные iSPI собирают статистическую информацию с сетевых устройств и сохраняют ее в базе данных, интегрируются с NNMi9. Это предоставляет единый интерфейс для просмотра и анализа статистики.

среда, 16 декабря 2009 г.

Jabber

Сети мгновенной передачи сообщений как средство связи в бизнесе.

Помимо традиционных средств связи, таких как телефон, факс, электронная почта рассмотрим еще одно - посредством сетей мгновенной передачи сообщений.

В последнее время набирает популярность открытый протокол XMPP (также известный как Jabber), в настоящее время используемый в таких сервисах как Я.Онлайн, Google Talk, LiveJournal.

Помимо открытости протокола, Jabber имеет еще одно преимущество - при помощи шлюзов клиенты Jabber могут работать также с такими популярными сетями, как ICQ, MSN и др.

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

Взято отсюда:
http://forum.itrm.ru/index.php?t=msg&th=178&start=0&rid=21

суббота, 23 мая 2009 г.

Резервное копирование (Backup)

В данной статье описывается система резервного копирования на основе программы с открытым исходным кодом - Bacula.

Общее описание системы и ее компонентов

Общая схема системы бекапирования представлена на рис. 1.

В систему входят: директор (Director), хранилище (Storage Daemon), клиент (File Daemon), каталог (Catalog) и консоль (Console).

Директор - это программа, которая курирует все операции резервного копирования и восстановления. Администратор использует директор для планирования бекапов и восстановления.

Консоль — это программа, которая позволяет администратору или пользователю подключаться к директору.

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

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

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

В качестве каталога может использоваться одна из трех баз данных MySQL, PostgreSQL и SQLite. В наше примере использована БД PostgreSQL.

Файлы конфигурации системы, запускаемые процессы.


Директор - самый важный компонент. Он ведает всеми клиентами, сторожами, пулами (Pool), планирует (Schedule) и инициирует начало работ (Job), создает список файлов и каталогов для бекапирования (FileSet). Через директора осуществляется взаимодействие с каталогом.

Основной конфигурационный файл — bacula-dir.conf.


Основной конфиг делится на несколько секций:

Секция Director - описание директора.

Здесь задается имя директора, порт, который он будет слушать, задается пароль, для авторизации консолей. WorkingDirectory назначает директорию для хранения бутстрапов (Bootstrap) работ.


Секция Storage — секция подключения сторожей.

В секции описаны сторожи, где bacula может сохранять бекапы. Задаются имя сторожа, IP адрес или DNS-имя сервера со storage-демоном (SD), порт, пароль от демона, устройство (Device) который предоставляет для записи SD, тип устройства (File или Лента).


Секция Pool — описание пулов.

В этой секции проводится описание пулов. Пулы служат для управления томами (Volume). В этой секции описывается тип пула (Backup, Scratch, Migration), задается формат имени тома - LabelFormat, Volume Retention - время, в течении которого, том гарантировано не будет использован другими работами (данные не будут перезаписаны), после этого времени том освобождается для новых работ.


Секция JobDefs - шаблоны работ.

В этой секции задаются значения по умолчанию, с которыми будет стартовать та или иная работа. Это существенно сокращает в дальнейшем описание опций самой работы. Здесь заданы имя шаблона, тип работы.


Секция Job — описание работ.

В этой секции описывается: какого клиента бекапить и где сохранять бекапы, назначается расписание запуска ful- и incremental-бекапа, а также назначается fileset — список бекапируемых и не бекапируемых файлов. Для unix серверов стандартный fileset - /usr/local/bacula/etc/filelist/unix.conf, а для windows - /usr/local/bacula/etc/filelist/windows.conf. Так как работы в основном стандартные, то описание работы можно строить на основе шаблонов JobDefs.


Секция Messages — система отчетов.

Bacula ведет журнал всех выполняемых работ. Отчеты отсылаются по трем направлениям: консоль оператора, файл логов и электронная почта. Соответственно, в этой секции описывается какие сообщения отсылать на консоль оператора — console, какую информацию записывать в журнальный файл - append, на какой почтовый ящик отсылать email отчеты mail = bacula-report@exmple.com. Команды отправки писем определяются директивами mailcommand и operatorcommand.


Секция Catalog.

Здесь даются параметры подключения к БД.


Секция Client — клиенты bacula.

В этой секции определяются параметры подключения к файловому демону (FD) клиента bacula. Задается IP адрес или DNS имя клиента, порт и пароль. Можно также поменять БД, в которой сохранять данные по файлам и работам этого клиента. Директивами File Retention и Job Retention задаются сроки хранения данных о файлах и работах клиента, соответственно. Bacula хранит информацию о всех работах, файлах и томах 15 дней.

Управление директором осуществляется с помощью консоли - bconsole. Существует также ряд GUI-консолей: bgnome-console, bwxconsole, а также BAT - Bacula Administration Tool.