Вебхуки на сервері для самостійного керування

Мова: Українська
Цю статтю перекладено з англійської за допомогою ШІ, тому вона може містити помилки. Ваші відгуки допоможуть нам її покращити.

У цій статті описано, як сервер для самостійного керування виконує автоматизацію вебхуків.

Виконання

Коли ви налаштовуєте вебхук, ActivityInfo надсилатиме сповіщення на вказану вами URL-адресу щоразу, коли запис (створений, оновлений або видалений), що відповідає тригеру вашої автоматизації, змінюється.

Коли спрацьовує вебхук, наш сервер надсилає дані на вашу URL-адресу і чекає на відповідь не більше 15 секунд.

  • Успішно: якщо ваш сервер відповідає статусом успішного виконання (будь-який код 2xx, наприклад 200 OK) протягом цього часу, процес позначається як завершений. Будь-яке попереднє повідомлення про помилку, збережене для цієї автоматизації, буде видалено.

  • Не вдалося: спроба вважається невдалою, якщо ваш сервер:

  • Відповідає довше 15 секунд (тайм-аут).

  • Повертає статус помилки (наприклад, 404 Not Found або 500 Server Error).

  • Недоступний (наприклад, збій DNS або відмова у з'єднанні).

  • Відповідає перенаправленням (див. нижче).

Перенаправлення не відстежуються

Зверніть увагу: ActivityInfo не відстежує перенаправлення під час надсилання вебхуків.

Якщо ваш сервер відповідає статусом перенаправлення (наприклад, 301, 302 або 307), це буде розцінено як невдача, навіть якщо новий Location є дійсним. Це запустить процес повторної спроби, описаний вище.

Будь ласка, переконайтеся, що ваш URL вебхука є кінцевою, прямою кінцевою точкою і не вимагає перенаправлення.

Процес повторної спроби

Якщо перша спроба не вдалася, система не здасться одразу. Вона спробує ще тричі, тобто всього буде чотири спроби.

Період очікування між повторними спробами збільшується, даючи вашому серверу час на відновлення:

  • 1-а невдача: очікування 10 секунд перед 2-ю спробою.
  • 2-а невдача: очікування 30 секунд перед 3-ю спробою.
  • 3-я невдача: очікування 90 секунд перед 4-ю (і останньою) спробою.
  • 4-а невдача: якщо остання спроба не вдасться, система припинить спроби.

Що реєструється

ActivityInfo відстежує останню помилку, яка відображається в інтерфейсі користувача.

  • У разі успіху: будь-яке попереднє повідомлення про помилку, збережене для цієї автоматизації, видаляється.
  • У разі невдачі (наприклад, помилка 404): якщо ваш сервер відповідає помилкою, код відповіді та повідомлення зберігаються (наприклад, 404,Not Found).
  • У разі невдачі (наприклад, тайм-аут): якщо виникає виняток (наприклад, 15-секундний тайм-аут), повідомлення про виняток зберігається.

Більш детальна інформація, включаючи помилки, які згодом вирішуються при повторній спробі, реєструється в системних журналах.

  • Успішний вебхук: для кожної успішної спроби реєструється повідомлення, що містить код повернення (наприклад, Automation: [My Webhook] -> hook successful with return code: 200).
  • Запит вебхука: для кожної спроби створюється запис у журналі, що показує URL-адресу та код результату (наприклад, Automation: Webhook request to https://example.com/hook result code is 404).
  • Невдалий вебхук (помилка сервера): реєструється, коли з'єднання не вдається через помилку сервера (наприклад, http connection failure while sending webhook: 404,Not Found).
  • Невдалий вебхук (виняток): реєструється, коли з'єднання не вдається через виняток (наприклад, exception occurred while sending webhook: java.net.SocketTimeoutException: Read timed out).
  • Внутрішні помилки: серйозні помилки реєструються, якщо весь процес автоматизації несподівано завершується збоєм.

Системні журнали можна знайти в каталозі даних ActivityInfo, зазвичай /opt/activityinfo/logs на платформах Unix або C:\ActivityInfoData\logs на Windows Server.

При розгортанні ActivityInfo як образу docker, ви можете отримати доступ до системних журналів за допомогою наступної команди:

docker logs <container_name_or_id>
Наступний елемент
Сканування на шкідливе ПЗ за допомогою ClamAV