У нас є три сервери, на яких запущені програми python, які виконують завдання аналізу даних всередині tmuxсеансу. Метод, який ми використовуємо на даний момент, - це ssh'ing для кожного з них, з'єднуючи tmuxсеанс і спостерігаючи за результатами в командному рядку.

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

Дякую за прочитане

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

Замість того, щоб підключатися до серверів, щоб побачити статус, кращим підходом є витіснення цієї інформації. Ви можете зробити найрізноманітніші речі, якщо хочете написати купу спеціального коду, але найпростіше, мабуть, почати надсилати вихід через syslog до централізованої системи реєстрації журналу (сам syslog, або ELK, чи будь-що інше). Таким чином ви можете відстежувати все з центрального місця.

Якщо робити це вперед, якщо це не одноразове завдання, моніторинг повинен бути автоматизованим. Тобто вам ніколи не доведеться просто дивитися журнали, щоб побачити, чи все прогресує так, як належить. Натомість слід припустити, що вони є (і продовжуйте інші роботи), поки ваше сповіщення не вимкнеться . Це вкладення часу на отримання надійного та широкого охоплення сповіщення, але, коли ваші системи зростають у складності, вона окупиться, оскільки вам не доведеться стежити за всім часом, коли ви щось змінюєте .

Graylog

Оскільки двоє людей вже порадили вам переосмислити свій поточний процес (який я другий, оскільки він спричинить у вас безсонні ночі в якийсь момент;)), я піду іншим маршрутом і рекомендую конкретний програмний продукт, який, на мою думку, підходить більшості ваші потреби: Graylog .

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

• Веб-інтерфейс
• Багатокористувацькі можливості
• Сповіщення

Наскільки я розумію ваш сценарій, виглядає так, ніби вам потрібно діяти або отримувати сповіщення про певні події, які з’являються у вашому потоці повідомлень журналу. Якщо ми подивимось на функції Graylog :

Запускайте дії або отримуйте сповіщення, коли щось потребує уваги, наприклад, невдалі спроби входу, винятки або зниження продуктивності.

Ідеї: надішліть електронною поштою або повідомлення про слабке повідомлення своїй команді. Породжують нову машину, щоб збалансувати обробку навантаження. Блокуйте IP-діапазони ваших брандмауерів автоматично при виявленні атаки.

Щоб спробувати сірий журнал, я рекомендую наступні два кроки:

• Налаштуйте спеціальний хост, який доступний усім хостам додатків для запуску сірого журналу (та його залежностей MongoDB та ElasticSearch)
• Надсилайте журнали зі своєї програми до сірого журналу (можливо, як повідомлення GELF )

Примітка. Ці два кроки мають можливість заповнювати сторінки та сторінки найкращих практик і повинні отримувати хоча б пару думок. Не кажучи вже про те, що сірий журнал не є моніторним рішенням, а сам сірий журнал слід контролювати за допомогою відповідного інструменту моніторингу (наприклад, Icinga, Prometheus, Nagios, щоб назвати лише кілька).

Я погоджуюся з @Xiong Chiamiov і хочу дати більше уточнюючого варіанту. Якщо ви хочете, щоб кожен рядок у CLI відслідковувався, я б запропонував перенаправити весь результат на певний файл та помилку на інший файл, потім використовуйте logstash або filebeat для надсилання обох цих файлів на Elasticsearch , тоді ви можете налаштувати Logtril за допомогою Kibana, щоб дати вам перегляд, аналіз, пошук та пошук журналів хвостів від декількох хостів у режимі реального часу з привабливим інтерфейсом

централізований tmux

Хоча інші відповіді розумніші та мудріші на тривалий термін, я думаю, що швидке хакі-рішення CLI варто згадати. Запустити tmuxна одному сервері, який може охопити всі інші. Хорошим місцем для цього може стати стрибок для стрибків чи якесь інше місце, до якого люди зазвичай входять. У цьому "центральному" tmuxssh до кожного вікна в іншій області та хвостовій частині потрібні файли журналу. Ви можете використовувати ctrl- b "щоб отримати більше панелей на одній вкладці в межах tmux. Тепер все, що хтось повинен зробити, щоб перевірити речі, приєднано до "центрального" tmuxсеансу, і вони можуть побачити весь кластер з першого погляду.

Я витратив багато часу на розробку веб-рішень інтерфейсу користувача, над якими ви працюєте, але якщо вам це потрібно сьогодні, зломляючи щось, tmuxможна врятувати день.