Что такое наблюдаемость API?

Фото Vivaan Trivedii на Unsplash

API — это кровеносные сосуды для цифрового бизнеса.

По мере прохождения данных подается энергия для активации новых возможностей. Часто мы сосредотачиваемся на специализированных компонентах, жизненно важных органах наших программных систем.

Что мы можем узнать, подключаясь к самим соединителям, извлекая информацию из потоков? Вот краткий обзор начальной загрузки стратегии наблюдаемости для API.

Откройте для себя сигналы

Данные живут повсюду. Когда дело доходит до измерения успеха, прогнозирования проблем или поиска следующей возможности, мы инстинктивно соскребаем, очищаем, полируем и анализируем информацию в меру своих возможностей.

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

Со временем мы применили эти инстинкты обработки данных и к нашим цифровым активам. Для современного бизнеса это практика выживания.

Поскольку в нашем бизнесе так много API-интерфейсов, ищем ли мы правильные сигналы?

Акроним MELT определяет нашу отправную точку.

• M — метрики, числовые измерения, собранные и отслеживаемые с течением времени.

• E - События, моментальные снимки существенных изменений состояния.

• L - Логи, подробная расшифровка поведения системы.

• T — Трассы, маршрут взаимодействия между компонентами в сочетании с соответствующим контекстом.

Процесс передачи и записи этих сигналов называется телеметрией.

Дальнейшее чтение:

• [MELT 101] (https://newrelic.com/platform/telemetry-data-101)

Осмотрите сантехнику

Большинство взаимодействий, которые мы имеем с API по сети, довольно высокоуровневые. Мы отправляем большой двоичный объект JSON. Получаем блоб JSON. Выгода! 💰 Какие сигналы мы можем получить из того, что лежит внизу?

1. Когда произошло значительное изменение трафика?

1. Сколько времени тратится на получение данных из внешних источников?

1. Какова тенденция ошибок подключения с течением времени?

Связь устройств отслеживания сигналов с нашими системами называется инструментированием.

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

Примеры:

• [Автоинструментация OpenTracing Node.js HTTP] (https://opentelemetry.io/docs/instrumentation/js/getting-started/nodejs/)

• Метрики Envoy, Istio Telemetry API

Запомнить домен

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

Но как насчет всего делового материала между ними? Как мы собираем измерения для ключевых показателей эффективности бизнеса (KPI)? Мы смотрим на инструмент домена.

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

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

1. Каков средний промежуток времени между предложением кодов скидок и их применением при оформлении заказа?

1. Какова корреляция между объявлениями о продуктах в приложении и подпиской на новостную рассылку?

1. Когда встречи отменяются, какое поведение непосредственно предшествует этому действию?

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

Дальнейшее чтение:

• [Наблюдаемость, ориентированная на предметную область] (https://martinfowler.com/articles/domain-Oriented-observability.html)

Найти путевые точки:

Когда мы разбили монолит на множество сервисов, мы потеряли возможность пошагового выполнения нашего кода с помощью отладчика: теперь он скачет по сети. Наши инструменты все еще справляются с этим сейсмическим сдвигом. - Благотворительные организации, [Наблюдаемость - трехлетняя ретроспектива] (https://thenewstack.io/observability-a-3-year-retrospective/)

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

Давайте посмотрим, как развивался ландшафт инструментов наблюдаемости.

Близко к металлу

Решения для регистрации и мониторинга появились, когда мы писали код, близкий к металлу. Стек с открытым исходным кодом, который раньше доминировал в ландшафте, представлял собой комбинацию этих инструментов:

• Graylog - полная система управления логами.

• [Nagios] (https://www.nagios.org/) — мониторинг и оповещение систем, сетей и приложений.

• StatsD — сбор и отправка метрик.

• Carbon — получение метрик для Graphite, хранящихся в базе данных Whisper.

• [Graphite] (https://graphiteapp.org/) — запрос метрик, визуализация и оповещение.

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

Абстрагирование машины

По мере того, как виртуальные машины — и, в конечном итоге, облачная инфраструктура — стали более популярными, чем работа на «голых» серверах, мы увидели сдвиг в подходе к сбору сигналов. Это привело к возникновению двух заметных стеков в пространстве наблюдаемости:

• [стек ELK] (https://www.elastic.co/what-is/elk-stack)

• ElasticSearch — полнотекстовый поисковик для хранения журналов и запросов

• Logstash - прием логов

• Kibana - визуализация журнала и оповещение

• TICK stack

• Telegraf — прием метрик

• InfluxDB — база данных временных рядов для хранения метрик и запросов.

• Chronograf - визуализация метрик

• Kapacitor - обработка метрик и оповещение

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

Тем не менее, мы находимся в середине еще одного кардинальных изменений. На карте есть последняя остановка.

Страна контейнеров

Произошел резкий переход к облачной инфраструктуре. А для систем, работающих в самоуправляемых центрах обработки данных, контейнеры начинают брать на себя роль элементарной единицы развертывания приложений.

Кроме того, Kubernetes стал доминирующим оркестратором контейнеров (Примечание: в мире Kubernetes атомарная единица известна как Pod и состоит из одного или нескольких связанных контейнеров).

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

• Prometheus — сбор метрик, запросы и оповещения.

• Grafana — визуализация показателей и оповещение.

• [стек EFK] (https://devopscube.com/setup-efk-stack-on-kubernetes/)

• Эластичный поиск

• [Свободно] (https://www.fluentd.org/)

• Kibana

• Jaeger или Zipkin — запрос трассировки и визуализация

Почему так много вариантов? Этот мир все еще созревает, и он значительно усложнился.

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

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

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

OpenTelemetry.io, независимая от инструментов платформа наблюдения для передачи данных телеметрии, определяет проект как:

OpenTelemetry — это набор инструментов, API и SDK. Используйте его для инструментирования, создания, сбора и экспорта данных телеметрии (показателей, журналов и трассировок), которые помогут вам проанализировать производительность и поведение вашего программного обеспечения.

Многие инструменты мониторинга производительности приложений (APM) также добавляют поддержку OpenTelemetry. Проверьте реестр OpenTelemetry для получения дополнительной информации.

Вот пример добавления автоматического инструментария в приложение Node.js.

```javascript

/ трассировка.js /

// Требуются зависимости

const opentelemetry = require("@opentelemetry/sdk-node");

константа {

получитьNodeAutoInstrumentations,

} = require("@opentelemetry/auto-instrumentations-node");

const sdk = новый opentelemetry.NodeSDK({

traceExporter: новый opentelemetry.tracing.ConsoleSpanExporter(),

инструменты: [getNodeAutoInstrumentations()],

SDK.старт();

Это дает отличный толчок, чтобы помочь нам начать получать сигналы с минимальными усилиями.

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

Трассировка состоит из нескольких компонентов, заслуживающих внимания.

Родитель (t1)

└── След (t2)

├── Размах (с1)

│ ├── Событие (e1)

│ └── Событие (e2)

└── Размах (с2)

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

Охватывает сегменты журнала трассировки. Вот пример сервера, получающего HTTP-запрос:

```javascript

// Этот сервер искусственный и только для примера

импортировать {SemanticAttributes} из "@opentelemetry/semantic-conventions";

импортировать { трассировку, SpanKind, SpanStatusCode} из "@opentelemetry/api";

асинхронная функция onGet (запрос, ответ) {

const span = tracer.startSpan(GET /applicants/:id, {

атрибуты: {

вид: SpanKind.SERVER,

постоянный пользователь = ожидание getUser();

ответ.отправить(пользователь.toJson());

span.setStatus({

код: SpanStatusCode.OK,

диапазон.конец();

server.on("GET", "/applicants/:id", onGet);

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

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

```javascript

// Получить текущий диапазон

const span = tracer.getCurrentSpan();

// Выполняем действие

заявитель.принять(домашнее животное)

// Запись действия

span.addEvent("заявитель.adoption.request", {

"заявитель.id", заявитель.id,

"pet.id": домашнее животное.id,

"applicant.eligibilityScore": заявитель.eligibilityScore,

Это только обзор высокого уровня. Ознакомьтесь с документацией OpenTelemetry для получения более подробной информации!

Подробнее:

• [Обзор спецификации OpenTelemetry] (https://opentelemetry.io/docs/reference/specification/overview/)

• [Контекст трассировки W3C] (https://www.w3.org/TR/trace-context/)

• Формат распространения контекста распределенной трассировки: Baggage

Повышение наблюдаемости API

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

В [Отчете VMWare о состоянии наблюдаемости за 2021 год] (https://tanzu.vmware.com/content/ebooks/the-state-of-observability-2021) говорится о следующих причинах роста сложности управления облачные приложения:

• Межкомандное внедрение фреймворков полиглотов для микросервисов.

• Запросы приложений, проходящие через многие сторонние API и технологии

• Различные подходы к безопасности приложений у разных поставщиков.

Устаревших стратегий телеметрии недостаточно. Как нам начать продвигать инициативу по улучшению?

1. Оцените, как наблюдаемость вписывается в текущую стратегию API. Поговорите с заинтересованными сторонами. Исследуйте влияние. Заведите дело. Следуйте рекомендациям, представленным в 5 советов разработчиков по выживанию в API-First.

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

1. Делегируйте обязанности. Team Topologies описывает подход, который может помочь разделить нагрузку по инструментированию приложений и управлению инфраструктурой наблюдаемости. Подробнее читайте по ссылке: 🚀 Масштабирование команд API с помощью Platform Ops.

Наблюдаемость открывает окно в органический поток информации, который проходит через наши системы. Это позволяет нам задавать важные вопросы, которые влияют на наш бизнес. Хорошая новость заключается в том, что мы почти наверняка знакомы с некоторыми из задействованных практик. Поскольку ландшафт продолжает расти, требуется много усилий, чтобы оставаться на шаг впереди. Это ожидаемо. Следование инициативе по обеспечению наблюдаемости — это долгосрочный подход к обеспечению выживания. Эволюция, как известно, требует терпения. 🧘

Дополнительное чтение:

• [Трехэтапный подход к наблюдению] (https://newrelic.com/resources/ebooks/3-phased-approach-to-observability) от New Relic

• [Наблюдение за распределенными системами] (https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/) Синди Шридхаран

• [Наблюдение не является отладкой (и другие неправильные термины)] (https://kislayverma.com/software-architecture/observing-is-not-debugging-and-other-misnomers/) Кислая Вермы

• [Состояние наблюдаемости Splunk 2021] (https://www.splunk.com/en_us/form/state-of-observability.html)

Социальное фото Эмилиано Витториози на Unsplash