#111 closed улучшение (fixed)
Журнал событий
| Сообщил: | san | Владелец: | alx |
|---|---|---|---|
| Приоритет: | Срочно | Этап разработки: | 1-я очередь |
| Ключевые слова: | Копия: | alx, art_M |
Описание (последним изменил )
- Лог и "Журнал событий" пишем отдельно
- Настройка "ведение журнала нормально/подробно" должна действовать на "Журнал событий" согласно тз:
Если Ведение журнала = подробно, то для каждой записи следует сохранять текущее состояние привода в момент записи, т.е. нагрузку на штоке, давление, токи двигателей, частоты двигателей, температуру масла, состояние клапанов, состояние датчиков положения.
- В "Журнал событий" сообщаем только следующее
- запуск программы (включения питания, перезагрузки).
- авт/руч/стоп
- возникновение и снятие аварий
- изменение настроек контроллера
- изменение числа качаний интеллектуальным режимом и условный коэф. наполнения
- отметки об АПВ
- пометки и снятие пометок о неисправности НУ и ЭК
- "текущее состояние привода"
- В лог пишем всё что угодно, размер памяти выделенной для лога увеличиваем в рамках разумного.
- С панели оператора должна быть возможность просматривать "Журнал cобытий" с фильтрацией по подпунктам перечисленным в п.3
- При использовании функции сохранения Журнала на портативный носитель - копировать и Журнал событий и лог.
История изменений (60)
comment:2 by , 6 лет ago
Это когда настройка "Ведение журнала" установлена в значение "нормально", а не "подробно".
comment:3 by , 6 лет ago
Сейчас планируется запуск первой станции в тестовую эксплуатацию, при этом пользователям явно потребуется знать были ли какие-то аварии на станции, например в прошлый день или позапрошлый. Но как и указано в тикете всей памяти лога хватит всего лишь на несколько часов.
comment:5 by , 6 лет ago
Конечно с включенным, но благодаря записям о срабатывания датчиков и другой избыточной информации, лога всё-равно не хватит на долго. Примерно 5 дней, учитывая только записи о датчиках положения при ~3кач/мин, а ещё таймауты от ЧРП и ещё какие-то записи от модема и др.., думаю что на день-два в лучшем случае.
comment:7 by , 6 лет ago
Может быть имеет смысл в настройке "Ведение журнала" сделать немного больше градаций подробности, чем две?
следующий: 10 comment:8 by , 6 лет ago
С журналом вообще надо переосмыслить.
Где можно ознакомиться с полным перечнем "событий" которые могут попасть в журнал?
comment:9 by , 6 лет ago
Ещё Андрей предложил интересный, на мой взгляд, вариант: разделить лог на 2 лога(краткий и подробный отдельно). Подобным образом у нас в SW-01 сделано: есть журнал аварий в котором только аварии, и есть лог в котором всё.
следующий: 11 comment:10 by , 6 лет ago
Replying to andrei:
Где можно ознакомиться с полным перечнем "событий" которые могут попасть в журнал?
В исходных кодах всех установленных пакетов.
comment:11 by , 6 лет ago
В исходных кодах всех установленных пакетов.
Для меня это слишком долго будет.
Буду читать логи и меню панели оператора.
следующие: 16 17 comment:12 by , 6 лет ago
Предложение. Объединить события, которые наступают каждый опрос. Например не фиксировать в нормальном журнале каждый сброс питания SIM5320. Достаточно записи когда он стал недоступен (давайте придумаем строгое определение) и записи, когда доступен снова.
Вопросы.
comment:13 by , 6 лет ago
Можно я, можно я отвечу) ?
- ошибка разрешения пула ntp.ubuntu.com: временно ошибка в разрешении имени (-3) ntpd [373]:
- smarthdcd [382]: smbus.cpp: 541: / dev / ttyS2: время ожидания запроса
з.ы. хотя я бы, в отличии от гугла переводчика, наверное поискал для "ресольвинга" другой синоним...
comment:14 by , 6 лет ago
Гуглом я и сам могу переводить, это не дает понимания что запись означает. Думаю на мой вопрос ты не ответил, садись, 2.
comment:16 by , 6 лет ago
Replying to andrei:
- Что обозначает запись error resolving pool ntp.ubuntu.com: Temporary failure in name resolution (-3) ntpd[373]:?
Это означает, что ntpd попытался ресолвить имя пула ntp.ubuntu.com, но не достиг успеха. Будет повторять попытку позже.
- Что обозначает запись smarthdcd[382]: smbus.cpp:541: /dev/ttyS2: request timeout?
Это означает, что smarthdcd передал в /dev/ttyS2 запрос, но не получил на него никакого ответа.
следующий: 18 comment:17 by , 6 лет ago
Replying to andrei:
Предложение. Объединить события, которые наступают каждый опрос.
Я не понял это предложение... О каком опросе вообще идет речь?
Например не фиксировать в нормальном журнале каждый сброс питания SIM5320. Достаточно записи когда он стал недоступен (давайте придумаем строгое определение) и записи, когда доступен снова.
Не возражаю, так как сброс питания - это лишь следствие проблем с модулем (например отсутствие ответа на команду). Так что о факте сброса питания можно вообще не писать...
следующий: 20 comment:18 by , 6 лет ago
Replying to alx:
Replying to andrei:
Предложение. Объединить события, которые наступают каждый опрос.
Я не понял это предложение... О каком опросе вообще идет речь?
Речь про опрос датчиков. Т.е. опросил датчик - записал в лог, опросил - в лог. А если состояние не меняется, то и лог не нужно занимать, это же малоинформативно. Давайте подумаем над заменой тысяч одинаковых записей на две. Например дата. время: ДД не доступен / дата. время: ДД в норме.
Например не фиксировать в нормальном журнале каждый сброс питания SIM5320. Достаточно записи когда он стал недоступен (давайте придумаем строгое определение) и записи, когда доступен снова.
Не возражаю, так как сброс питания - это лишь следствие проблем с модулем (например отсутствие ответа на команду). Так что о факте сброса питания можно вообще не писать...
Ну и вместо сброса питания не недоступность модуля в лог писать каждый раз, а зафиксировать когда он стал не доступен.
comment:19 by , 6 лет ago
А если состояние не меняется
Если состояние датчика не меняется, то в краткий лог(о котором тикет) ничего и не будет сообщено.
comment:20 by , 6 лет ago
Replying to andrei:
Я не понял это предложение... О каком опросе вообще идет речь?
Речь про опрос датчиков. Т.е. опросил датчик - записал в лог, опросил - в лог. А если состояние не меняется, то и лог не нужно занимать, это же малоинформативно.
А, теперь понял. Именно так у нас все и сделано. Мне бы в голову не пришло выдать в лог сообщение о том, что состояние датчика не изменилось. :) Так что твое предложение уже реализовано.
comment:21 by , 6 лет ago
В неподключенном УГП-ЧР в кратком логе:
request timeout smarthdcd[]:
haven't seen echo smarthdcd[]
повторяются раз по 5 подряд. Информативность сообщений для эксплуатирующего нефтяника стремится к 0, а лог не резиновый.
Давайте не будем повторять их так часто, забивая ими в логе ценную информацию.
comment:22 by , 5 лет ago
| Приоритет: | средний → Срочно |
|---|---|
| Этап разработки: | 2-я очередь → 1-я очередь |
Предлагаю вернуться к вопросу лога, т.к. часто возникают вопросы к нему.
Самый большой недостаток, что сообщения о вчерашних авариях уже не найти в логе, т.к. в лог пишется много всего, а эта информация об авариях важна для пользователя.
Вот мои предложения:
- Записывать "краткий лог" в отдельный файл.(по аналогии с журналом аварий в sw-01)
- В "краткий лог" сообщать только сообщения об авариях (может нужно что-то ещё?)
- Увеличить место отданное под обычный лог (или так мы всю флэшку изотрём?)
Повышаю приоритет с молчаливого согласия Андрея.
comment:24 by , 5 лет ago
Если такая срочность, я предлагаю для начала просто увеличить максимальный размер файла (при достижении которого происходит ротация) и, возможно, число хранимых файлов (сейчас, если я правильно помню, 30, миожно увеличить до 99).
По поводу сообщений о срабатывании датчиков и запуске/останове двигателей: в каком-то тикете уже обсуждалось, но я не смог найти. Кратко повторю: согласен, что в конечном итоге эти сообщения (по крайней мере, касающиеся ДВ/ДН) должны быть убраны. Но пока устройство в стадии отладки, эти сообщения могут быть крайне полезны для анализа, что же произошло. Например в некоторых из недавно рассматривавшихся тикетов подобные сообщения помогали понять, что происходило с установкой (см. например #163). Поэтому пока предлагаю потерпеть наличие этих сообщений в логе.
comment:25 by , 5 лет ago
Replying to Art_M:
Часто попадаются:
May 22 13:57:49 smarthdcd[373]: smbus.cpp:541: /dev/ttyS2: request timeout
May 22 08:57:49 dropbear[3510]: Login attempt for nonexistent user from 88.214.26.10:46896
May 22 08:57:50 dropbear[3510]: Client trying multiple usernames from 88.214.26.10:46896
не знаю что с этим делать, наверное тоже тут не нужны...
Если request timeout происходит редко, то можно с этим ничего не делать, это не страшно. Если часто - это говорит о проблемах шины RS-485, по которой происходит обмен данными с ЧРП. Во втором случае надо во-первых, проверить физическое соединение (исправность и качество кабелей и разъемов, наличие терминаторов), во-вторых, попробовать изменить (снизить) скорость работы шины.
Сообщения dropbear о подключении клиентов можно отключить.
следующий: 29 comment:26 by , 5 лет ago
Ребята!
Когда я писал ТЗ
В журнале событий должны отражаться дата и время и информация о событиях, таких как остановка, запуск, возникновение и снятие аварий, изменение настроек контроллера, изменение числа качаний интеллектуальным режимом, АПВ, пометки о неисправности НУ и т.д.
Я рассчитывал, что будет запуск и остановка будут указаны не у каждого ЧРП и клапана каждый ход, а вообще в целом, т.е. включение/остановка всего привода переключателем руч/авт/стоп.
При включенной настройке "подробного" ведения журнала, при каждой записи следует сохранять текущее состояние контроллера и привода в момент записи, т.е. нагрузку на штоке, давление, токи двигателей, частоты двигателей, температуру масла, состояние клапанов, состояние датчиков положения.
Т.е. тот же краткий, только еще и с параметрами...
Но из-за разночтений сделано, то что сделано. И то что сделано меня устраивает как подробный лог!
А еще мне понравилась идея Андрея вести два лога, и вот имеющийся сейчас "подробный" давайте будем считать "подробным"... Ранее я просто и не думал, что можно так подробно записывать каждый ход. А второй пусть будет "кратким"...
"Краткий" действительно будет полезен для обслуживающей организации, типа техноойла в плане статистики.... А вот имеющийся сейчас "подробный" полезен, когда привод отказал и стоит! Тогда можно подключиться и в подробностях узнать, что происходило с приводом непосредственно перед остановкой, прям как параметрический черный ящик у самолетов!
Хоть сейчас мы и привели приводы к состоянию хоть и не идеальному, но остановки стали происходить многократно реже нежели это было раньше, я все равно вижу в имеющемся сейчас подробном логе пользу... Тем более если учитывать существенно усложнившиеся алгоритмы...
Кто что думает по этому поводу? Не будет ли от этого портиться и приходить в негодность микросхемы памяти контроллера?
следующий: 32 comment:27 by , 5 лет ago
Тот лог (журнал?), который сейчас существует, оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Рядом создаем краткий лог (журнал аварий). Содержимое кратного лога:
- Аварии с временем возникновения и снятия.
- Время запуска программы (включения питания, перезагрузки).
- Изменения положения переключателя АВТ/РУЧ/СТОП.
Нужно ли фиксировать изменение настроек оператором через веб или с панели оператора?
Что еще необходимо хранить долговременно?
Ну и увеличиваем занимаемую память в разумных пределах.
следующий: 31 comment:28 by , 5 лет ago
оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Я бы оставил настройку. Если установлено "подробно", то пишем журнал аварий и лог, если "кратко", то пишем только журнал аварий.
comment:29 by , 5 лет ago
Replying to Art_M:
Кто что думает по этому поводу? Не будет ли от этого портиться и приходить в негодность микросхемы памяти контроллера?
Тут вопрос сложный. Но давайте посчитаем следующим путем. Сейчас у нас лог-файл ротейтится при достижении размера 200 кБ, и таких файлов хранится 30 штук, то есть всего 6 МБ. Этого хватает примерно на сутки. При размере флешки (за вычетом загрузчика, ядра и данных которые почти никогда не меняются) примерно 220 Мбайт. Такой объем запишется приблизительно за 36 суток. Если срок службы станции принять аз 10 лет, то за это время флешка перезапишется приблизительно 100 раз, что много меньше ее ресурса. Мой вывод - о том, что ресурс флешки израсходуется из-за записи лога, можно не беспокоиться.
comment:30 by , 5 лет ago
Стоит также учесть, что на флешку пишется не только лог, но еще и динамограммы...
comment:31 by , 5 лет ago
Replying to san:
оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Я бы оставил настройку. Если установлено "подробно", то пишем журнал аварий и лог, если "кратко", то пишем только журнал аварий.
Возражаю. Речь о том, чтобы параллельно писать два журнала (а так можно?), тогда меньше настроек и удобный функционал и для нефтяника и для Артема.
следующий: 49 comment:32 by , 5 лет ago
Replying to andrei:
Тот лог (журнал?), который сейчас существует, оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Рядом создаем краткий лог (журнал аварий). Содержимое кратного лога:
- Аварии с временем возникновения и снятия.
- Время запуска программы (включения питания, перезагрузки).
- Изменения положения переключателя АВТ/РУЧ/СТОП.
Нужно ли фиксировать изменение настроек оператором через веб или с панели оператора?
Что еще необходимо хранить долговременно?
Ну и увеличиваем занимаемую память в разумных пределах.
Поддерживаю!
Фиксировать изменение настроек оператором и в веб и в панели оператора нужно!
А так же, думаю, стоит осветить в кратком логе изменение числа качаний интеллектуальной функцией, если та включена, т.к. она будет периодически менять значение числа качаний (прикидываю, что раз в час), что бы не рыться в динамках, то было бы так же неплохо сразу видеть, какое и когда у нас было число качаний по этой функции. Ну и вместе с числом качаний используемый в расчете вычисленный по динамограммам условный коэффициент наполнения.
comment:33 by , 5 лет ago
Попытаюсь резюмировать:
- Лог и "Журнал событий" пишем отдельно
- Настройку "ведение журнала нормально/подробно" удаляем
- В "Журнал событий" сообщаем следующее
- запуск программы (включения питания, перезагрузки).
- авт/руч/стоп
- возникновение и снятие аварий
- изменение настроек контроллера
- изменение числа качаний интеллектуальным режимом и условный коэф. наполнения
- отметки об АПВ
- пометки и снятие пометок о неисправности НУ
- Увеличить размер памяти выделенной для лога
Вопросы:
в1. В какой лог будем пишем вот это ? при каждой записи следует сохранять текущее состояние контроллера и привода в момент записи, т.е. нагрузку на штоке, давление, токи двигателей, частоты двигателей, температуру масла, состояние клапанов, состояние датчиков положения.
в2. Какой лог будем отображать на экране панели оператора? только журнал событий?
comment:34 by , 5 лет ago
в2. Не вижу смысла отображать на панели подробнй лог. Те кто могут в нем разобраться или удаленно считывают или если оказались на скважине, то с ноутбуком.
comment:35 by , 5 лет ago
Насчёт в1 есть мнения?
Я предлагаю писать это в Журнал событий(можно той самой настройкой и включать/выключать эту запись, в тз так и указано). Вроде бы для персонала, строка состояния привода может быть полезной, а может и нет :)
comment:36 by , 5 лет ago
в1. Давайте дописывать эту информацию к событиям в оба журнала. Информация полезная.
Остальное оставляем как резюмировано в #comment:33.
comment:37 by , 5 лет ago
Ещё момент. Нужно исключить записывание одной и той же информации несколько раз в секунду.
Например:
May 27 17:25:24 smarthdcd[1078]: smbus.cpp:542: /dev/ttyS2: request timeout May 27 17:25:25 smarthdcd[1078]: smbus.cpp:542: /dev/ttyS2: request timeout May 27 17:25:25 smarthdcd[1078]: smbus.cpp:542: /dev/ttyS2: request timeout May 27 17:25:28 smarthdcd[1078]: smbus.cpp:542: /dev/ttyS2: request timeout
Может это конечно очень важно, записать каждый реквест таймаут, но я, например, не могу почерпнуть полезной информации. Предлагаю убрать это хотя бы из журнала событий.
comment:39 by , 5 лет ago
| Краткое описание: | Содержание краткого лога → Журнал событий |
|---|---|
| Описание: | изменено (отличие) |
comment:40 by , 5 лет ago
Андрей, я перенёс резюме в тело тикета, если нет возражений, предлагаю передать тикет Алексею.
comment:41 by , 5 лет ago
Артем предлагает добавить
- В краткий лог выводить пометки и снятие пометок о неисправности ЭК,
- При снятии лога на флэшку, записывать оба лога.
comment:43 by , 5 лет ago
если нет возражений, предлагаю передать тикет Алексею.
Или ещё есть что добавить/обсудить?
comment:44 by , 5 лет ago
| Владелец: | изменён с на |
|---|---|
| Состояние: | new → assigned |
comment:45 by , 5 лет ago
Верно ли я понял, что скорректированное описание тикета - это и есть решение, выработанное в процессе обсуждения, которое необходимо реализовать?
comment:47 by , 5 лет ago
Replying to san:
- изменение числа качаний интеллектуальным режимом и условный коэф. наполнения
??? Условный коэффициент наполнения сейчас в лог не выводится. Надо добавить его вывод, или он упомянут по ошибке?
comment:49 by , 5 лет ago
Replying to Art_M:
Ну и вместе с числом качаний используемый в расчете вычисленный по динамограммам условный коэффициент наполнения.
Судя по множественному числу "динамограмм", здесь имеется в виду среднее значение условного коэффициента наполнения, вычисленное по четырем динамограммам в алгоритме интеллектуальной функции. Правильно?
следующий: 53 comment:50 by , 5 лет ago
среднее значение условного коэффициента наполнения, вычисленное по четырем динамограммам в алгоритме интеллектуальной функции
да
Что такое "отметки об АПВ"?
Сообщение о том, что произошел АПВ или был сброшен счётчик АПВ
comment:51 by , 5 лет ago
Replying to san:
- ... размер памяти выделенной для лога увеличиваем в рамках разумного.
А какова цель увеличения памяти для лога? Ведь, насколько я понял, принято решение разделить логи на два - лог аварий и все остальное, что само по себе уже решает проблему (лог аварий не будет переполняться быстро, так как в него пишется мало информации). Зачем, в таком случае, увеличивать память, отведенную для всего остального? Не зная цели, я затрудняюсь оценить разумные рамки размера памяти...
comment:52 by , 5 лет ago
Цель та-же - иметь информацию о работе станции за больший временной период, раз память свободная у нас есть. Только это уже не для пользователей, а для нас и Артёма.
comment:53 by , 5 лет ago
Replying to san:
Что такое "отметки об АПВ"?
Сообщение о том, что произошел АПВ или был сброшен счётчик АПВ
Сейчас у нас таких сообщений нет (ТЗ их не требует). Надо добавить?
следующий: 60 comment:59 by , 5 лет ago
В лог не попадает информация, записываемая в журнал событий, так и должно быть?
Например, вот это:
Jun 06 12:18:03 P=0.9 атм. G=-6.4 кгс I1=0.0 A I2=0.0 A F1=0.0 Гц F2=0.0 Гц T=19.4°C ЭК1=выкл ЭК2=выкл ДВ=неактивен ДН=неактивен
Jun 06 12:20:18 Авария привода: 23. Ошибка датчика температуры
comment:60 by , 5 лет ago
Replying to andrei:
В лог не попадает информация, записываемая в журнал событий, так и должно быть?
Например, вот это:
Jun 06 12:18:03 P=0.9 атм. G=-6.4 кгс I1=0.0 A I2=0.0 A F1=0.0 Гц F2=0.0 Гц T=19.4°C ЭК1=выкл ЭК2=выкл ДВ=неактивен ДН=неактивен
Именно эта строчка (состояние контроллера при включенном подробном логе) попадает только в журнал событий, да. Все остальные должны попадать в оба журнала. Это мной проверялось.
А что такое "краткий лог"?