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

[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 логи с клиентской части пойдут на комп клиента. у администратора аксапты могут быть проблемы с доступом к логу на клиентском компе.

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

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

[DSPIC]

Пиши в log файл короче. Что-то мне предсказывает, что это не самое главное в твоей задаче.

[mazzy]

Цитата:

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

Пиши в log файл короче. Что-то мне предсказывает, что это не самое главное в твоей задаче.

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

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

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

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

• проект вламывается в очень базовый класс - кэши. без кэшей аксапта просто не запускается. поэтому кэши должны работать что бы там ни произошло со счетчиками. проинсталированы-не проинсталированы, есть права-нет прав, на сервере-на клиенте. причем должно работать без личного участия администратора. когда делаешь проект для себя, то можно сделать на коленке и в случае чего поправить на лету. когда делаешь проект для публичного выкладывания, то не хотелось бы подставлять людей и рушить их систему
• раз счетчики могут безмолвно и без последствий для системы отламываться, то хотелось бы дать информацию для людей которые используют этот проект. причем удобным для них способом.
• ну и конечно счетчики используются и на сервере, и на клиентах. на клиентских машинах пользователи могут быть вообще не в курсе происходящего.
• проект для акс2012 сделан в черновом варианте. теперь я хочу сделать аналогичный в акс7 но только на эксеншенах (заодно хочу проверить как живется в условиях закрытого кода)
• кроме того, пытаюсь нащупать какой-то баланс "сложности разработки". за основу взял проект https://github.com/DmitryNaumov/PerformanceCounters обратите внимание, как красиво и по делу там используются атрибуты для инсталляции счетчиков, как нормально вписана фабрика вместо конструкторов. как используются интерфейсы для рабочего функционала и для класса заглушки. Заодно проверил скорость разных вариантов реализации. в акс2012 вариант на интерфейсах работает медленнее всего, а вариант на иерархии - вдвое быстрее остальных вариантов. в акс7 ровно наоборот - вариант dummy-класса в иерархии работает вчетверо медленнее остальных вариантов, а вариант на интерфейсах так же быстр как и простой-класс-с-проверками-внутри.

сейчас в работе 6 вариант реализации этих счетчиков. пока я все еще думаю, что в аксапте конструкторы лучше (из-за единого для всех классов namespace). Но аксаптовский класс уже очень хочется раздербанить на SysPerformaceCounter, SysLog, SysPerformaceCounterInstaller. Но это путь к тому, о чем говорил MaxBelugin в ветке про сложность. Но нужны неймспейсы или вложенные классы, чтобы можно было создавать friend-классы, не опасаясь пересечений с другими доработками.

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

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

[Logger]

Цитата:

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

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

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

[Logger]

Цитата:

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

в акс7 ровно наоборот - вариант dummy-класса в иерархии работает вчетверо медленнее остальных вариантов, а вариант на интерфейсах так же быстр как и простой-класс-с-проверками-внутри.

Странный эффект.
А не могло быть так что для 2012-й вы замерили скорость работы p-code ?
Если бы был CIL то скорее всего было бы похоже на 7-ку