Привет, хабр! Меня зовут Алексей, я — системный инженер в компании Constanta. Мы с командой занимаемся практиками DevOps, развиваем процессы ci/cd и мониторинга.
Представьте, что у вас есть 10 серверов и 20 микросервисов на них, а релизы проходят каждую неделю. Вы уже мониторите жизнеспособность сервисов и докера с помощью zabbix или prometheus, а с помощью ELK или grailog собираете логи. Кажется, что всё хорошо, но в таком потоке релизов, хотфиксов и строчек кода нужно быстро ориентироваться и вылавливать ошибки внутри приложения, которые не влияют на жизнеспособность сервиса, но мешают его правильной работе.
Стоп! Есть же Sentry, скажете вы. И будете правы. Он удобен, хорошо описан, есть документация, комьюнити и поддержка. Однако, есть одно "но".
Облачный мы не рассматривали сразу по нескольким причинам:
он платный;
один непроверенный пятничный релиз может потратить все ивенты за выходные;
в случае блокировки с одной или с другой стороны можно потерять все.
Если рассматривать Sentry self-hosted с точки зрения инженера по DevOps, становится понятно, что для него требуется много ресурсов, вместе разворачивается много сущностей, что значительно усложняет поддержку и требует постоянный мониторинг потребления ресурсов и отслеживание живости компонентов. Соответственно, вероятность отказа в самый ненужный момент возрастает.
Посмотрите скриншоты (под спойлером)
По этим причинам во время поиска аналогов облачного Sentry наш выбор пал на Glitchtip.
Что такое GlitchTip?
GlitchTip — это приложение для мониторинга ошибок, поддерживающее api Sentry. Оно предоставляет возможность отслеживать ошибки, производительность, доступность эндпоинта, а также интегрироваться с различными сервисами (например, авторизацию через gitlab или keycloak, отправку уведомлений в slack).
Так выглядит GlitchTip
Сравнение Sentry c GlitchTip
Может быть, вы могли подумать, что GlitchTip — это полный клон Sentry, но это не так. В нем отсутствуют некоторые фичи Sentry, например, дашборды. В таблице ниже я сравнил основные фичи и интеграции.
Feature | Sentry | Gitchtip |
RAM (по документации) | 8GB | 1GB |
Free Disk Space (по документации) | 20GB | 30GB |
Error Tracking | + | + |
Uptime Monitoring | + | + |
Performance | + | + |
Dashboards | + | - |
Discover Trends | + | - |
В этой таблице привел в пример только самые популярные сервисы.
Integrations | Sentry | Gitchtip |
Slack | + | - |
Gitlab | + | + |
Githab | + | Только авторизация |
Jira | + | - |
Webhooks | + | + |
Благодаря поддержке api с точки зрения взаимодействия с приложением Gitchtip ничем не отличается от Sentry: при регистрации проекта вы получаете DSN (Data Source Name), который прописываете в настройках подключения своего приложения.
Пример под спойлером.
Далее для перехвата ошибок:
добавить sentry-sdk==1.6.0 в зависимости проекта;
добавить в докерфайл приложения переменную окружения с DSN, чтобы не показывать ее в коде:
ENV SENTRY_DSN='https://4b6a3d54e8904e5698ffbab8f5f55fc4@<URL GlitchTip>/1'
импортировать в проект нужные библиотеки, например:
import sentry_sdk from sentry_sdk import capture_exception
добавить инициализацию:
sentry_sdk.init(dsn=os.getenv('SENTRY_DSN'))
подставить перехватчик к ошибке:
def get_json(url): try: url = url get_metrics_api = urlopen(url).read() get_metrics_api_json = json.loads(get_metrics_api) except HTTPError as e: capture_exception(e) if e.code == 403: get_metrics_api_json = {'Code': 403}
После этого в проекте можно посмотреть, что ошибка появилась
C точки зрения администрирования у GlitchTip поднимается всего 4 контейнера (web, worker, redis и postrgresql), также для работы вам понадобится nginx. Помимо этого у вас есть стандандартная джанго-админка, где вы можете завести организацию и добавлять в нее пользователей. Еще вам может понадобится smtp (если вы хотите отправлять email о событиях), но нам данный функционал показался излишним и мы его не настраивали.
Установка и настройка
Установка и настройка описаны в документации, поэтому в статье мы не будем затрагивать этот процесс; если вкратце, то нужно забрать себе docker-compose.yml, поправить его под свои нужды и запустить на сервере.
Хотелось бы только отметить некоторые переменные для docker-compose, без которых не обойтись (спрятаны под спойлер).
Переменные:
SECRET_KEY – поменять на любую рандомную строку
PORT – если вы хотите переопределить порт, на котором поднимается GlitchTip
SOCIALACCOUNT_PROVIDERS_gitlab_GITLAB_URL – в переменную передается URL Gitlab для интеграции
GLITCHTIP_DOMAIN – домен, по которому будет доступен GlitchTip в браузере
CELERY_WORKER_CONCURRENCY - количество одновременных рабочих celery. По умолчанию количество ядер процессора.
GLITCHTIP_MAX_EVENT_LIFE_DAYS – количество дней, в течение которых хранятся события (по умолчанию 90).
Для автоматизированного заведения пользователей можно использовать Social Accounts. Мы выбрали для себя Gitlab. Подробнее можно посмотреть в документации. Под спойлером показано, как это выглядит в GlitchTip и Gitlab.
Настройка авторизации через Gitlab
Где и кому может пригодиться
GlitchTip легко поднять как локально для какого-нибудь пет-проекта, так и в компании для отслеживания ошибок с продуктовой среды. Он не требует больших усилий для установки и поддержки, поэтому его использование может пригодиться при разработке любого проекта любой сложности и на любом этапе. Стоит отметить, что за 5 месяцев использования GlitchTip ни разу нас не подвел и с ним не было никаких проблем.
Резюмируя, хочется отметить, что GlitchTip — это Sentry на минималках. Вы смело можете рассматривать его в качестве основного инструмента, если вам дороги ваше время и ресурсы и при этом не требуется полный функционал Sentry.
Если же вам крайне важно интегрироваться с такими сервисами, как Github, Jira, Bitbacked и другими, вы активно пользуетесь дашбордами или другими фичами, которых нет в GlitchTip, то лучше выбрать Sentry.
На этом у меня все, надеюсь, моя статья помогла принять решение в этом нелегком выборе :) Спасибо за внимание.
