Наблюдение микросервисов: использование OpenElemetry в реальных системах Gajinder Sharma
4 июля 2025 г.Как бэкэнд -разработчик, работающий с микросервисами в течение последних нескольких лет, одна истина стала болезненно очевидной: отладка проблем производства в распределенных системах может чувствовать себя как детективная работа в темноте.
У вас есть услуги, вызывая услуги, иногда десятки глубиной. Пользователь нажимает кнопку на пользовательском интерфейсе, а 15 микросервисов вращаются в действие. Если что -то сломается - или, что еще хуже, просто замедляется - выяснить, где и почему могут жевать часы.
Именно поэтому наблюдение имеет значение. И если вы строите или поддерживаете микросервисы в 2024 году, OpenElemetry - это инструмент, который вы хотите в своем углу.
Что даже наблюдается, на самом деле?
Наблюдение - это больше, чем просто журналы. Речь идет о понимании того, почему ваша система ведет себя определенным образом, а не только то, что она делает. В основе мы говорим о трех столпах:
- Журналы - необработанные события, полезные для отладки.
- Метрики - числа, которые вы можете отслеживать с течением времени (например, количество запросов, процессор).
- Следы-сквозные потоки запроса между службами (он же ваш распределенный «стек вызовов»).
Традиционные инструменты мониторинга в основном фокусируются на метриках и журналах, но трассировка является реальным изменением игры для микросервисов.
Почему мы выбрали OpenElemetry
Мы экспериментировали с несколькими стеками наблюдений-Datadog, New Relic, Prometheus, Jaeger, Zipkin-но у всех была одна проблема: либо они были заблокированы поставщиками, либо не имели консистенции на разных языках.
OpenElemetry (OTEL) проверила все наши коробки:
- Открытый исход, под CNCF
- Работает на языках (мы используем Node.js, Go и Python)
- Нейтральный продавец-экспорт в Графана, Джегер, Новая Реликвия и т. Д.
- Поддерживается всеми в отрасли (буквально: AWS, GCP, Microsoft и т. Д.)
Как мы используем OpenElemetry в Node.js Microservices
Позвольте мне провести вас через то, как мы на самом деле дали настоящий сервис. Допустим, у нас есть простой пользовательский сервис, встроенный в node.js с использованием Express. Он разоблачает конечную точку `/users`, которая получает пользовательские данные. Ниже приведены шаги.
Шаг 1: Установите зависимости
npm install @opentelemetry/api \
@opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http
Мы собираемся экспортировать следы через OTLP в местный экземпляр Jaeger.
Шаг 2: Создайте трассировку.
JavaScript: Tracing.js
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
const { Resource } = require('@opentelemetry/resources');
const traceExporter = new OTLPTraceExporter({
url: 'http://localhost:4318/v1/traces',
});
const sdk = new NodeSDK({
traceExporter,
instrumentations: [getNodeAutoInstrumentations()],
resource: new Resource({
[SemanticResourceAttributes.SERVICE_NAME]: 'user-service',})
});
sdk.start();
Шаг 3: Добавьте его в файл входа
JavaScript: Index.js
require('./tracing'); // Always load this first
const express = require('express');
const app = express();
app.get('/users', (req, res) => {
res.json([{ id: 1, name: "Alice" }, { id: 2, name: "Bob" }]);
});
app.listen(3000, () => console.log("User service running on port 3000"));
Наш сервис теперь экспортирует следы.
Шаг 4: Сверните Jaeger локально (или используйте Grafana Tempo)
Вот как мы тестируем локально:
docker run -d --name jaeger \
-e COLLECTOR_OTLP_ENABLED=true \
-p 4318:4318 -p 16686:16686 \
jaegertracing/all-in-one:latest
Посещатьhttp: // localhost: 16686Чтобы просмотреть ваши следы.
Следов цепочки между услугами
Теперь скажите, что у вас есть еще одна услуга-услуга по заказу-которая вызывает пользовательский сервис. Если оба предназначены для Opentelemetry, вы получите полную трассу от перехода между ними пользователя.
А лучшая часть? OpenElemetry обрабатывает трассировку по контексту размножения через заголовки HTTP автоматически. Вам не нужно вручную проходить идентификаторы трассировки между службами.
Добавление пользовательских пролетов для бизнес -логики
Иногда автоинструментации недостаточно. Например, если вы хотите отследить запрос DB или внешний вызов API:
const { trace } = require('@opentelemetry/api');
const tracer = trace.getTracer('user-service');
app.get('/users', async (req, res) => {
const span = tracer.startSpan('fetch-user-data');
try {
const users = await fetchUsersFromDB();
res.json(users);
} catch (err) {
span.recordException(err);
throw err;
} finally {
span.end();
}
});
Это очень полезно, когда вы хотите отслеживать производительность конкретной бизнес -логики.
Лучшие практики мы узнали трудным путем
1Используйте семантические соглашения
Вместо того, чтобы изобретать свои собственные имена атрибутов, придерживайтесь семантических соглашений Opentelemetry. Они облегчают понимание и совместимые с такими инструментами, как Grafana, Tempo и т. Д.
Пример:
JavaScript
span.setAttribute("http.method", req.method);
span.setAttribute("http.route", req.path);
2. Образец с умом
Если вы проследите каждый запрос, ваша система будет заглушить данные. Используйте отбор проб (например, 10%или только ошибки).
JavaScript
const sdk = new NodeSDK ({
sampler: new TraceIdRatioBasedSampler (0.1), // 10% sampling
});
3. Используйте коллекционер OpenElemetry в производстве
Не экспортируйте данные телеметрии непосредственно из ваших услуг в бэкэнд. Пропустите его через коллекционер OpenteLemetry - он дает вам буферизацию, пакетирование, повторение и преобразование формата.
4. Не регистрируйте PII в промежутке
Это критическое. Будьте очень осторожны, чтобы не хранить имена пользователей, электронные письма, информацию о кредитной карте и т. Д. В атрибутах или журналах SPAN. Придерживайтесь метаданных и идентификаторов.
Где это помогло нам больше всего
- Отладка проблем задержек: видение полных трассов в 4–5 микросервисах помогла нам определить узкие места за считанные минуты.
- Определение повторных штормов: мы обнаружили сервис, вызывая другое в цикле с повторными поисками, чего бы мы не поймали через журналы.
- Регрессии развертывания: сравнение трассов от одной версии с другой показало нам именно то, что изменилось.
Бонус: отслеживание в многоязычном стеке
Мы используем node.js для некоторых услуг, иди за другими. OpenElemetry позволила легкому прибору оба и отправила все данные в одно место - Jaeger для Dev, Grafana Cloud в постановке/Prod.
Нет блокировки продавца. Нет несоответствия в форматах трассировки. Просто чистая видимость.
Вывод: если вы создаете микросервисы, начните с наблюдения
- Микросервисы дают нам масштаб и гибкость, но они также приносят сложность. Без надлежащей наблюдения вы летете слепым.
- Opentelemetry стала основной частью нашей архитектуры не только для отладки, но и для оптимизации производительности, надежности и, в конечном итоге, - пользовательского опыта.
Если кто -то еще не использует его, я настоятельно рекомендую сделать это. Даже базовая установка с Jaeger и несколькими услугами заставит вас задуматься, как вы когда -либо жили без него.
Оригинал