Вопросы Теги

Узнать сколько Запросов/месяц DNS через WHM или SSH?

Я заявил это на другом сообщении, которое Вы связали, но мы работаем очень сервер магистрали без файла подкачки, и все здесь кажется прекрасным. На самом деле это кажется быстрее без него. У нас есть 8 ГБ RAM, и я сказал бы, что необходимо принять решение на основе того, есть ли у Вас много RAM, не, является ли Вашим жестким диском SSD или нет. Хотя я могу понять желание спасти жизнь его, не делая ненужные записи.

8
задан 2 June 2010 в 02:51
6 ответов

Как AndyN заявляет, ответ здесь:

sudo rndc stats

Когда Вы выполняете это (если настроено в named.conf файлы), Связывают, разгрузит статистическую информацию в настроенный файл статистики.

Необходимо проверить/etc/bind/named.conf.* файлы для следующей строки:

 [ statistics-file "path_name"; ]

(На Ubuntu это named.conf.options и путь /var/run/named/named.stats)

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

Выполненный sudo rndc статистика

Затем после подходящего времени (несколько часов? несколько дней?) выполняет его снова.

В Вашем файле статистики Вы будете видеть следующее (это с моего собственного домашнего сервера DNS - который является и кэширующимся сопоставителем и авторитетный).

Извинения за большую сумму информации... Число в первой строке находится во "Время эпохи" (секунды с тех пор 01.01.1970 0:00 UTC). Используя это можно разработать разницу во времени от один "rndc статистика" к следующему и также другому количеству запросов (Вы захотите посмотреть на Входящий "ЗАПРОС" и Исходящие общие количества (+ NS + SOA + PTR + TXT + AAAA). 

+++ Statistics Dump +++ (1275999954)
++ Incoming Requests ++
                432 QUERY
++ Incoming Queries ++
                 306 A
                   2 NS
                   4 SOA
                  45 PTR
                   5 TXT
                  70 AAAA
++ Outgoing Queries ++
[View: default]
                 523 A
                   4 NS
                   4 SOA
                  42 PTR
                   9 TXT
                 330 AAAA
[View: _bind]
++ Name Server Statistics ++
                 432 IPv4 requests received
                 431 responses sent
                 259 queries resulted in successful answer
                  96 queries resulted in authoritative answer
                 335 queries resulted in non authoritative answer
                  39 queries resulted in nxrrset
                 133 queries resulted in NXDOMAIN
                 238 queries caused recursion
                   1 duplicate queries received
++ Zone Maintenance Statistics ++
++ Resolver Statistics ++
[Common]
[View: default]
                 849 IPv4 queries sent
                  63 IPv6 queries sent
                 841 IPv4 responses received
                  67 NXDOMAIN received
                   2 FORMERR received
                   2 EDNS(0) query failures
                 123 query retries
                   5 query timeouts
                 118 IPv4 NS address fetches
                 118 IPv6 NS address fetches
                   1 IPv4 NS address fetch failed
                  90 IPv6 NS address fetch failed
                  13 queries with RTT < 10ms
                 549 queries with RTT 10-100ms
                 279 queries with RTT 100-500ms
[View: _bind]
++ Cache DB RRsets ++
[View: default]
                 366 A
                  87 NS
                   9 CNAME
                   1 PTR
                  97 AAAA
                  20 RRSIG
                  15 NSEC
                   4 !AAAA
                   1 NXDOMAIN
[View: _bind]
++ Socket I/O Statistics ++
                 852 UDP/IPv4 sockets opened
                  64 UDP/IPv6 sockets opened
                   3 TCP/IPv4 sockets opened
                   2 TCP/IPv6 sockets opened
                 850 UDP/IPv4 sockets closed
                  63 UDP/IPv6 sockets closed
                 123 TCP/IPv4 sockets closed
                   1 UDP/IPv4 socket bind failures
                  63 UDP/IPv6 socket connect failures
                 849 UDP/IPv4 connections established
                 124 TCP/IPv4 connections accepted
                  63 UDP/IPv6 send errors
                   3 UDP/IPv4 recv errors
++ Per Zone Query Statistics ++
--- Statistics Dump --- (1275999954)
10
ответ дан 2 December 2019 в 22:44

Команда "rndc статистика" должна работать с последними версиями BIND DNS.

По данным DistroWatch, CentOS 5.5, поставленный с, Связывает 9.3.4-P1. OP может проверить это из командной строки с "об/мин - обеспечение качества | grep связывает".

9
ответ дан 2 December 2019 в 22:44
  • 1
    Это было полезно, но bortzmeyer имел немного больше информации, в которой я нуждался - спасибо! –  Kerry Jones 11 June 2010 в 01:13
  • 2
    состояние rnd, казалось, работало, rndc статистика didn' t делают что-либо –  Kerry Jones 11 June 2010 в 01:32

AndyN "rndc статистика" (если Вы, оказывается, выполняете BIND) и "dnstop" kaerast являются хорошими советами. Я добавляю DSC, который является очень всесторонним пакетом для статистики DNS.

2
ответ дан 2 December 2019 в 22:44

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

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

1
ответ дан 2 December 2019 в 22:44

Предупреждение: это генерирует некоторые огромные журналы, если Ваш сервер занят, следите за своим пространством.

Сначала в Вашем/etc/named.conf позволяют каналу 'запросов' получить журнал; краткий пример:

logging {
  channel queries_channel {
        file "/var/log/named/queries.log" versions 5 size 500m;
        print-time yes;
  };
  category queries { queries_channel; }
}

Отметьте, как это сохранит 5 версий (повернутые журналы) в 500 meg - корректируются по мере необходимости для получения объема данных, в котором Вы нуждаетесь. Теперь, когда у Вас есть журналы, Google "обязывают статистику запроса" находить инструмент или программное обеспечение, которое лучше всего удовлетворяет Ваши потребности для обнаружения рассматриваемых чисел. Один из тех, которых я знаю об этом, поддерживает и BIND v8 и v9 форматы, http://www.logreport.org/.

1
ответ дан 2 December 2019 в 22:44
  • 1
    Не целый you' d думают, но это действительно зависит, насколько занятый Ваш сервер находится... на умеренном к легкому серверу, который имеет много ведомых устройств, выполняющих это на основном doesn' t вред –  troyengel 8 June 2010 в 11:53

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

0
ответ дан 2 December 2019 в 22:44

Теги

Похожие вопросы