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

Пока ваш проект только-только принимает первых пользователей, обычно не до полноценного observability инструментария. В 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);

Для вашего AI агента у нас лежит отдельная инструкция: дайте ему эту короткую инструкцию и он всё сделает за вас.

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

В интуитивно понятном интерфейсе настройте пороги срабатывания. Телеграм-бот пришлёт метрику и пояснение, почему сработал алерт 🤌🏻.

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

  Приложение само отправляет метрики: без service discovery, pull-эндпоинтов и открытых портов. Браузерный клиент весит меньше 5 КБ и не тянет зависимостей

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

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

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

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

• p50 + p95 + p99

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

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

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

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

  Топ сущностей за любой период

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  И не надо — мы работаем рядом, а не вместо. Инфраструктурные метрики остаются там, где были, продуктовые живут здесь.

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

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

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

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

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

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

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

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

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

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

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

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

  Через workload — стабильное имя сервиса, которое вы передаёте при инициализации. Разные значения дают разные наборы метрик и разные дашборды.

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

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

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

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

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

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