Temos três servidores que executam programas python que executam tarefas de análise de dados dentro de uma tmuxsessão. O método que estamos usando no momento é o ssh'ing em cada um deles, conectando a tmuxsessão e assistindo a saída na linha de comando.

Esse método é entediante, portanto, o que estamos procurando é uma solução que automatize o monitoramento do progresso do programa (saída na CLI) para vários servidores ao mesmo tempo. Idealmente, gostaríamos de uma solução de interface do usuário da Web, mas uma CLI também seria perfeitamente adequada.

Obrigado pela leitura.

Sempre que você estiver executando comandos ad-hoc de longa execução, você deve recuar e repensar seu processo, porque isso deve ser automatizado, incluindo o tratamento de erros.

Em vez de conectar-se aos servidores para ver o status, uma abordagem melhor é enviar essas informações. Você pode fazer uma grande variedade de coisas, se quiser escrever um monte de código personalizado, mas o mais simples é provavelmente começar a enviar a saída através do syslog para um sistema de registro centralizado (o próprio syslog, ou ELK, ou o que for). Dessa forma, você pode monitorar tudo a partir de um local central.

Pensando no futuro, se essa não é uma tarefa pontual, o monitoramento deve ser automatizado. Ou seja, você nunca deve apenas observar os logs para ver se as coisas estão progredindo como deveriam. Em vez disso, você deve assumir que eles são (e continuar com outro trabalho) até que o alerta seja disparado . É um investimento de tempo para obter alertas confiáveis ​​e de ampla cobertura, mas, à medida que seus sistemas aumentam em complexidade, eles serão recompensados, pois você não precisará monitorar tudo sempre que alterar alguma coisa .

Graylog

Como duas pessoas já o aconselharam a repensar seu processo atual (que segundo eu já lhe causará noites de insônia em algum momento;)), seguirei outra rota e recomendarei um software específico que - na minha opinião - se encaixa na maioria dos casos. suas necessidades: Graylog .

Eu implementei e usei algumas pilhas do ELK para agregação de logs e inteligência de negócios e também gerencio / mantenho o graylog há cerca de dois anos no meu atual empregador. Eu recomendo o graylog, pois ele possui os seguintes recursos integrados e é - na minha opinião - um pouco mais fácil de configurar e manter:

• Uma interface web
• Recursos multiusuário
• Alertando

Tanto quanto eu entendo o seu cenário, parece que você precisa agir ou ser alertado sobre determinados eventos que aparecem no seu fluxo de mensagens de log. Se olharmos para os recursos do Graylog :

Acione ações ou seja notificado quando algo precisar de atenção, como tentativas de login com falha, exceções ou degradação do desempenho.

Ideias: envie um email ou uma mensagem do Slack para sua equipe. Cria uma nova máquina para equilibrar a carga de processamento. Bloqueie automaticamente os intervalos de IP em seus firewalls quando um ataque é detectado.

Para experimentar o graylog, recomendo as duas etapas a seguir:

• Configure um host dedicado, acessível por todos os hosts de aplicativos para executar o graylog (e suas dependências MongoDB e ElasticSearch)
• Envie logs do seu aplicativo para graylog (possivelmente como mensagens GELF )

Nota: Essas duas etapas têm a capacidade de preencher páginas e páginas de práticas recomendadas e devem receber pelo menos algumas reflexões. Sem mencionar que o graylog não é uma solução de monitoramento e o próprio graylog deve ser monitorado por uma ferramenta de monitoramento adequada (como, por exemplo, Icinga, Prometheus, Nagios, para citar apenas alguns).

Concordo com @Xiong Chiamiov e quero dar uma opção mais clara. Se você deseja que todas as linhas da CLI sejam monitoradas, sugiro redirecionar toda a saída para um arquivo específico e o erro para outro arquivo, use o logstash ou batida de arquivo para enviar esses dois arquivos para o Elasticsearch , então você pode configurar o Logtril com Kibana para exibir, analisar, pesquisar e registrar eventos de vários hosts em tempo real com a interface amigável do devops

centralizado tmux

Embora as outras respostas sejam mais inteligentes e inteligentes a longo prazo, acho que vale a pena mencionar a solução rápida de CLI hacky. Execute tmuxem um servidor que possa alcançar todos os outros. Um bom lugar para isso seria uma caixa de salto ou algum outro lugar em que as pessoas normalmente estejam logadas de qualquer maneira. Dentro deste tmuxssh "central" para cada caixa em um painel diferente e siga os arquivos de log necessários. Você pode usar ctrl- b "para obter mais painéis em uma guia dentro tmux. Agora, tudo o que alguém precisa fazer para verificar as coisas é anexado à tmuxsessão "central" e pode ver rapidamente todo o cluster.

Passei muito tempo criando as soluções de interface do usuário da web nas quais você está trabalhando, mas se você precisar hoje de dia, hackear algo com ele tmuxpode salvar o dia.