У меня есть сценарий, который выполняет rndc reload <zone_name> in <view_name> на вторичных (подчиненных) серверах в измененных зонах. Эта команда возвращает успех, если перезагрузка успешно поставлена в очередь.
Я хотел знать, есть ли способ получить статус фактического переноса зоны, не просматривая сами журналы. Я хочу иметь возможность автоматически обрабатывать случай, когда перезагрузка привязки не удалась из-за самой ошибки. В настоящее время мне нужно проанализировать журналы, чтобы получить статус передачи зоны после выполнения rndc reload.
Может ли кто-нибудь помочь мне выяснить, как я могу получить статус передачи зоны после выполнения rndc reload <zone_name> что лучше, чем разбор логов.
ПРИМЕЧАНИЕ [для большей ясности]: Я знаю, что с помощью notify ведущее устройство может сообщить ведомому об изменении. Мой вопрос заключается в том, чтобы узнать, есть ли способ получить уведомлен когда передача зоны, инициированная ведомым устройством, не удалась по какой-либо причине без анализа журналов.
Например. Может быть, после уведомления ведомого главный сервер умер по какой-то причине. В этом случае, когда ведомое устройство инициирует передачу зоны, оно не сможет получить запись SOA от ведущего устройства. Я хочу получать уведомления об ошибках такого рода, которые могут произойти во время передачи зоны, без фактического анализа журналов.
Сообщите мне, если потребуется дополнительная информация.
Создать скрипт slave.sh с участием:
#!/bin/sh
ns1="yourfirstdnsserver"
ns2="yourslavednsserver"
serial='grep SOA |cut -d " " -f7'
domain=$1
rndc reload $domain
a=`host -t SOA $domain $ns1 |grep SOA |cut -d " " -f7`
b=`host -t SOA $domain $ns2 |grep SOA |cut -d " " -f7`
if [ $a = $b ];
then echo "$domain : synchro ok";
else "$domain : Error";
fi;
Просто используйте ./slave.sh yourdomain.com.
Наслаждайтесь!
Файл журнала (ошибок) - единственное место, где Bind будет регистрировать такие ошибки, поэтому, если вы не хотите анализировать файлы журнала на предмет конкретных ошибок (хотя вы можете использовать что-то вроде Splunk для автоматизации такого анализа и генерации соответствующих предупреждений) вам нужно что-то другое.
С точки зрения мониторинга, я думаю, что ваша сосредоточенность на получении уведомлений об ошибках во время передачи зон немного упускает суть. На самом деле не столько ошибки имеют значение, сколько то, что они указывают на сокращение, отказ или ошибочное обслуживание. Вместо этого сосредоточьтесь на обслуживании.
Правильно настроенное решение для мониторинга обнаружит такое измененное состояние службы и предупредит вас. Тогда ваш инженер / оператор сможет легко найти в файле журнала соответствующую причину сокращения / отказа услуги ...
В сценарии главный-подчиненный ваш мониторинг должен гарантировать, что:
Хорошей записью DNS для отслеживания зоны будет запись SOA, поскольку это то, что каждый сервер имен всегда должен иметь возможность возвращать для каждой зоны.
Во-вторых, серийный номер в записи SOA должен сообщить вам, синхронизируется ли ведомое устройство с ведущим. Если существует разница в серийных номерах, которая может быть вызвана пропущенным ведомым устройством сообщения NOTIFY, но если это различие присутствует дольше, чем интервал обновления SOA, возникает более серьезная проблема.
a=`host -t SOA yourdomain.com yourns1.com |grep SOA |cut -d " " -f7` && b=`host -t SOA yourdomain.com yourns2.com |grep SOA |cut -d " " -f7` && if [ $a = $b ]; then echo "synchro ok"; else "Error"; fi;