По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
API расшифровывается как Application Programming Interface (программный интерфейс приложения). Что же это такое?
По сути, это описание способов взаимодействия между программами, как они могут общаться и передавать данные друг другу.
Рассмотрим пример из жизни:
Приходя в ресторан вы взаимодействуйте с официантом - можете попросить меню, сделать заказ, попросить принести счет. Официант является интерфейсом вашего взаимодействия с рестораном - вам не нужно знать о том как готовится еда, ингредиенты, как рассчитывать чек, все это сделает ресторан, и отдаст вам результаты при помощи официанта, который в этом примере представляет собой API ресторана. От вас скрываются сложные детали и просто происходит общение между двумя системами - клиентом и рестораном.
Вернемся к компьютерам. Предположим, что у нашей платформы доступного айти образования Merion Academy есть интерфейс работы с клиентами - тот самый API, в котором есть определенные функции, куда можно отправить какой - то запрос, и получить ответ. Представим, что у нашего API есть функция вернуть список курсов по Linux, на которые сейчас действует скидка 50% - в такой случае браузер должен сделать запрос к нашему API на получение такого списка курсов, а ответ получить эти данные и отрисовать на странице.
Важно учесть, что API интерфейсы не всемогущи - вы получите только те функции, которые заложил разработчик. Например, если помимо курсов по Linux со скидкой 50% вы захотите еще получить прогноз погоды в селе “Добрые Пчёлы” - то сорри, наш API пока так не умеет. Для добавления каждой такой новой функции программист должен разработать ее.
API состоит из двух частей: это сам интерфейс взаимодействия, скажем так некий мост, портал, окно, а вторая часть - это его описание, которое отвечает на вопрос “а как этой штукой то пользоваться?”
Взаимодействие может быть не только между клиентом и сервером, как в примере с нашей ИТ платформой, но и между серверами. Представьте: решили вы полететь в солнечный Дубай, купили билетик на сайте, а он вам еще и погоду показывает. Как же так! Неужели у компании по продаже билетов еще и метеорологические датчики по всему миру стоят, которые сообщают о погоде? Конечно нет - сайт с билетами взаимодействует с каким - то сервисом погоды по API, который как раз занимается погодными данными. А сайт с билетиками еще и скорее всего платит за каждый запрос небольшую денюжку.
Кстати, API может быть не только у веб - сервисов, где общение происходит по протоколу HTTP. API есть и у операционных систем, для взаимодействия с самой операционкой и железом. Например, если вы создаете свой аналог инстаграма, то для работы с камерой на устройстве вам нужно взаимодействовать с API системы, которая уже знает как работать с камерой, а не придумывать что-то самому с нуля, да еще и для миллиона разных устройств.
API действительно делает жизнь разработчика удобнее, а чтобы работа с API не превратилась в бардак, оно стандартизировано. Самый популярный, это конечно же REST API, но перед тем как перейти к нему, скажем пару слов про SOAP (Service Object Access Protocol), который появился несколько раньше и описывал правила синтаксиса для сообщений запросов и ответов, отправляемых веб-приложениями. Подробнее про SOAP - тут.
Ну и все, кто поддерживал SOAP должны были обмениваться XML-сообщениями между системами через HTTP или SMTP. XML (Extensible Markup Language), он же расширяемый язык разметки - это формат для хранения и передачи данных, в котором данные размещены в тегах, что делает их легко читаемыми как для компьютера, так и для человека.
Развиваясь, люди перешли на REST, который в отличии от SOAP не является протоколом, а является архитектурным стилем. В SOAP приходилось писать в разы больше кода и заворачивать каждое сообщение в XML.
REST же делает данные доступными в качестве ресурсов, которые представлены уникальным URL-адресом, и можно запросить этот ресурс, указав его URL-адрес. Например чтобы посмотреть свои подписки на ютубе нужно выполнить запрос на вот такой адрес https://www.youtube.com/feed/subscriptions.
Веб-API, соответствующие стандартам подхода REST, называются RESTful API. Они используют различные HTTP-запросы для работы с ресурсами, такие как GET - запрос, который используется для получения информации или POST, который в свою очередь нужен для отправки данных.
RESTful системы поддерживают обмен сообщениями в различных форматах, таких как самый обычный текст, HTML формат, YAML, XML и JSON, в то время как SOAP разрешает только XML, как мы и сказали ранее. Самый популярный это конечно JavaScript Object Notation, он же JSON - простой и универсальный формат, который содержит в себе набор пар ключ:значение.
Также хотим сказать про штуку, которая называется gRPC (Remote Procedure Calls) которая в основном используется для связи между разными сервисами и работает очень быстро благодаря тому что тут используется протокол HTTP/2 который работает гораздо быстрее засчет всяких новинок вроде сжатия хедеров, а вместо JSON или XML используется формат Protocol Buffers (protobuf), который работает быстрее и потребляет меньше ресурсов при работе с ним. Работает все это настолько быстро, что можно делать вызов к функции на другом сервере с такой же скоростью, как если бы она находилась на нашем. Подробнее про gRPC и Protobuf - тут
Ну и не можем не сказать про модный GraphQL - это язык запросов для API который позволяет указывать точные данные, которые ему нужны, и упрощает получение и склейку данных из нескольких источников, поэтому разработчик может использовать один вызов API для запроса всех необходимых ему данных.
Протокол Syslog - это способ для сетевых устройств отправлять сообщения о событиях на сервер регистрации - обычно известный как Syslog сервер. Этот протокол поддерживается широким спектром устройств и может использоваться для регистрации различных типов событий. Например, маршрутизатор может отправлять сообщения о том, что пользователи подключаются через консоль, а веб-сервер может регистрировать события, в которых отказано в доступе.
Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog.
В отличие от SNMP, Syslog не может использоваться для «опроса» устройств для сбора информации. Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступное дисковое пространство. Это невозможно с Syslog - он просто отправляет сообщения в центральное место, когда инициируются определенные события.
Syslog серверы
Syslog - отличный способ объединить логи из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, которые делают это возможным.
Syslog слушатель: Syslog сервер должен получать сообщения, отправленные по сети. Процесс прослушивания собирает данные системного журнала, отправленные через 514 UDP порт. Как мы знаем UDP-сообщения не подтверждаются или не гарантируются, поэтому имейте в виду, что некоторые сетевые устройства будут отправлять данные Syslog через 1468 TCP порт для обеспечения доставки сообщений.
База данных: большие сети могут генерировать огромное количество данных syslog’а . Хорошие серверы будут использовать базу данных для хранения логов для быстрого поиска.
Программное обеспечение для управления и фильтрации: из-за больших объемов данных иногда бывает сложно найти конкретные записи в журнале. Решение состоит в том, чтобы использовать syslog сервер, который автоматизирует часть работы и позволяет легко фильтровать и просматривать важные сообщения журнала. Серверы должны иметь возможность генерировать оповещения, уведомления и алерты в ответ на выбранные сообщения, чтобы администраторы сразу узнавали, когда возникла проблема, и могли предпринять быстрые действия
Syslog сообщения
Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение.
Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog'а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7».
Syslog сообщения также имеют поле уровня серьезности. Уровень серьезности указывает, насколько важным считается сообщение. Серьезность «0» является чрезвычайной ситуацией, «1» - это предупреждение, которое требует немедленных действий, а шкала продолжается вплоть до «6» и «7» - информационных и отладочных сообщений.
0
Emergency
Система не работоспособна
1
Alert
Система требует немедленного вмешательства
2
Critical
Состояние системы критическое
3
Error
Сообщения об ошибках
4
Warning
Предупреждения о возможных проблемах
5
Notice
Сообщения о нормальных, но важных событиях
6
Informational
Информационные сообщения
7
Debug
Отладочные сообщения
Недостатки syslog
У протокола syslog есть несколько недостатков.
Во-первых, проблема согласованности. Протокол Syslog не определяет стандартный способ форматирования содержимого сообщения - и существует столько же способов форматирования сообщения, сколько существует разработчиков. Некоторые сообщения могут быть удобочитаемыми, а некоторые нет. Syslog это не волнует - он просто предоставляет способ передачи сообщения.
Есть также некоторые проблемы, которые возникают из-за того, что syslog использует UDP в качестве транспорта - поэтому возможно потерять сообщения из-за перегрузки сети или потери пакетов.
Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам.
Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.
В этой статье поговорим о локализации проблем функционирования ESXi/ESX.
Неисправности. Что может быть не так?
ПО, работающее в гостевой виртуальной машине - медленно реагирует на команды управления;
ПО, работающее в гостевой виртуальной машине, периодически прерывают работу;
Гостевая виртуальная машина работает медленно или не отвечает на запросы.
Проблемы с производительностью могут случаться из-за ограничений центрального процессора (CPU), переполнения памяти или, например, задержкой сети. Если виртуалки работают плохо, скорее всего имеют место траблы с памятью. Устраним?
Решение (воркэраунд)
Ограничения центрального процессора (проблемы CPU)
Чтобы определить, связана ли низкая производительность виртуалки с ограничением центрального процессора, надо:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки
Проверьте командой load average загрузку. Если среднее значение нагрузки равно 1.00 , то физические ЦП (центральные процессоры) гипервизора ESXi/ESX полностью используются, а среднее значение нагрузки, равное 0.5, значит, что используются наполовину. Логика, думаю, вам понятна. Значение нагрузки, равное 2.00, означает, что система в целом переполнена (бегите в серверную с огнетушителем 👀)
Проверьте поле %READY на процент времени на момент, когда виртуальная машина была готова, но не смогла запуститься на физическом ЦП. При нормальных условиях эксплуатации это значение должно находиться в пределах 5%. Если это значение высокое, и виртуальная машина имеет плохую производительность, тогда проверьте ограничение центрального процессора:
Убедитесь, что на виртуальной машине не установлен предел ЦП.
Убедитесь, что на виртуальной машине не установлен пул ресурсов (Resource Pool).
Если среднее значение нагрузки слишком высокое и время ожидания не вызвано ограничением центрального процессора, тогда отрегулируйте нагрузку ЦП на хост. Чтобы настроить нагрузку на хост, выполните следующие шаги:
Увеличьте значение физического ограничения ЦП на хост
Или уменьшите виртуальное ограничение ЦП, выделенное хосту. Чтобы уменьшить это ограничение, сделайте:
Уменьшите общее количество ЦП, выделенных всем виртуальным машинам, работающих на узле ESX
Или уменьшите количество виртуальных машин, работающих на хосте (но это весьма грубый способ, как мы считаем)
Если Вы используете ESX 3.5, проверьте доступ к IRQ.
Переполнение памяти
Чтобы определить, связана ли низкая производительность с избыточностью памяти:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки.
Проверьте параметр MEM в первой строке вывода. Это значение отражает отношение запрошенной памяти к доступной, минус 1. Например:
Если виртуальным машинам требуется 4 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то справедливо соотношение 1:1. После вычитания 1 (из 1/1) поле MEM overcommit avg считывает 0. Вывод - избытка нет и не требуется дополнительной оперативной памяти.
Если виртуальным машинам требуется 6 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то есть соотношение 1,5:1. После вычитания 1 (из 1,5/1), поле overcommit avg МЭМ считывает 0,5. Объем оперативной памяти превышен на 50%, что означает, что требуется на 50% больше доступной оперативной памяти.
Если память перегружается, отрегулируйте нагрузку на хост. Чтобы настроить нагрузку на память, выполните следующие действия:
Увеличьте количество физической оперативной памяти на хосте
Или уменьшите объем оперативной памяти, выделенной виртуальным машинам. Для уменьшения объема выделенной оперативной памяти:
Уменьшите общий объем оперативной памяти, выделяемой всем виртуальным машинам на узле
Или уменьшите общее число виртуальных машин на узле.
Определите, являются ли виртуальные машины "раздувающимися" или/и заменяемыми. Для обнаружения раздувания или замены:
Запустите esxtop
Введите m для просмотра памяти
Введите f для управления колонками вывода (полями)
Выберите букву J в поле Memory Swap Statistics "Статистика раздувания памяти" (MCTL)
Посмотрите на значение MCTLSZ. MCTLSZ (MB)отображает объем физической памяти гостя, возвращаемой драйвером баллона (Memory Ballooning).
Введите f для управления колонками вывода (полями)
Выберите букву для статистики свопов памяти (SWAP STATS)
Посмотрите на значение SWCUR. SWCUR (MB) отображает текущее использование обмена.
Чтобы устранить эту проблему, убедитесь, что раздувание и/или замена не вызваны неправильно установленным пределом памяти
Период ожидания запоминающего устройства
Чтобы определить, связана ли низкая производительность с задержкой хранения данных:
Определите, связана ли проблема с локальным хранилищем. Если связана, то перенесите виртуальные машины в другое место хранения.
Уменьшите количество виртуальных машин на одно логическое устройство.
Найдите записи журнала в Windows guests, которые выглядят следующим образом: The device, DeviceScsiPort0, did not respond within the timeout period.
Используя esxtop, найдите высокое время задержки DAVG.
Определите максимальную пропускную способность ввода-вывода, которую можно получить с помощью команды iometer.
Сравните результаты iometer для виртуальной машины с результатами для физической машины, подключенной к тому же хранилищу.
Проверьте наличие конфликтного обращения к ресурсу SCSI.
Если вы используете ресурсы хранения iSCSI и группу данных jumbo, убедитесь, что все настроено правильно.
Если вы используете ресурсы хранения iSCSI и передачу по нескольким трактам с использованием программного инициатора iSCSI, убедитесь, что все настроено правильно.
При выявлении проблемы, связанной с хранением:
Убедитесь, что аппаратный массив устройства и платы HBA сертифицированы для ESX/ESXi.
Убедитесь, что BIOS физического сервера обновлена.
Убедитесь, что встроенное ПО вашего HBA-адаптера обновлено.
Убедитесь, что ESX может распознать правильный режим и политику пути для типа массива хранения SATP и выбора пути PSP.
Задержка сети
На производительность сети может сильно влиять производительность ЦП. Исключите проблему производительности ЦП перед исследованием сетевой задержки.
Чтобы определить, вызвана ли низкая производительность задержкой сети, выполните следующие действия:
Проверьте максимальную пропускную способность виртуальной машины с помощью инструмента Iperf.
При использовании Iperf измените размер окон TCP на 64 K. Производительность также зависит от этого значения. Чтобы изменить размер окон TCP:
На стороне сервера введите следующую команду: iperf –s
На стороне клиента введите следующую команду: iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M
Запустите Iperf с компьютера вне хоста ESXi/ESX. Сравните результаты с ожидаемыми, в зависимости от физической среды.
Выполните команду Iperf с другого компьютера вне хоста ESXi/ESX в той же VLAN на том же физическом коммутаторе. Если производительность хорошая, и проблему можно воспроизвести только на машине в другом географическом месте, то проблема связана с вашей сетевой средой.
Выполните команду Iperf между двумя виртуальными машинами на одном сервере ESX/portgroup/vswitch. Если результат хороший, можно исключить проблему с ЦП, памятью или хранилищем.
Если вы определяете параметры, которые ограничивают производительность системы в сети:
Если вы используете ресурсы хранения iSCSI и кадры jumbo, убедитесь, что все настроено правильно.
Если вы используете Network I/O Control,то убедитесь, что общие ресурсы и ограничения правильно настроены для вашего трафика.
Проверьте правильность настройки формирования траффика.