Собственный тип пользовательских полей в 1с битрикс

Введение

Суть задачи сводится к тому, чтобы добавить новое поле в index elasticsearch, в котором будет содержаться id сессии пользователя в простом текстовом виде. Далее по этому полю можно будет делать группировку, чтобы посмотреть перемещение пользователя по сайту и другую информацию о его запросах.

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

Я буду показывать настройку на примере сайта на Bitrix. В WordPress все это настраивается точно так же, один в один.

Пользовательское свойство «Цвет»

Давайте разберёмся с более экзотическим классов «Цвет». Иногда нужно дать возможность контент-менеджеру определять цветовую схему элемента (новости, статьи или какой-то части её оформления), обычно для этого создаётся простое свойство типа «строка» куда записывается цвет скопированный из Photoship или ColorPicker, однако это требует больше действий от контентщика. Давайте реализуем такой функционал прямо внутри элемента.

За основу возьмём стандартный класс типа пользовательского поля «Строка» и определим для него необычный внешний вид (метод GetEditFormHTML()) . Нам так же потребуется какой-нибудь jQuery плагин для выбора цвета, я остановил свой выбор на jQuery ColorPicker он обладает нужным функционалом имеет необходимые события и довольно прост в настройке.

И так, для начала скачаем этот плагин и загрузим всё в /local/media/ как помните выше я определил константу APP_MEDIA_FOLDER.

Часто задаваемые вопросы по теме статьи (FAQ)

Подойдет ли этот же grok фильтр для парсинга логов в logstash?

Да, подойдет. Формат grok фильтров одинаков и в ingest node, где в данном случае происходит обработка логов, и в logstash.

Есть ли разница в настройке Elastic Cloud и собственного ELK сервера?

Принципиальной разницы в настройке нет. Это абсолютно одинаковые продукты. Первый развернут в публичном облаке, второй на ваших собственных серверах.

Будут ли корректно обрабатываться логи, если в них не будет присутствовать запись с session id?

Да, будут. В фильтре перед %{WORD:session_id} стоит вопросительный знак, который делает необязательным наличие этой строки в логе.

Реальный ip адрес посетителя bitrix в логах apache

Если вы используете преднастроенное окружение bitrixenv, то ничего особенного для вывода реального ip адреса в лог apache делать не надо. Напомню, для тех, кто не в курсе, о чем идет речь. Bitrixenv — набор рецептов ansible, которые автоматически разворачивают веб сервер на основе nginx и apache. На nginx приходят все запросы клиентов, а дальше проксируются на apache для исполнения php кода. Если ничего дополнительно не настраивать, то в логах apache все запросы будут с ip адреса 127.0.0.1.

При этом, в bitrixenv в настройках nginx для сайтов указано, что реальный ip адрес посетителя надо записывать в отдельный заголовок.

В apache можно взять информацию из этого заголовка и поместить сразу в лог файл.

Все, этого достаточно, чтобы в лог файле apache выводился реальный ip адрес посетителя. Теперь разберемся с session id.

Создаём класс для определения своего пользовательского свойства

Как вы уже поняли и листинга файла с константами, наши классы будут лежать в директории /local/php_interface/lib/. Я предпочитаю разделять собственные классы на группы по директориям, например классы для работы с инфоблоками храню в папке Iblock, работы с каталогом в Catalog, для пользовательских свойств предлагаю создать папку UserType.

И так в директории /local/php_interface/lib/UserType/ создадим 2 файла CUserTypeUserId.php и CUserTypeColor.php. Начнём со свойства «Привязка к пользователю».  Определим пространство имён, подключим доп.классы ядра.

  • GetList() — Получаем список значений
  • GetEditFormHTML() — Получить HTML формы для редактирования свойства
  • GetEditFormHTMLMulty() — Получить HTML формы для редактирования МНОЖЕСТВЕННОГО свойства
  • GetAdminListViewHTML() — Получаем HTML для списка элементов в админке
  • getEmptyCaption() — Получаем текст для пустого значения свойства
  • GetAdminListEditHTML() — Получить HTML для редактирования свойства в списке админ-панели
  • GetAdminListEditHTMLMulty() — Получить HTML для редактирования МНОЖЕСТВЕННОГО свойства в списке админ-панели
  • GetFilterHTML() — Получаем HTML блок для фильтрации списка элементов по этому свойству

Я не стану размещать здесь все методы, хочу отметить лишь GetList(), т.к. в стандартных классах он обычно возвращает объект CDBResult, а мне больше нравится подготовить данные для отображения заранее, поэтому в нём я получаю массив значений для отрисовки его в методах GetEditFormHTML() и подобных:

GetEditFormHTMLMulty()

  • GetAdminListViewHTML()
  • GetAdminListEditHTML()
  • GetAdminListEditHTMLMulty()

Значение свойств будут так же корректно отображаться и редактироваться в списке элементов:

Добавление произвольного поля в Elastic Cloud

Перемещаемся в Kibana. Первым делом проверим, какой pipeline для обработки логов загружен в Elasticsearch. Для этого идем в интерфейс Kibana, в раздел Dev Tools -> Console и вводим туда запрос

Запоминаем точное название пайплайна — filebeat-7.6.2-apache-access-default. Напоминаю, что такое pipeline. Мы используем легковесный filebeat для передачи логов в elastic. В отличие от logstash, filebeat сам не умеет выполнять сложный парсинг логов на основе grok фильтров. Этим занимается сама нода elastic на основе pipeline, который ей передает filebeat.

Теперь идем на целевой сервер, где работает apache и filebeat. Дефолтный pipeline должен располагаться в файле /usr/share/filebeat/module/apache/access/ingest/default.json. Необходимо проверить, что его содержимое соответствует тому, что было в выводе в консоли Kibana. В дефолтной установке это должно быть так.

Нам нужно изменить этот pipeline. Для этого останавливаем filebeat.

Редактируем default.json, предварительно сохранив копию исходного файла на всякий случай.

Берем следующий блок:

И приводим его к следующему виду:

Важно соблюдать структуру файла, все табуляции, отступы и пробелы. Мы добавили в конец новое поле для парсинга через встроенный grok фильтр ?%{WORD:session_id} и удалили лишние фильтры, которые нужны для совместимости с разными версиями apache

Предложенный фильтр проверен на версии Apache/2.4.6 и его стандартном формате логов, плюс текстовое поле с сессией

Мы добавили в конец новое поле для парсинга через встроенный grok фильтр ?%{WORD:session_id} и удалили лишние фильтры, которые нужны для совместимости с разными версиями apache. Предложенный фильтр проверен на версии Apache/2.4.6 и его стандартном формате логов, плюс текстовое поле с сессией.

Так же для удобства рекомендую удалить строки ниже:

Тогда в elastic будут в том числе сохраняться строки из лога в оригинальном виде, а не только распарсенные значения. Это бывает полезно для разбора полетов. По-умолчанию они удаляются для экономии места.

Теперь возвращаемся в консоль Kibana и удаляем текущий pipeline из elastic, так как мы туда загрузим новый.

Идем на сервер и запускаем filebeat

Смотрим его лог на наличие ошибок. Их быть не должно. Если есть, то надо проверять внимательно default.json, не нарушен ли его формат при редактировании

Расположение пробелов и отступов важно. При проверке статуса сервиса ошибок быть не должно

Видим, что новый pipeline загружен. Идем в консоль Kibana и проверяем, что это так.

Идем в Discovery и проверяем наличие нового поля session_id. Рядом с ним должен быть восклицательный знак.

Идем в Management -> Kibana -> Index Patterns. Выбираем индекс filebeat-* и жмем справа вверху на обновление — refresh field list.

После этого тут же проверяем через поиск, что в индексе появилось новое поле session_id.

Теперь можно вернуться в Discovery и осуществлять поиск по полю session_id.

На этом все. Новое поле в elasticsearch добавлено. Можно использовать в визуализациях и дашбордах.

Вывод Session ID посетителя Битрикс в лог apache

Каждому посетителю сайта на Битриксе прописывается в Cookie PHPSESSID с уникальным идентификатором сеанса. Он остается постоянным в рамках одного посещения. По крайней мере на первый взгляд это так. Я не занимался подробно исследованием того, как это работает. Задачи не стояло.

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

Если хотите вывести в лог все содержимое куки, то используйте такую конструкцию — %{Cookie}i. В нашем случае это излишне. Хватит только PHPSESSID. Перезапускаем apache и смотрим, что у нас будет в логе.

IP адрес и ID сессии присутствуют в логе. В данном случае ip адрес серый, потому что тестовое окружение настроено в локальной сети. Теперь нам нужно настроить grok фильтр elastic на парсинг измененного лог файла. Затем добавить новое поле в индекс elasticsearch, чтобы с ним можно было работать.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: