Как правильно информировать об ошибках из фоновой обработки/демона?

[mazzy]

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

такая служба скорее всего будет реализована пакетным заданием
ну или вручную при помощи tread на сервере.

главное, что infolog этой службы будет недоступен ни пользователю, ни администратору.

как на ваш взгляд правильно информировать пользователя об ошибках такой службы?
* Windows EventLog?
* SysExceptionLog
* хитрая модификация infolog? какая?
* что-то еще?

и почему вы считаете ваш способ правильным?

спасибо.


============================
upd:
пакетное задание сохраняет инфолог в базе. и это штатный функционал. поэтому для пакетного задания можно и нужно использовать infolog.

[macklakov]

Цитата:

Сообщение от mazzy

как на ваш взгляд правильно информировать пользователя об ошибках такой службы?

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

[DSPIC]

Я бы сделал кастомную таблицу для логирования. Она будет доступна через Inquiry + на нее можно будет настроить штaтный EventNotification + опционально, рассылку по e-mail с выводом сообщения об ошибки. Опуионально, ее можно будет дублирровать в Windows EventLog. Но в целом, никто не мешает делать все стандартно, где все логируется стандартным BatchFramework, хотя он не очень удобный и пакует Infolog в контейнер, что heavy.

e.g. Вложение 11543

[Logger]

Цитата:

Сообщение от mazzy

такая служба скорее всего будет реализована пакетным заданием
ну или вручную при помощи tread на сервере.

главное, что infolog этой службы будет недоступен ни пользователю, ни администратору.

Недавно решал такую проблему.
Сделал простенькую модификацию класcа info. В пакетном режиме он пишет в специальную табличку лога все сообщения выводимые в инфолог, тип исключения, стек вызовов, SessionId, AOSid.
Запись идет через отдельное соединение к базе.

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

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

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

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

А вообще можно по-разному реализовать. Это дело вкуса.

[mazzy]

Цитата:

Сообщение от macklakov

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

ну... отдельная база все-таки перебор.
отдельный connectoin - да. см. SysExceptionLog.

а лог-таблицы беспокоят давно ) http://axapta.mazzy.ru/lib/dbgrowthsolution/

Цитата:

Сообщение от Logger

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

ну... делать кастомную можно.
Но уже есть SysExceptionLog.
Правда этот класс и эта таблица изначально создавались для AIF.

Цитата:

Сообщение от Logger

А вообще можно по-разному реализовать. Это дело вкуса.

Именно.
Поэтому и спрашиваю не "как", а "как правильно" ))))

Цитата:

Сообщение от DSPIC

Но в целом, никто не мешает делать все стандартно, где все логируется стандартным BatchFramework

да, согласен, про кастомную. и согласен, что AIF.

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

наверное стоит рассказать о задаче.
собственно хочу опубликовать свою поделку для измерения кэшей.
это код, который "цепляется" к SysGlobalCache и "живет" на самых ранних этапах инициализации аксапты.

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

собственно из этого появляется по крайней мере два сообщения администраторам системы - не хватает счетчиков и не хватает прав для изменения счетчиков.

ключевой момент - на этапе, когда нужно вывести сообщение, еще нет инфолога. и это не пакетное задание.

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

напрашивается Windows Event Log - но в виндовый eventLog живет только на компьютере, где создается этот eventLog. а клиент и сервер - разные машины. на которые у администратора аксапты права могут отсутствовать.

SysExceptionLog - живет в таблицах аксапты. Но что-то я сомневаюсь, что администратор догадается туда посмотреть. в кастомные таблицы - точно не догадается.

Цитата:

Сообщение от mazzy

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

[Zabr]

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

[mazzy]

Цитата:

Сообщение от Zabr

У нас инфолог при ошибке пакетного задания

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

исправлю название ветки.

[Ivanhoe]

Может, все-таки стандартное оповещение (eventbox) на группу администраторов?

[mazzy]

eventbox? можно ссылку?

[Ivanhoe]

Цитата:

Сообщение от mazzy

eventbox? можно ссылку?

Ошибся, таблица EventInbox для версии 2009 / 2012, семейство классов EventNotification*.

В стандарте оповещения создаются на основании правил, которые пользователь сам настраивает, но, например, пакетные задания при явной настройке создают оповещения напрямую. Мы часто используем механизм для доп. оповещений пользователей о различных событиях в системе без настройки правил, см., например, тему с доработкой механизма для большего удобства админов и пользователей: Проект расширения стандартных оповещений AX 4.0

[Ivanhoe]

Только пишут, что еще их нет в d365, это так?

[mazzy]

Цитата:

Сообщение от Ivanhoe

Только пишут, что еще их нет в d365, это так?

хм...
в акс7 семейство классов EventNotificationWorkflow присутствует.
и даже код вроде не изменен.
но сообщения, созданные как в ax2012, в колокольчик не уходят.

да, насколько я понимаю, в акс7 "колокольчиком" манипулируют другие классы.
но почему из EventNotification не сделали вызов новых классов - не понятно.
Или чего-то переключить/настроить надо.
надо подумать. спасибо

[Ivanhoe]

Цитата:

Implementation of the alerts functionality is planned for a future update. Alerts help users keep track of data changes in the system.

Отсюда: https://docs.microsoft.com/en-us/dyn...itpro/toc.json

[mazzy]

что возвращает нас к исходному вопросу. )

Цитата:

Сообщение от mazzy

как на ваш взгляд правильно информировать пользователя об ошибках такой службы?

[EVGL]

Windows Event Log
Не понимаю аргумент, как у Администратора системы может отсутствовать доступ к серверу, на котором она работает. Что он администрирует тогда? Кроме того, доступ к логу можно получить в удаленном режиме.

[mazzy]

Цитата:

Сообщение от EVGL

Windows Event Log
Не понимаю аргумент, как у Администратора системы может отсутствовать доступ к серверу, на котором она работает. Что он администрирует тогда?

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

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

Цитата:

Сообщение от EVGL

Кроме того, доступ к логу можно получить в удаленном режиме.

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

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

пока склоняюсь к мысли, что правильнее всего писать одновременно и в виндовый лог, и в колокольчик администратора аксапты.

[EVGL]

Цитата:

Сообщение от mazzy

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

Бывали. Вы же не для AX 2012 спрашиваете? LCS администрирует один человек или группа людей, но все сразу - и серверы, и подключения для внешних приложений, и БД.

[mazzy]

Цитата:

Сообщение от EVGL

Вы же не для AX 2012 спрашиваете? LCS администрирует один человек или группа людей, но все сразу - и серверы, и подключения для внешних приложений, и БД.

для акс7 - резонно.
но спрашиваю и про акс2012, и про 2009. народ с ними работает.

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

[Logger]

Цитата:

Сообщение от EVGL

Windows Event Log
Не понимаю аргумент, как у Администратора системы может отсутствовать доступ к серверу, на котором она работает. Что он администрирует тогда? Кроме того, доступ к логу можно получить в удаленном режиме.

Если вы меня спрашивали, то я имел в виду сотрудника техподдержки из первой линии. У нас на проекте их права на серверах урезаны.

[macklakov]

Цитата:

Сообщение от EVGL

Windows Event Log
Не понимаю аргумент, как у Администратора системы может отсутствовать доступ к серверу, на котором она работает. Что он администрирует тогда? Кроме того, доступ к логу можно получить в удаленном режиме.

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