Observability в одном Go-бинарнике: как я собрал self-hosted без Kafka и Redis

[otezvikentiy]

Автор здесь, буду в комментариях ближайшие часы — с радостью отвечу на вопросы по архитектуре. Особенно на такие: почему именно PostgreSQL + ClickHouse, а не одна база; где проходит граница, за которой --mode=all перестаёт справляться и пора разносить процессы; что оказалось самым неприятным при реализации приёма Sentry-протокола.

И встречный вопрос, ради которого во многом и написано: если вы держите self-hosted-observability — какой у вас объём событий в сутки и на чём оно крутится? Мне сейчас не хватает именно этого фидбэка, чтобы понимать, на какие нагрузки целиться дальше.

[otezvikentiy]

Справедливо было бы спросить "а где цифры" - статья без них действительно неполная. Снял с рабочего стенда, привожу как есть, с оговорками.

Потребление в покое. Инстанс поднят 20 часов, --mode=all, три контейнера:

- сам бинарник gotcha: 6.3 МБ RAM, ~0% CPU

- PostgreSQL: 25 МБ, 3.7% CPU

- ClickHouse: 731 МБ, 3.5% CPU

Итого около 760 МБ. Львиную долю занимает ClickHouse - это его обычный базовый аппетит, и под нагрузкой он будет расти. Сам Go-бинарник в покое держится в пределах 6-7 МБ.

Сколько занимают данные. За 14 дней на стенде накопилось (строк / на диске / сжатие):

- спаны трейсов: 108 280 / 3.96 МиБ / 3.7x

- транзакции: 22 620 / 2.22 МиБ / 1.9x

- события (ошибки): 1 578 / 69 КиБ / 14x

- точки метрик: 3 840 / 44 КиБ / 10.6x

- сэмплы профилей: 1 620 / 29 КиБ / 6.9x

В пересчёте на запись: спан - около 38 байт на диске, точка метрики - около 12, событие - около 45. PostgreSQL со всей реляционкой (организации, проекты, пользователи, правила алертов, инциденты) - 10 МБ.

Важная оговорка. Стенд не продакшен: событий всего полторы тысячи, и сжатие 14x на таком маленьком однородном наборе почти наверняка оптимистичное. Цифре по спанам (108 тысяч строк) я доверяю заметно больше. Считайте это порядком величины, а не обещанием.

Чего я не мерил - пропускную способность. Нагрузочного теста не делал, поэтому называть события в секунду не буду. Если интересно - соберу и опубликую отдельно, уже с методикой.

Задокументированные требования, из которых я исхожу: минимум 2 vCPU / 2 ГБ RAM / 20 ГБ SSD, рекомендуемо 4 vCPU / 4 ГБ / 40 ГБ. Диск обязательно SSD — обе базы чувствительны к латентности.

[azk]

https://victoriametrics.com/products/

Почему не подошёл данный стек? Если брать не кластерную версию, как раз 3 бинарника + grafana и модули к ней

[otezvikentiy]

Согласен, в некластерном виде он действительно компактный, по ресурсам тут спорить не с чем.

Разница для меня была не в весе, а в задаче.

Насколько я понимаю их продукты, это прежде всего хранилища телеметрии плюс Grafana как слой визуализации. Мне же нужен был в первую очередь воркфлоу по ошибкам: исключения, сгруппированные в проблемы по сигнатуре, со стектрейсом и дедупликацией, со статусами (unresolved / ignored / resolved), назначением ответственного и историей по каждой проблеме. Это ближе к трекеру задач над потоком исключений, чем к дашборду, и на графане такое собирается плохо.

Второе, и для меня решающее: приём по протоколу Sentry. В проектах уже стояли официальные Sentry SDK, и условие было - не трогать инструментацию вообще. Перенос свёлся к смене DSN в конфиге. Ради этого пункта всё, собственно, и затевалось.

Третье - свой интерфейс из коробки, без отдельного слоя визуализации, который нужно конфигурировать. Это осознанный размен: меньше гибкости в обмен на отсутствие настройки.

Если задача - метрики и логи, ваш вариант её закрывает, и городить своё смысла нет. У меня отправной точкой были ошибки с уже подключённых Sentry SDK - отсюда и другой выбор.