Рекомендации по анализу метрик¶

Этот раздел предназначен для системных администраторов, которые отвечают за стабильную работу кластеров и компонентов TCF. Здесь собраны рекомендации по интерпретации метрик, собираемых с кластеров, и действиям в случае отклонений от нормы. Рекомендации помогут быстрее реагировать на инциденты, а также использовать метрики как инструмент для проактивного мониторинга, оценки производительности и планирования ресурсов.

Note

Общие рекомендации по анализу стандартных метрик Tarantool описаны в документации TDB.

Метрики TCF-worker/TCF-coordinator¶

Эти метрики помогают выявлять проблемы с задержками репликации, некорректным состоянием кластеров, а также общим здоровьем технологических ролей TCF-worker и TCF-coordinator.

Метрика	Описание возможной проблемы	Решение
`tcf_is_active = 0`	Кластер работает в пассивном режиме, когда должен быть активен	Убедитесь, что кластер действительно должен быть активным. Проверьте конфигурацию кластеров. При необходимости вручную переключите нужный кластер в активное состояние. Начальное состояние кластера при запуске указано в конфигурации опции `initial_status`
`tcf_source_vclock_signature`	Задержка в репликации. Значение метрики отстает от `tcf_gateway_sent_vclock_signature`	Проверьте состояние кластеров, возможны проблемы с мастер-узлами. Посмотрите журналы Gateway и Destination. Отслеживайте динамику: растет ли отставание со временем. Если задержка большая или продолжает увеличиваться, проверьте состояние сети и доступность кластеров. «Большим» отставанием можно считать значение от ~1000, но порог может зависеть от нагрузки и частоты изменений
`tcf_http_request_latency_count`	Ошибки при работе HTTP-интерфейсов компонентов	Найдите путь (`path`) и компонент (`alias`), где возникают ошибки `4xx/5xx`. При ошибках `4xx` проверьте клиента и корректность запросов. При ошибках `5xx` просмотрите записи журнала компонента и его текущее состояние
`tcf_src_vclock_signature`	Значение метрики не растет при ожидании активности	Возможна перегрузка, зависание или отсутствие клиентских изменений от исходного кластера
`tcf_dst_vclock_signature`	Значение примененной сигнатуры `vclock` отстает на целевом кластере от `tcf_src_vclock_signature`	Если значение метрики отстает от `tcf_src_vclock_signature`, проверьте метрику `tcf_destination_push_errors_total`, состояние сети и доступность Destination. Используйте для оценки задержек между кластерами

Метрики Gateway/Destination¶

Метрики отслеживают общее состояние репликации между кластерами: от чтения данных на стороне Gateway до доставки и обработки их в Destination.

Метрика	Описание возможной проблемы	Решение
`tcf_gateway_sent_errors_total`	Ошибки при отправке данных на Destination. Значение метрики растет	Проверьте записи журнала типа `ERROR` и `WARN` Убедитесь, что Destination доступен Перезапустите Gateway
`tcf_gateway_read_errors_total`	Ошибки при чтении из исходного кластера. Значение метрики растет	Проверьте записи журнала Gateway. Убедитесь, что исходный кластер доступен
`tcf_gateway_http_responses_total`	Ошибки HTTP API Gateway: метрика показывает рост ошибок `4xx`, `5xx`	Убедитесь, что используемые методы и пути API корректны. При появлении ошибок `5xx` проверьте внутренние ошибки и записи журнала Gateway
`tcf_destination_push_total`	Количество событий, отправленных из Destination	Используйте в паре с `tcf_destination_recv_total` для выявления разницы между значениями метрик
`tcf_destination_recv_total`	Количество событий, полученных от Gateway	Сравните с `tcf_destination_push_total` для выявления задержек
`tcf_destination_recv_vclock_signature`	Текущее состояние репликации, полученное от Gateway	Следите за ростом. Если не растет – проверьте записи журнала, `tcf_destination_recv_errors`, соединение
`tcf_destination_sent_vclock_signature`	Состояние репликации, отправленное в целевой кластер	Следите за ростом. Если роста нет – возможны ошибки `push` или проблемы с сетью
`tcf_destination_recv_errors_total`	Ошибки при получении данных	Перезапустите Gateway или проверьте соединение
`tcf_destination_push_errors_total`	Ошибки при отправке данных на целевой кластер	Проверьте записи журнала Destination. Убедитесь, что целевой кластер доступен
`tcf_destination_http_responses_total`	Ошибки API Destination: метрика показывает рост `4xx`, `5xx` > 5%	Проверьте методы и корректность запросов. При `5xx` – смотрите ошибки в записях журнала Destination
`tcf_app_info`	Метрика отсутствует в Grafana/Prometheus или отображается не у всех компонентов	Убедитесь, что метрика есть у всех компонентов (Gateway, Destination). Проверьте лейблы `app_name`, `app_version`, `alias`. Если метрика не отображается – проверьте scrape job Prometheus и конфигурацию компонента

Системные метрики (Go runtime metrics)¶

Системные метрики Go runtime позволяют мониторить внутреннее состояние и производительность приложений, написанных на Go – в данном случае компонентов Gateway и Destination. Тип: gauge.

Метрика	Описание возможной проблемы	Решение
`go_goroutines`	Значение метрики растет даже при стабильной нагрузке	Следите за ростом значения. Скачкообразный или постоянный рост может сигнализировать об утечках или блокировках. Проверьте нагрузку и проанализируйте записи журнала
`go_threads`	Значение метрики аномально выросло относительно типичных значений кластера	Рост может указывать на проблемы с управлением потоками. Ограничьте число потоков через `max_cpu` для Gateway и `max_cpu` для Destination в конфигурации репликатора или `GOMAXPROCS`
`go_memstats_alloc_bytes`	Память используется все активнее и значение постоянно растет	Следите за ростом – возможна утечка памяти. Проверьте, освобождаются ли объекты (`heap_object`) и как работает `GC`. Проанализируйте записи журнала
`go_memstats_alloc_bytes_total`	Резкий рост значения метрики	Накопительный счетчик, не требует действий, но резкий рост значения – повод обратить внимание на частоту выделения памяти
`go_memstats_sys_bytes`	Приложение удерживает все больше системной памяти, даже после сборки мусора	Следите за значением, рост значения может быть признаком неэффективного использования ресурсов. Используйте профилирование или принудительную сборку `GC`
`go_memstats_heap_objects`	Значение метрики стабильно растет без снижения	Если наблюдается устойчивый рост без снижения: - вручную вызовите сборщик мусора (`GC`) для проверки влияния на метрику; - проанализируйте записи журнала приложения
`go_memstats_mallocs_total`	Значение метрики быстро растет, особенно при низкой активности приложения	Используется для оценки частоты выделения памяти. Проанализируйте записи журнала
`go_memstats_frees_total`	Значение метрики отстает от `mallocs_total`, не увеличивается пропорционально	Должно расти примерно в той же пропорции, что и `mallocs`, иначе возможна утечка памяти. Проанализируйте записи журнала
`go_memstats_lookups_total`	Резкий рост метрики может сопровождаться падением производительности	Не критично. Вспомогательная метрика
`go_memstats_heap_alloc_bytes`	Используемая память в куче растет и не уменьшается после сборки мусора	Если значение увеличивается, возможна утечка памяти. Проанализируйте записи журнала
`go_memstats_heap_sys_bytes`	Рост метрики без снижения после сборки мусора	При росте значения оптимизируйте использование памяти и настройте `GOGC` (уменьшите значение для снижения потребления памяти). Рост метрики без снижения после сборки мусора – повод проверить записи журнала
`go_memstats_heap_inuse_bytes`	Значение метрики высокое и не снижается	Возможно, приложение постоянно держит много данных. Проверьте записи журнала, при необходимости вызовите сборщик мусора вручную и посмотрите, снижается ли метрика
`go_memstats_heap_idle_bytes`	Метрика растет, но `go_memstats_heap_released_bytes` не увеличивается	Высокое значение может указывать на возможность возврата памяти. Перезапустите процесс.
`go_memstats_heap_released_bytes`	Низкое значение метрики при высокой нагрузке	Если значение низкое и память не освобождается, можно вручную инициировать сборщик мусора или изменить параметры сборки мусора
`go_memstats_stack_inuse_bytes`	Память на стеке растет вместе с числом горутин	Рост значения метрики может указывать на большое количество горутин
`go_memstats_stack_sys_bytes`	Метрика растет при масштабировании	Следите за ростом метрики при масштабировании
`go_memstats_mcache_inuse_bytes`	Значение метрики нестабильно, растет при небольшой нагрузке	Не критично, но важно для полной картины
`go_memstats_mcache_sys_bytes`	Память не освобождается после снижения нагрузки	Следите за значением метрики при росте нагрузки
`go_memstats_mspan_inuse_bytes`	Резкий рост при стабильной нагрузке	При росте значения оптимизируйте использование памяти и настройте `GOGC` (уменьшите значение для снижения потребления памяти). Рост метрики без снижения после сборки мусора – повод проверить записи журнала
`go_memstats_mspan_sys_bytes`	Выделенная память не снижается	Следите за значением метрики при росте нагрузки
`go_memstats_buck_hash_sys_bytes`	Значение метрики превышает ожидаемое даже без профилирования	Повышенное значение при включенном профилировании – допустимо
`go_memstats_gc_sys_bytes`	Память на `GC` растет, а частота сборок не меняется	Рост может быть связан с частыми сборками мусора. Проверьте значения `go_gc_duration_seconds` и `next_gc_bytes`
`go_memstats_other_sys_bytes`	Значение метрики резко растет	Если значение метрики резко выросло, это может указывать на утечки памяти. Рекомендуется зафиксировать момент роста и передать информацию команде разработки для анализа
`go_gc_duration_seconds` (0.5)	Время сборки мусора растет, приложение перестает отвечать на запросы	Проверьте нагрузку, частоту выделения памяти и частоту `GC`
`go_gc_duration_seconds` (0.75)	На p75 наблюдаются пики выше 50 мс	Пики выше 50 мс на p75 могут указывать на то, что сборка мусора замедляет работу. Увеличьте интервал между `GC`, снизьте выделение памяти
`go_memstats_next_gc_bytes`	Значение метрики скачет или слишком часто сбрасывается	Проверьте частоту сборок мусора

Version:

Рекомендации по анализу метрик¶

Метрики TCF-worker/TCF-coordinator¶

Метрики Gateway/Destination¶

Системные метрики (Go runtime metrics)¶