waterius
waterius copied to clipboard
dontsovcmc
Поддержка Syslog
Добрый день!
Евгений, было бы здорово реализовать поддержку отправки всех событий (активация возможности через WEBUI) по протоколу Syslog на Syslog сервер/службу.
Как на примере как это реализовано в ESP Easy:
- указывается ip и порт куда слать,
- указывается тип и уровень события,
- но с дополнительной фишкой: с выбором по какому протоколу отправлять: UDP/TCP. Однако, так же необходимо учесть, что при выборе отправки по протоколу TCP необходим буфер (скажем на последние 20 событий, пока не знаю столько и какие они у вас, чтобы конкретнее описать), который нужен в случае не доступности приемника Syslog-службы. И соответственно сбрасывать флаг или очищать буфер, и опять же обновлять буферизируемые события, пока получатель Syslog-а не доступен.
Для чего всё это нужно: если включим уровень дебага, то очень сильно поможет понимаю что происходит с устройством. Ключевое, в том, что даже не нужно поднимать Syslog-сервер или службу, а простым tcdpump-ом на любой OS* можно запустить и видеть эти события. :) *OS - linux/windows/etc., разумеется если такая утилита установлена, но это всё же проще чем настроить syslog, хотя и в нем ничего сложного не требуется, но всё таки...)
Пример: устройство вроде работает, но иногда перезагружается и не понятно почему(?)... в итоге память заканчивается. :) А в отправке мы это можем увидеть (если такое в прошивке есть).
Спасибо!
Причину перезагрузки устройства в syslog не вывести: она может быть в attiny, там вообще не ясно как логировать что-то =(. Поступали предложения при загрузке адреса регистров в память писать и пересылать в ЕСП при пробуждении. Если будет глючить ЕСП, то да ,лог поможет. Но вопрос, насколько syslog проще, чем подключиться USB-TTL и посмотреть лог в консоли. Лог может быть полезен в качестве диагностики подключения к роутеру - тогда его нужно в интерфейсе настройки показывать.
Для хранения буфера лога нужно использовать LittleFS или есть еще решения? В целом штука полезная, но уж слишком сложна реализация при неочевидных плюшках. Ватериус либо работает, либо нет =/.
@obrianw если актуально, то neitri сделал пулл реквест подобного лога. Но кажется там только кольцевой буфер взят, а syslog не шлет никуда.
Ух... широковещательно сильно не правильно, как с точки зрения безопасности (получит служебную инфу тот кому это не предназначено, для дома это не актуально, но всё же не секурно, а если используется в организации, то однозначно актуально и критично), так и с точки зрения функционалов (на стороне сервер syslog-а никогда не включается на прием в широковещательных событий /так как не секурно, от подобных событий ИБ-сообщество уже отошло. Если найдёте подобные статьи, то это в корне не верный подход/, а так же прием таких событий проблематичен для разбора и корреляций), плюс если syslog сервер не в одной сети, то никак не получим события, не смаршрутизировать широковещательные пакеты (кроме этого есть куча паразитного траффика).
Так же IoT датчики, судя по последним тенденциям (раз работают на WiFi 2.4ГГц, а двухдиапазонные точки доступа сильно глючат с esp*) выводят на отдельную точку со своим IP-диапазоном, чтобы исключить разного рода проблем и помех.
А так адресная посылка событий на конкретный syslog (udp/tcp, tcp-приоритетней, пусть и затратный) сервер таки проще траблешутить, даже в случае не корректных/настроек на самом syslog сервере.
Посему, лично для меня, таки буду ждать чтобы можно было указать именно ip-сервер куда отправлять событий. Я фактически дублирую мониторинг других IoT, пусть и заведены датчики в монстроподобный Умный дом, потому как и от него тоже бывает молчание, а вот от syslog сервера сбоев за много лет пока не было (понятно что когда э/э вырубят тут никакой дубляж не поможет :), но зато видно когда начались проблемы.)
p.s. это не наезд, а попытка конструктивно и подробно показать/рассказать нужность данной фишки.
@obrianw мне кажется 99% проблем связанных с Ватериусом - это
- подключение к роутеру (тут syslog бесполезен, мы еще не подключились)
- синхронизация времени по NTP (сейчас добавили 3 попытки, но возможно она осталась) (тут ок, можно по syslog будет посмотреть)
Т.е. не очень понятен практический кейс. При этом настроить syslog и будут это делать единицы пользователей.
Однако, есть польза, чтобы нам получать лог от устройства, которое не выходило на связь: чтобы увидеть, почему оно не вышло на связь ранее. Но где бы взять готовое решение? Чтобы не изобретать ничего нового.
Реализацию вижу как: запись в LittleFS логов уровня ERROR и метками времени при подключении к серверу, получать от него метку времени последнего сообщения. отправлять на сервер все сообщения из лога после метки времени.