Трейс открыт что это
Введение в паттерн распределенной трассировки
Когда дело доходит до работоспособности и мониторинга, распределенная архитектура может подкинуть вам пару проблем. Вы можете иметь дело с десятками, если не сотнями микросервисов, каждый из которых мог быть создан разными командами разработчиков.
При работе с крупномасштабной системой очень важно следить за ключевыми показателями этой системы, работоспособностью приложений и достаточным объемом данных, чтобы иметь возможность быстро отслеживать и устранять проблемы. Пребывание в ОБЛАЧНОЙ среде, такой как AWS, Google Cloud, Azure, еще больше усугубляет проблему и затрудняет обнаружение, устранение и локализацию проблем из-за динамического характера инфраструктуры (вертикальное масштабирование, временные машины, динамические IP-адреса и т. д.).
Базис наблюдаемости:
В этой статье я сосредоточусь на двух аспектах наблюдаемости: логах (только сгенерированных приложением) и трейсах.
Использование централизованной системы логирования в распределенной архитектуре, чтобы иметь возможность собирать логи и визуализировать их, стало обычной практикой. Логи, сгенерированные различными микросервисами, будут автоматически отправляться в централизованную базу для хранения и анализа. Вот некоторые из популярных решений централизованных систем логирования для приложений:
Логи предоставляют полезную информацию о событиях, которые произошли в вашем приложении. Это могут быть логи INFO-уровня или логи ошибок с подробными стек трейсами исключений.
Кореляция логов между микросервисами
В большинстве случаев это может быть userId, связанный с запросом, или какой-нибудь уникальный UUID, сгенерированный в первой точке входа в приложение. Эти идентификаторы будут прикреплены к каждому сообщению в логе и будут передаваться последовательно от одного микросервиса к другому в заголовке запроса (в случае, если идентификатор не является частью последовательно обрабатываемого запроса). Так можно легко использовать requestId или userId для запроса к системе логирования, чтобы найти все логи, связанные с запросом в нескольких сервисах.
Рисунок 1. Централизованное логирование.
Ниже приведены несколько примеров того, как пометить (tag) ваши логи необходимой информацией на Java с помощью фильтров запросов (RequestFilter).
Рисунок 2: Конфигурация и образец лога Log4J2
Рисунок 3: Фильтры запросов по UUID или UserId
Трассировка
Путь запроса через распределенную систему.
Задержка запроса при каждой пересылке/вызове (например, от одного сервиса к другому).
Ниже приведен пример трассировки для запроса, взаимодействующего с двумя микросервисами (сервисом-аукционом рекламы и сервисом-интегратором рекламы).
Рисунок 4. Трассировка
В приведенном выше примере данные были захвачены и визуализированы с помощью инструмента DataDog. Есть несколько других способов захвата трейсов, о которых я расскажу в следующем разделе.
Составляющие трейса
Трейс представляет из себя древовидную структуру с родительским трейсом и дочерними спанами. Трейс запроса охватывает несколько сервисов и далее разбивается на более мелкие фрагменты по операциям/функциям, называемые спанами. Например, спан может охватывать вызов от одного микросервиса к другому. В рамках одного микросервиса может быть несколько спанов (в зависимости от того, сколько уровней классов/функций или зависимых микросервисов вызывается для обслуживания запроса).
Трассировка зиждется на создании уникального идентификатора для каждого запроса в точке входа и распространения его на последующие системы в качестве контекста трассировки в заголовках запросов. Это позволяет связать различную трассировочную информацию, исходящую от нескольких служб, в одном месте для анализа и визуализации.
Корреляция логов и трейсов
В итоге мы можем фильтровать логи по userId или другому уникальному идентификатору (например, сгенерированному UUID) и можем отслеживать по трейсам производительность/поведение отдельного запроса. Было бы неплохо, если бы мы могли связать это воедино и иметь возможность сопоставлять логи и трейсы для конкретного запроса!!
Наличие такой корреляции между логами и запросами позволяет:
Сопоставлять метрики производительности напрямую с логами.
Направлять в систему специальный запрос для устранения неполадок.
Выполнять искусственные транзакции с системой в разные моменты времени и иметь возможность сравнивать текущие трейсы с историческими, а также автоматически собирать системные логи связанные с этими запросами.
Реализация распределенной трассировки с помощью корреляции логов и трейсов
ПОДХОД #1: Инструментация с помощью сторонних решений, таких как DATADOG
Datadog по существу берет на себя заботу о централизованном логировании и сборе трассировочной информации. Datadog генерирует уникальные идентификаторы трейсов и автоматически распространяет их на все инструментированные нижестоящие микросервисы. Единственное, что от нас требуется, это связать DD traceId с логами, и мы сможем получим корреляцию логов и трейсов.
Рисунок 6: Инструментация приложения с DataDog
Рисунок 7: Корреляция логов и трейсов в DataDog
ПОДХОД #2: ZIPKINS, CLOUD-SLEUTH СО SPRING BOOT
Полная интеграция в SPRING boot
Простота в использовании
Трейсы можно визуализировать с помощью пользовательского интерфейса Zipkins.
Поддерживает стандарты OpenTracing через внешние библиотеки.
Поддерживает корреляцию логов через контексты Log4j2 MDC.
Нет решения для автоматического сбора логов, связанных с трейсами. Нам придется самостоятельно отправлять логи в ElasticSearch и выполнять поиск, используя идентификаторы трейсов, сгенерированные cloud-sleuth (как заголовок X-B3-TraceId).
Рисунок 8: Zipkins, Cloud Sleuth и Spring Boot.
ПОДХОД #3: AMAZON XRAY
Нативно поддерживает все ресурсы AWS, что очень хорошо, если ваши распределенные сервисы развернуты и работают в AWS
Балансировщики нагрузки AWS автоматически генерируют идентификаторы (REQUEST ID) для каждого входящего запроса, что освобождает приложение от этой заботы. (Ссылка)
Позволяет выполнять трассировку на всем пути от шлюза API до балансировщика нагрузки, сервиса и других зависимых ресурсов AWS.
Реализует корреляцию логов с помощью логов в CLOUDWATCH logs
Cloudwatch log может стать очень дорогими при большом объеме логов
Поддерживает opentracing по умолчанию
Имеет библиотеки, которые работают со Spring
Поддерживает Jager Agent, который можно установить в качестве средства распространения трейсов и логов.
С точки зрения обслуживания и настройки инфраструктуры достаточно сложен.
ЗАКЛЮЧЕНИЕ
Логи и трейсы сами по себе безусловно полезны. Но когда они связаны вместе с помощью корреляции, они становятся мощным инструментом для ускорения устранения проблем в производственной среде и в то же время дают девопсу представление о работоспособности, производительности и поведении распределенных систем. Как вы увидели выше, существует несколько способов реализации этого решения. Выбор за вами 🙂
Перевод статьи подготовлен в преддверии старта курса «Архитектура и шаблоны проектирования». Узнать подробнее о курсе.
Что скрывает в себе DEFAULT TRACE?
Часто вспоминается первая работа… Средненький офис, моник 943N и обогреватель Pentium D под ногами. Как возникал из ниоткуда Борис (нет… не Борис «Бритва») с линейкой в руках и настойчиво просил не делать «больно» серверу.
Именно в те далекие времена я впервые познакомился с профайлером. Пользовательские трейсы оказались очень кстати при отладке приложений и поиске медленных запросов. Потом для себя я открыл DMV и XEvents… и профайлером стал пользоваться реже. Причина такого поступка проста – трейсы очень ресурсоемкие.
Однако, данную функциональность не стоит преждевременно придавать анафеме. Начиная с 2005 версии при установке SQL Server по умолчанию создается легковесный системный трейс, который хранит в себе много полезной информации.
Находится он в папке где установлен SQL Server и состоит из пяти файлов с расширением trc. При каждом старте сервера автоматически создается новый файл для трейса, а самый старый затирается. Запись новых событий всегда идет в самый последний файл, размер которого ограничен 20 Мб. При превышении размера автоматом создается новый файл. Поменять данное поведение нельзя.
Разрешается только отключать или включать данную функциональность:
Проверить, что дефолтный трейс включен можно следующим запросом:
Путь к дефолтному трейсу:
А теперь начинаем самое интересное… Посмотрим, что за события могут храниться в дефолтном трейсе:
И рассмотрим на небольших примерах практическую пользу от информации из дефолтного трейса.
1. Auto Grow Events
Надеюсь не секрет, что для выполнения любой транзакции требуется определенное место на диске. В файле данных или логе. Не будем конкретизировать… но общем случае, если места недостаточно, то происходит авто-увеличение файла. В этот момент файл блокируется и SQL Server будет ждать пока дисковая подсистема сделает необходимые операции по выделению места на диске.
По умолчанию, SQL Server инициализирует новое место на диске нулями. Для файлов данных такое поведение можно отключить за счет использования Instant File Initialization. Но для лог файлов инициализация все равно будет происходить и это однозначно медленно. Поэтому рекомендуется на постоянной основе отслеживать Auto Grow события:
И если их количество резко увеличивается:
То это может вызывать не только фрагментацию файла на диске, но и существенные задержки при выполнении запросов:
Посмотрим на настройки проблемной базы:
Изначальный размер базы данных 8 Мб для файла данных и 1 Мб для лога:
… чего явно недостаточно, если сравнивать с текущим размером. Более того, нужно помнить, что при каждом рестарте SQL Server tempdb пересоздается. В сухом остатке, при следующем старте мы опять получим файл в 9 Мб, задержки при выполнении запросов и новую порцию сообщений в дефолтном трейсе.
Какой выход из этой ситуации? Следить за размером файлов и резервировать свободное место для них:
2. Auto Shrink Events
Недавно я уже писал о том, что опция AUTO_CLOSE снижает производительность. Так вот AUTO_SHRINK поступает еще хуже… Каждые 30 минут SQL Server пытается сделать усечение свободного места в файлах базы данных. Данный процесс достаточно ресурсоемкий и может приводить к фрагментации файлов на диске. При усечении файлов возникает высокая фрагментация индексов, что увеличивает логические чтения и снижает производительность запросов.
Представим простую ситуацию… Удалили данные из таблицы – усечение файла. Вставили новые данные – не хватило места и SQL Server пришлось увеличивать размер файла. Удалили данные и опять все по-новому…
Однозначно советую данную опцию отключать:
Еще одна полезность дефолтного трейса – возможность отслеживать кто и когда запускал DBCC команды. Ругать за DBCC CHECKDB обычно не стоит, но вот если кто-то на продакшене без ума выполняет:
то можно это легко отследить:
и кое с кем провести профилактическую беседу о пользе стояния в углу на гречке:
4. Errors and Warnings Events
В ситуации, когда SQL Server не имеет достаточного объёма свободной памяти, который требуется для выполнения запроса, обработка результатов некоторых операторов будет происходить в tempdb. Такое же поведение будет, когда оптимизатором была сделала неверная оценка ожидаемого количества строк.
Попробуем написать запрос, который вызовет spills в tempdb:
Благодаря сообщению из дефолтного трейса мы можем отследить такие запросы:
Найти их план выполнения и попытаться оптимизировать запрос:
К слову скажу, актуальные планы выполнения недоступны через DMV. Их можно получить только на этапе Post Query Execution Showplan, через соответствующий Trace event, или по команде SET STATISTICS XML ON. Начиная с SQL Server 2012 специально для таких целей добавили новый XEvent – post_query_execution_showplan.
Меня лично радует, что отслеживать можно разного рода предупреждения:
Например, когда по ошибке забыли указать поля по которым идет соединение:
или, когда на столбце по которому идет фильтрация отсутствует статистика:
В дефолтном трейсе можно отслеживать создание и удаление объектов:
Также через дефолтный трейс существует возможность следить за тем, кто и когда делал бекапы и ресторил базы:
Или отслеживать потребление памяти SQL Server-ом:
Дефолтный трейс является достаточно мощным средством для отслеживания состояния сервера. Разумеется, он имеет много недостатков, например, упомянутое ограничение в 20Мб и заявление от Microsoft что данная функциональность начиная с SQL Server 2008 объявлена устаревшей. Но все же иногда дефолтный трейс бывает очень полезным на этапе первичной диагностики проблем с SQL Server. Надеюсь мои примеры выши смогли это наглядно показать.
Все тестировалось на Microsoft SQL Server 2012 (SP3) (KB3072779) — 11.0.6020.0 (X64).
Если хотите поделиться этой статьей с англоязычной аудиторией:
Hidden gems of DEFAULT TRACE in SQL Server
Track&Trace. Системы и технологии. Перевозки автотранспортом
Track&Trace переводится на русский язык как «отслеживание пути».
Однако когда мы говорим об этом понятии в транспортной логистике, следует сразу определить, что именно мы собираемся отслеживать.
Системы отслеживания перемещения грузов можно разделить на следующие виды:
В данной статье мы расскажем о стандартных способах Track&Trace для перевозок автомобильным транспортом.
Отслеживание заказов LTL
Разобъем перевозку сборных грузов на следующие этапы:
1) Сбор груза и доставка его до терминала. Грузовладельцы могут выбирать, как именно доставить свой заказ.
В данном случае Track&Trace осуществляется либо через личный кабинет транспортной компании, либо посредством интеграции (особенно если ПО транспортной компании имеет открытый API).
3) Магистральная перевозка между терминалами.
4) Доставка от терминала до клиента. Может осуществляться вашими партнерами в регионе доставки. В данном случае это пример развозки либо FTL-перевозки.
Технические средства для организации Track&Trace в LTL-перевозке:
1) Интеграция с компанией-перевозчиком позволит передавать данные о заказе клиентам в вашем личном кабинете, а не на сайте транспортной компании.
В данном случае также рекомендуется выводить в личном кабинете статусы о выполнения заказа из ваших систем, начиная с регистрации в системе обработки заказа (интернет-магазин, 1С Предприятие, CRM или Order Management System), сбор заказа на складе (интеграция с WMS) и системой контроля оплаты заказа (например, 1С Бухгалтерия).
Кроме того, вы можете дать клиенту возможность сделать в личном кабинете отметку о доставке или сообщить о претензии, прикрепив фотографию испорченного груза. Обратите внимание, чаще всего клиент не будет сообщать о том, что доставка прошла успешно, а вот для оформления жалобы точно зайдет в личный кабинет и вы сможете улучшить свой сервис, в том числе благодаря моментальному реагированию онлайн.
2) Передача данных о доставке от первого терминала и из последнего перевозчику, осуществляющую доставку первой и последней мили соответственно. Вы можете предоставить своим партнерам личные кабинеты, в которых будете передавать данные о заказах, нуждающихся в перевозке.
Отслеживание заказов FTL
Основные способы Track&Trace FTL:
Для перевозчика не составит труда предоставить вам данные о местоположении ТС, однако с вашей стороны потребуется определенная работа, а именно настройка коннекторов с вашей системой.
Хорошая новость заключается в том, что коннекторов придется сделать не так уж и много, ведь на рынке сложился «костяк» основных интеграторов, и ваш перевозчик с вероятностью 99% работает с одним из них.
Дано: расстояния телефона до трех вышек. Найти: расположение телефона. На рисунке видно, отследить телефон можно с некоторыми допущениями.
Очевидно, что в городе точность будет лучше (до 200 метров), чем за городом (несколько километров).
Данный способ отслеживания имеет свои особенности:
3. Мобильное приложение. Многие компании создают мобильные приложения, в которых просят работать водителей своих перевозчиков. Однако данный способ плохо работает для FTL-перевозок.
Основные причины неудач при использовании мобильного приложения для перевозок на большие расстояния:1
1) Мобильный интернет может стоить достаточно дорого для водителя, особенно если вы не готовы оплачивать его затраты на сотовую связь.
2) Дублирование операций. Водитель вынужден оформлять «бумажные» документы, а потом их фотографировать и загружать в мобильное приложение, чтобы подтвердить статус. Вы готовы оплачивать по факту предоставления фотографии в мобильном приложении, а не после получения оригиналов документов? Если нет, то вы просто заставите водителя совершать ненужные ему действия.
3) Очень много грузовладельцев и экспедиторов увлеклись идеей отслеживания по мобильному приложению. В итоге водителю-ИП необходимо иметь на телефоне десятки приложений.
4. Личный кабинет перевозчика. Один из самых простых и удобных для грузовладельца способов. Переложите задачу по Track&Trace на вашего поставщика транспортных услуг. Диспетчер перевозчика держит связь с водителем и проставляет статус перевозки, а вы получаете в вашей системе необходимые данные.
Отслеживание заказов при развозке и milkrun.
В данном случае лучшим решением будет мобильное приложение.
Во-первых, перевозка внутри города/области неплохо просчитывается по возможным затратам на мобильный интернет.
Во-вторых, в развозке бывают срочные задачи, требующие моментального онлайн-реагирования от водителя и диспетчера (клиент не выходит на связь, возник затор и необходимо изменить маршрут и т.п.).
В-третьих, водитель сам заинтересован в использовании мобильного приложения при данном типе перевозок, так как с помощью системы статусов сможет доказать наличие форс-мажор при следовании по маршруту.
Tracert vs Traceroute
В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.
Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):
Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:
Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.
Итак, утилита tracert.
В основе работы данной утилиты лежит протокол icmp. Рассмотрим вот такую схему: 
Host отправляет по указанному в его таблице маршрутизации маршруту ICMP Echo-Request с ttl 1. Router1, получив такой пакет, проверит адрес назначения — может быть пакет ему. Так как данный пакет адресован другому хосту, то Router1 считает себя транзитным узлом, декрементирует ttl пакета и отбрасывает его, так как время жизни пакета становится равным 0. Так как пакет был дропнут, Router1 отправляет источнику пакета icmp сообщение с указанием причины дропа — Time Exceeded. Утилита tracert, получив данное icmp сообщение, указывает Router1 как первый хоп (информация об адресе указана в icmp сообщении). Далее процесс повторяется с инкрементированием ttl, пока ttl icmp запроса не будет равен количеству хопов между узлом-отправителем и узлом получателем. В данном примере Server1 является узлом назначения. Получив пакет, он проверит адрес назначения, увидит, что запрос адресован ему и отправит ICMP Echo-Reply, что и будет являться для утилиты tracert триггером к окончанию трассировки.
Traceroute — данная утилита работает по иному принципу, хоть и вывод команды похож на вывод предыдущей.
Traceroute основана не на ICMP Echo-Request, а на отправке udp фрагментов и получения сообщения о доступности/недостижимости порта. Вернемся к прошлой схеме. Host генерирует udp фрагмент, инкапсулирует его в IP пакет и выставляет ttl=1. Router1, являясь транзитным узлом, ответит на данный пакет icmp сообщением об окончании времени жизни пакета. Утилита traceroute, получив данное сообщение, указывает адрес источника icmp пакета (Router1) как адрес первого хопа. Далее процесс повторяется с инкрементированием ttl пакета. Всё практически так же, как и в tracert. Но ведь мы не отправляем ICMP Echo-Request, как утилита traceroute поймет, что трассировка закончена? Все просто — в udp заголовке есть поля source и destination порт. Логично, что source порт будет любым портом выше 1023. А каким указать destination порт? Как было сказано выше, работа утилиты traceroute основана на получении сообщения о недостижимости или доступности порта назначения. То есть мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434 (именно этот порт используется по умолчанию). Как и в предыдущем случае, Server1 является узлом назначения. Получив пакет, он распаковывает его и должен передать его протоколам высшего уровня. Но так как порт 33434 по умолочанию будет закрыт на сервере, то Server1 формирует icmp сообщение о недостижимости порта назначения (ICMP Type 3 «Destination Unreachable» Code 3 «Port Unreachable»). Получив данное сообщение, утилита traceroute считает трассировку законченной. В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д). Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK если для трассировки используются TCP SYN пакеты, что тоже будет являться триггером к окончанию трассировки.
Вывод:
Утилита traceroute позволяет сделать трассировку с указанием порта назначения.
Для этого разберем пример ниже:
Возьмем предыдущую схему и сделаем трассировку:
С использованием TCP SYN пакетов:
C использованием UDP пакетов:
Как видите трассировка прошла успешно. Мы видим путь до указанного хоста.
А теперь повесим на интерфейс Router4 фильтр на in (как указано на рисунке): 
Снова сделаем трассировку:
Примечание: Возможен случай, когда пакеты будут дропаться без отправки ICMP сообщений ( отправка в Null-интерфейс в Cisco/Huawei или discard в Juniper). В данном случае трассировка будет идти пока не кончится максимальное TTL, указанное в утилите traceroute (по умолчанию максимум 30 хопов, но можно задать вручную до 255, правда обычно достаточно 15-18 хопов) или ее не прервет администратор, а в выводе будут звездочки.
Примечание: Появление звездочек вместо адресов хостов может быть обусловлено различными причинами и хорошо описано тут
Надеюсь мы разобрались в основных принципах работы данных утилит. Если надо сделать трассировку по какому то порту в Windows системах, можно использовать сторонние утилиты, к примеру tcptrace.
Про интернет, роутеры и трейсы
хм. шакалисто вышло, но суть передаёт.
Итак, примерно в 6-7 вечера звонок на саппорт:
— Добрый вечер, слушаю Вас!
— А вот у меня из дома трейс ужасный! 100 и более мсек ответы и постоянные потери пакетов! Да я ваш интернет на оси земной мотал! Я сам одмин крутецкий и всё знаю! Да я сейчас видео снял и на городские форумы выложу, что бы все видели!
— Открывайте сайт и заходите на айпи 192.168.0.1, кое-что проверим.
По шагам довожу абонента до пункта трассировки в веб-морде роутера и запускаем её. Молодой человек видит идеальные показатели.
— Ну что, нормальный трейс с Вашего роутера?
— А вот теперь информаци: я снял это всё на видео и сам выложу на городские форумы. Думаю многим будет интересно. Хорошо?
— Не надо. Я. я понял, потери где-то у меня. Извините пожалуйста, спасибо Вам за информацию, буду разбираться со своим компом. До свидания.
Видео канеш я не снимал, просто маленький блеф 🙂
ну и каким образом ты так спокойно попал на клиентский роутер?
Т.е. видно, как и с какой примерно
скоростьюпроходят данные от сервера до вас.
Она дает поболее информации, можно заодно узнать, какой именно хоп дает потери
Про работу в МегаФоне 3
Так уж получилось, что самые неадекватные в плохом смысле слова обращения приходили в наш кц-мм (мультимедиа, переписка) из Москвы, Питера и, внезапно, Пензы. Если с первыми двумя всё и так ясно, то наличие Пензы в этом топ-3 меня удивило. Но как есть. При этом, мы обслуживали все регионы России.
Начитался я за год работы всякого: угрозы, суды, просьбы, предложения руки и сердца. Среди всего этого можно выделить несколько типов абонентов.
6) Клоуны, шутники, пранкеры.
С этими всегда весело. Пишут редко, но метко. Обычно лютый бред, в чем сами же и сознаются. Превращают даже реальную проблему в цирк.
Пример: это вопросы от одного человека.
— у нас вышка не работает. Пришлите бригаду, на 911 не отвечают.
— приехали миньоны, ничего не сделали, держу в курсе.
— пошел дождь, связи нет. Зовите Фиксиков.
— а можно я сам до вышки схожу?
— а если я попинаю вышку, меня посадят?
— а сколько стоит ремонт вышки? (Тут я чутка напрягся).
— да я просто считаю. А она из меди или алюминия?
— а на дереве так же будет ловить?
(Рекомендация перезагрузить телефон)
— о, заработало, спасибо! А как вы узнали?
— а вы в Хогвартсе учились?
— а можно к вам Фиксиком устроиться?
(Там была ещё куча подобных вопросов, но суть понятна. И прерывать диалог с нашей стороны тоже нельзя, вот и читали всем КЦ).
Итог: есть ещё подкатегории. Но пост и так вышел длинным, не могу я в краткость. Вроде столько интересного хочется рассказать, а получается не очень.
В следующий раз про подписки напишу. Уж больно цепляющая тема для абонентов.