Что такое хорошая практика ведения журнала для распределенных задач?


14

У меня есть следующие настройки:

Создайте несколько рабочих, сделайте вычисление и завершите их после того, как вычисление выполнено.

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

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

PS: моя инфраструктура без сервера. Итак, сейчас я подключаюсь к (AWS) CloudWatch. Но, пожалуйста, ответьте на вопрос независимо от AWS и максимально подходя для установки без сервера.

Ответы:


12

«Без сервера» в основном означает, что у вас есть относительно простые микросервисы, как правило, небольшое веб-приложение или одна функция, которая автоматически подключается к интерфейсу REST. Применяются те же понятия, что и при использовании более традиционных веб-сервисов: обычно это некоторая смесь удаленных разработчиков syslog и ElasticSearch.

Сетевой или удаленный системный журнал существует уже давно и имеет достаточно надежный набор инструментов. Вам придется запустить центральный сервер (ы) системного журнала, но протокол очень прост, и на каждом языке есть чистые клиентские библиотеки, которые вы можете использовать для отправки журналов. Одной из распространенных проблем с удаленным системным журналом является то, что он традиционно основан на UDP. Это означает, что при большой нагрузке некоторые сообщения журнала могут быть потеряны. Это может быть полезно, помогая избежать каскадной перегрузки, но об этом нужно знать. Некоторые новые демоны syslog также поддерживают протокол на основе TCP, но поддержка клиентов менее унифицирована, поэтому просто сделайте свое исследование.

Более свежая, но очень популярная регистрация в ElasticSearch. Это в основном полезно из-за панели инструментов Kibana и Logstash takelit (часто называемых ELK, ElasticSearch + Logstash + Kibana). Amazon даже предлагает размещенный вариант ElasticSearch, что облегчает начало работы. ES использует относительно простой REST API, поэтому любой язык с HTTP-клиентом (читай: все) должен быть в порядке с регистрацией в ES, но убедитесь, что вы осторожны с блокировкой сетевых операций в случае частичных сбоев системы (т.е. убедитесь, что ваш приложение не застревает в вызове журнала, который никогда не преуспеет и не прекратит обслуживание пользовательских запросов).

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

На стороне «без сервера» вы, как правило, захотите интегрироваться с этими системами непосредственно на сетевом уровне, поэтому отправка данных журнала напрямую в syslog или ES из вашей службы / функции, а не запись в локальные файлы (хотя, может быть, эхо тоже для локальной отладки и разработки).


6

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

Да, использование нескольких файлов журнала одновременно является хорошей практикой.

Попытка объединить в единые бревна LOGFILE из нескольких рабочих в режиме реального времени будет поднимать проблемы:

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

Разделение лог-файлов (с использованием нескольких активных одновременно) - это метод, используемый некоторыми хостинг-провайдерами, предлагающими высокопроизводительные, масштабируемые централизованные службы ведения журналов. Например, при экспорте журналов в файлы Google StackDriver Logging создает несколько файлов журналов с разборкой. Из записей журнала в Google Cloud Storage :

Когда вы экспортируете журналы в хранилище Cloud Storage, Stackdriver Logging записывает набор файлов в корзину. Файлы организованы в иерархии каталогов по типу журнала и дате. Тип журнала может быть как простым именем, так syslogи составным именем appengine.googleapis.com/request_log. Если эти журналы были сохранены в сегменте с именем my-gcs-bucket, тогда каталоги были бы названы как в следующем примере:

my-gcs-bucket/syslog/YYYY/MM/DD/
my-gcs-bucket/appengine.googleapis.com/request_log/YYYY/MM/DD/

Одно ведро может содержать журналы из нескольких типов журналов.

Листовые каталоги ( DD/) содержат несколько файлов, каждый из которых содержит экспортированные записи журнала за период времени, указанный в имени файла. Файлы разделяются, а их имена заканчиваются номером шарда Snили An(n = 0, 1, 2, ...). Например, вот два файла, которые могут храниться в directory my-gcs-bucket/syslog/2015/01/13/:

08:00:00_08:59:59_S0.json
08:00:00_08:59:59_S1.json

Эти два файла вместе содержат syslogзаписи журнала для всех экземпляров в течение часа, начинающегося с 08:00 UTC. Чтобы получить все записи журнала, необходимо прочитать все фрагменты за каждый период времени - в этом случае фрагменты файла 0 и 1. Количество записанных фрагментов файла может изменяться за каждый период времени в зависимости от объема записей журнала.

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

Наконец, если объединение файлов журналов в режиме реального времени не является обязательным, наличие нескольких файлов журналов может помочь в автономном управлении журналами:

  • Простота разработки прогрессивных схем резервного копирования, сжатия, архивирования и возможного удаления
  • возможна параллельная обработка нескольких наборов журналов (файлов журналов), уменьшая / избегая узких мест
  • нет необходимости разбивать файл и переписывать
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.