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

[san]

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

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

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

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

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

[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]

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