Битрикс отслеживание ошибок

• Система отслеживания ошибок средствами Универсальных списков в Битрикс24
• Строим архитектуру
• Фильтр и сортировка ошибок
• Ограничения и неудобства
• Другие возможности применения
• Развитие

Система отслеживания ошибок средствами Универсальных списков в Битрикс24

Многие компании в своей работе сталкиваются с потребностью в использовании системы отслеживания ошибок. Баг-трекера, простым языком. Рассмотрим, как можно использовать возможности Битрикс24 для создания на его основе работающего баг-трекера.

Скажем сразу, описанные возможности не привязаны только к веб-разработке или разработке ПО. Поэтому, мы намеренно называем данный сервис Системой отслеживания дефектов. С помощью сервиса можно организовать передачу сообщений в IT-службу о любых инцидентах или проблемах. Можно построить систему приема заявок от пользователей.

Вам может быть интересно:

Внедрение Битрикс24
Интеграция Битрикс24

Для запуска Системы отслеживания дефектов мы будем использовать механизм Универсальных списков в Битрикс24 (http://www.bitrix24.ru/features/docs.php#lists). Поэтому нам понадобится редакция Компания стоимостью 9990 рублей в месяц. Напоминаем, приобретая лицензию с помощью партнеров компании 1С-Битрикс, можно получить скидку от 5% до 10%.

Конечно, никто не будет использовать Битрикс24 в редакции Компания только для того, чтобы пользоваться Универсальными списками. Но мы ведь с вами рассматриваем решение для бизнеса, верно? Будем считать, что в вашей компании Битрикс24 уже используется совсем для других целей. И вы стремитесь хранить все данные в одном месте, а не распространять их по сети в сторонних сервисах. Пусть даже бесплатных и заслуживающих внимания Redmine (http://www.redmine.org/) и Bugzilla (http://www.bugzilla.org/).

Строим архитектуру

Рассмотрим пример создания баг-трекера для конкретного проекта по разработке сайта.

Универсальные списки могут привязываться к рабочим группам в Битрикс24, а могут использоваться для всех и привязываться к Компании. Рабочая группа является штатным способом ведения проектов. Поэтому, первое, что мы должны сделать – включить в группе функционал Универсальных списков. Перейдите в группу, выберите меню Действия и выберите Редактировать.

В открывшемся окне редактирования группы на вкладке Возможности установите флажок Списки.

После этого на панели группы появится кнопка Списки. Перейдите на страницу Списки и нажмите Добавить.

Если верить Википедии, у систем отслеживания ошибок для каждой ошибки может быть указана следующая информация:

• номер (идентификатор) дефекта;
• кто сообщил о дефекте;
• дата и время, когда был обнаружен дефект;
• версия продукта, в которой обнаружен дефект;
• серьёзность (критичность) дефекта и приоритет решения;
• описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);
• кто ответственен за устранение дефекта;
• обсуждение возможных решений и их последствий;
• текущее состояние (статус) дефекта;
• версия продукта, в которой дефект исправлен.

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

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

На вкладке Подписи указываем подписи для элементов списка и элементов управления списком. Можно использовать привычное Issue для обозначения ошибки.

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

После того, как мы нажмем Сохранить, в разделе Списки появится созданный “Отслеживание ошибок”. Перейдите в список.

Откроется окно списка, в котором пока нет элементов. Для настройки свойств элементов списка нужно перейти на страницу Настройки списка и затем нажать Поля списка. Вы увидите перечень полей, в котором пока что одно Название. Создадим необходимые поля. Для удобства используйте таблицу ниже.

Название поля	Тип	Обязательность	Комментарий
ID	Счетчик	Да
Дата и время создания	Дата создания
Тип ошибки	Список		* Ошибка в коде * Ошибка в верстке * Странность в поведении * Пожелание
Критичность	Список		* Не критично * Нормально (по умолчанию) * Критично
Состояние	Список	Да	* Не принято * Принято * Не удалось повторить * Исправлено * Не будет исправлено * Не подтверждено
Описание	Текст анонса		Использовать визуальный редактор — Да Ширина и высота элемента управления — 600px на 200px
Скриншоты	Файл		Множественное — Да

Можно использовать еще поле типа Детальный текст для расширенного описания ошибки.

После создания полей перейдите в список ошибок и нажмите «Create issue». Откроется окно добавления записи об ошибке. Заполните поля информацией и нажмите Сохранить. Отлично, мы сделали первую запись в нашем баг-трекере!

Фильтр и сортировка ошибок

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

Или найти все “Пожелания”, чтобы проверить, нужно их делать, или нет ))

И даже такой хитрый фильтр, как “Найти все исправленные баги конкретного ответственного за прошлый месяц” сработает:

Ограничения и неудобства

Конечно, описанная технология не идеальна, перечислим несколько очевидных минусов:

Проблема с прикреплением файлов — вам самостоятельно придется делать скриншот, сохранять его на жесткий диск, а только потом загружать в описание ошибки. Это долго и неудобно. Привыкнув к Youtrack с его “Вставить скриншот”, который он сам же и сделает, тяжело перестроиться. Решение — всевозможные сервисы «сделай скриншот и загрузи в сеть по уникальной ссылке». QipShot, Evernote, Awesome Screenshot (дополнение для Chrome) — вот только некоторые из них.

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

Цена внедрения. Самый неприятный минус. Как следствие, у многих пользователей описанный функционал не доступен. Мы уже говорили, покупать редакцию Компания только ради Универсальных списков не имеет смысла. Надеемся, компания 1С-Битрикс в будущем пересмотрит политику лицензирования, и Списки станут доступны, например, в редакции Команда.

Другие возможности применения

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

Перечислим возможные применения:

• Прием заявок от пользователей, или от населения, если вы Управляющая компания.
• Реестр договоров с хранением отсканированных копий файлов. Мы так долгое время и делали.
• База данных сотрудников или клиентских аккаунтов, с различными дополнительными полями. Подойдет для пенсионных фондов etc. Есть мнение, что для них возможностей встроенной CRM будет мало.

Развитие

Пусть Список есть, вы успешно работаете с ним и наполняете информацией. Что дальше?

В любом универсальном списке есть возможность создавать разделы. Поэтому, даже когда число записей станет большим, всегда можно создать папку “Архив” и переместить в нее ранние элементы.

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

Итак, мы рассмотрели баг-трекер с возможностью добавления файлов и назначения ответственных. Мы использовали механизм Универсальных списков в Битрикс24 редакции Компания. Просим поделиться в комментариях другими способами применения Универсальных списков. Спасибо за внимание, желаем отсутствия ошибок при разработке!

Вам может быть интересно:

Внедрение Битрикс24
Интеграция Битрикс24

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

А что если считать ошибки и этот счетчик передавать в уже настроенный мониторинг Zabbix? Добавляем highloadblock ErrorCounter с одним единственным полем «UF_CREATED» типа дата/время со значением по умолчанию — текущее время. Создаем кастомный обработчик ошибок:

namespace MyNamespace\Monitoring;

use Bitrix\Main\Diag\FileExceptionHandlerLog;
use Bitrix\Main\Loader;
use Bitrix\Main\ORM\Data\DataManager;
use Exception;
use Bitrix\Highloadblock\HighloadBlockTable;

Loader::includeModule("highloadblock");

class ExceptionCounter extends FileExceptionHandlerLog {

    /**
     * @param Exception $exception
     * @param int       $logType
     */
    public function write($exception, $logType) {
        parent::write($exception, $logType);

        self::getCounterDataClass()::add([]);
    }

    /**
     * @return DataManager|string
     */
    public static function getCounterDataClass() {
        return HighloadBlockTable::compileEntity("ErrorCounter")->getDataClass();
    }

}

В .settings.php прописываем наш класс в свойство class_name:

  'exception_handling' => 
  array (
    'value' => 
    array (
      'debug' => true,
      'handled_errors_types' => 4437,
      'exception_errors_types' => 4437,
      'ignore_silence' => false,
      'assertion_throws_exception' => true,
      'assertion_error_type' => 256,
      'log' => 
      array (
        'settings' => 
        array (
          'file' => 'error.log',
          'log_size' => 1000000,
        ),
        'class_name' => 'MyNamespace\Monitoring\ExceptionCounter',
      ),
    ),
    'readonly' => false,
  ),

После этого, при возникновении исключения, в счетчик записывается значение. Лог также пишется, как раньше.

Далее дело техники. Делается запрос выбора записей за последние сутки, считается количество результатов. Это и будут данные для наблюдения в Zabbix. Если значение 0, значит ошибок за день не было, если больше 0 — показывать триггер

Если есть сообщение — иду в логи смотреть что произошло, нет — курю бамбук. Момент фильтрации ошибок для счетчика опустил. Бывает что не нужно фиксировать проблему, например если код выполняется администратором из консоли PHP в админке. Отправку данных счетчика в Zabbix выполнил через расширение GraphQL схемы.

Любопытно посмотреть график возникновения ошибок за период:

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

qaa-engineer.ru > Битрикс > Как производить мониторинг ошибок и исключений на сайте, работающем на CMS 1С-Битрикс?

Для мониторинга ошибок и исключений на сайте, работающем на CMS 1С-Битрикс, можно использовать следующие методы:

1. Логирование ошибок и исключений в файлы логов. Каждая ошибка и исключение будет записано в соответствующий файл лога, который можно просмотреть и проанализировать. Для этого необходимо включить логирование в настройках системы.

2. Использование специальных компонентов и модулей, которые могут помочь отследить ошибки и исключения в системе и вывести их в удобочитаемом формате. Например, компонент «Отчет об ошибках» позволяет отследить все ошибки, которые произошли в системе, и вывести их в удобной таблице.

3. Использование внешних сервисов мониторинга, таких как Sentry или Bugsnag, которые могут собирать информацию об ошибках и исключениях и отправлять уведомления на email или в социальные сети. Эти сервисы можно интегрировать в 1С-Битрикс, используя специальные модули и плагины.

Обработка ошибок в Битрикс

При разработке под Битрикс можно пользоваться не только логами, установленными в конфигурации сервера, но и своими. Для этого нужно настроить обработчик ошибок в секции exception_handling в файле /bitrix/.settings.php.

'exception_handling' =>
    array (
        'value' =>
            array (
              'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_STRICT & ~E_USER_NOTICE & ~E_DEPRECATED,
              'exception_errors_types' => E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_USER_WARNING & ~E_USER_NOTICE & ~E_COMPILE_WARNING,
              'ignore_silence' => true,
              'assertion_throws_exception' => false,
              'assertion_error_type' => 256,
              'debug' => true,
              'log' => array (
                            'settings' => array (
                            'file' => 'bitrix/modules/error.log',
                            'log_size' => 1000000,
                            ),
            ),
    ),
),

• handled_errors_types — типы обрабатываемых ошибок

• exception_errors_types — типы ошибок, в случае которых системой выбрасывается исключение, и работа скрипта останавливается

• ignore_silence — отменить действие оператора подавления ошибок (значок @ перед функцией, например @file(), документация).

• assertion_throws_exception — выбрасывают ли утверждения (assert()) исключения.

• assertion_error_type — тип ошибки для неверного утверждения (по умолчанию — 256 E_USER_ERROR)

• debug — если выставить debug = true, информация об ошибке будет выведена пользователю в браузер. Если debug = false, при возникновении ошибки будет выведено стандартное сообщение от Битрикс, кроме ошибок E_ERROR | E_PARSE

if ($this->debug)
{
    error_reporting($this->handledErrorsTypes);
    @ini_set('display_errors', 'On');
    @ini_set('display_startup_errors', 'On');
    @ini_set('report_memleaks', 'On');
}
else
{
    error_reporting(E_ERROR | E_PARSE);
}

При отключении режима отладки, также сбрасываются настройки для assert()

if ($this->debug)
{
  assert_options(ASSERT_ACTIVE, 1);
  assert_options(ASSERT_WARNING, 0);
  assert_options(ASSERT_BAIL, 0);
  assert_options(ASSERT_QUIET_EVAL, 0);
  assert_options(ASSERT_CALLBACK, array($this, "handleAssertion"));
}
else
{
   assert_options(ASSERT_ACTIVE, 0);
}

• log — секция с указанием логгера. Если пусто, то запись ошибок происходить не будет. В данном случае по умолчанию всю работу на себя возьмет объект класса \Bitrix\Main\Diag\FileExceptionHandlerLog.
• settings — секция с настройками обработчика ошибок. Можно задавать произвольные параметры. Они все передадутся массивом в метод initialize() обработчика.
• file — относительный путь к файлу логов от корневой директории сайта (\Bitrix\Main\Application::getDocumentRoot().’/’.$file).
• log_size — максимальный размер файла логов в байтах.

Можно использовать собственный обработчик ошибок для записи логов. Для этого в секции log нужно указать:

'class_name' => 'MyLog',
'extension' => 'MyLogExt',
'required_file' => 'modules/mylog.module/mylog.php'

• class_name — имя класса-обработчика. Класс должен наследоваться от Bitrix\Main\Diag\ExceptionHandlerLog. Метод write в 16 версии отличается от реализации в 15 версии, эта несовместимость может сломать сайт, будьте внимательны.
• extension — подключаемое расширение, содержащее класс-обработчик
• required_file — файл, содержащий нужный класс.

Модули АХТУНГ 500 И АХТУНГ 500 ПРО

Модули Ахтунг 500 и Ахтунг 500 ПРО предназачены для мгновенного оповещения об ошибках по e-mail и через браузер, когда администратор находится на сайте.

Мониторинг ошибок происходит не только через обработчик ошибок Битрикса, но и через чтение файлов логов сервера, есть поиск.

Перейти к подробному описанию Ахтунг 500 ПРО