[Документация Yandex Cloud](../../index.md) > [Yandex Data Transfer](../index.md) > [Пошаговые инструкции](index.md) > Мониторинг состояния трансфера

# Мониторинг состояния трансфера

Данные о состоянии трансфера доступны в консоли управления:

* Краткая информация представлена на временной шкале в разделе **Обзор** для выбранного трансфера в сервисе [Data Transfer](https://kz.console.yandex.cloud/link/data-transfer/). В правой верхней части шкалы вы можете выбрать интервал для просмотра — час, день или неделю. Интервал разбит на сегменты. Наведите курсор на сегмент, чтобы узнать сколько байт и строк перенес трансфер за соответствующий период времени или просмотреть сообщения об ошибках.
* Подробная диагностическая информация представлена в виде графиков. Их можно посмотреть на вкладке **Мониторинг** страницы управления трансфером или в сервисе [Yandex Monitoring](../../monitoring/concepts/index.md).

Вы можете [настроить алерты](#monitoring-integration) в сервисе Yandex Monitoring для получения уведомлений о сбоях в работе трансфера. В Yandex Monitoring используются два порога срабатывания алерта: `Warning` и `Alarm`. При превышении заданного порога вы получите оповещения через настроенные [каналы уведомлений](../../monitoring/concepts/alerting.md#notification-channel).

Отслеживать состояние трансферов и получать логи их работы можно и в [мобильном приложении](https://yandex.cloud/ru-kz/mobile-app) Yandex Cloud.


## Ошибки, отображаемые на временной шкале трансфера {#errors-timeline}

Некоторые ошибки, информацию о которых можно увидеть на временной шкале для выбранного трансфера:

  * Трансфер записывает не все прочитанные данные. Количество событий, записанных в приемник, меньше, чем количество прочитанных из источника. Это может говорить о недостаточной пропускной способности приемника.
  * Время переноса данных выросло или слишком велико. Если трансфер обрабатывает данные слишком долго, возможно, дело в росте потока данных из источника или в низкой пропускной способности приемника.
  * Лаг репликации растет. Рост лага может быть вызван ростом количества событий из источника, проблемами в приемнике данных, нехваткой ресурсов или ошибками при работе.
  * Репликация часто перезапускается. Частые перезапуски репликации могут указывать на неполадки с источником или приемником данных, а также на нехватку памяти.

[Подробнее об ошибках, которые отображаются на временной шкале](../troubleshooting/index.md#timeline).

## Мониторинг состояния трансфера {#monitoring}

{% list tabs group=instructions %}

- Консоль управления {#console}

  1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
  1. Перейдите в сервис **Data Transfer**.
  1. На панели слева выберите ![image](../../_assets/console-icons/arrow-right-arrow-left.svg) **Трансферы**.
  1. Нажмите на имя нужного трансфера и выберите вкладку ![image](../../_assets/console-icons/display-pulse.svg) **Мониторинг**.
  1. Чтобы перейти к работе с метриками, дашбордами или алертами в сервисе Yandex Monitoring, нажмите кнопку **Открыть в Monium** на панели сверху.

{% endlist %}

На странице появятся графики:

### Number of source events {#publisher.data.changeitems}
`publisher.data.changeitems`

Число событий на источнике, сгенерированных для переноса (события помимо переносимых данных могут содержать технические операции).

### Number of target events {#sinker.pusher.data.changeitems}
`sinker.pusher.data.changeitems`

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

### Maximum data transfer delay {#sinker.pusher.time.row_max_lag_sec}
`sinker.pusher.time.row_max_lag_sec`

Максимальное отставание данных (в секундах).

### Reads {#publisher.data.bytes}
`publisher.data.bytes`

Объем считанных из источника данных (в байтах).

### Data transfer delay {#sinker.pusher.time.row_lag_sec}
`sinker.pusher.time.row_lag_sec`

Разница между временем появления записей на приемнике и временем их появления на источнике (в секундах). Гистограмма разбита на диапазоны (`bin`). Допустим, в выбранный момент времени на гистограмме представлены два диапазона `bin` 45 и 60, со значением 50% каждый. Это означает, что половина переносимых в этот момент записей имела задержку передачи от 30 до 45 секунд, а половина — от 45 до 60 секунд.

### Source buffer size {#publisher.consumer.log_usage_bytes}
`publisher.consumer.log_usage_bytes`

Объем буфера или журнала опережающей записи (там, где он поддерживается) в источнике (в байтах).

### Rows written to target, by table {#sinker.table.rows}
`sinker.table.rows`

50 таблиц с максимальным количеством записанных в приемник строк.

### Target response time {#sinker.pusher.time.batch_push_distribution_sec}
`sinker.pusher.time.batch_push_distribution_sec`

Полное время записи в приемник батча данных с учетом предварительной обработки (в секундах).

### Rows awaiting transfer, by table {#task.snapshot.remainder.table}
`task.snapshot.remainder.table`

Количество строк, ожидающих переноса.

### Operation status {#task.status}
`task.status`

Тип выполняющейся операции: `1` — задача активна.


## Настройка алертов в Yandex Monitoring {#monitoring-integration}

{% list tabs group=instructions %}

- Консоль управления {#console}

  1. В [консоли управления](https://kz.console.yandex.cloud) выберите каталог с трансфером, для которого нужно настроить алерты.
  1. Перейдите в сервис ![image](../../_assets/console-icons/display-pulse.svg) **Monitoring**.
  1. В блоке **Сервисные дашборды** выберите **Data Transfer**.
  1. На нужном графике нажмите на значок ![options](../../_assets/console-icons/ellipsis.svg) и выберите пункт **Создать алерт**.
  1. Если на графике несколько показателей, выберите запрос данных для формирования метрики и нажмите **Продолжить**. Подробнее о языке запросов в [документации Yandex Monitoring](../../monitoring/concepts/querying.md).
  1. Задайте значения порогов `Alarm` и `Warning` для срабатывания алерта.
  1. Нажмите кнопку **Создать алерт**.

{% endlist %}

## Рекомендованные алерты

### Число событий источника {#source-change-items}

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

Возможные причины срабатывания:

* База-источник недоступна по сети для Data Transfer. Например, из-за отзыва доступов или из-за отказа базы-источника.
* На базе-источнике отсутствуют данные для репликации.

Параметры алерта:

* Метрики:

    ![image](../../_assets/console-icons/chart-line.svg) `<имя_облака> > <имя_каталога>` `service = data-transfer` `name = publisher.data.changeitems`

    ![image](../../_assets/console-icons/function.svg) `derivative()` (в разделе **Преобразование**)

* Настройки алерта:

    * Условие срабатывания — `Меньше или равно`.
    * Alarm — `0`.
    * Warning — `-`.

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

    Дополнительные настройки:

    * **Функция агрегации** — `Максимум`.
    * **Окно вычисления** — `5 минут`. Если в базе-источнике изменения происходят реже одного раза в 5 минут, увеличьте окно вычисления до максимально допустимого интервала между двумя DML-операциями с данными в источнике.

### Число событий приемника {#target-change-items}

Срабатывание алерта означает, что на протяжении окна вычисления в базу-приемник не записывались реплицируемые события Data Transfer.

Возможные причины срабатывания:

* База-источник или база-приемник недоступны по сети для Data Transfer. Например, из-за отзыва доступов или из-за отказа базы-источника или базы-приемника.
* На базе-источнике отсутствуют данные для репликации.
* Данные из базы-источника не могут быть реплицированы в базу-приемник. Например, из-за ограничений целевого типа данных в базе-приемнике.

Параметры алерта:

* Метрики:

    ![image](../../_assets/console-icons/chart-line.svg) `<имя_облака> > <имя_каталога>` `service = data-transfer` `name = sinker.pusher.data.changeitems`
    ![image](../../_assets/console-icons/function.svg) `derivative()` (в разделе **Преобразование**)

* Настройки алерта:

    * Условие срабатывания — `Меньше или равно`.
    * Alarm — `0`.
    * Warning — `-`.

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

    Дополнительные настройки:

    * **Функция агрегации** — `Максимум`.
    * **Окно вычисления** — `5 минут`. Если в базе-источнике изменения происходят реже одного раза в 5 минут, увеличьте окно вычисления до максимально допустимого интервала между двумя DML-операциями с данными в источнике.

### Максимальная задержка передачи данных {#row-max-lag}

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

Возможные причины срабатывания:

* База-приемник недоступна по сети для Data Transfer. Например, из-за отзыва доступов или из-за отказа базы-приемника.
* Нехватка ресурсов для репликации. Например, нагрузка на базу-источник превышает возможности [виртуальной машины](../../glossary/vm.md), на которой запущена репликация Data Transfer.
* Данные из базы-источника не могут быть реплицированы в базу-приемник. Например, из-за ограничений целевого типа данных в базе-приемнике.

Параметры алерта:

* Метрики:

    ![image](../../_assets/console-icons/chart-line.svg) `<имя_облака> > <имя_каталога>` `service = data-transfer` `name = sinker.pusher.time.row_max_lag_sec`

* Настройки алерта:

    * Условие срабатывания — `Больше или равно`.
    *  Alarm — `15`. Если база-приемник медленная, или реплицируются сразу большие блоки данных, задайте максимально возможное значение.
    * Warning — `-`.

    Дополнительные настройки:

    * **Функция агрегации** — `Минимум`.
    * **Окно вычисления** — `1 минута`.

### Чтение {#reading}

Срабатывание алерта означает, что на протяжении окна вычисления из источника не было прочитано ни одного байта данных.

Возможные причины срабатывания:

* База-источник недоступна по сети для Data Transfer. Например, из-за отзыва доступов или из-за отказа базы-источника.
* На базе-источнике отсутствуют данные для репликации.

Параметры алерта:

* Метрики:

    ![image](../../_assets/console-icons/chart-line.svg) `<имя_облака> > <имя_каталога>` `service = data-transfer` `name = publisher.data.bytes`
    ![image](../../_assets/console-icons/function.svg) `derivative()` (в разделе **Преобразование**)

* Настройки алерта:

    * Условие срабатывания — `Равно`.
    * Alarm — `0`.
    * Warning — `-`.

    Дополнительные настройки:

    * **Функция агрегации** — `Максимум`.
    * **Окно вычисления** — `15 минут`. Если в базе-источнике изменения происходят реже одного раза в 15 минут, увеличьте окно вычисления до максимально допустимого интервала между двумя DML-операциями с данными в источнике.

## Особенности работы с алертами {#alert-specifics}

* Чтобы определить причины сбоя трансфера, проверьте все имеющиеся алерты. Информация о том, какие алерты сработали, а какие — нет, позволит определить причину более точно. Например, если алерт [Число событий источника](#source-change-items) сработал, а алерт [Число событий приемника](#target-change-items) не сработал, вероятнее всего проблема не на источнике.