modMonitor 2+

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

Сегодня я выкатил обновленную версию компонента modMonitor, который так же, возможно, кому-нибудь немного расстроил сон. Во всяком случае обсуждений было много.



Итак, что добавилось?

1. Учет вложенности элементов. Вот эта штука изначально планировалась, но являлась одной из двух сложнейших задач. Пример: вызывается у нас сниппет, внутри которого выполняется еще несколько вызовов сниппетов и чанков, а у тех еще вложенные вызовы есть. И вот эту вложенность и хотелось видеть, так как общий список вызванных элементов не очень был информативен, не было понятно где какой вызов выполнялся. Сейчас эту вложенность видно.



Согласитесь, так гораздо удобнее.

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

2. Учет реферальных страниц для ajax-запросов. Это была вторая из сложных задач. Надо было понимать, какие страницы напрямую вызваны, а какие в следствии ajax-запросов. Зачем это нужно? Не раз встречал, что заходя на страницу, с нее отправляются на сервер еще пара-тройка (а то и более), запросов, при чем часто на саму же себя. Пример:



То есть здесь, при заходе на страницу, мы получаем еще три запроса на текущую страницу. Эти запросы видно и по отдельности (с признаком parent), и в раскрываемой информации о запросе (с иконками глобуса — это дочерние ajax-запросы).

Здесь поделюсь очень полезным кодом:

$js = "<script type=\"text/javascript\">
    window.modMonitorObjectId = {$modMonitor->request->id};
    (function(open) { 
        XMLHttpRequest.prototype.open = function(method, url, async, user, pass) {
            open.call(this, method, url, async, user, pass);
            this.setRequestHeader('modmonitor-object-id', window.modMonitorObjectId);
        };
    })(XMLHttpRequest.prototype.open);
</script>";

При вызове данная функция переопределяет метод open родного оконного механизм Ajax-запросов XMLHttpRequest таким образом, чтобы при запросах сразу подставлялся пользовательский параметр в заголовках. Далее уже на стороне сервера я ловлю переданный идентификатор в заголовках, и если он есть, выставляю родителя.

3. Добавились фильтры запросов.
— В строчное поле можно прописать запрос, который учитывается так:
Если это число, то ищет либо запрос с указанным ID, либо документ с указанным ID.
Если это строка, тогда уже идет поиск по строке адреса запроса. Здесь я не стал делать поиск по маске, так как при неточном поиске будет слишком сложно искать более релевантную информацию. То есть если у вас страницы были запрошены по адресу /office/lk/, нельзя их будет увидеть, вбив просто “office”. В таком случае будет выполняться поиск страниц, запрошенных именно по адресу office (такие вряд ли будут когда). Это важно учитывать. Но зато можно использовать родные sql-спецсимволы, такие как % — любое количество любых символов и подчеркивание _ — один любой символ. Так по запросу /office/% будут найдены и /office/, и /office/lk/ и т.п., а по запросу /office_, только /office/. А вот так %office%?% будут найдены документы типа /office/?.. или …../office/….?..
Уверен, вы разберетесь, документация по SQL всегда поможет.
В дальнейшем планирую добавить поддержку регулярных выражений.
— В поле “Время” можно указать время в секундах (можно дробных), чтобы вывести только те запросы, которые по времени выполнялись дольше указанного.
— Кеш. Выпадающий список. Можно отфильтровать только те запросы, которые сформированы из кеша, или наоборот не из кеша.

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

4. Мониторинг теперь работает не только при обработке документов. По сути, он сейчас работает при любом вызове MODX-а. Даже если вы в Console выполните $modx->runSnippet($snippetName);, этот запрос будет зафиксирован и сохранен. Это особенно полезно для мониторинга Ajax-запросов, в том числе на коннекторы.

Здесь только оговорочка: если это выполняется в контексте mgr, то такой запрос может быть не зафиксирован. Об этом подробней в следующем пункте.

5. Добавлена системная настройка modmonitor.exclude_contexts. По умолчанию прописано mgr, но можно очистить ее, или наоборот через запятую перечислить контексты, в которых не будет выполняться сохранение статистики.

6.Добавлена системная настройка modmonitor.min_time_for_save. По умолчанию пустая. Сюда можно указать в секундах время (например, 0.3), и если общее время запроса будет меньше этого времени, то этот запрос не будет сохранен в базу данных, что существенно снизит объем хранящейся в базе информации.
Хотя лично я против этого. Если у вас не будет информации о хороших запросах, то как вы узнаете, что сайт по большей степени хорошо работает? Надо, указав минимальное пороговое время, увидеть всего не более 10% запросов (являющихся проблемными), что будет говорить о нормальном состоянии сайта. А если вы будете видеть только плохие, то не с чем будет сравнивать. Да, информации храниться будет много лишней, но, во-первых, можно фильтровать эту информацию, а во-вторых, и вовсе отключать плагин модмонитора, если вы ведете отладку только в риалтайме.

7. Добавлена таки кнопка очистки собранной статистики.


Статистика очищается через truncate table, так что и быстро получается (несколько сотен тысяч записей должно вообще легко очищать), и счетчик айдишников сбрасывается.

8. Добавлена ссылка с переключением на пользователя.


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

Ну и напоследок несколько кейсов с использованием modMonitor.

1. Глобальное отключение кеширования ресурсов.
Вот это, честно говоря, мне не очень понятно зачем люди делают. Тем не менее за пару недель на тройке сайтов уже встречал. Начинаешь анализировать статистику и видишь там такое:


То есть все документы не из кеша берутся, даже при повторном заходе. Такое сразу в глаза бросается.
В чем же проблема? Народ зачем-то идет в системные настройки и выставляет cache_resource = 0.
Не надо так! В таком случае не просто все элементы на странице не кешируются, но и в целом документ не кешируется (включая настройки политик безопасности, ТВ-поля и т.п.). Из-за этого нагрузка на сервер сильно возрастает. Переживаете за кеширование и хотите чтобы для всех пользователей все элементы вызывались не кешируемые, не жалейте плюсиков, прописывайте их всем элементам. Даже если вообще все элементы у вас будут не кешируемые, разница в нагрузке будет ощутимая, если вы полностью отключаете кеширование документов.

2. Лишние ajax-запросы. Про это я уже выше упоминал. В одном случае их плодит гугл-тагманагер (почему три запроса вместо одного, не знаю, не ковырял еще). В другом случае просто логическая ошибка в пользовательских скриптах, из-за чего одно и то же событие несколько раз вызывалось.

3. Разбор большого количества вызываемых элементов.
Достался сайт на оптимизацию, так там вот такой ужас творится:


Одних только pdoResources 38 вызовов.


Жесть, как она есть. Разбираться в таком без модмонитора сложно в том плане, что элементов много, но далеко не все они дают серьезную нагрузку. Вычленить из общей кучи только нагруженные элементы и заняться конкретно ими, не распыляясь на мелочь — это серьезная экономия времени.

4. Поиск потерянных элементов.
modMonitor умеет сообщать о вызываемых, но не найденных элементах. Например, вот о таком сообщил один пользователь:

еще ошибка в логе

(ERROR @ /***/www/core/components/modmonitor/model/modmonitor/parser/modmonitorparser.class.php : 79) Не был получен элемент modSnippet [['"±","©","©","®","©","©","®","
"],["±","©","©","®","©","©","®"," "']]

А тут он вот это правило в Jevix воспринимает как снипет

<meta property="og:description" content="[[Jevix? &input=`[[*introtext]]` &cfgAllowTags=`` &cfgSetAutoBrMode=`0` &cfgSetAutoReplace=`[["±","©","©","®","©","©","®","
"],["±","©","©","®","©","©","®"," "]]`]]">

На самом деле совсем не зря MODX-парсер воспринимает это как сниппет, ведь синтаксис соответствует.
Вот мой развернутый ответ на этот счет:

Это не modMonitor ошибается. modMonitor кушает то, что находит MODX-парсер. А он это воспринимает как сниппет. Синтаксис-то соответствует. Просто MODX-парсер работает в двух режимах:
1. Не найденные теги не очищаются.
2. Не найденные теги очищаются.

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

Чтобы нормально работало и все рады были, достаточно пробелы поставить между квадратными скобками, вот так:

[ ["±","©","©","®","©","©","®",""],["±","©","©","®","©","©","®"," "] ]

Кстати, есть еще одна хитрость. Если в настройках включить modmonitor.debug = 1, то в логах можно увидеть такие записи:

[2016-11-13 15:24:53] (ERROR @ /var/www/core/components/modmonitor/model/modmonitor/parser/modmonitorparser.class.php : 85) Не был получен элемент modSnippet 'some_snippet'

А если при этом включить плагин Debug из пакета modxSite, то можно увидеть подобную картину:


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

Вот как-то так. Демо-версия так же доступна на сайте modmonitor.ru/ (регистрируемся во фронте и со своим логином-паролем идем в админку смотреть статистику).

По традиции пакет выходит в статусе beta (просто я так привык), тем не менее основа заложена плотно, предыдущая модель лишь чуть-чуть расширена, так что предыдущая статистика не пропадет.

Если кто обновляется, сразу предупреждаю, что пакет переустановить надо пару раз (просто в менеджере пакетов после установки новой версии еще раз нажать Переустановить). Это отдельная песня. Модуль добавляется в extensionPackages, и в момент установки его модель уже получена MODX-ом. При этом он должен на уже существующие таблицы добавить пару колонок. Но в текущей модели именно в этот момент информации об этих колонках у него нет, потому он их не может создать. При повторной установке модель уже корректно формируется при инициализации MODX-а и колонки новые формируются. В общем, при установке должна быть ругань на то, что не может создать колонки parent и properties, так как они уже существуют. Тогда все ОК уже.
И не забудьте после установки принудительно сбросить кеш сайта.

P.S. Напоминаю, что сегодня последний день продажи компонента со скидкой 30%. Завтра уже будет стоить полную цену и скидок больше не будет. Зато то ли еще будет новенькое в следующих версиях. Держите свои сайты под контролем!
Два пакета уже взяли.

P.P.S. Для, тех, кто все еще считает, что это не стоит 5000: я сегодня просидел к ряду 21 час (с перерывами на покушать и в туалет). Если кто считает, что он легко и быстро такое накатать может и продавать по три рубля (еще и профит получать), повторюсь: первая версия лежит на гитхабе, качайте, прокачивайте, продавайте.

P.P.P.S. Количество продаж уже 4 шт. Компонент получает финансирование и гарантированно будет развиваться.