📈 Мониторинг, логирование и observability

Короткий ответ При нескольких серверах/подах логи физически разбросаны по разным машинам и теряются при перезапуске или пересоздании контейнера; централизованная агрегация (например, стек ELK/EFK или Loki) собирает логи в одно место, где их можно искать, фильтровать и коррелировать между сервисами без ручного обхода каждого узла. Как это работает подробнее на каждом узле или рядом с каждым приложением работает агент сбора логов (Filebeat, Fluent Bit, Promtail), который читает файлы логов или stdout контейнера, добавляет метаданные (имя пода, namespace, контейнер) и отправляет их в центральное хранилище (Elasticsearch или Loki), откуда их можно искать через Kibana или Grafana. Пример кода Что использовать на практике Практика. в Kubernetes логи контейнера по умолчанию хранятся на узле и пропадают при удалении пода — особенно важно централизовать сбор логов до того, как понадобится разобрать инцидент с уже перезапущенным подом. Централизация также даёт единый поиск по всем инстансам сервиса сразу, а не по одном

Читать полностьюcentralized-logging

Короткий ответ OpenTelemetry SDK инструментирует код (автоматически через auto-instrumentation для популярных фреймворков или вручную через API), создаёт спаны и передаёт контекст трейса (trace_id, span_id) между сервисами через стандартный HTTP-заголовок traceparent (W3C Trace Context); собранные спаны экспортируются в OpenTelemetry Collector, который пересылает их в backend (Jaeger, Tempo, Zipkin). Как это работает подробнее при входящем запросе SDK либо создаёт новый trace_id (если заголовка traceparent нет), либо продолжает существующий трейс (если заголовок есть), создавая для текущей операции span с родителем из заголовка. При исходящем HTTP/gRPC-вызове SDK автоматически прокидывает тот же traceparent в заголовки следующего запроса, обеспечивая сквозную связность без ручной передачи ID разработчиком. Пример кода Что использовать на практике Практика. для большинства популярных веб-фреймворков (Express, Spring, Django, Gin) существуют готовые auto-instrumentation библиотеки OpenTelemetry, которые оборачи

Читать полностьюdistributed-tracing

Короткий ответ Простейший PromQL-запрос — это просто имя метрики, например http_requests_total, которое вернёт все текущие временные ряды с этим именем; чтобы выбрать конкретный ряд, к имени добавляют фильтр по labels в фигурных скобках, например http_requests_total{job="api", status="500"}. Как это работает подробнее каждая метрика в Prometheus — это набор временных рядов, различающихся комбинацией labels (пар ключ-значение). Запрос без фигурных скобок возвращает все ряды с данным именем; оператор = внутри {} фильтрует по точному совпадению значения label, != — по несовпадению, =~ и !~ — по регулярному выражению. Пример кода Что использовать на практике Практика. при построении дашборда или алерта почти всегда нужно сузить выборку до конкретного сервиса/окружения, иначе график смешает данные разных инстансов. Полезно сначала посмотреть доступные labels метрики через вкладку "Metrics explorer" в Grafana или curl к /api/v1/series, а затем писать точный фильтр. Практика. Выполнение второго запроса в Prometheus

Читать полностьюmonitoring

Короткий ответ Prometheus хранит временные ряды метрик и умеет их агрегировать через PromQL; Grafana — это инструмент визуализации, который сам метрики не хранит, а подключается к Prometheus (и другим источникам: Loki, Elasticsearch, базам данных) как к data source и строит дашборды из результатов запросов. Как это работает подробнее в Grafana создаётся "Data source" с адресом Prometheus-сервера; дальше каждая панель дашборда содержит PromQL-запрос, который Grafana отправляет в Prometheus по HTTP при каждом обновлении экрана и отображает результат как график, число, таблицу и т.д. Пример кода Что использовать на практике Практика. один дашборд Grafana может одновременно показывать панели из разных источников — например, метрики из Prometheus и логи из Loki на одном экране, что удобно для корреляции во время инцидента. Grafana также поддерживает Alerting поверх тех же запросов, но управление алертами на основе Prometheus обычно удобнее вести через правила самого Prometheus и Alertmanager. Практика. После добав

Читать полностьюgrafana

Короткий ответ Counter — монотонно растущий счётчик (например, число запросов), gauge — значение, которое может расти и падать (например, текущая память), histogram — распределение значений по заранее заданным бакетам (например, latency), summary — похож на histogram, но считает квантили на стороне клиента, а не на сервере. Как это работает подробнее counter увеличивается только вверх и может сбрасываться в 0 при перезапуске процесса — поэтому для него используют функции rate()/increase(), а не читают "сырое" значение напрямую. Gauge — это просто текущее число без накопления. Histogram хранит несколько counter'ов-бакетов (le="0.1", le="0.5" и т.д.) плюс _sum и _count, из которых на сервере можно посчитать квантиль через histogram_quantile(). Summary считает квантили внутри клиентской библиотеки и отдаёт уже готовые значения, но их нельзя агрегировать между инстансами. Пример кода Что использовать на практике Практика. для latency в production почти всегда выбирают histogram, а не summary, потому что histogram

Читать полностьюmetrics

Короткий ответ Метрики (агрегированные числовые ряды во времени), логи (дискретные события с контекстом) и трассировки (путь запроса через систему) — три взаимодополняющих типа сигналов: метрики показывают "что происходит в целом", логи — "что именно случилось", трассировка — "где по времени ушёл запрос". Как это работает подробнее метрика — число с меткой времени и набором labels (например, http_requests_total{method="GET"}), хранится компактно и агрегируется; лог — текстовая или структурированная запись конкретного события с деталями (ошибка, запрос, stack trace); трейс — дерево спанов, показывающее, как один запрос прошёл через несколько сервисов и сколько заняла каждая часть. Пример кода Что использовать на практике Практика. метрики используют для алертинга и дашбордов, так как их дёшево хранить и быстро агрегировать; логи — для детального разбора конкретного инцидента; трассировку — чтобы найти, какой сервис в цепочке вызовов стал причиной задержки. Сигналы дополняют друг друга: метрика говорит "latency

Читать полностьюdistributed-tracing

Короткий ответ SLI (Service Level Indicator) — измеримый показатель качества (например, доля успешных запросов); SLO (Service Level Objective) — внутренняя цель по этому показателю (например, "99.9% запросов успешны за 30 дней"); SLA (Service Level Agreement) — формальное соглашение с внешней стороной, обычно включающее последствия (компенсацию) за невыполнение. Как это работает подробнее сначала выбирают SLI — конкретную метрику, которая отражает опыт пользователя (latency, доля ошибок, доступность). Затем на основе SLI формулируют SLO — целевой порог, который команда обязуется поддерживать внутри себя. SLA обычно шире и формальнее: это договор с клиентом, часто с санкциями (возврат денег, кредиты) при невыполнении, и SLA-порог обычно мягче внутреннего SLO, чтобы оставался запас. Пример кода Что использовать на практике Практика. команды используют SLO для принятия решений — например, если error budget (допустимый остаток "неудачи" по SLO) истрачен, замораживают рискованные релизы и фокусируются на надёжност

Читать полностьюmonitoring

Короткий ответ Распределённая трассировка — это способ отследить путь одного запроса через множество сервисов, записывая для каждого шага отдельный "спан" (span) с временем начала/конца и привязкой к общему trace_id; это позволяет увидеть, через какие сервисы прошёл запрос и сколько заняла каждая часть. Как это работает подробнее когда запрос входит в систему, ему присваивается уникальный trace_id; при каждом вызове между сервисами этот идентификатор передаётся дальше (через HTTP-заголовки или метаданные gRPC), и каждый сервис создаёт свой span с временем начала/окончания операции, родительским span_id и дополнительными атрибутами. Собранные спаны складываются в дерево — трейс, который можно визуализировать как временную диаграмму (например, в Jaeger, Tempo или Zipkin). Пример кода Что использовать на практике Практика. трассировка особенно полезна, когда нужно понять, где именно в цепочке из 5–10 сервисов "потерялось" время при обработке одного медленного запроса — без трейса пришлось бы вручную сопоставлять

Читать полностьюdistributed-tracing

Короткий ответ Alertmanager — отдельный компонент, который принимает уже сработавшие алерты от одного или нескольких серверов Prometheus и занимается их дальнейшей судьбой: группировкой, подавлением дублей, задержкой (inhibition), маршрутизацией в нужный канал (Slack, email, PagerDuty) и управлением периодами "тишины" (silences). Как это работает подробнее сам Prometheus только вычисляет alerting rules (PromQL-условия) и, когда условие истинно дольше заданного for, отправляет алерт по HTTP в Alertmanager. Дальше Alertmanager группирует похожие алерты в одно уведомление, подавляет повторные отправки на период repeat_interval и решает, куда маршрутизировать алерт согласно дереву route. Пример кода Что использовать на практике Практика. разделение ответственности позволяет нескольким инстансам Prometheus отправлять алерты в один общий Alertmanager (или кластер из нескольких для отказоустойчивости), а также централизованно настраивать "тишину" на время планового обслуживания без изменения правил в самом Prometheu

Читать полностьюalertmanager