> Есть другая сторона, когда к вам обращается пользователь в моем случае это, к счастью, невозможно - у него нет моего телефона, и техподдержка мне тоже звонить не будет, если проблема не массовая.
> и жалуется на проблему (например, потерю пакетов) которая была несколько часов (а может и дней)
> назад.
они ответят "прищемил в году минувшем - что ж ты в нынешнем орешь?" ;-)
в теории - открываете latest data, включаете фильтр по группе (которая у вас, надеюсь, как-то отражает расположение клиента) и ищете внутри порт, не надо рыть от схемы сети (все равно неудобно, но хоть так). На практике при массовом сервисе - у вас хранилки не хватит на неделю все это богатство хранить. Поэтому никакой жабикс не открывая, идете на устройство и смотрите прямо на порту - если там есть ошибки, вяло предлагаете пользователю поменять кабель, монтажники приедут после дождичка в четверг, с 23:42 до 1:33. Выслушиваете куда вам пойти и закрываете задачу.
Если бы ошибок было заметно - вам (на деле мониторингу) бы пришел алерт, и вы бы знали о проблеме никуда не заглядывая и тем более не дожидаясь пока клиент пожалуется. Если алерта не было, а он жалуется - скорее смотреть надо на всплеск траффика (и не факт что на его порту, может у вас апстрим просел).
А при немассовом сервисе я вот так сразу хрен знает где смотреть - проблемы у пользователя, арендующего l2vpn Москва-Казань могут быть (и скорее всего и будут) вовсе не (только) на порту в его сторону, задействованна куча своего и чужого железа, включая то, которое его пакеты не посещают, но оно влияет на их хождение... и как с этим жить без интегральных показателей, не привязанных к схеме устройств и автоматического мониторинга - не знаю.
