Дашборд парсинга: метрики, ошибки, скорость в реальном времени

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Дашборд парсинга: метрики, ошибки, скорость в реальном времени
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1252
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    958
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    949

Отметим: когда ваш парсинг обрабатывает миллионы запросов в день, без дашборда вы слепы. Ошибки копятся, прокси падают, а вы узнаёте об этом через час. Дашборд статистики парсинга решает: видеть здоровье системы в реальном времени, реагировать на сбои за минуты, оптимизировать скорость сбора. Мы разрабатываем такие дашборды под ключ с учётом ваших источников данных и инфраструктуры. Более 5 лет на рынке, 50+ успешных проектов — наш опыт гарантирует стабильность. Оценим ваш проект за 1 день. Закажите консультацию, чтобы обсудить вашу задачу.

Ключевые метрики

Метрика Описание
Success Rate % успешных запросов за период
Requests/min Скорость обхода (requests per minute)
Items/hour Скорость сбора данных
Error Rate % запросов с ошибками 4xx/5xx
Proxy Health % рабочих прокси в пуле
Queue Depth Длина очереди URL для обхода
Avg Response Time Среднее время ответа источника

Решение проблемы падения прокси

Представьте: пул из 200 прокси, 15% из них периодически отваливаются. Без мониторинга вы теряете до 30% пропускной способности. Мы встраиваем в дашборд метрику Proxy Health: если её значение падает ниже 95%, алерт отправляется в Telegram. Аналитика показывает, что среднее время восстановления сокращается с 40 до 8 минут. Дополнительно мы настраиваем автоматическую ротацию прокси: при падении health ниже порога прокси исключается из пула, а его нагрузка перераспределяется на рабочие адреса. Это снижает количество потерянных запросов на 20%. Мы также отслеживаем время ответа и ошибки по каждому прокси, что позволяет точечно заменять проблемные IP. В недавнем проекте для агрегатора электронной коммерции это снизило общий уровень ошибок с 12% до 3.5% за первую неделю. Свяжитесь с нашими инженерами для обсуждения ваших метрик.

Какие метрики критически важны для мониторинга парсинга?

Из набора метрик особое внимание стоит уделить Success Rate и Proxy Health. Success Rate показывает долю успешных ответов — если он падает ниже 90%, значит источник блокирует запросы или прокси перегружены. Proxy Health отслеживает работоспособность каждого прокси: если health падает, система автоматически исключает прокси из ротации. Также важен Avg Response Time — резкий рост часто сигнализирует о проблемах с сетью или перегрузке целевого сервера. Мы рекомендуем настраивать дашборд так, чтобы все три метрики отображались на главном экране.

Почему TimescaleDB подходит для метрик парсинга?

Для временных рядов специализированные инструменты эффективнее стандартного PostgreSQL. TimescaleDB — это расширение PostgreSQL с автоматическим партиционированием по времени. Запросы на недельные или месячные срезы выполняются быстро даже при 10 млн строк. В одном проекте мы хранили 500 млн записей — агрегация занимала менее 2 секунд. Кроме того, TimescaleDB поддерживает сжатие данных, что сокращает объём хранилища в 5–10 раз без потери производительности.

# TimescaleDB (расширение PostgreSQL)
import psycopg2

CREATE TABLE scraper_metrics (
    time          TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    scraper_id    INTEGER,
    requests_ok   INTEGER DEFAULT 0,
    requests_fail INTEGER DEFAULT 0,
    items_scraped INTEGER DEFAULT 0,
    avg_resp_ms   FLOAT,
    proxy_used    TEXT
);

SELECT create_hypertable('scraper_metrics', 'time');
CREATE INDEX ON scraper_metrics (scraper_id, time DESC);

API для дашборда

@app.get('/api/v1/stats/overview')
async def get_overview(scraper_id: int, period: str = '24h'):
    interval = {'1h': '1 hour', '24h': '24 hours', '7d': '7 days'}[period]

    rows = await db.fetch(f'''
        SELECT
            time_bucket('5 minutes', time) AS bucket,
            SUM(requests_ok)   AS ok,
            SUM(requests_fail) AS fail,
            SUM(items_scraped) AS items,
            AVG(avg_resp_ms)   AS avg_ms
        FROM scraper_metrics
        WHERE scraper_id = $1
          AND time > NOW() - INTERVAL '{interval}'
        GROUP BY bucket
        ORDER BY bucket
    ''', scraper_id)

    return {
        'timeline': [dict(r) for r in rows],
        'totals': {
            'requests':    sum(r['ok'] + r['fail'] for r in rows),
            'success_rate': sum(r['ok'] for r in rows) / max(sum(r['ok'] + r['fail'] for r in rows), 1),
            'items':       sum(r['items'] for r in rows),
        }
    }

Визуализация

import { LineChart, Line, XAxis, YAxis, Tooltip, ResponsiveContainer } from 'recharts';

function MetricsChart({ data }: { data: TimelinePoint[] }) {
  return (
    <ResponsiveContainer width="100%" height={300}>
      <LineChart data={data}>
        <XAxis dataKey="bucket" tickFormatter={d => format(new Date(d), 'HH:mm')} />
        <YAxis />
        <Tooltip />
        <Line dataKey="ok"   stroke="#22c55e" name="Успешных" strokeWidth={2} dot={false} />
        <Line dataKey="fail" stroke="#ef4444" name="Ошибок"   strokeWidth={2} dot={false} />
      </LineChart>
    </ResponsiveContainer>
  );
}

Алерты

Пример настройки алерта

Threshold success rate < 80% — automatic notification to Telegram with details: which proxy or source failed. Configured for your scenarios. For example, you can set different thresholds for different sources or add escalation via email for repeated failures.

Сравнение хранилищ метрик

Хранилище Производительность Сложность Подходит для
TimescaleDB Высокая (автопартиционирование) Средняя Временные ряды, до 10 млн строк/день
InfluxDB Очень высокая Выше (отдельный стек) Сверхбольшие объёмы
PostgreSQL Низкая (без расширений) Низкая Малые объёмы

Как мы строим дашборд: процесс работы

  1. Аналитика — изучаем ваши источники данных и требования к метрикам. Определяем критические KPI. Оцениваем объём данных и частоту обновления. Проводим интервью с вашей командой, чтобы выявить узкие места.
  2. Проектирование схемы — выбираем инструменты (TimescaleDB, FastAPI, React). Проектируем структуру таблиц и API-эндпоинтов. Учитываем будущее масштабирование.
  3. Реализация API — пишем бэкенд для сбора и агрегации метрик. Обрабатываем до 10 000 запросов в секунду. Используем асинхронные воркеры для минимизации задержек.
  4. Фронтенд — разрабатываем интерфейс с графиками и алертами. Используем Recharts для интерактивных графиков. Добавляем фильтры по времени и scraper_id.
  5. Тестирование — проверяем на нагрузке до 1000 запросов/сек. Исправляем узкие места. Проводим UAT с вашей командой.
  6. Деплой — разворачиваем на вашем сервере или облаке. Настраиваем мониторинг самого дашборда. Даём инструкции по эксплуатации.

Что входит в работу

  • Документация API в формате OpenAPI
  • Исходный код дашборда (бэкенд и фронтенд)
  • Инструкция по развёртыванию
  • Обучение команды (до 2 часов)
  • Гарантия на код 3 месяца

Сроки

Дашборд с TimescaleDB, REST API и React-визуализацией: 5–8 рабочих дней. Оценим ваш проект за 1 день. Свяжитесь с нами для консультации — предложим архитектуру под вашу нагрузку. Закажите оценку прямо сейчас, чтобы получить индивидуальное предложение. Получите индивидуальную смету за 1 день — отправьте заявку.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

  • GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
  • Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
  • GTM Preview в staging-окружении перед продакшеном
  • Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

  • Все ли рекомендуемые события присутствуют в DebugView
  • Нет ли задвоений (считаем количество purchase на 100 сессий)
  • Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Компонент Описание
Аудит текущих тегов Проверка существующих GTM-тегов, dataLayer, дублей и ошибок
Дизайн событийной схемы Документация: список событий, параметры, триггеры
Настройка GA4 + GTM Создание конфигурации, тегов, Custom definitions
Яндекс.Метрика Установка счётчика, создание целей, настройка Вебвизора
Amplitude (опционально) Настройка клиентского и серверного SDK, когорты
QA и мониторинг Тестирование в Preview Mode, Alerting
Обучение и передача Доступы, инструкция по добавлению новых событий, консоль

Процесс и сроки

  1. Аудит текущих тегов и данных (2 дня)
  2. Дизайн событийной схемы (2 дня)
  3. Разработка Data Layer и настройка тегов (3–5 дней)
  4. QA в Preview Mode и на staging (2 дня)
  5. Деплой и настройка дашбордов (1 день)
Сценарий Срок
Базовая настройка GA4 + GTM 1 неделя
Полный e-commerce tracking + Метрика 2–3 недели
Server-side GTM + Amplitude 3–5 недель

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.