sentry что это за программа
Мониторинг ошибок с помощью Sentry во фронтенд-приложениях, написанных на JavaScript: Часть 1
Сервис Sentry позволяет удаленно мониторить баги в фронтенд-приложениях, написанных на JavaScript.
Попытка устранить проблемы в фронтенд-приложениях на JavaScript может оказаться непростой задачкой, поскольку они возникают в браузере пользователя, к чему, зачастую, у вас нет доступа. Однако, Sentry дает возможность удаленно мониторить баги.
Здесь можно скачать решения, которые рассматривались в этой статье.
Что необходимо
Если вы хотите воспользоваться этими примерами, то вам понадобятся:
Установка на ваш сервер
Чтобы установить Sentry On-Premise на ваши сервер можно пойти 2 путями
Воспользоваться официальным установщиком:
Стандартное использование
Чтобы начать, добавьте с сайта сервиса новый Sentry-проект для приложения. После выбора нужного языка вы получите соответствующую документацию. В нашем случае мы выбрали JavaScript.
Первый пример — стандартный JavaScript. Здесь две кнопки: «Hello» (Привет) и «Error» (Ошибка).
После того, как вы кликнете по кнопке «Hello», экран перезагрузится, а блок try обнаружит и поймает баг. После того, как баг «пойман», отчет об ошибке вручную пересылается на сервис Sentry.
Кнопка «Error» позволяет просто обнаружить баг.
Чтобы протестировать этот пример, можем воспользоваться статической веб-серверной платформой Node.js: http-сервером. Заходим в папку, где хранится файл index.html, и вводим (опция с отключает кэширование) следущую строку, чтобы открыть в браузере адрес http://localhost:8080.
Как отображаются пойманные баги
Сперва кликаем кнопку «Hello».
Мы словили баг, поэтому он не всплывет вверх по стеку вызовов, поэтому и не мониторится в консоли. Однако, поскольку мы отсылаем в Sentry отчет о баге вручную, то увидим сообщение о нем в аккаунте.
Как отображаются непойманные баги
Кликаем кнопку «Error».
Баг всплывает вверх по стеку вызовов и, таким образом, на консоле отображается сообщение об ошибке. После этого Sentry автоматически мониторит баг, без каких-либо дополнительных действий.
Как обеспечить безопасность проекта
Вы, возможно, обратили внимание на способ, как мы контролируем страницы, которые могут отправлять отчет об ошибках в наш проект Sentry; при помощи dsn записи. Проблема заключается в том, что вход может увидеть каждый, кто просмотрит исходный код вашей страницы.
Чтобы этого не было, нужно ограничить количество доменов, которые могут заносить в наш проект отчеты об ошибках. В этом примере мы использовали localhost (локальный хост). Данная опция настраивается во вкладке настроек Sentry-проекта, Sentry Project Setting.
Релизы
Если подумать о том, как использовать Sentry в разных вариациях нашего приложения, то здесь нужен некий механизм, который будет помечать ошибки номером версии.
Не нужно ведь, чтобы исправленный нами баг выплыл опять, а мы думали, что не сработало то, что мы пофиксили. Может быть ведь и такое, что пользователь запустил более старую, кэшированную версию приложения.
Чтобы решить проблему, нужно вписать идентификатор релиза (версии) при запуске Sentry.
После этого все новые ошибки будут отмечены как release (0.1.0), то есть будут привязаны к правильной версии кода.
OpenTelemetry и Sentry — недооцененные инструменты трассировки распределенных систем на Golang
Sep 16 · 5 min read
Краткое описание 🚶
Создадим небольшой пример инструментирования приложения на Golang с его настройкой, использованием OpenTelemetry и передачей получаемых трассировок на бэкенд Sentry. Вот ссылка на него в Github (с этапами запуска самого примера):
Введение 👋
Трассировки распределенных систем — важная составляющая наблюдаемости, отслеживания и профилирования микросервисной архитектуры. Не будем подробно разбирать, что такое трассировки и как они работают: статей на эту тему так же много, как бэкендов с трассировками.
Проблема большого количества бэкендов с трассировками 🤔
Но здесь есть небольшая проблема. Бы в ает так, что техтребования и гайды по контексту трассировок объявлены, а вопрос инструментирования приложений по-прежнему решается в каждом конкретном бэкенде своими средствами. Потому что есть много разных бэкендов ( Sentry, Jaeger, Google Cloud Tracing, New Relic, ElasticAPM и другие), которые визуализируют трассировки. И у каждого из них свои пакеты SDK для инструментирования.
Сегодня задействуем для инструментирования микросервиса пакеты SDK для Elastic APM. А что, если завтра они покажутся слишком тяжелыми? Перейдем на что-то более легкое ( Jaeger или Sentry)?
Но тогда придется проводить инструментирование всего приложения заново, и с пакетом SDK, используемым только в Jaeger или Sentry. А это приведет к огромным накладным расходам.
И тут приходится кстати OpenTelemetry 🚀
С OpenTelemetry этого делать не придется: выполним инструментирование приложения один раз, после чего эти трассировки будут отправляться в коллектор OpenTelemetry, а оттуда — экспортироваться сразу в несколько бэкендов.
Почему Sentry? 👀
Потому что у него как инструмента трассировки распределенных систем много достоинств, среди которых мне особенно по нраву:
Инструментирование приложения на Golang. Практика ⚒️
Пройдем шаг за шагом процесс инструментирования приложения (полностью находится в файле main.go в репозитории на Github).
Инициализация трассировщика
Для среды разработки это нормально, а вот для эксплуатационной среды частоту отбора желательно понизить до 10–20% во избежание технических недоработок в системе (трассировки обычно довольно тяжелые).
Начало и завершение спана, распространение его контекста
Базовый tracerprovider готов. Разберемся, как именно начинаются, завершаются и записываются события в span на Golang.
Текущий контекст спана (в данном случае ctx2 ) просто передается в следующую функцию. Вот как это было сделано в функции ErrorWork() :
Настройка коллектора и экспортера OpenTelemetry 🚢
Это простая часть: выполняется всего три настройки в файле конфигурации.
Как восстановить Sentry после неудачного обновления
Всем привет. Я хочу рассказать о том, как проходило восстановление Sentry после неудачного обновления.
Что же такое Sentry?
Это система полного отслеживания ошибок с открытым исходным кодом, которая поддерживает широкий спектр серверных, браузерных, настольных и родных мобильных языков и сред, включая PHP, Node. js, Python, Ruby, C #, Java, Go, React, Angular, Vue, JavaScript и другие.
Немного о том, как просто и непринуждённо всё поломалось.
Жили мы на версии 9.0.0 и пришло время обновиться. Пощупав web интерфейс 10.0.0, принял решение обновиться на неё. Это была самая большая ошибка!
Обновление прошло в штатном режиме. Сначала переход на 9.1.2 затем, на 10.0.0 (иначе нельзя). Далее обнаружил, что не запускается worker. Причиной этому добавление новых приложений и зависимостей.
Попытки собрать приложения и засунуть их в k8s не увенчались успехом.
Было принято решение откатиться назад. Но тут меня ждало разочарование. После миграции на 10 версию, часть данных переезжает в clickhouse и удаляется из Postgres.
После 3 часов работ и привлечения DBA эксперта данные были восстановлены до рабочего состояния.
Сделали рядом инстанс PG, закинули туда схему от версии 9.0.0 и начали потабличное восстановление. Конечно, без ошибок и напильника тут не обошлось.
На этом история не заканчивается. Пришло время всё же обновиться на версию 9.1.2.
Собрал образ, запускаю:
и видим вот такое чудесное сообщение:
После долгих поисков, проб и ошибок было найдено решение.
Необходимо восстановить схему данных текущей версии.
Для этого клонируем репозиторий:
Переходим в ветку 9.1.2, так как ветки 9.0.0 уже нет.
Далее правим образ в Dockerfile:
Затем правим compose file
Немного пояснений. Так как у меня есть отдельный инстанс базы данных, то создание через compose пропускаю, также не нужен volume sentry-postgres.
После данных манипуляций запускаем сборку:
В процессе может выскочить ошибка, о которой я упомянул выше. Не обращаем внимания и после того, как процесс закончится, запускаем следующую команду:
Далее можно запускать upgrade.
Итак, схема восстановлена. Можно обновиться на 9.1.2.
Для этого в Dockerfile меняем версию на 9.1.2:
И запускаем install.sh
Если всё сделано верно, то процесс завершится без ошибок. Вывод должен быть примерно такой:
Всё, версия 9.1.2 установлена.
Это всем известные прописные истины. Не спешите, делайте резервные копии и проверяйте всё несколько раз.
Sentry
Sentry
Мониторинг приложений, трекинг и логирование ошибок
Описание
Допустим, мы предприняли все возможные меры по недопущению ошибок во время разработки и сборки проекта. Однако ошибки все-равно могут проникать в продуктивный код. Нам требуется как-то узнавать об их наличии и принимать скорые меры по исправлению. Просить пользователей открывать консоль браузера и делать скриншоты — не самый лучший вариант. Поэтому к проекту неплохо подключить логирование ошибок.
Смысл простой: на каждое событие window.onerror или в каждый переход исполнения кода в блок catch выполняется простой AJAX-запрос на специально выделенный адрес сервера, в тело которого кладется информация об ошибке. Далее потребуется инструмент, который быстро оповестит техподдержку и разработчиков о наличии новых ошибок и позволит эффективно работать с ними. Самый популярный из таких инструментов для фронтенда — Sentry.
Система логирования Sentry позволяет собирать, группировать, представлять ошибки в реальном времени. Есть сборки для разных языков, в том числе JavaScript. Проект предоставляет платный доступ с расширенными возможностями для бизнеса, однако можно попробовать его основные возможности на бесплатном тестовом аккаунте.
Подключать Sentry можно как непосредственно в HTML-файле, так и в компонентах, выполненных на одном из популярных фреймворков: React, Vue, Angular, Ember и других.
Аналоги и альтернативы для Sentry
Zabbix
Zabbix — свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым. Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP
Graphite
Готовый к работе на предприятии инструмент мониторинга, который одинаково хорошо работает на дешевом оборудовании или облачной инфраструктуре
Prometheus
Включите свои метрики и оповещения с помощью ведущего решения для мониторинга с открытым исходным кодом
Grafana
Grafana это решение для анализа и мониторинга с открытым исходным кодом
Агрегирование исключений и логов при помощи Sentry
Это агрегатор «исключений», который делится на две части, серверную и клиентскую. На сервере будут агрегироваться исключения и можно будет производить поиск и фильтрацию и т.д. Клиентская сторона просто посылает на сервер «исключения» и всё.
Делает эту клевую штуку небезызвестный David Cramer и команда DISQUS.
Можно добавлять группы ошибок в избранное. А при подключении плагинов можно, к примеру, регистрировать «исключения» в Jira, Assembla и Trello.
Помимо проектов на Python (в частности меня интересует Django и Flask) поддерживается также PHP, Ruby, Node.js, Java, Javascript. Все официальные клиенты работают через raven.
Сам sentry работает на Django +зависимости. В качестве wsgi-сервера использует gunicorn.
Имеет вот такой секси-интерфейс на Twitter bootstrap:
Текущая версия Sentry 5.0.21
Настройка серверной части
Есть платное хранилище на getsentry.com, где вы сможете хранить свои «исключения», минимальная цена на текущий момент всего $9/mo. То есть вы можете вообще не устанавливать серверную-часть, а сразу перейти к настройке клиентской части. Меня не устраивал этот вариант из-за некоторой паранойи у проекта, если у вашего проекта нет такого, то конечно проще арендовать sentry-сервер.
Итак, приступим к установке и настройки серверной части! Входим на сервер и устанавливаем Sentry, а также генерируем конфигурационный файл:
Далее указываем нужный бекенд (секция ENGINE в DATABASES) для хранения данных о ошибках, лично я предпочитаю MySQL:
Доустанавливаем MySQL-python:
Подсоединяемся к нашему mysql-server:
Настраиваем проксирование через Nginx:
Теперь создаем конфигурационный файл для supervisor:
И запускаем вебсервер:
Если по каким-то причинам вы не используете supervisor, то запускать Sentry надо так:
Остальное можно прочитать в документации, а про запуск Sentry читать в этом разделе документации.
Добавляем суперпользователя
Выполните и введите имя, пароль, почту, вообщем как обычно для Django-проекта:
Если у вас возникла вот такая ошибка:
Тогда установите язык в консоли и выполните снова createsuperuser:
Добавление новых пользователей осуществляется в два этапа, сначала в админке http://sentry.example.org/admin/auth/user/ создаете пользователя, потом добавляете его в настройках проекта.
Настройки на стороне клиента
Сначала устанавливаем raven (клиент для Sentry):
Документация по настройке raven и Django тут.
/settings.py (точнее в local_settings.py) вашего проекта следующие настройки:
Оберните WSGIHandler в Sentry, файл
Пример uWSGI-конфига, файл
Это собственно всё, Sentry решил проблему со сбором «исключений» и предоставил удобный интерфейс для работы с ними! Рекоммендую воспользоваться этим замечательным инструментом!
Про минусы забыл написать 🙂
Пока рано, но ты можешь привести свои пункты 🙂
Уже месяц хочу попробовать но все руки не доходят._)
Делает эту клевую штуку небезызвестный David Cramer и команда DISQUS.
А если по существу:
1. это SPOF, без рецептов по распределению
2. это избыточность (ну nginx+uwsgi+django(с роутингом, с прослойками, с сигналами, с ORM)+RDB для того чтобы лог записать)
3. это низкая производительность (как следствие пункта 2).
4. отсутствие аналитики (понятно, что можно выгрузить, или плагин написать, но из коробки ноль)
Это просто коллектор логов. На питоновском MVC-фреймворке. С SQL-базой. Без аналитики.
Да, и у меня ощущение, что это правильно делать на riak или couchDB(couchApp).
Да, django тут невписывается. А вообще я считаю надо всегда заниматься чем-то одним, одни делают коллекторы и хранилище, другие веб-интерфесы, графики и аналитику
Я уже писал про настройку UDP в Sentry, но сам постоянно забываю использовать внешний интерфейс в SENTRY_UDP_HOST:
Проверять идут ли логи по UDP можно так:
И в соседней консоли:
ps. вообщем это я для себя записал, не обращайте внимание 🙂