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

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

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

Сбои в распределенных системах редко происходят из-за одного единственного события, сгенерированного каким-либо конкретным компонентом. Любой сбой обычно может включать в себя несколько возможных триггеров от одного или нескольких компонентов сильно разрозненных компонентов в системе. Таким образом, простое рассмотрение точки отказа может не дать правильного понимания причины отказа. Таким образом, для того, чтобы добраться до первопричины, необходимо:

  1. Проанализируйте симптом на детальном уровне.
  2. Отслеживайте жизненный цикл запроса в различных компонентах системы.
  3. Проанализируйте взаимодействие между различными компонентами.

В этой статье мы обсудим, что такое логи, метрики и трейсы и какую роль они играют в мониторинге системы.

ЖУРНАЛЫ

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

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

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

  1. Чрезмерное ведение журналов может иметь негативные последствия, поскольку может привести к увеличению затрат на хранение и снижению эффективности поиска в журналах. Поэтому становится важным решить, какие данные нам нужно регистрировать, а какие нет.
  2. Журналы должны содержать всю контекстуальную информацию, которая может дать некоторое представление о событии.
  3. Ведение журнала всегда должно быть асинхронным и не должно блокировать поток обработки запросов.
  4. При отправке данных в журналы убедитесь, что важные/конфиденциальные данные не были отправлены или правильно замаскированы перед отправкой.
  5. Большинство данных журнала событий актуальны в течение более короткого периода времени, в отличие от аналитических данных, которые необходимы для более длительного выполнения, поэтому для журналов может применяться политика архивирования для повышения эффективности систем ведения журналов.

ПОКАЗАТЕЛИ

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

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

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

Метрика обычно состоит из следующих полей:

  1. Название показателя
  2. Отметка времени
  3. Этикетки

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

ОТСЛЕЖИВАНИЕ

Хотя метрики и журналы дают хорошее представление о системе, они ограничены одной системой/службой, и становится трудно понять что-либо еще, кроме того, что происходит внутри конкретной системы. Таким образом, создается вариант использования другого мощного инструмента, называемого трассировкой.

Трассировка дает возможность отслеживать судьбу запроса в течение его жизненного цикла в различных компонентах системы.

Распределенная трассировка — это метод, который решает проблему обеспечения видимости времени жизни запроса в нескольких системах.

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

Трассировка помогает командам определить путь запросов через различные службы и понять поведение запроса на различных этапах потока. Таким образом, мотивация его отслеживания для определения конкретных точек в приложении, прокси-сервере, промежуточном программном обеспечении, библиотеке, базе данных, кеше и т. д., чтобы выяснить:

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

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

На приведенной выше диаграмме запрос начался с адреса Src и закончился с адресатом. Общее время перехода от src к dest составило 500 мс. Если поток расширен, это дает представление о том, что 500 мс были потрачены на разные промежутки, например. 50 мс для достижения B и 400 мс для достижения C, а затем еще 50 мс для достижения пункта назначения. Таким образом, трассировка может быть расширена, чтобы получить подробные сведения о каждом диапазоне и проанализировать полный поток запросов от начала до конца в системе. Это дает возможность идентифицировать и указать источник, в котором увеличилась задержка или использование ресурсов.

Zipkin и Jaeger — два самых популярных решения для распределенной трассировки с открытым исходным кодом, совместимые с OpenTracing. (OpenTracing — это независимые от поставщика спецификации и инструментальные библиотеки для распределенных API-интерфейсов трассировки.)

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

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

Заключение

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

Предоставьте любые отзывы, разъяснения или улучшения в разделе комментариев. Если вы хотите обсудить какую-либо тему дизайна, добавьте ее в раздел комментариев.

Удачного обучения…