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

Содержание

Odigos - распределенная трассировка с открытым исходным кодом
Давайте все устроим🔥
Автоматическое соединение с Одигосом 🤝
Завершаем! 📝

Представьте себе, что вы отправляете HTTP-запрос из одного приложения; это приложение отправляет его в другое приложение, которое отправляет его в другое приложение. **Что, если по пути что-то случится?

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

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

Вы узнаете:

Как контролировать наше приложение с помощью OpenTelemetry.
Как просматривать журналы и трассировку кораблей.
Как просматривать метрики и фильтровать трассы.
Как автоматизировать мониторинг приложений.

GIF

Odigos - распределенная трассировка с открытым исходным кодом

**Мониторинг всех ваших приложений одновременно без написания одной строки кода! Упростите сложность OpenTelemetry с помощью единственной платформы, которая может генерировать распределенную трассировку во всех ваших приложениях.

Мы действительно только начинаем.
Можете ли вы помочь нам со звездой? Пожалуйста? 😽

https://github.com/keyval-dev/odigos

Давайте все устроим🔥

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

Создайте папку проекта для веб-приложения, как показано ниже.

mkdir monitor-app
cd monitor-app
mkdir server

Настройка сервера Node.js 🤖

Перейдите в папку сервера и создайте файл package.json.

cd server && npm init -y

Установите Express.

npm install express

ExpressJS - это фреймворк для создания RESTful API на базе Node.js.

Создайте файл index.js - точку входа на наш веб-сервер.

// 👇server/index.js
touch index.js

Настройте сервер Node.js с помощью Express. Приведенный ниже фрагмент кода возвращает объект JSON с одним ключом, когда мы делаем запрос get к конечной точке /static-data или /fetch-data в нашем браузере.

// 👇server/index.js
const express = require('express');
const app = express();
const PORT = 8000;

app.use(express.urlencoded({ extended: true }));
app.use(express.json());

app.get('/static-data', (req, res) => {
	res.json({
		msg: 'Hello world!',
	});
});

app.get('/fetch-data', (req, res) => {
	// Имитируем вызов реальной базы данных
	setTimeout(() => {
		res.json({
			msg: 'Hello world!',
		});
	}, 2000);
});

app.listen(PORT, () => {
	console.log(`Сервер прослушивает порт: ${PORT}`);
});

💡 СОВЕТ ДНЯ

Начиная с версии Node v18.11.0 нам больше не нужен nodemon для отслеживания изменений и перезапуска сервера, теперь он встроен в Node с флагом --watch.

Настройте node --watch, добавив команды start и trace-start в список скриптов в файле package.json.

// 👇server/package.json
"scripts": {
  "test": "echo \"Error: no test specified\" && exit 1",
  "start": "node --watch index.js",
  "trace-start": "node -r ./tracing.js --watch index.js"
},

start: Этот фрагмент кода запускает веб-сервер.
trace-start: Этот фрагмент кода запускает веб-сервер с предварительной загрузкой файла tracing.js. Мы будем использовать эту команду для демонстрации.

Ручная настройка OpenTelemetry и SigNoz ⚒️

OpenTelemetry используется для инструментации, генерации, сбора и экспорта телеметрических данных. SigNoz - это APM с открытым исходным кодом. Он помогает разработчикам отслеживать работу своих приложений и устранять проблемы, являясь альтернативой другим APM с открытым исходным кодом. Это универсальное решение для получения доступ к метрикам, журналам и трассировкам приложения.

Начнем с установки необходимых пакетов OpenTelemetry.

⚠️ Если вы работаете под Windows, выполните каждую из этих команд по отдельности.

npm install --save @opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http

Для установки SigNoz выполните шаги по установке, показанные [здесь] (https://signoz.io/docs/install/docker/).

Установите трассировку, создав файл tracing.js и используя приведенный ниже код.

// 👇server/tracing.js
'use strict';
const process = require('process');
const opentelemetry = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');
const { Resource } = require('@opentelemetry/resources');
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');

const exporterOptions = {
	url: 'http://localhost:4318/v1/traces', // URL по умолчанию для отправки данных трассировки.
};

const traceExporter = new OTLPTraceExporter(exporterOptions);
const sdk = new opentelemetry.NodeSDK({
	traceExporter,
	instrumentations: [getNodeAutoInstrumentations()],
	resource: new Resource({
		[SemanticResourceAttributes.SERVICE_NAME]: 'Monitor-Node-App',
	}),
});

// инициализируем SDK и регистрируемся в API OpenTelemetry
sdk.start();

// завершение работы SDK при выходе из процесса
process.on('SIGTERM', () => {
	sdk
		.shutdown()
		.then(() => console.log('Трассировка завершена!'))
		.catch((error) => console.log('Ошибка при завершении трассировки.', error))
		.finally(() => process.exit(0));
});

Для мониторинга нашего Node-приложения мы используем Node SDK @opentelemetry/sdk-node для трассировки и метрик, @opentelemetry/auto-instrumentations-node для простой настройки инструментария и @opentelemetry/exporter-trace-otlp-http для экспорта данных трассировки в OTLP-совместимые приемники через HTTP и JSON.

Мы закончили с базовым инструментированием нашего демонстрационного Node-приложения с помощью OpenTelemetry и SigNoz 🥂. Теперь выполните команду trace-start.

npm run trace-start

Зайдите в пользовательский интерфейс SigNoz http://localhost:3301. После входа в систему у нас должно появиться что-то вроде этого.

Не беспокойтесь об этих данных, они уже заполнены SigNoz. Обратите внимание, что мы не видим нашего Monitor-Node-App в списке сервисов. Это потому, что мы не делали запросов к нашему серверу.

Чтобы SigNoz показал трассировку, нам нужно создать определенную нагрузку на наш сервер. Для этого мы можем несколько раз обновить конечные точки в браузере или выполнить следующую команду CLI на наших конечных точках /static-data или /fetch-data, чтобы автоматически сделать это за нас.

Для пользователей Linux

ℹ️ Убедитесь, что установлен curl.

for i in {1..20}; do curl http://localhost:8000/fetch-data; done

Для пользователей Windows

1..20 | ForEach-Object { Invoke-RestMethod -Uri 'http://localhost:8000/fetch-data' }

Теперь при повторном посещении SigNoz UI мы должны увидеть наш сервис в списке сервисов.

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

GIF

Для наглядности посмотрим на запросиз одного из демонстрационных приложений, уже поставляемых с SigNoz.

Как мы видим, первый запрос, который, по сути, выполняет SQL-запрос, проходит через множество шагов, и, наконец, выполняет SQL-запрос. Мы также можем увидеть время, затраченное на каждый этап запроса.

Приборная панель SigNoz’s Traces предлагает готовые визуализации для данных трассировки. Она включает в себя сильные фильтры для анализа пролетов на основе выбранных нами критериев и временных рамок.

Визуализация метрик из Hostmetrics 👀

Наиболее распространенным способом получения метрик в SigNoz является приемник Prometheus.

Для простоты я покажу, как визуализировать стандартные метрики, предоставляемые Hostmetrics, которые по умолчанию включены при установке SigNoz.

Весь список доступных метрик можно найти здесь.

В разделе Dashboards пользовательского интерфейса SigNoz создайте новую панель Time Series.

В поле ввода запроса PromQL введите следующее: Для примера воспользуемся метрикой system_cpu_load_average_5m, как следует из названия, она дает среднее значение 5-минутной загрузки процессора. Не стесняйтесь настраивать метрику по своему усмотрению.

Автоматическое соединение с Одигосом 🤝

Odigos - это плоскость управления наблюдаемостью с открытым исходным кодом, которая позволяет организациям создавать и поддерживать свой конвейер наблюдаемости.

Помните, через какие трудности мы прошли при ручной настройке? С Odigos в этом нет необходимости. Он автоматически настраивает наше приложение, избавляя нас от необходимости самостоятельно настраивать OpenTelemetry или что-либо еще. Odigos все сделает за нас. 🤯

Инструкции по установке Odigos можно найти [здесь] (https://docs.odigos.io/installation).

Нам нужно установить SigNoz на Kubernetes, чтобы OpenTelemetry мог отправлять ему собранные данные.

SigNoz можно легко установить на Kubernetes с помощью Helm:

helm repo add signoz https://charts.signoz.io
kubectl create ns platform
helm --namespace platform install my-release signoz/signoz

Чтобы перенести пользовательский интерфейс SigNoz на нашу локальную машину, выполните следующие действияng.

export POD_NAME=$(kubectl get pods --namespace platform -l "app.kubernetes.io/name=signoz,app.kuber
    netes.io/instance=my-release,app.kubernetes.io/component=frontend" -o jsonpath="{.items[0].metadata.name}")

kubectl --namespace platform port-forward $POD_NAME 3301:3301

Теперь вы можете получить доступ к пользовательскому интерфейсу SigNoz по адресу http://localhost:3301.

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

Создайте клон этого репозитория microservices-demo

git clone https://github.com/keyval-dev/microservices-demo.git

Создайте новый локальный кластер Kubernetes, выполнив следующую команду. Она понадобится нам при настройке Odigos.

ℹ️ Для пользователей Windows убедитесь, что запущен Docker Desktop.

minikube start

Инструкции по установке minikube можно найти здесь.

Разверните клонированное приложение с помощью следующей команды

kubectl apply -f https://raw.githubusercontent.com/keyval-dev/microservices-demo/master/release/kubernetes-manifests.yaml

Запустите пользовательский интерфейс Odigos с помощью следующей команды.

./odigos ui

Зайдите в пользовательский интерфейс Odigos на localhost:3000. Выберите все микросервисы в пространстве имен, как показано ниже.

После выбора всех приложений нам будет предложено:

Имя места назначения: Имя нашего назначения.
Конечная точка хоста: Используйте конечную точку хоста для SigNoz.

После этого у нас должен появиться следующий пользовательский интерфейс.

Поздравляем🎉! Настройка Odigos прошла успешно. Теперь он должен автоматически отправлять трассировки, метрики и логи в наш бэкенд наблюдаемости.

Теперь, чтобы увидеть это на практике, нам нужно сначала настроить внешний IP для нашего сервиса frontend-external LoadBalancer.

Выполнение команды kubectl get services должно показать следующее. Обратите внимание на <pending> IP для службы external-frontend.

По умолчанию в браузере невозможно получить доступ к сервису LoadBalancer. Для этого нам необходимо настроить minikube tunnel. Более подробную информацию об этой команде можно найти здесь.

туннель minikube
kubectl get services

Вход в полноэкранный режим

Теперь мы можем увидеть IP и порт, назначенные службе external-frontend.

Зайдите на http://127.0.0.1:8081 в браузере, чтобы получить доступ к приложению.

Приложение электронной коммерции Google ge/fetch/s–q-_msvwC—/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://res.cloudinary.com/practicaldev/image/fetch/s–qIwqSoqV—/c_limit%252Cf_auto%252Cfl_progressive%252Cq_auto%252Cw_800/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/osqhlyq3pahhwb195ps0.png)

Запустите службу SigNoz и выполните следующую команду.

kubectl port-forward -n tracing svc/<имя_сервиса> <порт_к_использованию>:<порт>

Теперь мы должны иметь возможность просматривать все трассировки нашего приложения, как мы это делали ранее.

Завершаем! 📝

Итак, мы научились внимательно следить за производительностью нашего приложения с помощью трассировок и Hostmetrics, сначала вручную с помощью OpenTelemetry и SigNoz, а затем автоматизировали процесс с помощью Odigos.

Примечание: мы не ограничиваемся использованием SigNoz; мы можем использовать любую базу данных наблюдаемости. В рамках этой статьи я решил использовать SigNoz.

Всегда полезно иметь систему мониторинга для любого приложения производственного уровня. Это поможет нам отладить ошибки, если таковые возникнут в будущем. Самое главное, это поможет нам выявить все узкие места в производительности нашего приложения, что приведет к повышению эффективности и улучшению качества работы пользователей.

Исходный код этого руководства доступен здесь:

https://github.com/keyval-dev/blog/tree/main/instrumenting-node-app

Спасибо за чтение! 🎉

Поделиться: