Живая статистика от файла журнала

возможно, это столь же просто как добавление Listen ip.add.re.ss2:80 в Вашей httpd конфигурации?

и удаление любого Listen 80 директивы, для проверки сервер только служит IP-адресу, который Вы хотите.

я просто перечитал Ваши правила iptables; Вы отправляете трафик от ip2 на порте 80 к ip1 на порте 80..., конечно, Ваши журналы собираются показать ip1. Вы перенаправляете трафик, прежде чем он поразит сервер.

0
задан 27 January 2012 в 18:43
3 ответа

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

0
ответ дан 24 November 2019 в 11:57

Вы ведь знаете о заглушке статистики Nginx , верно? Внизу страницы есть ссылки на методы мониторинга Nginx. Однако я не уверен, сколько времени это даст.

0
ответ дан 24 November 2019 в 11:57

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

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

Если вы можете жить без времени отклика (например, просто запросов / с - и разбивки # чтение, запись, активный, общее количество подключений и т. д.) используйте модуль состояния HTTP-заглушки . Он обеспечивает текстовый вывод информации, которую можно легко запросить и проанализировать. (Чтобы использовать этот модуль, Nginx должен быть скомпилирован с - with-http_stub_status_module )

Пример вывода:

Active connections: 291
server accepts handled requests
  16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

(3-я строка - принятые соединения, обработанные соединения, принятые запросы)

Есть интересная статья об использовании этих данных для создания графиков с помощью rrdtool, здесь .

Если данные о времени отклика особенно важны для вас, должна быть возможность изменить модуль статуса заглушки. Код (на самом деле всего около 5 КБ) находится в src / http / modules / ngx_http_stub_status_module.c . Например, здесь имеется модификация , в которой модуль выводит агрегированные подсчеты возвращенных кодов состояния HTTP.

Наконец, если вам просто нужно время ответа. Вы можете сохранить данные в Memcached, используя HTTP-модуль Memc . Для целей вашей гистограммы вы, по сути, должны создавать 2 ключа в секунду - основывать ключ на времени (например, $ time_local ) - один ключ для хранения счетчика количества запросов за эту секунду, и один для хранения среднего времени ответа (или совокупного времени ответа) - работа с переменными $ request_time и / или $ upstream_response_time .

Я уверен, что вы можете придумать простой способ графического представления данных, когда они у вас есть, но вот некоторые из возможных отправных точек:

  • Пусть сценарий извлекает данные (из заглушки, memcached и т. д.) и генерирует столбцы ascii (например, вот так ) используйте часы для отслеживания вывода сценария.
  • Если на вашем сервере есть PHP (и вы хотите его использовать (не идеальный язык сценариев)), рассмотрите возможность модификации этого сценария .
  • Наконец, возможно, рассмотрите возможность использования gnuplot (output as_ascii ), хотя для этой цели это кажется чрезмерным.
0
ответ дан 24 November 2019 в 11:57

Теги

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