Как проверить доступность api

Проверить доступность серверов на c#

Имеется несколько компьютеров с 3g модемами, на них должен быть запущен apache(порт 8080). Как проверить что apache запущен на каждом из них. Visual studio 2013 c#.

Отслеживать
задан 15 мар 2016 в 17:17
Alexandr Samodurov Alexandr Samodurov
165 1 1 серебряный знак 14 14 бронзовых знаков

WAN IP-адреса статические? Порты с внешки доступны (проброшены через NAT и брендмауэр, если он есть)?

15 мар 2016 в 17:31

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Попробуйте (для каждого IP-адреса)

WebRequest request = WebRequest.Create("http://A.B.C.D:8080/"); HttpWebResponse response = (HttpWebResponse)request.GetResponse(); if (response == null || response.StatusCode != HttpStatusCode.OK) < // failed >response.Close();

Если нет гарантий, что адреса буду всегда одни и те же, можно использовать какую-нибудь службу DDNS. Тогда вместо IP-адресов можно использовать FQDN.

Отслеживать
ответ дан 15 мар 2016 в 18:08
Aziz Kabyshev Aziz Kabyshev
176 5 5 бронзовых знаков
Есть небольшая проблема. Вот так он видит m01:8080, а вот так нет m01.company.internal:8080
16 мар 2016 в 19:50

Что на выходе ping m01.company.internal и nslookup m01.company.internal (в cmd )? Должен быть актуальный IP-адрес. Сравните с выводом ping m01 и nslookup m01

16 мар 2016 в 19:55

Нашли проблему на сервере. Но появился еще один вопрос. Если опрашиваемых сервером много, то есть смысл выполнять такие проверки в отдельных потоках? И такие проверки все-равно выполняются очень долго, можно ли как-то ускорить процесс?

16 мар 2016 в 20:04

Разумеется, но есть тонкости. Например, может не хватать свободных сокетов на клиенте. Придется менять HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort и/или HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPTimedWaitDelay

Правильный мониторинг API: метрики и лучшие практики

Применение API в разработке ПО сыграло большую роль в создании современных приложений и повлияло на их общую оценку и опыт конечных пользователей. В этой статье Екатерина Саяпина, Product Owner личного кабинета платформы МТС Exolve, рассказывает про правильные подходы при отслеживании работы API. Подробности — под катом.

Доходы бизнеса возросли, что подтверждают результаты опроса более 40 000 разработчиков из отчёта Postman о состоянии API. 43% заявили, что использование API приносит более четверти общего дохода их компаниям. В то же время важно контролировать функционирование программных интерфейсов и проводить качественный мониторинг жизненного цикла, чтобы убедиться в корректности их работы. Такой анализ поможет определить проблемные места и обнаружить ошибки до того, как продукт выйдет на рынок.

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

Для чего отслеживать API

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

Вот несколько преимуществ такого подхода.

1. Обеспечение успешности транзакций API

API создаёт в современных программах необходимый уровень абстракции между микросервисами. Эта архитектура требует использования сложных многоэтапных взаимодействий API со сторонними интеграциями.

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

2. Проверка данных ответа и обработка ошибок

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

3. Выявление изменённых конечных точек и ошибок сторонних интеграций

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

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

Мониторинг API помогает выявлять и решать подобные проблемы в режиме реального времени. Это эффективный инструмент оптимизации служб в организации или проекте.

Какие ключевые метрики API отслеживать

1. Доступность или время безотказной работы (Uptime)

Эта метрика — стандарт измерения доступности вашего продукта, она обычно входит в SLA (соглашение об уровне обслуживания) при заключении договора между поставщиком услуги и заказчиком. Время безотказной работы API измеряют в процентах или в некоторых случаях как среднюю продолжительность простоя в год. В среде разработчиков часто можно услышать, что показатель определяется «девятками».

Рассмотрим на примере таблицы:

Доступность, %

Время простоя в год

99,9% («три девятки»)

99,99% («четыре девятки»)

99,999% («пять девяток»)

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

2. Использование процессора и памяти (CPU and memory usage)

При локальной отладке API вы увидите загрузку процессора системой через диспетчер задач в Windows (или монитор активности на Mac).

Однако на сервере это сделать проблематичнее. Высокая загрузка ЦП или памяти хост-сервера API обычно указывает на перегрузку виртуальной машины, контейнера или узла шлюза API, что замедляет его производительность.

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

3. Спрос на API (API Consumption)

Спрос на API измеряется количеством запросов в минуту или секунду (RPM). Эту метрику производительности часто используют при сравнении серверов HTTP или баз данных. Зная количество одновременных обращений пользователей, скорость ответа на них и среднее время размышления, вы легко сможете вычислить количество запросов в минуту по формуле:

r = n ÷ (T_response + T_think)

Например, вы увидели, что после запуска ПО для интернет-ресурса среднее количество одновременных пользователей составило 2 800. Это зависит от числа людей, зарегистрировавшихся на сайте, их поведения и времени, которое они выбирают для отправки запросов.

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

n = 2 800 одновременных пользователей
T_response = 1 (среднее время ответа на запрос — одна секунда)
T_think = 3 (среднее время размышления — три секунды)

Расчёт количества запросов в секунду:
г = 2 800 ÷ (1 + 3) = 700

Следовательно, количество запросов в секунду равно 700, а количество запросов в минуту — 42 000.

4. Время ответа API (API Response Time)

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

Высокопроизводительными API считаются, если среднее время отклика составляет от 0,1 до 1 секунды. При такой скорости человек, использующий вашу программу, не увидит каких-либо перебоев в её работе. Спустя одну-две секунды задержка уже заметна, а через пять секунд вы рискуете потерять пользователя приложения.

Например, у вас может быть конечная точка POST /checkout, задержка которой постепенно увеличивается из-за роста объёма таблицы SQL и её неправильной индексации. Однако из-за небольшого количества вызовов POST /checkout эта проблема маскируется вашей конечной точкой GET /items, которая вызывается гораздо чаще, чем checkout. Аналогично, если у вас GraphQL, вам нужно посмотреть среднюю задержку на операцию GraphQL.

5. Частота ошибок (Error rate)

Error rate показывает количество ошибок в минуту или секунду. Он позволяет получить точную информацию об отслеживании проблем в конкретных конечных точках API. Это количество вызовов API в минуту с кодами состояния, отличными от 200, и оно имеет решающее значение для измерения того, насколько ваш API некорректно работает и подвержен ошибкам. Поэтому чем меньше значение показателя, тем лучше. Все коды состояния можно посмотреть в Википедии.

6. Количество уникальных пользователей API (Unique API Consumers)

Эта API-метрика помогает команде разработчиков получить представление об общем росте продукта и привлечении новых клиентов на основе числа активных пользователей за месяц. Быстрое снижение показателей в часы пик работы может указывать на проблему с платформой приложений.

Важно измерять API DAU (ежедневные активные пользователи) и веб-DAU, если внедрили такой формат. Мы говорим о тех случаях, когда ваша команда создаёт продукт и в виде API, и в виде веб-платформы. Если веб-DAU растёт намного быстрее API DAU, это может означать негерметичную воронку во время интеграции. Это особенно актуально, когда основной продукт компании — API, как у МТС Exolve.

7. Рост процента использования API (API usage growth)

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

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

Практики мониторинга API

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

Мониторинг поддерживающей инфраструктуры. Не все проблемы с API касаются работоспособности и доступности его конечных точек, некоторые возникают в других частях стека. Например, недостаточно подготовленная база данных или сбой в сети могут приводить к задержке и ошибкам.
Периодический пересмотр настроек мониторинга: потребности бизнеса постоянно меняются, как и технологии, которые их поддерживают. Поэтому важно регулярно обращаться к своей стратегии мониторинга, чтобы гарантировать её эффективность и актуальность.
Отправка автоматических оповещений клиентам через мессенджеры или SMS API от Exolve. Стратегия мониторинга API не будет эффективной, если разработчикам придётся вручную проверять его состояние. Поэтому руководителю следует использовать возможности оповещения и интеграцию с инструментами коммуникации, чтобы команды автоматически получали уведомления о соответствующих действиях.
Ищите исторические тренды. Это поможет повышать производительность, анализируя тесты с течением времени, и выявлять тенденции при возникновении проблем.
Запускайте мониторинг с правильной частотой. Определите, как часто будете выполнять тесты. Ваш API критически важен и требует ежеминутного мониторинга? Или достаточно запускать тесты каждые 60 минут или 24 часа?

Инструменты мониторинга

Все описанные показатели и метрики можно просмотреть и проанализировать при помощи любой из существующих на сегодняшний день APM-систем (Application Performance Monitoring).

Вот несколько решений для мониторинга и тестирования API:

AWS Cloudwatch
Postman (статья на русском о тестировании API при помощи Postman)
AppDynamics
Datadog
SigNoz (в открытом доступе)
New Relic
Prometheus (в открытом доступе)
Sauce Labs
Graphite (в открытом доступе)
SmartBear

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

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

управление разработкой
api
разработка по
разработка приложений

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

Предлагаем посмотреть и оценить, как работает Ping-Admin.Com, воспользовавшись бесплатной проверкой вашего сайта из разных уголков мира. Введя адрес или IP своего сайта (конкретной страницы на сайте), вы сможете увидеть, как будет выглядеть проверяемый ресурс с наших точек мониторинга.

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

Регистрация
Наши возможности
Наши точки мониторинга
Новости
Тарифы и способы оплаты
Акции и скидки

Бесплатные проверки:
— Детальная разовая проверка сайта
— Ping
— Проверка обратных ссылок
— Проверка ИКС
— Регулярная проверка сайта

Рейтинг хостингов
Рейтинг фотохостингов

API

Реклама на сайте
Партнёрская программа
Наши логотипы

Поддержка
Частые вопросы
Форум

© Ping-Admin.Com 2009–2024.
Концепция, программирование и дизайн проекта — «Седжин».
Ping-Admin.Com — проверка работоспособности сайта.

Проверка доступности Application Insights

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

Вы можете настроить тесты доступности для любой конечной точки HTTP или HTTPS, доступной из Интернета. Вам не нужно вносить никаких изменений в тестируемый веб-сайт. На самом деле даже не обязательно быть владельцем сайта. Можно проверить доступность интерфейса REST API, от которого зависит служба.

Типы тестов

Существует четыре вида тестов доступности.

Стандартный тест. Этот единый тест запроса аналогичен проверке связи с URL-адресом. Он включает срок действия TLS/SSL-сертификата, упреждающее время существования проверка, команду HTTP-запроса (например, GET HEAD или POST ), пользовательские заголовки и пользовательские данные, связанные с HTTP-запросом.
Тесты доступности пользовательской трассировки. Если вы решили создать пользовательское приложение для выполнения тестов доступности, используйте метод TrackAvailability() для отправки результатов в Application Insights.
Классические тесты (старые версии тестов доступности)
- Проверка связи по URL-адресу. Этот тест можно создать с помощью портал Azure, чтобы проверить, отвечает ли конечная точка и измеряет производительность, связанную с этим ответом. Вы также можете задать настраиваемые критерии успеха с помощью расширенных функций, таких как синтаксический анализ зависимых запросов и разрешение на повторные попытки.
- Многоэтапный веб-тест (не рекомендуется) — вы можете воспроизвести эту запись последовательности веб-запросов для тестирования более сложных сценариев. Многоэтапные веб-тесты создаются в Visual Studio Enterprise и загружаются на портал для выполнения.
Старые классические тесты, тест ping URL-адресов и многоэтапный веб-тест используют инфраструктуру DNS общедоступного Интернета для разрешения доменных имен тестируемых конечных точек. Если вы используете частный DNS, необходимо убедиться в том, что серверы общедоступных доменных имен могут разрешать каждое доменное имя теста. Если это невозможно, вместо них можно использовать настраиваемые тесты TrackAvailability.

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

Тесты доступности хранятся в зашифрованном виде в соответствии с политиками шифрования данных Azure при хранении .

Устранение неполадок

Недавно мы включили TLS 1.3 в тестах доступности. Если в результате отображаются новые сообщения об ошибках, убедитесь, что клиенты, работающие в Windows Server 2022 с включенным протоколом TLS 1.3, могут подключаться к конечной точке. Если этого не удается сделать, вы можете временно отключить TLS 1.3 в конечной точке, чтобы тесты доступности вернулись к более старым версиям TLS.
Дополнительные сведения см. в статье по устранению неполадок проверка. См. специальные инструкции по устранению неполадок.

Часто задаваемые вопросы

В этом разделы приводятся ответы на часто задаваемые вопросы.

Можно ли выполнять веб-тесты доступности на сервере в интрасети?

Наши веб-тесты выполняются в точках подключения, которые распределены по всему миру. Есть два решения.
- Дверь брандмауэра. Разрешите запросы к серверу из длинного и изменяемого списка агентов веб-тестирования.
- Пользовательский код: напишите собственный код для отправки периодических запросов на сервер из интрасети. Для этой цели можно выполнять веб-тесты Visual Studio. Тестировщик может отправить результаты приложению Аналитика с помощью TrackAvailability() API.
Следующие шаги
- Оповещения о доступности
- Стандартные тесты
- Создание и запуск пользовательских тестов доступности с помощью Функций Azure
- Веб-тесты шаблона Azure Resource Manager
Похожие публикации: