Лог действий оператора

Стартовая страница Форумы Новые идеи Лог действий оператора

Просмотр 10 сообщений - с 1 по 10 (из 10 всего)
  • Автор
    Сообщения
  • #16949
    vg
    Участник

    Здравствуйте!

    Не так давно занимаюсь SCADA-системами, но, как я понял, лог действий оператора вещь в целом полезная. Сейчас вижу в логах ScadaServer и ScadaWeb, что информация о действиях присутствует, но она совершенно не раскрыта.

    Например:
    Осуществляю в веб-интерфейсе квитирование. Что вижу в логах?
    ScadaSeverSvc:
    Получена команда 0x0E (квитирование события) от клиента 127.0.0.1

    Нет информации о том какое событие было квитировано, какой номер события, какие значения были зафиксированы во время возникновения события.

    Или изменяю уставки по нажатию кнопки.
    ScadaServerSvc:
    Получена команда 0x06 (команда ТУ) от клиента 127.0.0.1
    Команда ТУ: канал упр. = 2, ид. польз. = 14

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

    В общем интересно планируете ли вы делать отдельный лог действий оператора?

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

    #16957
    Mikhail
    Модератор

    Добрый день!

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

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

    Запросы пользователей на расширенное логирование действий оператора есть. Здесь 2 варианта реализации:
    1. Запись каких-либо ещё действий оператора в архив событий. Например, событие входа в систему.

    Информация о квитировании события хранится в самом событии (только требуется добавить время квитирования).

    2. Запись максимально полного лога действий оператора в отдельную базу данных PostgreSQL: вход и выход в систему, открытие представлений, генерация отчётов, отправка команд, квитирование. Также нужен веб-интерфейс для поиска по журналу.

    2-й вариант более интересен, на мой взгляд. Надеюсь, мы найдём спонсора на его реализацию.

    #16958
    Mikhail
    Модератор

    Архив событий забивать слишком подробными записями о действиях оператора было бы не правильно.

    #16960
    vg
    Участник

    Благодарю за ответ.

    #16966
    manjey73
    Участник

    По варианту 2. Было бы здорово, но вот зачем сюда приплетать Postgre ? Думаю лучше так же встроенная база и возможность экспорта модулем в любую выбранную. + плагин типа Уведомлений и т.д.

    #16970
    Mikhail
    Модератор

    но вот зачем сюда приплетать Postgre ?

    Для удобства поиска. Вариант с отдельным архивом действий оператора на основе файлового формата событий можно отметить как 3-ю опцию.

    #16973
    manjey73
    Участник

    Хм, ну так плагин и должен уметь работать либо с внутренней базой, либо с базой Postgre. Не всегда ведь необходимо устанавливать стороннюю БД при проектах.

    Пока система маленькая, пользуемся внутренним механизмом БД, разрослась, тогда уже устанавливаем Postgre и вперед… (тут неплохо бы при разрастании системы сделать утилиты переноса БД из внутренней в Postgre) это неплохо было бы для многих плагинов. Те же Уведомления (не смотрел пока как оно и что), действий операторов и т.д.

    #16975
    a80808
    Участник

    Хорошая идея про внешнюю базу. У Вега-абсолют сервер так же построен — по умолчанию встроенная, если надо больше — подключается Постгре или МуСкуль… Сервер сам определяет (в конфигурационном файле параметр работы с внешней базой) и сам переносит. Причем если база уже существует, то он дописывает туда то, что во встроенной отличается.

    #16976
    baur
    Участник

    Было бы проще если бы события отправил http\post (асинхронный без разбора ответа) если прописан

    #16977
    baur
    Участник

    потом в природе наверняка существуют универсальные rest api менеджеры, где данные можно раскидать как угодно и куда угодно или поднять свой rest api …

Просмотр 10 сообщений - с 1 по 10 (из 10 всего)
  • Вы должны авторизироваться для ответа в этой теме.