Яка хороша практика ведення журналів для розподілених завдань?

У мене є наступне налаштування:

Створіть декілька працівників, зробіть обчислення та припиніть їх після обчислення.

Отже, кожен раз, коли це буде інший екземпляр, який виконує завдання, тому кожен хост матиме власний файл журналу, це призведе до величезного списку файлів.

Це хороша практика? Якщо ні, що було б кращим способом реєстрації обробки завдань у цьому конкретному випадку використання?

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

"Без сервера" здебільшого означає, що у вас є відносно прості мікросервіси, як правило, лише невеликий веб-сервер або одна функція, яка автоматично підключається до переднього інтернету REST. Ті самі поняття застосовуються, як і для традиційних веб-сервісів: зазвичай це поєднання віддалених системних журналів та ElasticSearch.

Мережевий або віддалений системний журнал існує вже давно і навколо нього є досить надійний набір інструментів. Вам доведеться запустити центральний сервер syslog, але протокол дуже простий і на кожному мові є чисті бібліотеки клієнтів, які ви можете використовувати для надсилання журналів. Одна поширена проблема віддаленого syslog - це те, що він традиційно базується на UDP. Це означає, що при великому навантаженні деякі повідомлення журналу можуть бути втрачені. Це може бути хорошою справою, допомагаючи уникнути каскадного перевантаження, але це щось, що слід пам’ятати. Деякі нові демони syslog також підтримують протокол на основі TCP, але підтримка клієнтів менш уніфікована, тому просто займіться дослідженнями.

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

Складніші топології реєстрації обмежуються лише вашою фантазією, хоча в ці дні ви бачите багато використання бази даних / черги / все, що ви хочете, щоб зателефонувати як базу даних в дуже складних системах розподілу журналів .

На стороні "без сервера", як правило, ви хочете інтегруватися з цими системами безпосередньо на мережевому рівні, тому надсилайте дані журналу безпосередньо в syslog або ES з вашого сервісу / функції, а не записуйте в локальні файли (хоча можливо, це перегукується на ці теж для локальної налагодження та розвитку).

Ця відповідь стосується більшої міри масштабності - якщо кількість працівників може бути великою та / або декількома з них, вони можуть одночасно виготовляти журнали з високою швидкістю.

Так, використання декількох логін одночасно є хорошою практикою.

Спроба об'єднати в один журнал журналів декількох працівників у режимі реального часу спричинить проблеми:

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

Шардування журналів (використання декількох реєстраційних файлів, активних за один і той же час) - сама техніка, яка використовується деякими постачальниками послуг хостингу, що пропонують високопродуктивні масштабовані послуги централізованого ведення журналу. Наприклад, при експорті журналів у файли StackDriver Logging Google виробляє декілька зрубаних журналів. З записів журналу в Google 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записи журналу для всіх екземплярів протягом години початку 0800 UTC. Щоб отримати всі записи журналу, ви повинні прочитати всі фрагменти для кожного періоду часу - у цьому випадку, фрагменти файлів 0 та 1. Кількість записаних фрагментів файлів може змінюватися за кожен період часу, залежно від обсягу записів журналу.

Такі високоефективні сервіси ведення журналу можуть також запропонувати альтернативи входу до файлів, таким чином управління логінами можна взагалі уникнути, якщо це цікавить:

• вставлення журналів безпосередньо в базу даних. Наприклад, Stackdriver Logging може пересувати журнали безпосередньо в Google BigQuery
• просування журналів безпосередньо в двигун обробки. Наприклад, Stackdriver Logging може вносити журнали до тем Google Pub / Sub

Нарешті - якщо об'єднання файлів у режимі реального часу не є вимогою, що має декілька логін-файлів, може допомогти керування журналом офлайн:

• легко розробити прогресивні схеми резервного копіювання, стиснення, архівування та можливі схеми видалення
• можлива паралельна обробка декількох наборів журналів (журналів), зменшення / уникнення вузьких ефектів
• не потрібно розділення та повторне записування файлів