Пара минут —
и продукт как на ладони.

Пока ваш проект только-только принимает первых пользователей, обычно не до полноценного мониторинга. В IT принято считать, что «сделать нормально» — это поднять Prometheus, экспортеры, service discovery, Grafana и разобраться, как работать с PromQL. Много всего, даже сейчас, когда под рукой есть ИИ-агенты.

Поэтому обычно вы смотрите в логи и в графики, которые показывает хостинг. А потом что-то ломается, и хорошо ещё, если вы узнаёте об этом раньше пользователей. С Простометрикой узнаёте: алерт приходит в телеграм.

Приложение само отправляет метрики, поэтому не нужно поднимать эндпоинты для скрейпинга, настраивать service discovery и открывать порты наружу. Вызов ничего не блокирует: событие ложится в буфер в памяти, так что даже в горячем цикле он почти ничего не стоит.

prostometrics.Init("billing", cfg)

prostometrics.Count("signups", 1)
prostometrics.Value("request.duration_ms", elapsedMs)
prostometrics.CountUnique(user.ID, "users.dau")

init("billing", { apiKey: process.env.PROSTOMETRICS_API_KEY });

count("signups", 1);
value("request.duration_ms", elapsedMs);
countUnique(userId, "users.dau");

prostometrics.init("billing")

prostometrics.count("signups", 1)
prostometrics.value("request.duration_ms", elapsed_ms)
prostometrics.count_unique(user.id, "users.dau")

init({ publicKey: "42_pk_..." });

count("web.checkout.step", 1, { step: "payment" });
value("web.api.duration_ms", elapsedMs);
unique("web.users.dau", user.id);

Для ИИ-агентов у нас есть отдельная инструкция. Дайте своему агенту строчку ниже, и он всё сделает сам.

Код для метрик самой машины писать не нужно: их соберёт готовый сервис.

Порог задаётся мышкой, без YAML. Когда метрика его перейдёт, телеграм-бот пришлёт её и объяснит, почему сработал алерт 🤌🏻.

• Push-модель — и с сервера, и из браузера

  Метрики отправляет само приложение, с сервера или из браузера. Браузерный клиент весит меньше 5 КБ и обходится без зависимостей

• Автоматические дашборды

  Метрику не нужно объявлять заранее — она появляется в интерфейсе с первым событием

• Фронтенд и бэкенд на одном графике

  Время ответа в браузере и время обработки на сервере лежат рядом, и видно, где теряются секунды

• p50 + p95 + p99

  Значения отправляются один раз, а функцию агрегации вы выбираете, когда смотрите на график

• Уникальные значения

  DAU и MAU, в том числе прямо из браузера. Храним только хеш идентификатора

• Топ статей, товаров и страниц — чего угодно

  Что открывали чаще всего, за любой период

• Алерты — это просто

  Почти в один клик

Если узнали себя хотя бы в одной — дальше можно не читать, просто попробуйте.

• Телеграм-боты и небольшие сервисы

  «Бот работает. Сколько людей вчера дошли до оплаты — не знаю, надо лезть в логи.»

  Веб-аналитика тут не работает, Prometheus — из пушки по воробьям. Счётчик на каждый хендлер и алерт в тот же телеграм, где живёт бот.

• Соло-основатели с живым продуктом

  «Я вчера выкатил фичу и понятия не имею, пользуется ей кто-нибудь или нет.»

  Вам нужен ответ на один вопрос, и для него хватит трёх вызовов в коде фичи: завтра на дашборде будет видно, сколько людей до неё дошло.

• Команды на 2–10 человек без девопса

  «Нам сказали поднять Prometheus и Grafana. Это неделя работы, которую никто не хочет делать.»

  Несколько сервисов на паре машин. Ставить, обновлять и чинить нечего: приложение отправляет метрики само, дашборды собираются без вас.

• Бэкендеры, которым нужны продуктовые метрики

  «Prometheus у нас есть. Но „сколько людей дошли до третьего шага чекаута“ я в нём моделировать не хочу.»

  И не надо. Инфраструктурные метрики пусть остаются в Prometheus, а продуктовые можно держать у нас.

• Те, кто устал от сложных систем мониторинга

  «Мне нужны три графика, а не платформа, которую надо изучать неделю.»

  Никакого query language, никаких экспортеров и правил в YAML. Метрика появляется в интерфейсе с первым событием и сразу попадает на дашборд.

• Те, кто пишет код вместе с агентом

  «Если ставится одной строкой в Claude Code — поставлю сейчас. Если надо читать доку — потом.»

  Одной строкой и ставится. Инструкция для агентов лежит открыто на /llms.txt — её же можно вставить руками, если ваш инструмент не ходит в интернет.

Мы намеренно делаем узкий инструмент. Ниже — сравнение с тремя вариантами, из которых обычно выбирают.

• Нужно ли что-то ставить на сервер?

  Для метрик приложения — нет, достаточно добавить в проект библиотеку: она отправляет метрики сама, без сайдкаров и без открытых наружу портов. Метрики самой машины — CPU, память, диски, сеть — собирает отдельный агент, который ставится одной командой. Он тоже только отправляет наружу, и ставить его не обязательно.

• Нужно ли объявлять метрики заранее?

  Нет. Метрика появляется в интерфейсе с первым событием и сразу попадает на дашборд — ничего не описывать в конфиге и не перезапускать.

• Как разделить локальную разработку и продакшен?

  Через workload — имя сервиса, которое вы передаёте при инициализации. Назовите сервис billing на продакшене и billing-dev локально, и у вас будут два отдельных набора метрик и дашбордов.

• Что будет при высокой кардинальности?

  Количество уникальных комбинаций лейблов у метрики ограничено, чтобы одна опечатка в коде не съела память. Идентификаторы пользователей и заказов в лейблы класть не нужно — для вопроса «сколько разных пользователей» есть отдельный тип метрики, unique. А для вопроса «что открывали чаще всего» — ещё один, top: элементы в нём не лейблы, и их может быть сколько угодно.

• Что происходит с идентификаторами пользователей?

  Уникальные значения считаются вероятностно: идентификатор хешируется, а в исходном виде не сохраняется. Это работает и на сервере, и прямо из браузера.

• Какие языки поддерживаются?

  Go, Node.js, Python и браузерный фронтенд. Браузерный клиент весит меньше 5 КБ и не тянет зависимостей.