Время прихода сообщений

tata,  Не из пушки ли по воробьям - запросы в ТП?  И как быть с LOCAL - тоже в ТП?
И какой темп запросов выдержит Ваша ТП, в каких объемах, как часто, если интегратор - 'ищущая" натура ? ))
Масса БД в разных предметных областях кроме времени появления события еще и содержат время создания записи.
При гибкости Вашей БД с добавлением произвольных параметров от приборов добавить такое поле не представляет труда - вроде бы...
Не думаю,что вы хотите спрятать какие-то Ваши внутренние тайминги.
А вот для аналитики мониторинга это был бы большой плюс. Вы же не отрицаете возможности аналитики у интеграторов?
Гораздо проще будет понять и показать проблемы задержки доставки данных клиентам, желающим видеть всё онлайн.

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

Существует. На сайте gurtam.com выделена для описания гарантий страница.

На текущий момент мы не готовы изменить формат сообщения, чтобы он передавал еще и время прихода сообщения на сервер. В первую очередь, потому что необходимо будет предусмотреть совместимость со всеми приложениями, связанными с Wialon, в т.ч. написанными не Gurtam, а партнерами. Также каждое сообщение вырастет на 4 байта, т.е. вырастет трафик для клиентов, количество обрабатываемых данных для web, количества данных для хранения для серверов. Прямо сейчас в Wialon поступает 1250586 сообщений в минуту. Одна небольшая доработка множится на повторяемость и места, где используется, в итоге получается совсем не маленькая доработка.

В данном случае всё же лучший способ - обращение в техподдержку. Как мне кажется, пакеты данных за 100 объектов  трудно анализируются вместе и достаточно меньшего количества.

К слову, некоторое оборудование помечает сообщения, которые идут из черного ящика.

tata это уже ближе к сути проблемы. если ситуация такая как вы описываете то вижу 4 варианта:
1. партнер  может опционально для себя включать отображение этих сообщений
2. партнер может нажать кнопку, которая повторяет действия ТП за уазываемый период и выгружает данные
3. Создать в свойствах объекта или еще где-то кнопку "Проверить качество передачи данных", при нажатии на которую для данного объекта (или группы объектов) будет проводится анализ на указываемую в настройках разницу между снятием данных и приходом на сервер
4. Сделать отчет, который анализирует данные не только в сообщениях, но и там где ТП берет данные о получении данных, ведь они все равно на сервере существуют и для администратора системы все равно откуда отчет берет данные.

Изучил правила по Вашей ссылке:

Т.е. создал запрос  в ТП по 1 объекту за один временной интервал
- "При создании запроса в службу технической поддержки компании Gurtam клиентом (пользователем) должны быть указаны следующие данные:...    указаны конкретные элементы, по которым возник вопрос (объект, шаблон отчета, временной интервал и т.д.);"
Создал для сравнения еще 3-4 аналогичных запроса по тому же или другим объектам
Подождал от 4 до 8 часов. -"Время реакции на запрос    8 часов 4 часа    4 часа" (в зависимости от Start -Unlimited)
и вуаля - можно запускать следующую итерацию?.

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

Наверное, даже такие умные трекеры в своих пометках не делают разницы межу 30 секундным и 1,5 часовых запозданием )

Подскажите, какова максимальная глубина хранения логов сообщений (по времени и количеству) для 1 объекта? Можно ли получить логи 2-х-4-х недельной давности по желаемым объектам?  Хранятся ли логи сообщений для каждого объекта в отдельном файле, или все сообщения  для каждого типа прибора хранятся  в одном файле?

Идея классная.
А если еще время прихода сообщений можно было бы использовать в качестве параметров датчика как time только будет параметр timeserver, то можно очень многое анализировать по потерям связи.
Может у трекера просто не хватило памяти что-бы записать какой-то кусок данных а может он прост завис и ничего не писал в память.
Для интегратора в спорных ситуациях было бы очень полезно.

А запрашивать эти данные каждый раз это умрешь.
У нас тоже есть некие тайминги для конечных клиентов и если каждый раз лепить 4-8 часов к ним для ответа Gurtam то уже мы не укладываемся, так как нам нужно их еще проанализировать и сформировать некий ответ.

Здравствуйте, STAN
Коль скоро Вы упомянули наличие логов, как какое-то решение, то не могли бы Вы хотя бы предоставить ссылку , по которой можно найти ответы на вышеприведенные вопросы.
Приведенный ответ или сформулирован слишком общо, или является отпиской.
Есть ли у самого Gurtam'а количественная оценка этих данных?

Может быть, в логах все-таки нет искомой информации в разумных и гарантированных объемах ?

Добрый день!

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

tata  Только я обрадовался и тут такое (такое в прикреплении)  если на словах, то колонка пуста

Костыль от меня:
Создали группу не на связи, объекты в которые перемещаются по уведомлению потери связи в течении 8 минут. Если ТС вышла на связь, то объект удаляется из группу не на вязе. Уведомления регистрируют в журнале события. В отчет журнал событий вы увидите всю историю потери связи ТС(не забудьте про 8 минут при перемещении, т.е. если в журнале указано 12:38, то фактически потеря связи произошла в 12:30).

Нет прощения, на колени! (шутка). Для этого требуются отдельные сервера? А на локал будет реализовано?

Спасибо, Tatsiana, понятно всё. Подождём, надеюсь - будет удобно-полезно. Мне более интересно появление данной фишки на локал.