Основной принцип и использование цепочки вызовов микросервиса

распределенный

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

Если мониторинг не применяется:

  • Сервис опубликован в сети, откуда вы знаете, что все в норме
  • Сообщается о большом количестве ошибок, где они произошли и кто является причиной
  • Ошибки ручной настройки, ночные расследования, труд и деньги
  • Проблемы с базой данных, можете ли вы получить представление, прежде чем что-то пойдет не так?

Все, что может пойти не так, пойдет не так, микросервисы требуют мониторинга приложений — закон Конвея

Как обнаружить проблемы на ранней стадии?

  • Практика 1: Чтобы улучшить, вы должны сначала уметь измерять. Нужно дать разработчикам линейку для измерения обратной связи

  • Практика 2: Кто строит, кто разрешает, кто контролирует. Эксплуатация и техническое обслуживание не знают контекста разработки и имеют ограниченное понимание.Если разработчики помогут себе, они смогут лучше улучшить систему

Принцип мониторинга цепочки вызовов

В 2010 году Google выпустила статью Даппера, вы можете прочитать статью.Бумажный адрес

image-20190413144942473

  • traceid: некоторые из них будут называться requestNo, traceid во всей цепочке вызовов одинаков, так что все взаимодействующие запросы и ответы между системами можно найти через traceid
  • spanid: есть только traceid, и невозможно точно узнать, какая служба вызывается первой, а какая позже.Комбинация spanid и parentSpanid может быть выражена в виде древовидной связи вызова.

Когда система дает сбой:

  1. Соберите идентификаторы трассировки в коллекцию, включая запросы и ответы.
  2. Восстановить вызов дерева через spanid и parentSpanId
  3. Идентифицируйте и помечайте узлы с тайм-аутами и ошибками
  4. Отображение приведенной выше информации и информации об узле ошибки

Теперь система мониторинга цепочки звонков с открытым исходным кодом:

  • Cat, Meituan Dianping имеет открытый исходный код, прототип и концепция основаны на системе клиентских лицензий eBay, а наша компания основана на Cat.GitHub.com/comments/rubbing…
  • Zipkin: реализация с открытым исходным кодом, основанная на документе Google Dapper,zipkin.io/

Кот Мэйтуань Дяньпин

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

  • Подробные отчеты помогают понять организацию системы и обзор со всех сторон.
  • Для быстрого обнаружения и решения проблем с корневыми нотами
  • Помогите взрастить интернет-людей: осознание DevOPS автономии и самопомощи, осознание превосходного качества
  • Найдите технические долги, красные и черные списки, внесите системы с хорошей производительностью в красный список, а системы с низкой производительностью в черный список и попросите персонал оптимизировать

использовать

Показанный здесь основан на Cat с некоторыми модификациями.

сообщение об ошибке
  1. Быстро найти аномалии минутного уровня

image-20190413150806244

  1. Нажмите, чтобы просмотреть тип и конкретную информацию об исключении.

image-20190413151045242

  1. Щелкните сводку исключений, чтобы просмотреть полную цепочку вызовов исключения, щелкните время возникновения, вы увидите цепочку вызовов метода исключения.

image-20190413151142727

Относительно использования диска с сообщениями об ошибках, пожалуйста, обратитесь к моей предыдущей записи:Помните простой опыт устранения неполадок

анализ производительности
  1. Просматривайте производительность скрытых точек, среднее время вызова, максимальное время, 95% времени вызова и т. д., вы можете быстро определить колебания производительности.

image-20190413151457440

  1. Проанализируйте звонки в определенный момент.

image-20190413151829265

  1. Щелкните вызов в определенный момент, вы можете увидеть статистику вызовов на уровне минут, а затем отследить вызов в цепочке вызовов приведенного выше анализа ошибок.

image-20190413152021381

Статистика событий
  1. Перейдите к точке обслуживания в приведенном выше анализе производительности, чтобы узнать, сколько раз вызываются определенные службы.

image-20190413152544715

служебные отношения

Убедитесь, что система была вызвана этими системами, и мы вызвали эти системы

image-20190413152756538

Для услуги вы можете увидеть, кто ее вызывал

image-20190413152914032

Рынок баз данных

Посмотреть, сколько раз вызывается тот или иной sql, количество сбоев, уровень доступности, среднее время и т. д.

image-20190413153059465

трендовый рынок

Настройте индикаторы той системы, которую хотите видеть, и вновь созданные индикаторы будут размещены в личной панели

image-20190413153307494

статус службы

Просмотр информации о хосте, ЦП, памяти, сети, JVM, пуле потоков, диске и др. Сама Cat не подходит для этой информации мониторинга, и другие системы также могут быть выбраны для мониторинга хоста.

image-20190413153352672

Иногда ошибки могут возникать и при проблемах с диском, так что обратите внимание и на это.

Производственная практика

На сайте github проекта cat он сделал несколько интегрированных скрытых точек, адрес интеграции:GitHub.com/comments/rubbing…

Похороненный:

  • При переходе между процессами должна передаваться контекстная информация, такая как вызовы Http, а информация о вызове может быть помещена в заголовок Http.
  • Скрытые точки Cat навязчивы. Если вы не хотите вторгаться в код, вы можете сделать некоторые спрятанные точки на основе АОП и аннотаций.

развертывать:

  • В качестве кластеров рекомендуется использовать физические машины.
  • Если вы храните данные в течение длительного времени, вы можете использовать HDFS.

Наконец

В основном рассказывалось о том, зачем нужен мониторинг цепочки вызовов и преимущества мониторинга цепочки вызовов, кратко объяснялся принцип мониторинга цепочки вызовов и, наконец, демонстрировалось использование системы цепочки вызовов на базе Cat.

Ссылаться на