Observability для Full Stack приложений: OpenTelemetry, Prometheus, Grafana и Distributed Tracing

Представим, что вы разрабатываете SaaS-приложение на React, FastAPI и PostgreSQL.

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

Архитектура постепенно усложняется.

Теперь приложение использует:

• React для Frontend;

• FastAPI для Backend;

• PostgreSQL для хранения данных;

• Redis для кеширования;

• Celery для фоновых задач;

• Stripe для оплаты;

• S3 для хранения файлов;

• Nginx в качестве Reverse Proxy;

• Docker для развёртывания.

Однажды пользователи начинают жаловаться, что Dashboard загружается слишком долго.

Вы открываете Backend Logs.

Ошибок нет.

Проверяете PostgreSQL.

База данных работает.

Проверяете Redis.

Он доступен.

Но пользователи по-прежнему ждут по 10 секунд.

Где искать проблему?

В React? В API? В медленном SQL-запросе? Во внешнем сервисе? В очереди задач? Или в перегруженном сервере?

Обычного логирования уже недостаточно.

Нужна Observability веб-приложения — возможность понимать внутреннее состояние системы по данным, которые она предоставляет во время работы.

В этой статье разберём, как организовать мониторинг Full Stack приложения, настроить OpenTelemetry, Prometheus и Grafana, реализовать Distributed Tracing, собирать структурированные логи, отслеживать производительность React и FastAPI и создавать полезные Production Alerts.

Часть 1. Основы Observability

1. Что такое Observability

Observability — способность исследовать состояние системы на основании её внешних сигналов.

В разработке веб-приложений обычно выделяют три основных сигнала:

1. Logs.

2. Metrics.

3. Traces.

Их часто называют Three Pillars of Observability.

Application

|

+------------+------------+

| | |

v v v

Logs Metrics Traces

| | |

+------------+------------+

|

v

Observability

|

v

Problem Diagnosis

Каждый сигнал отвечает на разные вопросы.

2. Logs vs Metrics vs Traces

Logs vs Metrics vs Traces:

Например, пользователь жалуется на медленную загрузку отчёта.

Metrics показывают увеличение P95 Latency.

Traces показывают, что задержка возникает в PostgreSQL.

Logs содержат сведения об ошибке конкретного SQL-запроса.

Вместе эти сигналы позволяют быстрее найти причину.

3. Monitoring vs Observability

Monitoring vs Observability — связанные, но не идентичные понятия.

Monitoring обычно отвечает на заранее определённые вопросы.

Например:

Доступен ли API?

Какова загрузка CPU?

Сколько запросов завершается ошибкой?

Observability помогает исследовать и неожиданные проблемы.

Например:

Почему только у некоторых организаций запросы стали медленными после нового релиза?

Monitoring — важная часть Observability.

Но Observability включает более широкие возможности диагностики.

4. Почему Console Logs недостаточно

Пример:

print("Request started")

Такое сообщение практически не помогает при высокой нагрузке.

Представим, что приложение обрабатывает тысячи запросов одновременно.

В логах появляются записи:

Request started

Request started

Request started

Database query completed

Request failed

Непонятно, какие сообщения относятся к одному запросу.

Поэтому необходимы:

• Structured Logging;

• Request ID;

• Trace ID;

• Timestamp;

• Log Level;

• Service Name;

• Error Context.

5. Что такое Telemetry

Application Telemetry — данные, которые приложение генерирует для анализа своей работы.

Например:

HTTP Request Duration

Database Query Duration

Queue Processing Time

Error Count

Memory Usage

Frontend Page Load Time

Telemetry помогает обнаруживать проблемы, сравнивать релизы и оценивать производительность.

6. Что такое OpenTelemetry

OpenTelemetry — открытый набор стандартов, API, SDK и инструментов для сбора и передачи телеметрии.

Он позволяет инструментировать приложения и экспортировать данные в разные системы наблюдаемости.

OpenTelemetry поддерживает:

• Traces;

• Metrics;

• Logs.

При этом зрелость и возможности конкретных SDK и инструментов могут отличаться.

7. OpenTelemetry vs Prometheus vs Grafana

OpenTelemetry vs Prometheus vs Grafana:

Эти инструменты не обязательно конкурируют друг с другом.

Они часто используются совместно.

Часть 2. Архитектура Observability

8. Как выглядит Observability Stack

Observability Stack Architecture:

React Frontend

|

v

FastAPI API

|

+-------------+-------------+

| | |

v v v

PostgreSQL Redis Celery

| | |

+-------------+-------------+

|

v

OpenTelemetry

|

v

OTel Collector

|

+-------------+-------------+

| | |

v v v

Prometheus Tempo Loki

| | |

+-------------+-------------+

|

v

Grafana

Это концептуальная архитектура.

На практике метрики могут поступать в Prometheus через Scrape Endpoint или совместимый Exporter, а логи — через отдельный агент.

OpenTelemetry Collector не является обязательным компонентом каждой установки, но часто упрощает централизованную обработку Telemetry.

9. Зачем нужен OpenTelemetry Collector

OpenTelemetry Collector — сервис, принимающий, обрабатывающий и экспортирующий телеметрию.

Он может:

• принимать OTLP;

• выполнять Batching;

• фильтровать данные;

• ограничивать объём Telemetry;

• удалять чувствительные атрибуты;

• направлять данные в Backend наблюдаемости.

Пример:

FastAPI

|

v

OTLP

|

v

OpenTelemetry Collector

|

+-- Trace Backend

|

+-- Metrics Backend

|

+-- Log Backend

Так приложение меньше зависит от конкретного поставщика Observability.

10. Что такое OTLP

OpenTelemetry Protocol (OTLP) — протокол передачи телеметрии.

Он поддерживает транспорт через gRPC и HTTP.

Например:

Application

|

v

OTLP Exporter

|

v

Collector

Важно не путать OTLP Endpoint с Prometheus Metrics Endpoint.

Это разные способы передачи данных.

11. Что такое Instrumentation

Application Instrumentation — добавление в приложение механизмов сбора телеметрии.

Существует два основных подхода.

Automatic Instrumentation — библиотека автоматически создаёт Telemetry для поддерживаемых компонентов.

Manual Instrumentation — разработчик самостоятельно создаёт Spans и Metrics для бизнес-операций.

Обычно полезно сочетать оба подхода.

Часть 3. OpenTelemetry в FastAPI

12. Как установить OpenTelemetry для FastAPI

FastAPI OpenTelemetry Integration:

pip install \

opentelemetry-sdk \

opentelemetry-exporter-otlp-proto-http \

opentelemetry-instrumentation-fastapi

При необходимости можно добавить инструментирование SQLAlchemy, HTTP-клиентов и других компонентов.

13. Как настроить Tracer Provider

OpenTelemetry Python TracerProvider:

from opentelemetry import trace

from opentelemetry.sdk.resources import Resource

from opentelemetry.sdk.trace import TracerProvider

from opentelemetry.sdk.trace.export import (

BatchSpanProcessor,

)

from opentelemetry.exporter.otlp.proto.http.trace_exporter import (

OTLPSpanExporter,

)

resource = Resource.create({

"service.name": "saas-api",

"deployment.environment.name": "production",

})

provider = TracerProvider(

resource=resource

)

exporter = OTLPSpanExporter(

endpoint=(

"http://otel-collector:4318/v1/traces"

)

)

provider.add_span_processor(

BatchSpanProcessor(exporter)

)

trace.set_tracer_provider(provider)

Этот пример отправляет Traces через OTLP/HTTP.

В Production следует учитывать TLS, аутентификацию, сетевые ограничения и конфигурацию Collector.

14. Как инструментировать FastAPI

FastAPI Automatic Instrumentation:

from fastapi import FastAPI

from opentelemetry.instrumentation.fastapi import (

FastAPIInstrumentor,

)

app = FastAPI()

FastAPIInstrumentor.instrument_app(app)

Инструментирование создаёт Spans для входящих HTTP-запросов.

Конкретные атрибуты и поведение зависят от версии библиотек и настроек.

15. Как создать Manual Span

OpenTelemetry Manual Span:

from opentelemetry import trace

tracer = trace.get_tracer(__name__)

def generate_report():

with tracer.start_as_current_span(

"generate_report"

):

return calculate_report()

Теперь операция generate_report может отображаться как отдельный Span.

Это помогает видеть не только HTTP-запрос, но и внутренние бизнес-операции.

16. Как добавлять атрибуты Span

OpenTelemetry Span Attributes:

with tracer.start_as_current_span(

"generate_report"

) as span:

span.set_attribute(

"report.type",

"financial"

)

span.set_attribute(

"report.format",

"pdf"

)

result = calculate_report()

Атрибуты помогают фильтровать и анализировать Traces.

Но нельзя без необходимости добавлять:

• Access Tokens;

• Passwords;

• Email Addresses;

• Payment Details;

• содержимое приватных документов.

17. Как записывать исключения

OpenTelemetry Exception Recording:

with tracer.start_as_current_span(

"process_invoice"

) as span:

try:

process_invoice()

except Exception as exc:

span.record_exception(exc)

span.set_status(

trace.Status(

trace.StatusCode.ERROR

)

)

raise

В этом примере используется API Status и StatusCode, доступный через модуль opentelemetry.trace в соответствующих версиях SDK.

Важно не подавлять исключение только ради Telemetry.

Часть 4. Distributed Tracing

18. Что такое Distributed Tracing

Distributed Tracing — отслеживание выполнения одного запроса через несколько компонентов системы.

Например:

React

|

v

API Gateway

|

v

FastAPI

|

+-- PostgreSQL

|

+-- Redis

|

+-- External API

Distributed Trace помогает определить, какой компонент потребовал больше всего времени.

19. Что такое Trace

Trace — набор связанных Spans, представляющих выполнение операции.

Например:

Trace: GET /api/dashboard

HTTP Request 850 ms

|

+-- Authentication 20 ms

|

+-- PostgreSQL Query 600 ms

|

+-- Redis Lookup 10 ms

|

+-- Response Build 100 ms

Значения в примере условные.

Spans могут выполняться параллельно, поэтому их длительности нельзя всегда просто складывать.

20. Что такое Span

Span — отдельная операция внутри Trace.

Span обычно содержит:

• Trace ID;

• Span ID;

• Parent Span ID;

• Start Time;

• End Time;

• Attributes;

• Status;

• Events.

Например:

Trace ID: abc123...

Span: database.query

Duration: 620 ms

Status: OK

21. Что такое Trace Context Propagation

Trace Context Propagation позволяет передавать контекст трассировки между сервисами.

Для HTTP часто используется стандарт W3C Trace Context.

Например:

traceparent: 00-<trace-id>-<span-id>-01

Здесь <trace-id> и <span-id> обозначают значения в установленном формате.

Благодаря передаче контекста запросы между сервисами можно связывать в один Trace.

22. Как инструментировать HTTP Client

OpenTelemetry HTTPX Instrumentation:

pip install opentelemetry-instrumentation-httpx

from opentelemetry.instrumentation.httpx import (

HTTPXClientInstrumentor,

)

HTTPXClientInstrumentor().instrument()

Теперь поддерживаемые запросы HTTPX могут автоматически создавать Spans и передавать Trace Context.

Для других HTTP-клиентов существуют отдельные инструменты.

23. Как инструментировать SQLAlchemy

OpenTelemetry SQLAlchemy Instrumentation:

pip install opentelemetry-instrumentation-sqlalchemy

Пример для синхронного SQLAlchemy Engine:

from opentelemetry.instrumentation.sqlalchemy import (

SQLAlchemyInstrumentor,

)

SQLAlchemyInstrumentor().instrument(

engine=engine

)

Для AsyncEngine необходимо использовать соответствующий синхронный Engine, доступный через async_engine.sync_engine, если это поддерживается используемой версией инструментирования.

При настройке важно не включать сбор чувствительных SQL Parameters.

24. Как диагностировать медленный запрос

Slow Request Distributed Tracing:

GET /api/reports

|

v

Authentication 15 ms

|

v

Load Organization 20 ms

|

v

SQL Query 4,800 ms

|

v

Generate Response 100 ms

Теперь видно, что основной источник задержки — SQL Query.

Следующий шаг:

• изучить Query Plan;

• проверить индексы;

• проверить объём данных;

• оценить Lock Contention;

• проверить Connection Pool.

Distributed Tracing показывает место проблемы, но не всегда автоматически объясняет её первопричину.

Часть 5. Структурированные логи

25. Что такое Structured Logging

Structured Logging — запись логов в структурированном формате.

Часто используется JSON.

Пример:

{

"timestamp": "2026-10-30T10:00:00Z",

"level": "ERROR",

"service": "saas-api",

"message": "Report generation failed",

"request_id": "req_123",

"trace_id": "abc123",

"error_code": "REPORT_TIMEOUT"

}

Такие записи легче искать и фильтровать.

26. Почему JSON Logs удобнее

JSON Logging FastAPI позволяет выполнять поиск по отдельным полям.

Например:

service = saas-api

level = ERROR

error_code = REPORT_TIMEOUT

Это удобнее, чем анализировать произвольные текстовые сообщения.

27. Как настроить JSON Logging в Python

Python Structured Logging можно реализовать через стандартный logging и JSON Formatter.

import json

import logging

class JsonFormatter(logging.Formatter):

def format(self, record):

payload = {

"level": record.levelname,

"logger": record.name,

"message": record.getMessage(),

}

return json.dumps(

payload,

ensure_ascii=False,

)

Для Production нужно дополнительно обрабатывать Timestamp, Exceptions и контекст запроса.

Также можно использовать специализированные библиотеки Structured Logging.

28. Что такое Request ID

Request ID Logging — использование уникального идентификатора HTTP-запроса.

Например:

Request ID: req_456

API Gateway

|

v

FastAPI

|

v

Database

Request ID полезен для поиска записей, относящихся к конкретному запросу.

Но Request ID и Trace ID не всегда одно и то же.

29. Как связать Logs и Traces

Log Trace Correlation:

from opentelemetry import trace

span = trace.get_current_span()

context = span.get_span_context()

if context.is_valid:

trace_id = format(

context.trace_id,

"032x"

)

else:

trace_id = None

Trace ID можно добавлять в структурированные логи.

Тогда из сообщения об ошибке можно перейти к соответствующей трассировке.

30. Что нельзя логировать

Sensitive Data Logging Prevention:

Не следует записывать без необходимости:

• JWT Tokens;

• API Keys;

• Passwords;

• Session Cookies;

• банковские данные;

• содержимое приватных файлов;

• персональные данные;

• полные тела запросов.

Особенно опасно автоматически логировать все HTTP Headers.

Observability не должна становиться источником утечки данных.

Часть 6. Prometheus и метрики

31. Что такое Prometheus

Prometheus Monitoring — система сбора и хранения временных рядов метрик.

Обычно Prometheus периодически опрашивает Metrics Endpoints.

Например:

FastAPI /metrics

|

v

Prometheus

|

v

Grafana

Prometheus также поддерживает различные интеграции и модели получения метрик.

32. Какие типы метрик существуют

Prometheus Metric Types:

Например:

• Counter — число HTTP-запросов;

• Gauge — количество активных задач;

• Histogram — длительность запросов.

33. Как установить Prometheus Client

Prometheus Python Client:

pip install prometheus-client

Библиотека позволяет создавать и экспортировать метрики.

34. Как создать Counter

Prometheus Counter FastAPI:

from prometheus_client import Counter

HTTP_REQUESTS = Counter(

"app_http_requests_total",

"Total HTTP requests",

["method", "route", "status"],

)

Использование:

HTTP_REQUESTS.labels(

method="GET",

route="/api/projects",

status="200",

).inc()

Важно использовать нормализованный Route Template, а не полный URL с динамическими идентификаторами.

35. Как создать Histogram

Prometheus Histogram Latency:

from prometheus_client import Histogram

REQUEST_DURATION = Histogram(

"app_http_request_duration_seconds",

"HTTP request duration",

["route"],

buckets=(

0.01,

0.05,

0.1,

0.25,

0.5,

1,

2.5,

5,

10,

),

)

Пример:

with REQUEST_DURATION.labels(

route="/api/reports"

).time():

generate_report()

Buckets следует выбирать в соответствии с ожидаемыми задержками и целевыми SLO.

36. Как создать Gauge

Prometheus Gauge Example:

from prometheus_client import Gauge

ACTIVE_JOBS = Gauge(

"app_active_jobs",

"Currently running jobs",

)

Использование:

ACTIVE_JOBS.inc()

try:

process_job()

finally:

ACTIVE_JOBS.dec()

Так можно отслеживать количество одновременно выполняющихся задач в рамках соответствующего процесса.

При использовании нескольких Worker Processes необходима корректная стратегия агрегации.

37. Как добавить Metrics Endpoint

FastAPI Prometheus Metrics Endpoint:

from fastapi import Response

from prometheus_client import (

generate_latest,

CONTENT_TYPE_LATEST,

)

@app.get("/metrics")

def metrics():

return Response(

content=generate_latest(),

media_type=CONTENT_TYPE_LATEST,

)

Это базовый пример для одного процесса.

При запуске нескольких Uvicorn/Gunicorn Workers требуется специальная настройка Multiprocess Mode либо отдельная схема экспорта метрик.

Также /metrics следует защищать сетевыми ограничениями или другой подходящей политикой доступа.

38. Как настроить Prometheus Scrape

Prometheus Scrape Configuration:

global:

scrape_interval: 15s

scrape_configs:

- job_name: "fastapi"

static_configs:

- targets:

- "api:8000"

Prometheus будет опрашивать Metrics Endpoint приложения.

В Docker Compose имя api может соответствовать имени сервиса.

Часть 7. PromQL

39. Что такое PromQL

PromQL — язык запросов Prometheus.

Он используется для анализа Time-Series Metrics.

Например:

app_http_requests_total

Возвращает соответствующие временные ряды Counter.

40. Как измерять Requests Per Second

Prometheus Request Rate:

sum(

rate(

app_http_requests_total[5m]

)

)

Это приблизительная средняя скорость запросов за выбранное окно.

41. Как измерять Error Rate

Prometheus HTTP Error Rate:

sum(

rate(

app_http_requests_total{

status=~"5.."

}[5m]

)

)

/

sum(

rate(

app_http_requests_total[5m]

)

)

Результат показывает долю HTTP 5xx среди всех запросов, если метрика охватывает нужный трафик.

Для отображения в процентах результат можно умножить на 100.

Следует учитывать возможное отсутствие запросов и деление на ноль.

42. Как измерять P95 Latency

Prometheus P95 Latency:

histogram_quantile(

0.95,

sum by (le) (

rate(

app_http_request_duration_seconds_bucket[5m]

)

)

)

Запрос рассчитывает приблизительный P95 на основании Histogram Buckets.

Точность зависит от границ Buckets и объёма наблюдений.

43. Что такое RED Method

RED Method Monitoring — подход к мониторингу сервисов через три группы метрик:

• Rate;

• Errors;

• Duration.

Например:

Rate:

Requests per second

Errors:

5xx percentage

Duration:

P95 latency

RED Method особенно полезен для HTTP API.

44. Что такое USE Method

USE Method Monitoring:

• Utilization;

• Saturation;

• Errors.

Подход применяется для анализа ресурсов.

Например:

CPU Utilization

Memory Pressure

Disk Saturation

Network Errors

RED и USE дополняют друг друга.

Часть 8. Grafana

45. Что такое Grafana

Grafana Monitoring Dashboard — инструмент визуализации и анализа данных.

Grafana может подключаться к различным Data Sources.

Например:

Prometheus -> Metrics

Tempo -> Traces

Loki -> Logs

Это позволяет объединять разные сигналы в одном интерфейсе.

46. Какие панели нужны для FastAPI

FastAPI Grafana Dashboard:

Начать лучше с небольшого набора понятных панелей.

47. Почему P95 важнее среднего значения

P95 vs Average Latency:

Представим:

90 requests: 100 ms

10 requests: 5000 ms

Средняя задержка:

[\frac{90\times100+10\times5000}{100}=590\text{ ms}]

Но часть пользователей ждёт 5 секунд.

Среднее значение скрывает эту проблему.

P95 помогает увидеть задержки в хвосте распределения.

При этом P95 не заменяет P99, Error Rate и анализ отдельных пользовательских сценариев.

48. Как связывать Grafana Logs и Traces

Grafana Logs Traces Correlation позволяет переходить между сигналами.

Например:

Grafana Dashboard

|

v

High P95 Latency

|

v

Trace in Tempo

|

v

Slow Database Span

|

v

Related Logs

Для такой связи нужно правильно настроить Trace ID, Labels и Data Source Correlations.

Часть 9. Мониторинг PostgreSQL и Redis

49. Какие метрики PostgreSQL отслеживать

PostgreSQL Monitoring Metrics:

• Active Connections;

• Slow Queries;

• Lock Waits;

• Transaction Rate;

• Deadlocks;

• Cache Hit Ratio;

• Replication Lag;

• Disk Usage;

• Query Duration.

Особенно важно отслеживать задержки запросов и количество подключений.

50. Что такое Slow Query Monitoring

PostgreSQL Slow Query Monitoring помогает находить SQL-запросы, которые требуют слишком много времени.

Для анализа можно использовать:

• pg_stat_statements

  ;

• EXPLAIN ANALYZE

  ;

• PostgreSQL Logs;

• Database Spans.

Но необходимо учитывать накладные расходы диагностических инструментов.

51. Как мониторить Redis

Redis Monitoring Metrics:

• Used Memory;

• Connected Clients;

• Cache Hit Rate;

• Evictions;

• Command Latency;

• Rejected Connections;

• Persistence Status.

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

Но интерпретировать метрики нужно в контексте конфигурации Redis.

Часть 10. Мониторинг Celery

52. Почему HTTP Metrics недостаточно

В Full Stack приложении часть работы выполняется асинхронно.

Например:

POST /api/reports

|

v

Create Celery Task

|

v

Return 202

HTTP-запрос может завершиться быстро.

Но сама задача может выполняться несколько минут.

Поэтому нужен отдельный Celery Task Monitoring.

53. Какие метрики очередей отслеживать

Background Job Monitoring Metrics:

• Queue Length;

• Task Processing Time;

• Task Failure Rate;

• Retry Count;

• Oldest Pending Task Age;

• Worker Availability.

Особенно полезна метрика возраста самой старой ожидающей задачи.

Она показывает, насколько сильно очередь отстаёт от входящей нагрузки.

54. Как связать HTTP Request и Celery Task

Distributed Tracing Celery требует передачи Trace Context через сообщения.

Например:

HTTP Request

|

v

Create Task

|

v

Message Broker

|

v

Celery Worker

|

v

Generate Report

При корректной инструментации можно связать создание задачи с её выполнением.

Для этого важно передавать контекст через Headers сообщения и поддерживать соответствующую Instrumentation.

Часть 11. Frontend Observability

55. Почему Backend Monitoring недостаточно

Frontend Observability React помогает видеть проблемы, которые Backend не замечает.

Например:

• JavaScript Errors;

• медленный рендеринг;

• проблемы загрузки ресурсов;

• ошибки браузерной сети;

• неудачные пользовательские действия;

• задержки взаимодействия.

Backend может отвечать за 100 мс, но пользователь всё равно видит медленный интерфейс.

56. Что такое Real User Monitoring

Real User Monitoring (RUM) — сбор показателей работы приложения в реальных браузерах пользователей.

Например:

User Browser

|

v

Performance Measurements

|

v

Telemetry Endpoint

|

v

Analytics / Observability

RUM позволяет анализировать производительность по устройствам, браузерам и другим безопасным измерениям.

57. Что такое Core Web Vitals

Core Web Vitals Monitoring включает ключевые метрики пользовательского опыта.

Основные показатели:

• LCP — Largest Contentful Paint;

• INP — Interaction to Next Paint;

• CLS — Cumulative Layout Shift.

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

58. Как измерять Web Vitals в React

React Web Vitals Monitoring:

npm install web-vitals

import {

onCLS,

onINP,

onLCP,

} from "web-vitals";

function reportMetric(metric: unknown) {

console.log(metric);

}

onCLS(reportMetric);

onINP(reportMetric);

onLCP(reportMetric);

В Production вместо console.log можно отправлять данные в Telemetry Backend.

При этом нужно учитывать Sampling, Privacy и ограничения браузера.

59. Как отслеживать Frontend Errors

React Error Monitoring можно реализовать через Error Boundaries и обработчики ошибок.

Но Error Boundary не перехватывает абсолютно все ошибки JavaScript.

Например, ошибки асинхронных операций и некоторых обработчиков требуют отдельной обработки.

Поэтому Frontend Error Monitoring должен сочетать несколько механизмов.

60. Как связывать Frontend и Backend Traces

Frontend Backend Distributed Tracing:

React User Action

|

v

Frontend Span

|

v

HTTP Request

|

v

FastAPI Span

|

v

PostgreSQL Span

Для передачи Trace Context между браузером и Backend необходимо правильно настроить CORS и разрешённые Headers.

Также следует учитывать, что браузерные Traces могут содержать чувствительную информацию.

Часть 12. SLI, SLO и SLA

61. Что такое SLI

Service Level Indicator (SLI) — измеримый показатель качества сервиса.

Например:

Successful Requests / Total Requests

Или:

Requests completed under 500 ms

SLI должен отражать реальный пользовательский опыт.

62. Что такое SLO

Service Level Objective (SLO) — целевое значение SLI за определённый период.

Например:

99,9% запросов API должны завершаться успешно за 30 дней.

Или:

95% запросов к Dashboard должны выполняться быстрее 500 мс.

Это примеры, а не универсальные требования.

63. Что такое SLA

Service Level Agreement (SLA) — соглашение об уровне сервиса.

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

SLO — внутренняя или публичная цель качества.

SLA — договорное соглашение.

Эти понятия не следует смешивать.

64. Что такое Error Budget

Error Budget SRE — допустимый объём нарушения SLO.

Если целевая доступность составляет 99,9%, то Error Budget равен 0,1% за выбранный период.

Для 30 дней это приблизительно:

[30\times24\times60\times0.001=43.2\text{ минуты}]

Но такое представление через минуты подходит для модели доступности во времени.

Если SLI определяется долей успешных запросов, Error Budget следует рассчитывать на основании количества соответствующих событий.

65. Как использовать Error Budget

SLO Error Budget Policy:

Error Budget Healthy

|

v

Continue Releases

Error Budget Exhausted

|

v

Prioritize Reliability

Это не обязательно означает полный запрет новых релизов.

Политика зависит от рисков и потребностей команды.

Но Error Budget помогает принимать решения на основании измеримого качества сервиса.

Часть 13. Alerting

66. Что такое Alerting

Production Alerting — автоматическое уведомление команды о проблемах, требующих внимания.

Например:

API Error Rate > Threshold

|

v

Alert Rule

|

v

Notification

Уведомление может отправляться в систему управления инцидентами или другой канал.

67. Какие Alerts действительно полезны

Actionable Alerts должны быть связаны с конкретными действиями.

Например:

• высокий HTTP 5xx Rate;

• нарушение SLO;

• длительное отставание очереди;

• недоступность критического сервиса;

• исчерпание дискового пространства;

• ошибки обработки платежей.

Не каждое изменение метрики требует срочного уведомления.

68. Почему слишком много Alerts вредно

Alert Fatigue возникает, когда команда получает слишком много уведомлений.

Например:

CPU 81% -> Alert

CPU 79% -> Recovery

CPU 82% -> Alert

Такое поведение может создавать постоянный шум.

Полезные методы:

• Alert Windows;

• Hysteresis;

• Grouping;

• Deduplication;

• Severity Levels;

• SLO-Based Alerting.

69. Что такое Burn Rate Alerting

SLO Burn Rate Alerting помогает обнаруживать быстрое расходование Error Budget.

Например, если сервис за короткое время потребляет значительную часть месячного бюджета ошибок.

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

70. Как организовать Incident Response

Production Incident Response:

Alert Triggered

|

v

Acknowledge

|

v

Assess Impact

|

v

Mitigate

|

v

Identify Root Cause

|

v

Postmortem

Важный принцип — сначала уменьшить влияние инцидента на пользователей.

Например, отключить проблемную функцию через Feature Flag.

После восстановления можно провести подробный анализ причины.

Часть 14. Производительность и стоимость Observability

71. Что такое High Cardinality Metrics

Prometheus High Cardinality — проблема чрезмерного количества уникальных временных рядов.

Например, плохая метрика:

http_requests_total{

user_id="123"

}

Если пользователей миллионы, количество рядов может стать огромным.

Поэтому не стоит использовать в Prometheus Labels:

• User ID;

• Request ID;

• Trace ID;

• случайные UUID;

• полный URL с динамическими параметрами.

Для таких данных лучше использовать Traces или Logs с соответствующими ограничениями.

72. Что такое Trace Sampling

OpenTelemetry Trace Sampling — выбор части Traces для записи и экспорта.

Например:

100,000 Requests

|

v

Sample 10%

|

v

10,000 Traces

Sampling помогает контролировать стоимость хранения и обработки.

Но слишком агрессивное Sampling может скрыть редкие ошибки.

73. Head Sampling vs Tail Sampling

Head Sampling vs Tail Sampling:

Tail Sampling может позволять сохранять медленные и ошибочные Traces.

Но требует дополнительной инфраструктуры и ресурсов.

74. Как контролировать Observability Costs

Observability Cost Optimization:

• использовать Sampling;

• ограничивать High Cardinality;

• выбирать Log Retention;

• удалять ненужные атрибуты;

• агрегировать метрики;

• использовать Batching;

• разделять Production и Development;

• контролировать объём Telemetry.

Цель — сохранить диагностическую ценность без неконтролируемого роста расходов.

Часть 15. Production-архитектура

75. Полная архитектура Observability для SaaS

Production Observability Architecture React FastAPI:

Users

|

v

React App

|

v

API Gateway

|

v

FastAPI API

|

+------------+------------+

| | |

v v v

PostgreSQL Redis Celery

| | |

+------------+------------+

|

v

OpenTelemetry SDK

|

v

OTLP Export

|

v

OpenTelemetry Collector

|

+------------+------------+

| | |

v v v

Metrics Traces Logs

| | |

v v v

Prometheus Tempo Loki

| | |

+------------+------------+

|

v

Grafana

|

v

Dashboards & Alerts

|

v

Incident Response

Эта архитектура объединяет инфраструктурные и прикладные сигналы.

Однако её не обязательно внедрять полностью с первого дня.

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

76. Как внедрять Observability поэтапно

Observability Implementation Roadmap:

Этап 1. Логирование

Добавить:

• Structured Logs;

• Request ID;

• Log Levels;

• Error Tracking.

Этап 2. Метрики

Добавить:

• Request Rate;

• Error Rate;

• P95 Latency;

• CPU;

• Memory;

• Database Connections.

Этап 3. Distributed Tracing

Добавить:

• OpenTelemetry;

• HTTP Spans;

• Database Spans;

• Trace Context Propagation.

Этап 4. Dashboards

Добавить:

• Prometheus;

• Grafana;

• Service Dashboards;

• Database Dashboards.

Этап 5. Reliability

Добавить:

• SLI;

• SLO;

• Error Budgets;

• Alerts;

• Incident Runbooks.

Этап 6. Advanced Observability

Добавить:

• Frontend RUM;

• Celery Tracing;

• Tail Sampling;

• Cost Optimization;

• Cross-Signal Correlation.

Часть 16. Типичные ошибки

77. Ошибки Observability в Production

Первая ошибка — полагаться только на Console Logs.

Вторая — не использовать Request ID и Trace ID.

Третья — собирать слишком много Telemetry без понятной цели.

Четвёртая — записывать JWT Tokens и другие секреты в логи.

Пятая — использовать User ID как Prometheus Label.

Шестая — мониторить только CPU и Memory.

Седьмая — не измерять P95 и P99 Latency.

Восьмая — игнорировать фоновые задачи.

Девятая — не отслеживать PostgreSQL Lock Waits.

Десятая — не связывать Logs и Traces.

Одиннадцатая — не мониторить Frontend.

Двенадцатая — создавать Alerts без понятного действия.

Тринадцатая — не учитывать Alert Fatigue.

Четырнадцатая — не определять SLO.

Пятнадцатая — не проверять, работает ли сама система мониторинга.

Шестнадцатая — не учитывать расходы на Telemetry.

Семнадцатая — собирать Traces без Context Propagation.

Восемнадцатая — не использовать Sampling при высокой нагрузке.

Девятнадцатая — не анализировать изменения после Deployment.

Двадцатая — не проводить Postmortem после серьёзных инцидентов.

Эти ошибки Observability снижают способность команды быстро обнаруживать и устранять проблемы.

Часть 17. Production Checklist

78. Чек-лист Observability для Full Stack приложения

Observability Production Checklist:

Logging

• Используются Structured Logs.

• Есть Timestamp.

• Есть Service Name.

• Есть Request ID.

• Есть Trace ID.

• Логи не содержат секретов.

• Настроена Log Retention.

• Есть централизованный поиск.

Metrics

• Измеряется Request Rate.

• Измеряется HTTP Error Rate.

• Измеряется P95 Latency.

• Измеряется P99 Latency.

• Мониторятся CPU и Memory.

• Мониторится PostgreSQL.

• Мониторится Redis.

• Мониторятся фоновые задачи.

• Контролируется Metric Cardinality.

Tracing

• Настроен OpenTelemetry.

• Инструментирован FastAPI.

• Инструментирован HTTP Client.

• Инструментирован SQLAlchemy.

• Работает Trace Context Propagation.

• Есть Manual Business Spans.

• Настроен Sampling.

• Нет чувствительных данных в Span Attributes.

Frontend

• Отслеживаются JavaScript Errors.

• Измеряется LCP.

• Измеряется INP.

• Измеряется CLS.

• Есть Frontend Performance Monitoring.

• Учитываются Privacy Requirements.

Reliability

• Определены SLI.

• Определены SLO.

• Есть Error Budget Policy.

• Настроены Alerts.

• Есть Incident Runbooks.

• Проводятся Postmortems.

Operations

• Grafana Dashboards доступны команде.

• Проверена работоспособность Metrics Pipeline.

• Проверена работоспособность Trace Pipeline.

• Проверена работоспособность Log Pipeline.

• Контролируются расходы на Telemetry.

• Мониторится сама Observability Infrastructure.

FAQ

Что такое Observability?

Способность исследовать состояние системы с помощью Logs, Metrics, Traces и других сигналов.

Чем Observability отличается от Monitoring?

Monitoring обычно контролирует заранее определённые показатели, а Observability помогает исследовать более широкий круг проблем.

Что такое OpenTelemetry?

Открытый набор стандартов и инструментов для сбора и передачи телеметрии.

Что такое Prometheus?

Система сбора и хранения Time-Series Metrics.

Что такое Grafana?

Инструмент визуализации метрик, логов и трассировок из разных источников.

Что такое Distributed Tracing?

Отслеживание выполнения операции через несколько сервисов и компонентов.

Что такое Trace?

Набор связанных Spans, описывающих выполнение операции.

Что такое Span?

Отдельная операция внутри Trace.

Что такое Trace ID?

Идентификатор трассировки, позволяющий связывать её компоненты.

Что такое OTLP?

Протокол передачи Telemetry в экосистеме OpenTelemetry.

Что такое OpenTelemetry Collector?

Сервис для приёма, обработки и экспорта Telemetry.

Можно ли использовать OpenTelemetry с FastAPI?

Да. Существуют SDK и Instrumentation для FastAPI и связанных компонентов.

Как мониторить FastAPI?

Через HTTP Metrics, Structured Logs, Distributed Tracing и инфраструктурные показатели.

Как мониторить React?

Через Frontend Error Tracking, Real User Monitoring и Web Vitals.

Что такое Structured Logging?

Логирование в формате с отдельными структурированными полями, например JSON.

Зачем нужен Request ID?

Чтобы связывать записи, относящиеся к конкретному HTTP-запросу.

Чем Request ID отличается от Trace ID?

Request ID обычно идентифицирует запрос, а Trace ID — связанную цепочку операций, которая может охватывать несколько сервисов.

Что такое PromQL?

Язык запросов Prometheus.

Что такое Counter?

Метрика для подсчёта событий.

Что такое Gauge?

Метрика, представляющая текущее значение.

Что такое Histogram?

Метрика для анализа распределения наблюдений.

Что такое P95 Latency?

Значение задержки, ниже которого находится приблизительно 95% наблюдений.

Что такое RED Method?

Подход к мониторингу сервисов через Rate, Errors и Duration.

Что такое USE Method?

Подход к мониторингу ресурсов через Utilization, Saturation и Errors.

Что такое Real User Monitoring?

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

Что такое Core Web Vitals?

Ключевые показатели пользовательского опыта, включая LCP, INP и CLS.

Что такое SLI?

Измеримый показатель качества сервиса.

Что такое SLO?

Целевое значение SLI за определённый период.

Что такое SLA?

Соглашение об уровне сервиса.

Что такое Error Budget?

Допустимый объём нарушения SLO.

Что такое Burn Rate Alerting?

Уведомления, основанные на скорости расходования Error Budget.

Что такое Alert Fatigue?

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

Что такое High Cardinality?

Чрезмерное количество уникальных комбинаций Labels в метриках.

Что такое Trace Sampling?

Выбор части Traces для хранения и анализа.

Что такое Tail Sampling?

Подход, при котором решение о сохранении Trace принимается после получения информации о его выполнении.

Какие инструменты выбрать для небольшого SaaS?

Можно начать со Structured Logs, Prometheus Metrics, Grafana Dashboards и базового OpenTelemetry Tracing.

Нужна ли Observability микросервисам?

Да, особенно при распределённой архитектуре. Но она полезна и для монолитных приложений.

Заключение

Observability — важная часть современной Full Stack разработки.

Когда приложение состоит из React, FastAPI, PostgreSQL, Redis, Celery и внешних API, проблемы редко ограничиваются одним компонентом.

Медленный интерфейс может быть вызван SQL-запросом.

Ошибка оплаты может возникнуть из-за задержки обработки Webhook.

Фоновая задача может зависнуть в очереди, хотя HTTP API продолжает успешно отвечать.

Поэтому недостаточно просто проверять доступность сервера.

Нужно понимать, что происходит внутри системы.

Logs помогают исследовать конкретные события.

Metrics показывают общую картину производительности и надёжности.

Traces позволяют проследить выполнение запроса через несколько компонентов.

OpenTelemetry помогает стандартизировать сбор телеметрии.

Prometheus предоставляет возможности работы с Time-Series Metrics.

Grafana объединяет данные в удобные Dashboards.

SLI и SLO позволяют формулировать измеримые цели качества.

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

Главный принцип: Production-приложение должно не только работать, но и предоставлять достаточно информации, чтобы команда могла быстро понять, почему оно работает неправильно.

Для небольшого проекта не нужно сразу внедрять десятки инструментов.

Начните со Structured Logging, HTTP Error Rate, P95 Latency и нескольких важных Dashboards.

Затем добавьте Distributed Tracing, Frontend Monitoring, SLO и более развитую систему Alerting.

Так Observability станет не дополнительной нагрузкой на команду, а инструментом, который помогает быстрее выпускать функции, находить проблемы и поддерживать стабильность продукта.