Методы мониторинга и оповещения о проблемах данных при работе со сложными зависимостями
В этом гипотетическом примере у нас есть поток данных между несколькими группами инженеров в компании электронной коммерции. Эти команды предоставляют услуги, производят данные, и потребляют данные в разных точках потока.
Например;
- «Team Orders» поддерживает базу данных заказов и интерфейсы.
- «Team Traffic» генерирует данные веб-трафика
- «Team Warehouse» поддерживает данные хранилище
- «Командный трафик» зависит от «Службы командного заказа для получения данных о заказах и связывания их с веб-трафиком»
- «Командный склад» зависит от «данных командного трафика для построения таблиц DW»
Представьте себе, что «командные заказы» обнаруживает проблему с базой данных (нагрузка, задержка и т. д.) - их система мониторинга предупреждает инженера, который начинает исследовать проблему с базой данных.
Тем временем, «командный трафик» также был предупрежден, поскольку они видят всплеск плохих ответов. Они начинают расследование и быстро понимают, что проблема связана с «службой командных заказов, и поднимите заявку на «Командный порядок»
. После всего этого «Командный склад» получает неверные данные. Их мониторинг DW предупреждает их об этой разнице, поэтому они начинают искать первопричину.
Проблема в том, что теперь у нас есть как минимум три инженера, исследующие ту же проблему, и они могут даже не знать, что другие команды делают то же самое. вещь.
Важным моментом является то, что все три группы используют разные системы мониторинга и оповещения; Team Orders отслеживает проблемы с сервером баз данных, а Team Warehouse ищет различия в количестве записей.
Есть и другие подходы; оповещение только наверху конвейера (блокирование эскалации вниз по потоку) или оповещение внизу конвейера для вышестоящих систем.
Существуют ли какие-либо передовые методы, официальные документы, или инженерные решения, которые я могу изучить, чтобы понять различные способы оповещения и эскалации проблем с данными в нескольких группах поддержки / поддержки?
Настоятельно рекомендую "Практика администрирования облачных систем", в которой подробно рассматриваются некоторые из них. Здесь у нас есть 3 уровня мониторинга
- От конца до конца (о, черт возьми, что-то не так)
- Для каждой службы / API (о, черт возьми, член кластера SQL не работает, API отвечает медленно или с чем-то другим, кроме 200/300 HTTP-код и т. Д.)
- APM - Какой фрагмент кода и т. Д. Работает медленно, количество ошибок для определенных служб и т. Д.
Эти + журналы дают нам большую часть того, что нам нужно знать, что происходит, обычно у нас есть один лицо, ответственное за то, чтобы убедиться, что проблема устранена - координирует исправление, но НЕ выполняет техническую работу, которая передается другим лицам. Работа координатора заключается в том, чтобы при устранении проблемы мы не наступали друг другу на ноги.