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

Этот метод утомителен, поэтому мы ищем решение, которое автоматизирует мониторинг хода выполнения программы (вывод на CLI) для нескольких серверов одновременно. В идеале нам бы хотелось решения для веб-интерфейса, но CLI также был бы идеально подходящим.

Спасибо за чтение.

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

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

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

Graylog

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

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

• Веб-интерфейс
• Многопользовательские возможности
• Alerting

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

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

Идеи: Отправьте электронное письмо или сообщение Slack вашей команде. Создайте новую машину, чтобы сбалансировать нагрузку обработки. Блокировать диапазон IP-адресов в брандмауэрах автоматически при обнаружении атаки.

Чтобы попробовать Graylog, я бы порекомендовал следующие два шага:

• Настройте выделенный хост, доступный всем хостам приложения для запуска graylog (и его зависимостей MongoDB и ElasticSearch)
• Отправлять журналы из вашего приложения в graylog (возможно, как сообщения GELF )

Примечание. Эти два шага позволяют заполнить страницы и страницы с рекомендациями и должны получить как минимум пару мыслей. Не говоря уже о том, что graylog не является решением для мониторинга, и сам graylog должен контролироваться надлежащим инструментом мониторинга (например, Icinga, Prometheus, Nagios и многие другие).

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

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

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

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