Журнал событий

[san]

1. Лог и "Журнал событий" пишем отдельно

2. Настройка "ведение журнала нормально/подробно" должна действовать на "Журнал событий" согласно тз:

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

3. В "Журнал событий" сообщаем только следующее
   • запуск программы (включения питания, перезагрузки).
   • авт/руч/стоп
   • возникновение и снятие аварий
   • изменение настроек контроллера
   • изменение числа качаний интеллектуальным режимом и условный коэф. наполнения
   • отметки об АПВ
   • пометки и снятие пометок о неисправности НУ и ЭК
   • "текущее состояние привода"
4. В лог пишем всё что угодно, размер памяти выделенной для лога увеличиваем в рамках разумного.

5. С панели оператора должна быть возможность просматривать "Журнал cобытий" с фильтрацией по подпунктам перечисленным в п.3

6. При использовании функции сохранения Журнала на портативный носитель - копировать и Журнал событий и лог.

[alx]

А что такое "краткий лог"?

[san]

Это когда настройка "Ведение журнала" установлена в значение "нормально", а не "подробно".

[san]

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

[alx]

Тестовая эксплуатация будет проводиться при выключенном ЧРП?

[san]

Конечно с включенным, но благодаря записям о срабатывания датчиков и другой избыточной информации, лога всё-равно не хватит на долго. Примерно 5 дней, учитывая только записи о датчиках положения при ~3кач/мин, а ещё таймауты от ЧРП и ещё какие-то записи от модема и др.., думаю что на день-два в лучшем случае.

[andrei]

Саша, закрой 31 тикет как частный случай этого.

[alx]

Может быть имеет смысл в настройке "Ведение журнала" сделать немного больше градаций подробности, чем две?

[andrei]

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

[san]

Ещё Андрей предложил интересный, на мой взгляд, вариант: разделить лог на 2 лога(краткий и подробный отдельно). Подобным образом у нас в SW-01 сделано: есть журнал аварий в котором только аварии, и есть лог в котором всё.

[alx]

Replying to andrei:

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

В исходных кодах всех установленных пакетов.

[andrei]

В исходных кодах всех установленных пакетов.

Для меня это слишком долго будет.
Буду читать логи и меню панели оператора.

[andrei]

Предложение. Объединить события, которые наступают каждый опрос. Например не фиксировать в нормальном журнале каждый сброс питания SIM5320. Достаточно записи когда он стал недоступен (давайте придумаем строгое определение) и записи, когда доступен снова.
Вопросы.

1. Что обозначает запись error resolving pool ntp.ubuntu.com: Temporary failure in name resolution (-3) ntpd[373]:?
2. Что обозначает запись smarthdcd[382]: smbus.cpp:541: /dev/ttyS2: request timeout?

[san]

Можно я, можно я отвечу) ?

1. ошибка разрешения пула ntp.ubuntu.com: временно ошибка в разрешении имени (-3) ntpd [373]:

2. smarthdcd [382]: smbus.cpp: 541: / dev / ttyS2: время ожидания запроса

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

[andrei]

Гуглом я и сам могу переводить, это не дает понимания что запись означает. Думаю на мой вопрос ты не ответил, садись, 2.

[san]

Ок, подожду ответа Алексея с ручным переводом (смайлик с попкорном) :)

[alx]

Replying to andrei:

1. Что обозначает запись error resolving pool ntp.ubuntu.com: Temporary failure in name resolution (-3) ntpd[373]:?

Это означает, что ntpd попытался ресолвить имя пула ntp.ubuntu.com, но не достиг успеха. Будет повторять попытку позже.

2. Что обозначает запись smarthdcd[382]: smbus.cpp:541: /dev/ttyS2: request timeout?

Это означает, что smarthdcd передал в /dev/ttyS2 запрос, но не получил на него никакого ответа.

[alx]

Replying to andrei:

Предложение. Объединить события, которые наступают каждый опрос.

Я не понял это предложение... О каком опросе вообще идет речь?

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

Не возражаю, так как сброс питания - это лишь следствие проблем с модулем (например отсутствие ответа на команду). Так что о факте сброса питания можно вообще не писать...

[andrei]

Replying to alx:

Replying to andrei:

Предложение. Объединить события, которые наступают каждый опрос.

Я не понял это предложение... О каком опросе вообще идет речь?

Речь про опрос датчиков. Т.е. опросил датчик - записал в лог, опросил - в лог. А если состояние не меняется, то и лог не нужно занимать, это же малоинформативно. Давайте подумаем над заменой тысяч одинаковых записей на две. Например дата. время: ДД не доступен / дата. время: ДД в норме.

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

Не возражаю, так как сброс питания - это лишь следствие проблем с модулем (например отсутствие ответа на команду). Так что о факте сброса питания можно вообще не писать...

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

[san]

А если состояние не меняется

Если состояние датчика не меняется, то в краткий лог(о котором тикет) ничего и не будет сообщено.

[alx]

Replying to andrei:

Я не понял это предложение... О каком опросе вообще идет речь?

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

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

[andrei]

В неподключенном УГП-ЧР в кратком логе:
request timeout smarthdcd[]:
haven't seen echo smarthdcd[]
повторяются раз по 5 подряд. Информативность сообщений для эксплуатирующего нефтяника стремится к 0, а лог не резиновый.
Давайте не будем повторять их так часто, забивая ими в логе ценную информацию.

[san]

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

1. Записывать "краткий лог" в отдельный файл.(по аналогии с журналом аварий в sw-01)
2. В "краткий лог" сообщать только сообщения об авариях (может нужно что-то ещё?)
3. Увеличить место отданное под обычный лог (или так мы всю флэшку изотрём?)

Повышаю приоритет с молчаливого согласия Андрея.

[alx]

Если такая срочность, я предлагаю для начала просто увеличить максимальный размер файла (при достижении которого происходит ротация) и, возможно, число хранимых файлов (сейчас, если я правильно помню, 30, миожно увеличить до 99).

По поводу сообщений о срабатывании датчиков и запуске/останове двигателей: в каком-то тикете уже обсуждалось, но я не смог найти. Кратко повторю: согласен, что в конечном итоге эти сообщения (по крайней мере, касающиеся ДВ/ДН) должны быть убраны. Но пока устройство в стадии отладки, эти сообщения могут быть крайне полезны для анализа, что же произошло. Например в некоторых из недавно рассматривавшихся тикетов подобные сообщения помогали понять, что происходило с установкой (см. например #163). Поэтому пока предлагаю потерпеть наличие этих сообщений в логе.

[alx]

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 о подключении клиентов можно отключить.

[Art_M]

Ребята!

Когда я писал ТЗ

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

Я рассчитывал, что будет запуск и остановка будут указаны не у каждого ЧРП и клапана каждый ход , а вообще в целом, т.е. включение/остановка переключателем руч/авт/стоп.

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

Но из-за разночтений сделано, то что сделано. И то что сделано меня устраивает как подробный лог!

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

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

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

Кто что думает по этому поводу?

[andrei]

Тот лог (журнал?), который сейчас существует, оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Рядом создаем краткий лог (журнал аварий). Содержимое кратного лога:

• Аварии с временем возникновения и снятия.
• Время запуска программы (включения питания, перезагрузки).
• Изменения положения переключателя АВТ/РУЧ/СТОП.

Нужно ли фиксировать изменение настроек оператором через веб или с панели оператора?

Что еще необходимо хранить долговременно?

Ну и увеличиваем занимаемую память в разумных пределах.

[san]

оставляем и убираем настройку нормально/подробно, будет всегда подробно.

Я бы оставил настройку. Если установлено "подробно", то пишем журнал аварий и лог, если "кратко", то пишем только журнал аварий.

[alx]

Replying to Art_M:

Кто что думает по этому поводу? Не будет ли от этого портиться и приходить в негодность микросхемы памяти контроллера?

Тут вопрос сложный. Но давайте посчитаем следующим путем. Сейчас у нас лог-файл ротейтится при достижении размера 200 кБ, и таких файлов хранится 30 штук, то есть всего 6 МБ. Этого хватает примерно на сутки. При размере флешки (за вычетом загрузчика, ядра и данных которые почти никогда не меняются) примерно 220 Мбайт. Такой объем запишется приблизительно за 36 суток. Если срок службы станции принять аз 10 лет, то за это время флешка перезапишется приблизительно 100 раз, что много меньше ее ресурса. Мой вывод - о том, что ресурс флешки израсходуется из-за записи лога, можно не беспокоиться.

[alx]

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

[andrei]

Replying to san:

оставляем и убираем настройку нормально/подробно, будет всегда подробно.

Я бы оставил настройку. Если установлено "подробно", то пишем журнал аварий и лог, если "кратко", то пишем только журнал аварий.

Возражаю. Речь о том, чтобы параллельно писать два журнала (а так можно?), тогда меньше настроек и удобный функционал и для нефтяника и для Артема.

[Art_M]

Replying to andrei:

Тот лог (журнал?), который сейчас существует, оставляем и убираем настройку нормально/подробно, будет всегда подробно.
Рядом создаем краткий лог (журнал аварий). Содержимое кратного лога:

• Аварии с временем возникновения и снятия.
• Время запуска программы (включения питания, перезагрузки).
• Изменения положения переключателя АВТ/РУЧ/СТОП.

Нужно ли фиксировать изменение настроек оператором через веб или с панели оператора?

Что еще необходимо хранить долговременно?

Ну и увеличиваем занимаемую память в разумных пределах.

Поддерживаю!

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

[san]

Попытаюсь резюмировать:

1. Лог и "Журнал событий" пишем отдельно
2. Настройку "ведение журнала нормально/подробно" удаляем
3. В "Журнал событий" сообщаем следующее
   • запуск программы (включения питания, перезагрузки).
   • авт/руч/стоп
   • возникновение и снятие аварий
   • изменение настроек контроллера
   • изменение числа качаний интеллектуальным режимом и условный коэф. наполнения
   • отметки об АПВ
   • пометки и снятие пометок о неисправности НУ
4. Увеличить размер памяти выделенной для лога

Вопросы:

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

в2. Какой лог будем отображать на экране панели оператора? только журнал событий?

[andrei]

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

[san]

Насчёт в1 есть мнения?
Я предлагаю писать это в Журнал событий(можно той самой настройкой и включать/выключать эту запись, в тз так и указано). Вроде бы для персонала, строка состояния привода может быть полезной, а может и нет :)

[andrei]

в1. Давайте дописывать эту информацию к событиям в оба журнала. Информация полезная.
Остальное оставляем как резюмировано в #comment:33.

[andrei]

Ещё момент. Нужно исключить записывание одной и той же информации несколько раз в секунду.
Например:

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

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

[san]

В журнал событий это и так не попадет.

[san]

Андрей, я перенёс резюме в тело тикета, если нет возражений, предлагаю передать тикет Алексею.

[andrei]

Артем предлагает добавить

1. В краткий лог выводить пометки и снятие пометок о неисправности ЭК,
2. При снятии лога на флэшку, записывать оба лога.

[san]

добавил

[san]

если нет возражений, предлагаю передать тикет Алексею.

Или ещё есть что добавить/обсудить?

[alx]

Верно ли я понял, что скорректированное описание тикета - это и есть решение, выработанное в процессе обсуждения, которое необходимо реализовать?

[andrei]

Да, результаты обсуждения Саша внес в описание тикета.

[alx]

Replying to san:

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

??? Условный коэффициент наполнения сейчас в лог не выводится. Надо добавить его вывод, или он упомянут по ошибке?

[alx]

Replying to san:

• отметки об АПВ

Что такое "отметки об АПВ"?

[alx]

Replying to Art_M:

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

Судя по множественному числу "динамограмм", здесь имеется в виду среднее значение условного коэффициента наполнения, вычисленное по четырем динамограммам в алгоритме интеллектуальной функции. Правильно?

[san]

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

да

Что такое "отметки об АПВ"?

Сообщение о том, что произошел АПВ или был сброшен счётчик АПВ

[alx]

Replying to san:

4. ... размер памяти выделенной для лога увеличиваем в рамках разумного.

А какова цель увеличения памяти для лога? Ведь, насколько я понял, принято решение разделить логи на два - лог аварий и все остальное, что само по себе уже решает проблему (лог аварий не будет переполняться быстро, так как в него пишется мало информации). Зачем, в таком случае, увеличивать память, отведенную для всего остального? Не зная цели, я затрудняюсь оценить разумные рамки размера памяти...

[san]

Цель та-же - иметь информацию о работе станции за больший временной период, раз память свободная у нас есть. Только это уже не для пользователей, а для нас и Артёма.

[alx]

Replying to san:

Что такое "отметки об АПВ"?

Сообщение о том, что произошел АПВ или был сброшен счётчик АПВ

Сейчас у нас таких сообщений нет (ТЗ их не требует). Надо добавить?

[san]

да

[alx]

In 730/smartHDC:

Некоторые сообщения кроме syslog записываются также в отдельный лог ("журнал событий").
Функция просмотра журнала теперь просматривает журнал событий, а не системный журнал.
Соответственно изменены фильтры для просмотре журнала.
В меню портативного носителя добавлена функция корирования журнала событий. Также
журнал событий копируется на портативный носитель при его подключении. Closes #111.

[alx]

In 731/smartHDC:

Число хранимых файлов системного журнала увеличено до 99. See #111.

[alx]

In 734/smartHDC:

Добавлен вывод в лог отметок АПВ. See #111.

[alx]

In 735/smartHDC:

Добавлен вывод в лог сообщений о сбросе счетчиков АПВ. See #111.

[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=выкл ДВ=неактивен ДН=неактивен
Jun 06 12:20:18 Авария привода: 23. Ошибка датчика температуры

[alx]

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=выкл ДВ=неактивен ДН=неактивен

Именно эта строчка (состояние контроллера при включенном подробном логе) попадает только в журнал событий, да. Все остальные должны попадать в оба журнала. Это мной проверялось.