Формат ответа проверки работоспособности для HTTP API
4 июня 2023 г.Я продолжаю знакомиться с HTTP API, читая соответствующий запрос на комментарии. На этот раз я прочитал Формат ответа проверки работоспособности для HTTP API по предложению Стефано Фаго. В этом посте я хотел бы подвести итог прочитанному.
Обратите внимание, что это черновик. Более того, он бездействовал почти два года и, таким образом, автоматически истек. Тем не менее, он наиболее близок к спецификации проверки работоспособности и поэтому заслуживает уважения.
Пример визуализации данных
Несмотря на то, что это не длинное чтение, оно немного "сухое". К счастью, в спецификации есть образец JSON. Я скопировал его в PlantUML, и вуаля, он показывает его визуальное представление:
Давайте рассмотрим предложенную структуру поэлементно.
Корневой объект
В простейшем случае ответ представляет собой объект JSON с обязательным свойством status:
Значения могут быть:
* pass для работоспособного статуса. Значение также может быть ok (для NodeJS) и up (для Spring Boot) для учета существующих библиотек проверки работоспособности. Код состояния HTTP должен находиться в диапазоне от 2xx до 3xx.
* warn для работоспособного состояния, но с проблемами в том же диапазоне состояний HTTP.
* fail для обозначения неработоспособного состояния. Возможные альтернативные значения включают error (NodeJS) и down (Spring Boot). Код состояния HTTP должен находиться в диапазоне от 4xx до 5xx.
Можно добавить дополнительные необязательные значения:
версия: общедоступная версия службы .
releaseId: внутренняя версия службы. Например,версиябудет увеличена для несовместимых изменений, аreleaseIdможет быть хэшем фиксации или семантической версией.serviceId: уникальный идентификатор службыописание: говорит само за себязаметки: массив неструктурированных заметоквывод: простое сообщение об ошибке в случаеpassилиwarn. Поле следует оставить пустым дляpass.
Объекты links
Объект links состоит из пар объектов. Значения — это URI, а ключи могут быть URI или общими/зарегистрированными: см. RFC5988. общие значения, например,, self.
Объекты checks
Ключи объектов checks состоят из двух терминов, разделенных двоеточием, имени компонента и имени измерения. Последнее может быть:
* Предустановленное значение: использование, responseTime, соединения или время безотказной работы.
* Стандартный термин из известного источника, например,, IANA, microformat.org и т. д.
* URI
Значения состоят из одного из следующих ключей:
* componentId: уникальный идентификатор этого компонента
* тип компонента:
* Предустановленное значение, компонент, хранилище данных или система.
* Стандартный термин из известного источника, например,, IANA, microformat.org и т. д.
* URI
* observedValue: любое допустимое значение JSON.
* observedUnit: единица измерения
* status: как статус родительского объекта, но только для этого компонента
* affectedEndpoints: если компонент не является pass, перечисляются все затронутые конечные точки.
* время: дата-время наблюдения в формате ISO8601.
* output: как вывод родительского объекта, но только для этого компонента
* ссылки: см. предыдущий раздел
* Любое другое нестандартное значение
Я попытался реализовать описанное выше с помощью Spring Boot, используя собственный HealthIndicator. Вот лучшее, что я смог придумать:
Текущая структура ответа JSON должна быть (легко?) настраиваемой. Вам нужно будет создать свою конечную точку. Я надеюсь, что команда Spring Boot предоставит возможность создать совместимую структуру.
Заключение
Предварительный проект Healthcheck IETF — это отличная инициатива по стандартизации проверок работоспособности в отрасли. Это позволит инструментам мониторинга полагаться на статус HTTP и тело ответа без специальной настройки для каждой службы.
К сожалению, срок действия черновика истек из-за отсутствия активности. Однако я бы хотел, чтобы его возродили.
Дальше:
* API проверки работоспособности * "Привод Spring Boot: работоспособность"
:::информация Первоначально опубликовано на странице Знаток Java, 28 мая 2023 г.
:::
Оригинал