📝 Шпаргалка по Logging, Tracing и Metrics.
Помогает понять, как устроен мониторинг в распределённых системах: что измерять, где искать события и как восстанавливать путь запроса между сервисами.
➡️ Три компонента мониторинга
— Metrics (метрики)
Числовые показатели системы во времени: загрузка CPU и памяти, RPS, задержка, процент ошибок, количество запросов, доступность сервисов. Метрики хорошо подходят для дашбордов, алертов и быстрой оценки состояния системы.
— Logging (логирование)
События, которые происходят внутри приложения или инфраструктуры: ошибки, предупреждения, действия пользователя, сбои интеграций, системные сообщения. Логи помогают разбирать конкретные инциденты и понимать, что произошло внутри сервиса.
— Tracing (трассировка запросов)
Путь одного запроса через несколько сервисов. Особенно полезно в микросервисной архитектуре, где один пользовательский запрос может пройти через API, очередь, базу данных и несколько внутренних сервисов.
➡️ Как это обычно собирается
— Метрики сервисов отправляются в базы данных для мониторинга: Prometheus, InfluxDB, VictoriaMetrics
— Логи собираются с хостов и приложений, затем передаются в хранилище и систему анализа: Logstash, Elasticsearch, Kibana.
— Трейсы собираются через OpenTelemetry: SDK, API, auto instrumentation и OTel Collector.
— Дальше данные можно передавать в разные системы анализа и визуализации: Grafana, DataSet, Lightstep, Honeycomb, Jaeger.
➡️ Где что использовать
➡️ метрики — чтобы быстро увидеть состояние системы;
➡️ логи — чтобы разобрать конкретную ошибку;
➡️ трейсы — чтобы проследить путь запроса между сервисами.
В рабочей системе эти три слоя обычно используются вместе: метрики показывают отклонение, логи дают детали, а трейсы помогают найти участок, где запрос начал тормозить или завершился ошибкой.
#полезное
Помогает понять, как устроен мониторинг в распределённых системах: что измерять, где искать события и как восстанавливать путь запроса между сервисами.
➡️ Три компонента мониторинга
— Metrics (метрики)
Числовые показатели системы во времени: загрузка CPU и памяти, RPS, задержка, процент ошибок, количество запросов, доступность сервисов. Метрики хорошо подходят для дашбордов, алертов и быстрой оценки состояния системы.
— Logging (логирование)
События, которые происходят внутри приложения или инфраструктуры: ошибки, предупреждения, действия пользователя, сбои интеграций, системные сообщения. Логи помогают разбирать конкретные инциденты и понимать, что произошло внутри сервиса.
— Tracing (трассировка запросов)
Путь одного запроса через несколько сервисов. Особенно полезно в микросервисной архитектуре, где один пользовательский запрос может пройти через API, очередь, базу данных и несколько внутренних сервисов.
➡️ Как это обычно собирается
— Метрики сервисов отправляются в базы данных для мониторинга: Prometheus, InfluxDB, VictoriaMetrics
— Логи собираются с хостов и приложений, затем передаются в хранилище и систему анализа: Logstash, Elasticsearch, Kibana.
— Трейсы собираются через OpenTelemetry: SDK, API, auto instrumentation и OTel Collector.
— Дальше данные можно передавать в разные системы анализа и визуализации: Grafana, DataSet, Lightstep, Honeycomb, Jaeger.
➡️ Где что использовать
➡️ метрики — чтобы быстро увидеть состояние системы;
➡️ логи — чтобы разобрать конкретную ошибку;
➡️ трейсы — чтобы проследить путь запроса между сервисами.
В рабочей системе эти три слоя обычно используются вместе: метрики показывают отклонение, логи дают детали, а трейсы помогают найти участок, где запрос начал тормозить или завершился ошибкой.
#полезное