Назад | Перейти на главную страницу

Методы мониторинга и предупреждения о проблемах с данными при работе со сложными зависимостями

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

Например;

Представьте, что «командные заказы» обнаруживают проблему с БД (нагрузка, задержка и т. Д.) - их система мониторинга предупреждает инженера, который начинает исследовать проблему с БД.

Между тем, «Team Traffic» также были предупреждены, поскольку они видят всплеск плохих ответов. Они начинают расследование и быстро понимают, что проблема связана с сервисом «Командный заказ», и поднимают заявку на «Командный заказ».

После всего этого «Team Warehouse» получает неверные данные. Их мониторинг DW предупреждает их об этой разнице, поэтому они начинают искать первопричину.

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

Важным моментом является то, что все три команды используют разные системы мониторинга и оповещения; Team Orders отслеживает проблемы с сервером базы данных, а Team Warehouse ищет различия в количестве записей.

Есть и другие подходы; оповещение только в верхней части конвейера (блокирование эскалации вниз по потоку) или оповещение в нижней части конвейера для вышестоящих систем.

Есть ли какие-либо передовые методы, официальные документы или инженерные решения, которые я могу изучить, чтобы понять различные способы оповещения и эскалации проблем с данными в нескольких группах поддержки / поддержки?

Настоятельно рекомендую "Практика администрирования облачных систем", в которой подробно рассматриваются некоторые из них. Здесь у нас есть 3 уровня мониторинга

  1. От конца до конца (о, черт возьми, что-то не так)
  2. Для каждой службы / API (о, черт возьми, член кластера SQL не работает, API отвечает медленно или с чем-то другим, кроме HTTP-кода 200/300 и т. Д.)
  3. APM - какой фрагмент кода и т. Д. Работает медленно, количество ошибок для определенных служб и т. Д.

Эти + журналы дают нам большую часть того, что нам нужно знать, что происходит, обычно у нас есть один человек, ответственный за то, чтобы видеть, что проблема исправлена ​​- координирует исправление, но они НЕ выполняют техническую работу, которая передана на откуп другим. Задача координатора - следить за тем, чтобы мы не наступали друг другу на ноги при устранении проблемы.