Re: [идея модуля] external API 4 monit oring

[Alexandre Kalendarev <akalend@xxxxxxx>]

> 
> Хотелось бы, чтобы модуль умел выводить информацию о:
> 1. (fastcgi|proxy)cache
> а) информация по зонам:
> -название зоны
> -выделено памяти
> -израсходовано
> -кол-во закешированниых ответов

что это тебе даст и как ты себе это представляешь? 

> б) информация по закэшированным ответам
> -значение ключа
> -дата создания кэша
> -через сколько запись будет обновлена
> -использовано раз (если ведется такая статистика)
> - и прочая информация, доступная в nginx и полезная для отладки.

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

> 2. limit_zone
> -хотелось бы по каждой зоне видеть информацию о израсходованных ресурсах
> -иметь возможность получить информацию о кол-ве соединений по "ключу"

> Модуль предназначен для мониторинга и будет крайне удобен при отладке (к
> примеру, не придется лазить по папкам с кэшем и смотреть, какие же запросы
> попали в кэш).


> Хочу подчеркнуть, что модуль в принципе не должен вести собственную
> статистику, а должен давать возможность доступа к служебной информации,
> хранящейся в shared памяти. Соответственно, на производительности это не
> должно отразиться. Так же радует возможность реализовать в качестве отдельно
> собирающегося модуля.

есть логи, можно расширить информацию, предназначенную для логгирования

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

> Я не знаю, на сколько принято делать просмотр системных данных из коробки,
> однако то, как реализовано отображение системной информации у eaccelerator,
> оставляет наиприятнейшие впечатления. (Для тех, кто не видел, поясню:
> eaccelerator предоставляет API, а также скрипт с интерфейсом, для удобного
> представления информации о закэшированных скриптах и другой системной
> информации).

видел и знаем. там изначально проектировалось с условием, что будет внешнее АПИ.

 
> P.S.: Смею предположить, что даже если идею Игорь одобрит, то у него вряд ли
> будет возможность тратить время на разработку. В связи с этим, хочу
> попросить откликнуться тех, кому описанные возможности показались
> интересными. Хочется узнать, есть ли востребованность в таком функционале,
> есть ли энтузиаст, заинтересовавшийся идеей модуля?
> Если модуль окажется востребованным, но энтузиаста, готового реализовать не
> появится, есть предложение собрать $ на реализацию. (Хотя возможно об этом
> говорить рано.)

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

готов оказать посильную помощь.

> P.P.S.: Повторю, хотелось бы услышать мнение Игоря об этой идее, в
> частности, существует ли возможность включения данного модуля в продакшн
> версию при сторонней реализации. Так же интересует, на сколько
> правильно/безопасно добавлять возможность управлением системными данными (к
> примеру удаление закэшированного ответа, или же давать пометку, что
> закэшированное значение нужно обновить и т.п.)





_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru