Strm yandex net что это
Как удалить Yamdex.net в браузере. Избавляемся от Yambler.net, Webalta и Амиго
Браузер Амиго от Mail.ru сюда попал до кучи, за назойливость, заточен на соцсети и часто его установка сопровождается троянами.
Ежу понятно, что словили трояна и как показывает практика, обычно не одного. Для начала стоит проверить компьютер антивирусом, желательно свежим (сам предпочитаю DrWeb, не сочтите рекламой). DrWeb, можно скачать вполне легально с демонстрационным ключом с официального сайта https://download.drweb.ru.
Чем же интересны Yamdex.net, Yambler.net и Webalta и как их удалить?
Суть в том, что даже после лечения браузеры продолжают вас отправлять на сайты злоумышленников.
Смена стартовой страницы в настройках браузера проблемы не решает, всё остаётся как и было. Причем и вирусов на компьютере антивирус больше не находит. А их и нет! Надстройки в браузерах уже отключены или удалены. что не так?
Это легко проверяется. Кликните правой кнопкой мыши по ярлыку браузера и зайдите в «Свойства». Внимательно смотрим что написано в поле «Объект». Уверен что увидите измененный путь запуска программы, в ряде случаев он идентичен обычному пути, но имеет расширение url.
В меню «Пуск» ярлыки браузеров тоже следует проверить, на скриншоте ниже как раз видно измененный путь к Internet Explorer:
Любителям Internet Explorer может потребоваться правка реестра, да и Google Chrome тоже оттуда кормится. Вирус заменяет подстановку префикса адреса поисковой строки на yamdex.net. То есть, какой бы сайт вы не хотели посетить, в первую очередь вас выкинет на вредоносный.
Собственно, можно просто удалить всё что там имеется. В моем случае там стояли ссылки на какой-то левый поисковик. Удачи!
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 17
Разобралась, я просто удалила все ярлыки и создала новые. Спасибо вам, без вас я бы даже не догадалась что дело просто в ярлыках.
Удалил yamdex.net через реестр. Весь интернет излазил, везде только про ярлыки написано. Спасибо огромное!
Сын накачал игрушек и в результате на всех сайтах реклама и этот дукацкий ямблер. Уже хотела в сервис нести компьютер. Спасибо вам за описание, убрала самостоятельно
я в свойствах ярлыка браузера убрал webalta и больше не появилась
У меня такая же проблема, все перечитал в интернете, перепробовал и чистку реестра по разным статьям, удалял и чистил в папке APP соответствующие папки и файлы. В итоге только по вашей статье удалось убрать поиск по умолчанию yamdex.net
Отлично. Удалил ЯМДЕКС по вашей статье. Я рад. Автору спасибо
У кого не удаляется yamdex.net попробуйте восстановить система позднее число.
spasibo za pomosch! udalil v reestre
Могу посоветовать Malwarebytes Anti-Malware. Всю шелуху типа yamdex.net и прочую дрянь (даже ту, что прописывается в сервисы) вырывает с корнем.
давно пользуюсь mac os и забыл про вирусы
кучу времени экономлю
Спасибо автору. Наконец-то избавился от этой херни
«полагаю, что-то из этого вы наблюдаете на своем компьютере или ноутбуке, иначе не искали бы как избавиться от этого безобразия». Да? А почему у меня этого нет? Может на компьютере с Windows у меня лицензионный Касперский? Может, потому что на компьютере с Linux я систему регулярно обновляю?
Александр, на вашем компьютере вирус гораздо страшнее, чем описанные в статье. Это Касперский, чтобы комп нормально работал, срочно удаляйте его.
Яндекс помогает распространять вредоносное ПО?
По роду деятельности мне приходится наблюдать за работой сотен рядовых пользователей ПК. Человек, который не первый день держит мышку, всё чаще сталкивается с проблемами при банальном скачивании бесплатного ПО. При разборе выясняется, что он всего лишь набрал в Яндексе «скачать Вайбер», а дальше что-то пошло не так. Я давно слежу за распространением заразы при непосредственном участии Яндекса. Когда-то это были единичные случаи, но теперь явление уже приобрело массовый характер. Объясню, в чём суть. Введём в запросе название любой популярной программы, которую условный домашний пользователь хочет скачать, и получим примерно такую выдачу:
Каждая строка с пометкой «реклама» — это платное объявление от физического или юридического лица, которое зарегистрировано в сервисе Яндекс.Директ со всеми адресами, телефонами и прочими ИНН. Каждое такое объявление проходит ручную модерацию, то есть, в данном случае модератора вовсе не смутил тот факт, что пять разных «официальных» сайтов подали рекламу для скачивания бесплатного приложения. И уж точно проверенный модератором номер (495) 111-22-33 не принадлежит Скайпу.
И, что самое интересное, порядок выдачи разных объявлений по одному запросу определяется аукционом. Если не вдаваться в подробности админки Директа — кто выставил бОльшую стоимость клика, того показывают выше. Да, каждое нажатие на такую ссылку обходится автору объявления в N рублей! За что именно борются рублём рекламодатели — неизвестно, вариантов много: от относительно безобидного майнинга криптовалюты на чужом железе до перехвата платёжных данных из Сбербанк.Онлайн или Алиэкспресса. Но логично, что альтруизмом здесь и не пахнет.
upd2 На двух предыдущих скринах результаты поиска прокручены, чтобы нижний рекламный блок оказался рядом с запросом.
На Директе мошенничество не заканчивается. Ниже обычная поисковая выдача без рекламы по запросу «anydesk» — популярного приложения от бывшей команды TeamViewer. anydesk.com — это настоящий сайт, который и должен вылезать первым по данному запросу. А уже второй результат (с точка ru) — фэйк. Достаточно одного взгляда на этот одностраничный сайт с морально устаревшим клипартом, чтобы понять, что перед нами подделка, нарисованная на коленке за 15 минут. НО только не для модераторов Яндекса. Обратите внимание: адрес этого сайта содержит заглавные и строчные буквы (AnyDesk, а не anydesk). Такое возможно только в одном случае: автор сайта зарегистрирован в сервисе Яндекс.Вебмастер и прошёл ручную модерацию на изменение регистра символов в адресе этого «официального сайта».
Помойка в выдаче повторяется для любого ПО, которое только приходит в голову, хоть платного, хоть бесплатного. Приписка «официальный сайт» положение не спасает, а популярная среди начинающих пользователей фраза «скачать бесплатно» наоборот только помогает попасть на поддельный сайт. Чудесные алгоритмы ранжирования Яндекса, которые совершенствуются каждый день, помогают подозрительным сайтам лезть выше. А как показывает практика, неопытный пользователь обычно жмёт первый результат поиска, доверяя лучшему отечественному поисковику.
И ещё немного про Директ. Сервис позволяет таргетировать рекламу по разным признакам. Например, показывать её только жителям Кировской области мужского пола в возрасте от 25 до 45 лет. Это удобно для честной рекламы, скажем, магазина электроинструмента. Или можно показывать её только пользователям браузера Internet Explorer. Последние обычно ассоциируются с неопытными пользователями ПК, поэтому за такого «чайника» можно заплатить и побольше: рекламная ссылка в примере ниже вылезает даже выше искомого официального сайта. Этот запрос сделан в Internet Explorer, в альтернативном браузере рекламный блок здесь не появляется.
upd3 Проверим теорию с таргетингом: заходим под *nix, и всю платную рекламу по тем же запросам как рукой сняло — такие пользователи точно зря потратят стоимость клика.
Что делать с этой информацией? Ограничивать права учётных записей на компьютерах родственников, и объяснять, что верить никому нельзя.
И вопрос к Яндексу, если этот текст до него дойдёт: вы собираетесь как-то решать эту проблему?
Массовость проблемы подтверждает статистика запросов wordstat.yandex.ru: по каждому из ключевых слов тысячи и десятки тысяч ежемесячных запросов.
upd Изначально похвалил Гугл, но в комментариях меня поправили. Google занимается тем же самым (установленная баннерорезка скрыла эти результаты).
upd4 В комментариях появился ответ от представителя Яндекса:
На Хабре меня достаточно давно знают как автора публикаций про технологии Яндекса, поэтому я вызвался добровольцем ответить на этот пост. Кроме того, мне уже приходилось рассказывать про то, как вообще работает дистрибуция софта в индустрии.
Во-первых, Яндекс сотрудничает только с теми компаниями, которые производят или распространяют ПО на легальных основаниях. Это касается и рекламы в выдаче. Вы можете возразить: но ведь на скриншотах неофициальные сайты. Суть в следующем.
Неофициальность сайта с программой в абсолютном большинстве случаев не означает, что он вредоносный. Разработчики ПО как правило заинтересованы в том, чтобы их продукты также распространялись через сайты партнёров. Для них это увеличение загрузок, а для партнёров — проценты от доходов разработчиков.
Во-вторых, как верно подметил автор, Яндекс проверяет такие объявления. Не только вручную, но и с применением наших технологий в области антифрода. Собственно, в комментариях уже подметили, что ни по одному из примеров нет однозначного вердикта о вредоносности со стороны каких-либо сканеров и баз данных. Эти примеры мы тоже перепроверили на всякий случай. Никаких признаков вредоносной деятельности там нет.
В общем, всё не так страшно. Но если вы видите что-то подозрительное, то можете сообщить об этом поддержке Яндекса или лично мне — проверим.
Strm yandex net что это
Здравствуйте!
Необходимо блокировать доступ к потоковому видео на yandex.ru с помощью связки squid+squidguard.
Кто-нибудь решал такую задачу?
Открываешь режим разработчика в браузере. Смотришь с какого домена грузится поток. Блокируешь его в squidguard.
video-tub.yandex.ru
strm.yandex.ru
strm.yandex.net
proxy.video.yandex.net
video-tub-ru.yandex.net
Открыл режим разработчика. Там очень много доменов. И как там определить, с какого идет поток?
Еще вопрос: их же может быть много? Я таким образом закрою один домен, а что делать с другими?
Добавляете в squidguard strm.yandex.net. Всё что стоит перед strm.yandex.net, будет блокироваться. Если хотите блокировать средствами squid, то поставьте точку перед strm.
Спасибо большое.
Вроде все получилось. Если что, напишу еще.
Еще раз спасибо.
Добрый.
Как вариант, научить squid фильтровать https. И блокировать по расширениям (.ts в данном случае)
У ТС нет мультивана.
Да и проблемы «вроде».
У меня у соседа нет вообше интернета ;D ;D Да и проблемы «вроде». :-*
Мой совет ТС касаемо решения его проблемы с помощью squid как и ответ выше на ваше «У SQUID вроде проблемы с Multiwan что есть не очень хорошо» отсуствием смысла не страдает. В отличие от вашего словоблудия с соседом.
Делегировать домен
Делегировать домен — значит передать управление доменом на выбранный DNS-сервер. Вы можете делегировать домен на DNS-серверы Яндекса — тогда они будут хранить служебную информацию о вашем домене и управлять этой информацией.
Если вы делегируете домен на серверы Яндекса:
будут автоматически настроены необходимые для работы Почты DNS-записи — MX, SPF, CNAME и DKIM;
вы сможете управлять DNS-записями домена c помощью DNS-редактора Коннекта.
Если на вашем домене находится сайт, в большинстве случаев делегирование домена не повлияет на его работу. Чтобы убедиться, что адрес сайта привязан к имени домена, в DNS-редакторе Коннекта проверьте A-записи домена.
Делегировать домен можно в личном кабинете на сайте вашего регистратора. Для этого в настройках домена нужно изменить NS-записи — адреса DNS-серверов, которые обеспечивают работоспособность домена. Вы можете делегировать только те домены, которые уже подключены к вашей организации в Коннекте.
Чтобы делегировать домен на серверы Яндекса:
Если в настройках делегирования есть поля для ввода IP-адресов, оставьте их пустыми.
Подождите, пока изменения в DNS вступят в силу. Может потребоваться до 72 часов, чтобы DNS-серверы в интернете обменялись данными о новых DNS-записях.
На странице управления доменамиубедитесь, что статус вашего домена отображается как Делегирован.
Делегировать домен
Делегировать домен — значит передать управление доменом на выбранный DNS-сервер. Вы можете делегировать домен на DNS-серверы Яндекса — тогда они будут хранить служебную информацию о вашем домене и управлять этой информацией.
Если вы делегируете домен на серверы Яндекса:
будут автоматически настроены необходимые для работы Почты DNS-записи — MX, SPF, CNAME и DKIM;
вы сможете управлять DNS-записями домена c помощью DNS-редактора Коннекта.
Если на вашем домене находится сайт, в большинстве случаев делегирование домена не повлияет на его работу. Чтобы убедиться, что адрес сайта привязан к имени домена, в DNS-редакторе Коннекта проверьте A-записи домена.
Делегировать домен можно в личном кабинете на сайте вашего регистратора. Для этого в настройках домена нужно изменить NS-записи — адреса DNS-серверов, которые обеспечивают работоспособность домена. Вы можете делегировать только те домены, которые уже подключены к вашей организации в Коннекте.
Чтобы делегировать домен на серверы Яндекса:
На главной странице Яндекс.Коннекта на карточке сервиса Вебмастер нажмите значок 
.
Удобное логирование на бэкенде. Доклад Яндекса
Что-то всегда идет не по плану. Приходится отвечать на вопросы, «Что сломалось?», «Почему тормозит?» и «Почему мы не увидели этого раньше?». На примере простого приложения Даниил Галиев zefirior из Яндекс.Путешествий показал, как отвечать на эти вопросы и какие инструменты в этом помогут. Настроим логирование, прикрутим трассировку, разложим ошибки, и все это в удобном интерфейсе.
— Давайте начинать. Я расскажу об удобном логировании и инфраструктуре вокруг логирования, которую можно развернуть, чтобы вам с вашим приложением и его жизненным циклом было удобно жить.
Что будем делать? Мы построим небольшое приложение, наш стартап. Потом внедрим в него базовое логирование, это маленькая часть доклада, то, что поставляет Python из коробки. И дальше самая большая часть — мы разберем типичные проблемы, которые встречаются нам во время отладки, выкатки, и инструменты для их решения.
Небольшой дисклеймер: я буду говорить такие слова, как «ручка» и «локаль». Поясню. «Ручка» — возможно, яндексовый сленг, это обозначает ваши API, http или gRPC API или любые другие комбинации букв перед APU. «Локаль» — это когда я разрабатываю на ноутбуке. Вроде бы я рассказал обо всех словах, которые я не контролирую.
Приложение «Книжная лавка»
Начнем. Наш стартап — это «Книжная лавка». Главной фичей этого приложения будет продажа книг, это все, что мы хотим сделать. Дальше немного начинки. Приложение будет написано на Flask. Все сниппеты кода, все инструменты общие и абстрагированы от Python, поэтому их можно будет интегрировать в большинство ваших приложений. Но в нашем докладе это будет Flask.
Действующие лица: я, разработчик, менеджеры и мой любимый коллега Эраст. Любые совпадения случайны.
Давайте немного про структуру. Это приложение с микросервисной архитектурой. Первый сервис — Books, хранилище книг с метаданными о книгах. Он использует базу данных PostgreSQL. Второй микросервис — микросервис доставки, хранит метаданные о заказах пользователей. Cabinet — это бэкенд для кабинета. У нас нет фронтенда, в нашем докладе он не нужен. Cabinet агрегирует запросы, данные из сервиса книг и сервиса доставки.
По-быстрому покажу код ручек этих сервисов, API Books. Это ручка выгребает данные из базы, сериализует их, превращает в JSON и отдает.
Пойдем дальше. Сервис доставки. Ручка точно такая же. Выгребаем данные из базы, сериализуем их и отправляем.
И последняя ручка — ручка кабинета. В ней немного другой код. Ручка кабинета запрашивает данные из сервиса доставки и из сервиса книг, агрегирует ответы и отдает пользователю его заказы. Всё. Со структурой приложения мы по-быстрому разобрались.
Базовое логирование в приложении
Теперь давайте про базовое логирование, то, которое мы впилили. Начнем с терминологии.
Что нам дает Python? Четыре базовые, главные сущности:
— Logger, входная точка логирования в вашем коде. Вы будете пользоваться каким-то Logger, писать logging.INFO, и все. Ваш код больше ничего не будет знать о том, куда сообщение улетело и что с ним дальше произошло. За это уже отвечает сущность Handler.
— Handler обрабатывает ваше сообщение, решает, куда его отправить: в стандартный вывод, в файл или кому-нибудь на почту.
— Filter — одна из двух вспомогательных сущностей. Удаляет сообщения из лога. Другой стандартный вариант использования — это наполнение данными. Например, в вашей записи нужно добавить атрибут. Для этого тоже может помочь Filter.
— Formatter приводит ваше сообщение к нужному виду.
На этом с терминологией закончили, дальше к логированию прямо на Python, с базовыми классами, мы возвращаться не будем. Но вот пример конфигурации нашего приложения, которая раскатана на всех трех сервисах. Здесь два главных, важных для нас блока: formatters и handlers. Для formatters, есть пример, который вы можете увидеть здесь, шаблон того, как будет выводиться сообщение.
В handlers вы можете увидеть, что logging.StreamHandler использован. То есть мы выгружаем все наши логи в стандартный вывод. Всё, с этим закончили.
Проблема 1. Логи разбросаны
Переходим к проблемам. Для начала проблема первая: логи разбросаны.
Немножечко контекста. Наше приложение мы написали, конфетка уже готова. Мы можем на нем зарабатывать денежку. Мы его выкатываем в продакшен. Конечно, там не один сервер. По нашим скромным подсчетам, нашему сложнейшему приложению нужно порядка трех-четырех машинок, и так для каждого сервиса.
Теперь вопрос. Прибегает к нам менеджер и спрашивает: «Там сломалось, помоги!» Вы бежите. У вас же все логируется, это великолепно. Вы заходите на первую машинку, смотрите — там ничего нет по вашему запросу. Заходите на вторую машинку — ничего. И так далее. Это плохо, это надо как-то решать.
Давайте формализуем результат, который мы хотим увидеть. Я хочу, чтобы логи были в одном месте. Это простое требование. Немного круче то, что я хочу поиск по логам. То есть да, оно лежит в одном месте и я умею грепать, но было бы прикольно, если бы были какие-нибудь tools, крутые фичи помимо простого грепа.
И я не хочу писать. Это Эраст любит писать код. Я не про это, я сразу сделал продукт. То есть хочется меньше дополнительного кода, обойтись одним-двумя файликами, строчками, и всё.
Решение, которое можно использовать, — Elasticsearch. Давайте его попробуем поднять. Какие плюсы Elasticsearch нам даст? Это интерфейс с поиском логов. Сразу из коробки есть интерфейс, это вам не консолька, а единственное место хранения. То есть главное требование мы отработали. Нам не нужно будет ходить по серверам.
В нашем случае это будет довольно простая интеграция, и с недавним релизом у Elasticsearch выпустился новый агент, который отвечает за большинство интеграций. Они там сами впилили интеграции. Очень круто. Я составлял доклад чуть раньше и использовал filebeat, так же просто. Для логов все просто.
Немного об Elasticsearch. Не хочу рекламировать, но там много дополнительных фич. Например, крутая штука — полнотекстовый поиск по логам из коробки. Очень круто звучит. Нам пока достаточно этих плюсов. Прикручиваем.
В первую очередь нам нужно будет развернуть агент, который будет отправлять наши логи в Elasticsearch. Вы регистрируете аккаунт в Elasticsearch и дальше добавляете в ваш docker-compose. Если у вас не docker-compose, можете поднимать ручками или в вашей системе. В нашем случае добавляется вот такой блок кода, интеграции в docker-compose. Всё, сервис настроен. И вы можете увидеть в блоке volumes файл конфигурации filebeat.yml.
Вот пример filebeat.yml. Здесь настроен автоматический поиск логов контейнеров docker, которые крутятся рядом. Кастомизован выбор этих логов. По условию можно задавать, вешать на ваши контейнеры лейблы, и в зависимости от этого ваши логи будут отправляться только у определенных контейнеров. С блоком processors:add_docker_metadata все просто. В логи добавляем немножечко больше информации о ваших логах в контексте docker. Необязательно, но прикольно.
Что мы получили? Это все, что мы написали, весь код, очень круто. При этом мы получили все логи в одном месте и есть интерфейс. Мы можем поискать наши логи, вот плашечка search. Они доставляются. И можно даже в прямом эфире включить так, чтобы стрим летел к нам в логи в интерфейс, и мы это видели.
Тут я бы и сам спросил: а чего, как грепать-то? Что из себя представляет поиск по логам, что там можно сделать?
Да, из коробки в таком подходе, когда у нас текстовые логи, есть небольшой затык: мы можем по тексту задать запрос, например message:users. Это выведет нам все логи, у которых есть подстрока users. Можно пользоваться звездочками, большинством других юниксовых wild cards. Но кажется, этого недостаточно, хочется сделать сложнее, чтобы можно было нагрепать в Nginx раньше, как мы это умеем.
Давайте немного отступим от Elasticsearch и попытаемся сделать это не с Elasticsearch, а с другим подходом. Рассмотрим структурные логи. Это когда каждая ваша запись лога — это не просто текстовая строчка, а сериализованный объект с атрибутами, которые любая ваша сторонняя система может сериализовать, чтобы получить уже готовый объект.
Какие от этого есть плюсы? Это единый формат данных. Да, у объектов могут быть разные атрибуты, но любая внешняя система может прочитать именно JSON и получить какой-то объект.
Какая-никакая типизация. Это упрощает интеграцию с другими системами: не нужно писать десериализаторы. И как раз десериализаторы — это другой пункт. Вам не нужно писать в приложении прозаичные тексты. Пример: «User пришел с таким-то айдишником, с таким-то заказом». И это все нужно писать каждый раз.
Меня это напрягало. Я хочу написать: «Прилетел запрос». Дальше: «Такой-то, такой-то, такой-то», очень просто, очень по-айтишному.
Давайте дальше. Договоримся: логировать будем в формате JSON, это простой формат. Сразу Elasticsearch поддерживается, filebeat, которым мы сериализуем и попробуем впилить. Это не очень сложно. Для начала вы добавляете из библиотеки pythonjsonlogger в блок formatters JSONFormatter файлика settings, где у нас хранится конфигурация. У вас в системе это может быть другое место. И дальше в атрибуте format вы передаете, какие атрибуты вы хотите добавлять в ваш объект.
Блок ниже — это блок конфигурации, который добавляется в filebeat.yml. Здесь из коробки есть интерфейс у filebeat для парсинга JSON-логов. Очень круто. Это все. Для этогов вам больше ничего писать не придется. И теперь ваши логи похожи на объекты.
Что мы получили в Elasticsearch? В интерфейсе вы сразу видите, что ваш лог превратился в объект с отдельными атрибутами, по которым вы можете искать, создавать фильтрации и делать сложные запросы.
Давайте подведем итог. Теперь наши логи имеют структуру. По ним несложно грепать и можно писать интеллектуальные запросы. Elasticsearch знает об этой структуре, так как он распарсил все эти атрибуты. А в kibana — это интерфейс для Elasticsearch — можно фильтровать такие логи с помощью специализированного языка запросов, который предоставляет Elasticsearch.
И это проще, чем грепать. Греп имеет довольно сложный и крутой язык. Там очень много можно написать. В kibana можно сделать многие вещи проще. С этим разобрались.
Проблема 2. Тормоза
Следующая проблема — тормоза. В микросервисной архитектуре всегда и везде бывают тормоза.
Тут немного контекста, расскажу вам историю. Ко мне прибегает менеджер, главное действующее лицо нашего проекта, и говорит: «Эй-эй, кабинет тормозит! Даня, спаси, помоги!»
Мы пока ничего не знаем, лезем в Elasticsearch в наши логи. Но давайте я расскажу, что, собственно, произошло.
Эраст добавил фичу. В книгах мы теперь отображаем не айдишник автора, а его имя прямо в интерфейсе. Очень круто. Сделал он это вот таким кодом. Небольшой кусок кода, ничего сложного. Что может пойти не так?
Вы наметанным взглядом можете сказать, что с SQLAlchemy так делать нельзя, с другой ORM тоже. Нужно сделать прекэш или что-нибудь еще, чтобы в цикле не ходить в базу с маленьким подзапросиком. Неприятная проблема. Кажется, что такую ошибку вообще нельзя допустить.
Давайте расскажу. У меня был опыт: мы работали с Django, и у нас в проекте был реализован кастомный прекэш. Много лет все шло хорошо. В какой-то момент мы с Эрастом решили: давай пойдем в ногу со временем, обновим Django. Естественно, Django ничего не знает о нашем кастомном прекэше, и интерфейс поменялся. Прикэш отвалился, молча. На тестировании это не отловили. Та же самая проблема, просто ее сложнее было отловить.
Проблема в чем? Как я помогу вам решить проблему?
Давайте расскажу, что я делал до того, как начал решать именно проблему поиска тормозов.
Первое, что делаю, — иду в Elasticsearch, у нас он уже есть, помогает, не нужно бегать по серверам. Я захожу в логи, ищу логи кабинета. Нахожу долгие запросы. Воспроизвожу на ноутбуке и вижу, что тормозит не кабинет. Тормозит Books.
Бегу в логи Books, нахожу проблемные запросы — собственно, он у нас уже есть. Точно так же воспроизвожу Books на ноутбуке. Очень сложный код — ничего не понимаю. Начинаю дебажить. Тайминги довольно сложно отлавливать. Почему? Внутри SQLAlchemy довольно сложно это определить. Пишу кастомные тайм-логгеры, локализую и исправляю проблему.
Мне было больно. Сложно, неприятно. Я плакал. Хочется, чтобы этот процесс поиска проблемы был быстрее и удобнее.
Формализуем наши проблемы. Сложно по логам искать, что тормозит, потому что наш лог — это лог несвязанных событий. Приходится писать кастомные таймеры, которые показывают нам, сколько выполнялись блоки кода. Причем непонятно, как логировать тайминги внешних систем: например, ORM или библиотек requests. Надо наши таймеры внедрять внутрь либо каким-то Wrapper, но мы не узнаем, от чего оно тормозит внутри. Сложно.
Хорошее решение, которое я нашел, — Jaeger. Это имплементация протокола opentracing, то есть давайте внедрим трассировку.
Что дает Jaeger? Это удобный интерфейс с поиском запросов. Вы можете отфильтровать долгие запросы или сделать это по тегам. Наглядное представление потока запросов, очень красивая картинка, чуть позже покажу.
Тайминги логируются из коробки. С ними ничего не надо делать. Если вам нужно про какой-то кастомный блок проверить, сколько он выполняется, вы можете его обернуть в таймеры, предоставляемые Jaeger. Очень удобно.
Посмотрим, как вообще можно было найти проблему в интерфейсе и там же ее локализовать. Мы заходим в интерфейс Jaeger. Вот так выглядят наши запросы. Мы можем поискать запросы именно кабинета или другого сервиса. Сразу фильтруем долгие запросы. Нас интересуют именно долгие, их по логам довольно сложно найти. Получаем их список.
Проваливаемся в этот запрос, и видим большую портянку SQL-подзапросов. Мы прямо наглядно видим, как они исполнялись по времени, какой блок кода за что отвечал. Очень круто. Причем в контексте нашей проблемы это не весь лог. Там есть еще большая портянка на два-три слайда вниз. Мы довольно быстро локализовали проблему в Jaeger. В чем после решения проблемы нам может помочь контекст, который предоставляет Jaeger?
Jaeger логирует, например, SQL-запросы: вы можете посмотреть, какие запросы повторяются. Очень быстро и круто.
Проблему мы решили и сразу видим в Jaeger, что все хорошо. Мы проверяем по тому же запросу, что у нас теперь нет подзапросов. Почему? Предположим, мы проверим тот же запрос, узнаем тайминг — посмотрим в Elasticsearch, сколько запрос выполнялся. Тогда мы увидим время. Но это не гарантирует, что подзапросов не было. А здесь мы это видим, круто.
Давайте внедрим Jaeger. Кода нужно не очень много. Вы добавляете зависимости для opentracing, для Flask. Теперь о том, какой код мы делаем.
Первый блок кода — это настройка клиента Jaeger.
Затем мы настраиваем интеграцию с Flask, Django или с любым другим фреймворком, на который есть интеграция.
install_all_patches — самая последняя строчка кода и самая интересная. Мы патчим большинство внешних интеграция, взаимодействуя с MySQL, Postgres, библиотекой requests. Мы все это патчим и именно поэтому в интерфейсе Jaeger сразу видим все запросы с SQL и то, в какой из сервисов ходил наш искомый сервис. Очень круто. И вам не пришлось много писать. Мы просто написали install_all_patches. Магия!
Что мы получили? Теперь не нужно собирать события по логам. Как я сказал, логи — это разрозненные события. В Jaeger это одно большое событие, структуру которого вы видите. Jaeger позволяет отловить узкие места в приложении. Вы просто делаете поиск по долгим запросам, и можете проанализировать, что идет не так.
Проблема 3. Ошибки
Последняя проблема — ошибки. Да, я лукавлю. Я не помогу вам избавиться от ошибок в приложении, но я расскажу, что с ними можно делать дальше.
Контекст. Вы можете сказать: «Даня, мы логируем ошибки, у нас есть алерты на пятисотки, мы настроили. Чего ты хочешь? Логировали, логируем и будем логировать и отлаживать.
По логам вы не знаете важность ошибки. Что такое важность? Вот у вас есть одна крутая ошибка, и ошибка подключения к базе. База просто флапнула. Хочется сразу видеть, что эта ошибка не так важна, и если нет времени, не обращать на нее внимания, а фиксить более важную.
Частота появления ошибок — это контекст, который может нам помочь в ее отладке. Как отслеживать появление ошибок? Преподолжим, у нас месяц назад была ошибка, и вот она снова появилась. Хочется сразу найти решение и поправить ее или сопоставить ее появление с одним из релизов.
Вот наглядный пример. Когда я впиливал интеграцию с Jaeger, то немного поменял свою API. У меня изменился формат ответа приложения. Я получил вот такую ошибку. Но в ней непонятно, почему у меня нет ключа, lots в объекте order, и нет ничего, что мне бы помогло. Мол, смотри ошибку здесь, воспроизведи и самостоятельно отлови.
Давайте внедрим sentry. Это баг-трекер, который поможет нам в решении подобных проблем и поиске контекста ошибки. Возьмем стандартную библиотеку, поддерживаемую разработчиками sentry. В четыре строчки кода мы ее добавляем в наше приложение. Всё.
Что мы получили на выходе? Вот такой дашборд с ошибками, которые можно сгруппировать по проектам и за которыми можно следить. Огромная портянка логов с ошибками группируется в одинаковые, похожие. По ним приводится статистика. И вы также можете работать с этими ошибками с помощью интерфейса.
Посмотрим на нашем примере. Проваливаемся в ошибку KeyError. Сразу видим контекст ошибки, что было в объекте order, чего там не было. Я сразу по ошибке вижу, что мне приложение Delivery отдало новую структуру данных. Кабинет просто к этому не готов.
Что дает sentry, помимо того, что я перечислил? Формализуем.
Это хранилище ошибок, в котором можно искать их. Для этого есть удобные инструменты. Есть группировка ошибок — по проектам, по похожести. Sentry дает интеграции с разными трекерами. То есть вы можете следить за вашими ошибками, работать с ними. Вы можете просто добавлять задачу в ваш контекст, и все. Это помогает в разработке.
Статистика по ошибкам. Опять же, легко сопоставить с выкаткой релиза. В этом вам поможет sentry. Похожие события, которые произошли рядом с ошибкой, тоже могут вам помочь в поиске и понимании того, что к ней привело.
Давайте подведем итог. Мы с вами написали приложение, простое, но отвечающее потребностям. Оно помогает вам в разработке и поддержке, в его жизненном цикле. Что мы сделали? Мы собрали логи в одно хранилище. Это дало нам возможность не искать их по разным местам. Плюс у нас появился поиск по логам и сторонние фичи, наши tools.
Интегрировали трассировку. Теперь мы наглядно можем следить за потоком данных в нашем приложении.
И добавили удобный инструмент для работы с ошибками. Они в нашем приложении будут, как бы мы ни старались. Но мы будем фиксить их быстрее и качественнее.
Что еще можно добавить? Само приложение готово, оно есть по ссылке, вы можете посмотреть, как оно сделано. Там поднимаются все интеграции. Например, интеграции с Elasticsearch или трассировки. Заходите, смотрите.
Еще одна крутая штука, которую я не успел осветить, — requests_id. Почти ничем не отличается от trace_id, который используется в трассировках. Но за requests_id отвечаем мы, это самая главная его фича. Менеджер может прийти к нам сразу с requests_id, нам не потребуется его искать. Мы сразу начнем решать нашу проблему. Очень круто.
И не забывайте, что инструменты, которые мы внедряли, имеют overhead. Это проблемы, которые нужно рассматривать для каждого приложения. Нельзя бездумно внедрить все наши интеграции, облегчить себе жизнь, а потом думать, что делать с тормозящим приложением.
Проверяйте. Если на вас это не сказывается, круто. Вы получили только плюсы и не решаете проблемы с тормозами. Не забывайте об этом. Всем спасибо, что слушали.