Tag Archives: Php

Выводим в cacti статистику со своего скрипта

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

Для этого сначала пишем на сайте скрипт типа stat_cacti.php который будет выводить ответ формата

count:XXX

В моем случае скрипт принимал еще параметры с (параметр, характеризующий какого рода статистику выдавать) и i (интервал, за какое время выдавать стату).

Скрипт готов, настраиваем кактус.

Сначала добавляем data input method -> add и приводим его примерно к следующему виду:

В input string  у меня следующее:

/usr/local/bin/wget --tries=1 --inet4-only --connect-timeout=3 --dns-timeout=3 --timeout=3 --quiet --no-check-certificate -O - "<url>?c=<command>&i=<interval>"

Суть такова — скрипт выполняет запрос на удаленный сервер, который будет позже задан в конфиге <url> и читает результат.

Далее добавляем data template и приводим примерно к следующему виду:

Добавляем graph template.

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

 Теперь, если вы все правильно сделали, все готово для добавления графика. Ждя этого жмакаем кнопку new graphs и в скиске выбираем то, что вы вписывали в название graph template. После нажатия на кнопку добавить, кактус должен бы вас спросить написать адрес откуда брать стату, название создаваемого графика и еще вроде что то. Если каких то полей он не спросил, а должен, проверяйте в созданных шаблонах (template), что бы на нужных полях стояла галочка user per-data value.

После этого все, следите что там рисует кактус, у меня спустя минут 10 уже были видны первые штрихи. Правда меня ожидала еще и неожиданность, о ней в следующем посте =)

Zend Framework: разделение проекта на Core-Custom

Если вам нужно будет разделить проект на две части: ядро и кастом (например если многие части кода используются для нескольких проектов), то одним из вариантов решения такой задачи будет использовать ядро как и раньше, а все что отличается веносить в папки типа Project_custom/application|configs|models и так далее.

Так же важно что бы файлы подключались сразу из cutom папки, и только если не находились там, то брались с ядра.

Для моделей это легко делается правильной настройкой аутолоадера, а точнее даже просто прописать include_paths в правильном порядке.

А вот с контроллерами было сложнее. В конфиге одному модулю можно задать только один путь. А вешать кастомные контроллеры на отдельный модуль в итоге не давало бы возможности перезаписывать стандартные контроллеры.

В общем по итогу у меня родился такой вот изящный результат. Пишем плагин.

class Plugin_CustomController extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$front = Zend_Controller_Front::getInstance();
$dispatcher = $front->getDispatcher();
// здесь указываем путь к кастом контроллерам
$dispatcher->setControllerDirectory(APPLICATION_CUSTOM_PATH.’/controllers’);
if (!$dispatcher->isDispatchable($request))
$dispatcher->setControllerDirectory(APPLICATION_PATH.’/controllers’);   // а здесь контроллеры ядра
}
}

И в бутстрапе подключаем плагин:

Zend_Controller_Front::getInstance()->registerPlugin(new Plugin_CustomController());

Так же еще сходу не знал как сделать возможность перебивания layout-ов, но для них все оказалось еще проще — просто в конфиге проекта указать следующее:

‘resources’ => array(

‘layout’            => array(‘layoutPath’ => array(APPLICATION_PATH.’/layouts/scripts/’, APPLICATION_CUSTOM_PATH.’/layouts/’)),

)

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

Так само указывается путь для подключения скриптов вида:

array(‘resources’ => array(

‘view’ => array(
‘scriptPath’ => array(APPLICATION_PATH.’/views/scripts/’,APPLICATION_CUSTOM_PATH.’/views/scripts/’),
));

UPD: как оказалось, переделать автозагрузчик оказалось не тривиальной задачей. Не буду писать всего, скажу как в итоге сделать правильно. Код правда здесь приводить не могу.

  1. создать один массив resourceTypes с описанием неймспейсов и путей к папкам нужным;
  2. создать два Zend_Loader_Autoloader_Resource в первом путь basePath задать к кастомной части, во втором к core файлам, resourceTypes в этих автозагрузчиках поставить одинаковым;
  3. для Zend_Loader_Autoloader сделать поочередно pushAutoloader сначала для кастом части, а затем для ядра;
  4. правильность подключения файлов без заковыристых namespace-ов обеспечивается указанием includePaths  в правильной последовательности: сначала путь к кастом части, затем к ядру.

Note: не забудьте убрать затем все include/require — это поломает логику правильных автолоадов файлов =)

Уютный сервер на FreeBSD: определяем страну посетителя через nginx (установка GeoIP)

И снова здравствуйте!

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

Итак, как мы помним из предыдущих серий, при установке nginx я выбрал модуль geoip, поэтому порт /usr/ports/net/GeoIp/ уже должен быть установлен, если это не так то вам нужно поставить его дополнительно и потом переустановкить nginx с этим модулем.

Далее качаем бесплатную (или платную, кто что может =) версию бинарной базы geoip:

cd /usr/local/etc/nginx/
mkdir data
mkdir data/geo && cd data/geo
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
gunzip GeoIP.dat.gz

А потом всего лишь добавляем немного конфига:

geoip_country /usr/local/etc/nginx/data/geo/GeoIP.dat;

в секцию http файла nginx.conf (если у вас файл данных геоайпи лежит в другом месте то естественно указываете его)

И что бы этот параметр прокидывался скриптам, добавляем

# GeoIP
fastcgi_param GEOIP_COUNTRY_CODE $geoip_country_code;
fastcgi_param GEOIP_COUNTRY_NAME $geoip_country_name;

В fastcgi_params.

service nginx  restart

И вуаля, в $_SERVER видим что то типа

    [GEOIP_COUNTRY_CODE] => NL
    [GEOIP_COUNTRY_NAME] => Netherlands

xDebug и xdebug.profiler_enable_trigger = 1

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

Решил я пропрофилировать свой проектик, поставил xdebug. Но включать профилирование для всех страниц это просто собирать мусор, нашел опцию xdebug.profiler_enable_trigger которая позволяет включать профилирование по параметру xdebug_profile в гет/посте/сессии либо можно поставить расширение для хдебаг и тогда это вообще будет кнопочкой включаться/выключаться.

Так вот, согластно документации http://xdebug.org/docs/profiler

In order for the trigger to work properly, xdebug.profiler_enable needs to be set to 0.

И я долго не мог понять, почему же все таки оно не работает как надо, а в итоге оказалось что для корректной работы нужно xdebug.profiler_enable как раз в 1 выставить. Тогда для всех страниц профилирования не будет, а для тех что с триггером — будет.

Такие пироги, доки иногда тоже вводят в заблуждение.