forum.lissyara.su

Добавлено: **2008-11-19 11:06:19**

Спасибо за просвящение.
Я использую FreeBSD 7,0 на виртуалке MS PC 2007, для эксперементов...

з.ы. 3 месяц в NIX-ах, полет нормальный

Добавлено: **2008-11-19 14:40:50**

спасибо за помошь! поднял unbound и nsd....нечего пока неадекватного не заметил...логи молчат..подождём роста кеша)) там дальше будет видно)

Добавлено: **2008-11-19 16:32:07**

Дальше будет новая статья, так как вышел unbound 1.1.0 - там много нового. Теперь, например, заявляют корректную работу с libevent и появилась возможность для мониторинга. Так же доступны официальные руководства по тюнингу и прочее!

Чуть попозже, когда новый в портах появится, я статью переделаю.

Добавлено: **2009-02-02 14:50:19**

Код: Выделить всё

/usr/local/bin/snmpget -v2c -Ovqa -c hiusread localhost

в скриптах для Cacti надо вот так

/usr/local/bin/snmpget -v2c -Ovqa -c <snmp_community> <management_ip> blabla

а то получилось у вас только для локальной машины.

Добавлено: **2009-02-02 15:33:15**

Вообще вот template для Cacti подправленные.
http://noc.ugtel.ru/cacti/cacti_data_te ... y_type.xml
http://noc.ugtel.ru/cacti/cacti_data_te ... e_hits.xml
http://noc.ugtel.ru/cacti/cacti_data_te ... _usage.xml
http://noc.ugtel.ru/cacti/cacti_data_te ... y_type.xml

Добавлено: **2009-02-02 22:23:11**

Спасибо! Точно, так намного удобнее - настройки hostname можно же сразу брать из настроек Device чтобы руками не забивать!

А как быть с SNMP OIDами? Просто дело в том, что я подразумеваю, что статистика для отдельных графиков висит на отдельных OID. Например:

Код: Выделить всё

cache_hits .1.3.6.1.3.1983.1.1.4.1.2.10.99.97.99.104.101.95.104.105.116.115.1
memory_usage .1.3.6.1.3.1983.1.2.4.1.2.12.109.101.109.111.114.121.95.117.115.97.103.101.1
queues_by_type .1.3.6.1.3.1983.1.3.4.1.2.14.113.117.101.117.101.115.95.98.121.95.116.121.112.101.1
answers_to_queries .1.3.6.1.3.1983.1.4.4.1.2.18.97.110.115.119.101.114.115.95.116.111.95.113.117.101.114.105.101.115.1

Если я правильно понял, то в вашем шаблоне вместо hostname и snmp_community будет подставляться то, что указано в настройках устройства, а можно ли так же кустомизировать ввод OIDа, например во время создания графика?

----

Разобрался. Теперь почти все (кроме версии протокола) берется из настроек Device, а OID будет вводится пользователем при создании графика.

Добавлено: **2009-02-03 1:00:14**

seacat23, я исправил шаблоны и описание - в unbound_cacti.tar.gz теперь новые.

У меня есть просьба/предложение. На сколько я помню у вас были какие-то зверские объемы трафика через DNS сервера, кажется 50к+ в секунду? Если у вас уже используется версия unbound имеющая в поставке unbound-control, и кроме того, если есть желание поддержать всемирное движение по отказу от BIND

то хотел бы попросить протестировать этот скрипт и шаблоны, а потом показать всем красивую статистику того, как работал unbound. Типа - повесим ее в статье вместо моих, а то как-то несерьезно это смотрится 2 запроса в секунду

Добавлено: **2009-02-03 10:08:37**

Можно и полностью отказаться от внешнего скрипта. Сейчас занимаюсь этим.

Добавлено: **2009-02-03 10:50:09**

Чтобы отказаться от скрипта надо было бы включать statistics-cumulative: что не есть установки по-умолчанию. При этом так же не очищаются счетчики после их считывания. Тогда можно было бы использовать такой вариант, что SNMP демон сам спрашивает unbound-control при каждом обращении к нему используя для изменения формата вывода sed, awk, grep...

Я прикидывал как делать и решил, что пусть лучше статистику один раз будет спрашивать скрипт, а обращения SNMP демона будут идти к готовым файлам. Типа при таком раскладе и счетчики обнуляются и заДОСить unbound через очень частые обращения к статистике будет сложнее... Скрипт конечно не идеальный получился - на perl наверное быстрее был бы.

А как вы решили делать?

Добавлено: **2009-02-04 10:41:42**

terminus писал(а):Чтобы отказаться от скрипта надо было бы включать statistics-cumulative: что не есть установки по-умолчанию. При этом так же не очищаются счетчики после их считывания. Тогда можно было бы использовать такой вариант, что SNMP демон сам спрашивает unbound-control при каждом обращении к нему используя для изменения формата вывода sed, awk, grep...

Я прикидывал как делать и решил, что пусть лучше статистику один раз будет спрашивать скрипт, а обращения SNMP демона будут идти к готовым файлам. Типа при таком раскладе и счетчики обнуляются и заДОСить unbound через очень частые обращения к статистике будет сложнее... Скрипт конечно не идеальный получился - на perl наверное быстрее был бы.

А как вы решили делать?

Имелось в виду, отказ от скрипта в Cacti.

Добавлено: **2009-02-04 10:46:43**

Сейчас работаю над альтернативной версией отображения статистики.
ниже пример

Добавлено: **2009-02-04 11:46:22**

Имелось в виду, отказ от скрипта в Cacti.

Все таки не понял фишки.

Отказ от функций unbound_cactI, то есть от парсинга переменных получаемых от unbound-control? Чисто спортивный интерес - можете в двух словах накидать схему как вы решили заводить в какти данные из unbound-control stats?

А ваши графики интереснее выглядят

Может мои поделки выкинуть и вы свои красивые шаблоны выложите?

Тут еще такая тема организовалась - разработчик unbound заметил в листах сообщение про шаблоны и предложил включить их в пакет unbound как сторонний contribution в кучу к остальным вещам типа SELinux политик. Если ваши метод опроса и графики лучше чем мои поделки так может их и предложим на включение?

Добавлено: **2009-02-04 12:30:05**

terminus писал(а):
Имелось в виду, отказ от скрипта в Cacti.
Все таки не понял фишки. Отказ от функций unbound_cactI, то есть от парсинга переменных получаемых от unbound-control? Чисто спортивный интерес - можете в двух словах накидать схему как вы решили заводить в какти данные из unbound-control stats?

А ваши графики интереснее выглядят Может мои поделки выкинуть и вы свои красивые шаблоны выложите?

Тут еще такая тема организовалась - разработчик unbound заметил в листах сообщение про шаблоны и предложил включить их в пакет unbound как сторонний contribution в кучу к остальным вещам типа SELinux политик. Если ваши метод опроса и графики лучше чем мои поделки так может их и предложим на включение?

1) скрипт парсинга данных - остаеться как есть.
2) имелось в виду отказаться в теплейтах Cacti от метода получения данных через Script/Command, и переделка на прямое обращение по Get SNMP Data (Indexed).
3) Пока еще все в этапе разработки. Данные загоняются в базу данных, дальше обрабатываются PHP и рисуются pChart.
4) Нужно время пока его не очень много.

Добавлено: **2009-02-04 16:39:33**

имелось в виду отказаться в теплейтах Cacti от метода получения данных через Script/Command, и переделка на прямое обращение по Get SNMP Data (Indexed).

А вот это кстати вопрос - я так и не разобрался как назначать в качестве источника для Data Input Method тип ввода SNMP Query. Остановился на проблеме, что при выборе этого типа, не появлялась возможность назначать в Data Template соответсвие между Data Source Item и Output Fields из Data Input Method. А при выборе в качестве типа ввода Script/Command все красиво получилось...

А насколько принципиальна разница между этими типами ввода?

Добавлено: **2009-02-05 10:26:32**

terminus писал(а):А насколько принципиальна разница между этими типами ввода?

никакой, но просто хочеться так.

Добавлено: **2009-02-20 1:04:55**

Попробовал настроить unbound по статье, при "num-threads: 4" возникла следующая проблема:

Код: Выделить всё

rt# unbound-control stats
thread0.num.queries=2
thread0.num.cachehits=0
thread0.num.cachemiss=2
thread0.num.recursivereplies=2
thread0.requestlist.avg=2
thread0.requestlist.max=4
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=0
thread0.requestlist.current.user=0
thread0.recursion.time.avg=1.014996
thread0.recursion.time.median=0
thread1.num.queries=0
thread1.num.cachehits=0
thread1.num.cachemiss=0
thread1.num.recursivereplies=19878790
thread1.requestlist.avg=0
thread1.requestlist.max=0
thread1.requestlist.overwritten=18
thread1.requestlist.exceeded=19878772
thread1.requestlist.current.all=18
thread1.requestlist.current.user=18
thread1.recursion.time.avg=1.000001
thread1.recursion.time.median=1.69858e-313
error: could not SSL_read

Код: Выделить всё

rt# uname -a
FreeBSD rt.weird.ru 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Wed Feb 11 14:41:46 MSK 2009     root@:/usr/obj/usr/src/sys/METEOR  [b]amd64[/b]

при "num-threads: 2" всё становится на свои места:

Код: Выделить всё

rt# unbound-control stats
thread0.num.queries=2
thread0.num.cachehits=0
thread0.num.cachemiss=2
thread0.num.recursivereplies=2
thread0.requestlist.avg=2
thread0.requestlist.max=4
thread0.requestlist.overwritten=0
thread0.requestlist.exceeded=0
thread0.requestlist.current.all=0
thread0.requestlist.current.user=0
thread0.recursion.time.avg=1.014996
thread0.recursion.time.median=0
thread1.num.queries=0
thread1.num.cachehits=0
thread1.num.cachemiss=0
thread1.num.recursivereplies=19878790
thread1.requestlist.avg=0
thread1.requestlist.max=0
thread1.requestlist.overwritten=18
thread1.requestlist.exceeded=19878772
thread1.requestlist.current.all=18
thread1.requestlist.current.user=18
thread1.recursion.time.avg=1.000001
thread1.recursion.time.median=1.69858e-313
total.num.queries=2
total.num.cachehits=0
total.num.cachemiss=2
total.num.recursivereplies=19878792
total.requestlist.avg=2
total.requestlist.max=4
total.requestlist.overwritten=18
total.requestlist.exceeded=19878772
total.requestlist.current.all=18
total.requestlist.current.user=18
total.recursion.time.avg=1.000001
total.recursion.time.median=8.49289e-314
time.now=1235080362.682373
time.up=467.014117
time.elapsed=81.877011

собирал с различными комбинациями libevent и threads. результат тот же.
может кто-нибудь прокомментировать ситуацию, может я где недопонял?

Добавлено: **2009-02-20 11:28:46**

Код: Выделить всё

total.num.recursivereplies=19878792
total.requestlist.avg=2
total.requestlist.max=4
total.requestlist.overwritten=18
total.requestlist.exceeded=19878772
time.up=467.014117

threadX.requestlist.exceeded
Queries that were dropped because the request list was full.
This happens if a flood of queries need recursive processing,
and the server can not keep up.

Вот интересно - за 467 секунд (почти 8 минут) обработано 19 878 792 запросов, и при этом 19 878 772 запросов в очереди на разрешение были перезаписаны по таймауту. Вас не ДОСят случайно или это вы сами тесты проводили?

Какая версия unbound у вас запущенна? В версии 1.2.0 исправили такую проблему, (а сейчас уже вышла 1.2.1):

Fix problem reported by Jaco Engelbrecht where unbound-control stats freezes up unbound if this was compiled without threading, and was using multiple processes

Добавлено: **2009-02-20 11:43:13**

terminus писал(а):
Код: Выделить всё
total.num.recursivereplies=19878792
total.requestlist.avg=2
total.requestlist.max=4
total.requestlist.overwritten=18
total.requestlist.exceeded=19878772
time.up=467.014117
threadX.requestlist.exceeded
Queries that were dropped because the request list was full.
This happens if a flood of queries need recursive processing,
and the server can not keep up.
Вот интересно - за 467 секунд (почти 8 минут) обработано 19 878 792 запросов, и при этом 19 878 772 запросов в очереди на разрешение были перезаписаны по таймауту. Вас не ДОСят случайно или это вы сами тесты проводили?

Да, удивительно, откуда взялась эта цифра. сейчас 337 и 0 соответственно. Надо наблюдать за активностью. Хотя трудно представить такую ситуацию, потому как внутренних клиентов очень мало и они все "чистые", то есть без различных троянов и прч. Скорее всего очередное "свойство" unbound'a?

Какая версия unbound у вас запущенна? В версии 1.2.0 исправили такую проблему, (а сейчас уже вышла 1.2.1):
Fix problem reported by Jaco Engelbrecht where unbound-control stats freezes up unbound if this was compiled without threading, and was using multiple processes

собирал последнюю из портов: 1.2.1.
Первый раз собирал именно без threads, но потом пробовал в различных комбинациях.. результат оставался тем же.
Кстати, в некоторых случаях ошибка (error: could not SSL_read) не вылетала, а unbound-control stats именно "фризился".
Может написать разработчикам?

Добавлено: **2009-02-20 11:44:36**

не разобрался с квотами, в предыдущем ответе текст добавлен в квотирование

Да, удивительно, откуда взялась эта цифра. сейчас 337 и 0 соответственно. Надо наблюдать за активностью. Хотя трудно представить такую ситуацию, потому как внутренних клиентов очень мало и они все "чистые", то есть без различных троянов и прч. Скорее всего очередное "свойство" unbound'a?

Добавлено: **2009-02-20 12:06:32**

Покажите весь unbound.conf. Если там все те же настройки, что и в статье (статья расчитана на средне-малый по загруженности сервер), то для того чтобы перекачивать через себя 19878792 запросов надо бы использовать libevent и увеличит:

Код: Выделить всё

outgoing-range: 2048
num-queries-per-thread: 4096 
msg-cache-size: больше
rrset-cache-size: больше

А вообще проблема забавная.
А как он вел себя при этом - он продолжал работать, тогда когда на запрос unbound-control stats выводилось error: could not SSL_read ?

Добавлено: **2009-02-20 12:29:13**

Конфиг такой же, как и в статье.. но на всякий случай привожу:

Код: Выделить всё

rt# cat /usr/local/etc/unbound/unbound.conf
server:
        verbosity: 0
        # statistics-interval: 0
        # statistics-cumulative: no
        # extended-statistics: no
        num-threads: 2
        interface: 0.0.0.0
        # interface-automatic: no
        port: 53
        outgoing-range: 512
        msg-cache-size: 16m
        msg-cache-slabs: 4
        num-queries-per-thread: 1024
        rrset-cache-size: 32m
        rrset-cache-slabs: 4
        cache-max-ttl: 86400
        infra-host-ttl: 60
        infra-lame-ttl: 120
        infra-cache-slabs: 4
        infra-cache-numhosts: 10000
        infra-cache-lame-size: 10k
        do-ip4: yes
        do-ip6: no
        do-udp: yes
        do-tcp: yes
        do-daemonize: yes
        access-control: 0.0.0.0/0 refuse
        access-control: 172.16.0.0/12 allow
        access-control: 127.0.0.0/8 allow
        access-control: ::0/0 refuse
        access-control: ::1 allow
        access-control: ::ffff:127.0.0.1 allow
        chroot: "/usr/local/etc/unbound"
        username: "unbound"
        directory: "/usr/local/etc/unbound"
        logfile: ""
        use-syslog: no
        pidfile: "/usr/local/etc/unbound/unbound.pid"
        root-hints: "/usr/local/etc/unbound/named.cache"
        hide-identity: yes
        hide-version: yes
        identity: "DNS"
        version: "1.0"
        harden-glue: yes
        do-not-query-address: 127.0.0.1/8
        do-not-query-address: ::1
        do-not-query-localhost: yes
        module-config: "iterator"

# Remote control config section.
remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 953
        server-key-file: "/usr/local/etc/unbound/unbound_server.key"
        server-cert-file: "/usr/local/etc/unbound/unbound_server.pem"
        control-key-file: "/usr/local/etc/unbound/unbound_control.key"
        control-cert-file: "/usr/local/etc/unbound/unbound_control.pem"

# Stub zones.
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of nameservers. list zero or more
# nameservers by hostname or by ipaddress. If you set stub-prime to yes,
# the list is treated as priming hints (default is no).
# stub-zone:
#       name: "example.com"
#       stub-addr: 192.0.2.68
#       stub-prime: "no"
# stub-zone:
#       name: "example.org"
#       stub-host: ns.example.com.

# Forward zones
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of servers. These servers have to handle
# recursion to other nameservers. List zero or more nameservers by hostname
# or by ipaddress. Use an entry with name "." to forward all queries.
# forward-zone:
#       name: "example.com"
#       forward-addr: 192.0.2.68
#       forward-addr: 192.0.2.73@5355  # forward to port 5355.
# forward-zone:
#       name: "example.org"
#       forward-host: fwd.example.com
rt#

после unbound-control stats с ошибкой "error: could not SSL_read" процесс (или процессы, в зависимости от сборки) падал.
когда unbound-control stats "фризился" без видимой ошибки - процесс продолжал работать и отвечать на запросы.

Добавлено: **2009-02-20 12:34:02**

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

Добавлено: **2009-02-20 12:43:00**

ок, спасибо!

Может это как то с архитектурой связано. у меня amd64.
Вы на i386 собирали?

Добавлено: **2009-02-20 12:45:31**

Да по идее не должно бы, как раз наоборот. У меня все работают под i386.

Добавлено: **2009-02-20 12:52:23**

а вообще unbound и с "num-threads: 4" работает "нормально". Конечно, наверняка сказать сложно, потому как thread2 и thread3 могли быть не задействованы при низкой нагрузке запросов, однако около дня он у меня в рабочем режиме так простоял. Дело то как раз в unbound-control, который не может, судя по всему, не может считать статистику с thread2 и thread3.

forum.lissyara.su

Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound

Re: Готовится статья о DNS сервере Unbound