Agora, a maioria de vocês já descobriram como usar o mais recente e melhorado node-inspetor (construído com ferramentas de desenvolvimento do Google Blink) para debugar aplicações Node. Mas que tal aplicações clusterizadas? Neste blog vamos apresentar o que é preciso ser feito para realizar essa façanha.
Debugar uma aplicação Node clusterizada não deixa de ser uma idiossincrasia, particularmente caso esteja executando a versão do Node v0.10. Mas, ele funciona bem o suficiente caso você entenda o que ocorre dentro dos bastidores. Agora, antes de embarcar nesta aventura de debug, você provavelmente deve se perguntar, “(i) posso executar minha aplicação não-clusterizada e debugá-la nesse modo ou (ii) é uma issue que estou tentando rastrear, vista somente ao executar minha aplicação numa configuração clusterizada?”
Se for o primeiro caso, certamente pode usar o node-inspetor para debugar a aplicação numa configuração clusterizada. Mas, isso envolve uma seqüência de várias etapas para funcionar:
- execute a aplicação
- execute o node-inspetor
- abra uma nova aba no Chrome
Uma das maneiras mais fáceis para começar o debug com o node-inspector é instalar a ferramenta de linha de comando da StrongLoop, o strong-cli, que fará toda a configuração necessária.
npm install -g strong-cli
Usar o strong-cli é algo do tipo:
slc debug app.jsSupondo que a aplicação app.js seja clusterizada, então execute:
slc debug app.jsCaso esteja usando o Node v0.10, então uma janela de debug vai ser aberta no Chrome para o processo principal, que pode não ser o que você espera (geralmente os workers fazem umas escolhas interessantes). O que é mais problemático é que provavelmente você vai ver uma série de mensagens aumentando a barra de rolagem do terminal para baixo:
Failed to open socket on port 5858, waiting 1000 ms before retrying
Failed to open socket on port 5858, waiting 1000 ms before retrying
Failed to open socket on port 5858, waiting 1000 ms before retrying
O que está acontecendo aqui é que o Node está passando todos os argumentos do node-specific para os processos filhos. Caso a opção seja --max-stack-size, o que é uma coisa boa. Se a opção for --debug, isso resulta em que o processo master e em todos os workers tente escutar a porta de debug 5858, o que não vai bem.
Na versão v0.11, o mantenedor do node-inspetor e desenvolvedor da StrongLoop, Miroslav Bajtos, corrigiu isso:
Pull request: 5713
Commit: c16963b
Mas a mudança não foi de backported pra stable. Por que? Isso é uma mudança muito grande. Essa correção foi atribuir a cada worker um deslocamento de porta de debug do processo master pela identificação do worker. De fato, a porta master é 5858, a do primeiro worker é 5859, e do segundo é 5860, e assim sucessivamente.
Então, caso você repita o comando de debug com o Node v0.11 (ou v0.12 quando for lançado): você deve achar que slc debug app.js funciona muito bem. A aplicação será executada, a janela de debug será aberta no Chrome e o processo master vai estar em modo debug.
Observe que a URL deve ser algo parecido com:
http://localhost:8080/debug?port=5858
Caso deseje depurar o primeiro worker, altere a porta para 5859 e recarregue a página. Isto pode parece um pouco bruto, mas é bastante funcional e permite percorrer todos os processos em cluster.
Caso você adicione uma expressão watch para o process.pid (pressione o '+' no canto superior direito da tela) a medida que alterna entre os workers, você pode ver a mudança do PID. Você também pode abrir várias abas de debug simultaneamente.
O debug de aplicações em cluster na versão v0.10 não é tão bom. Mas, saiba que o que precisa ser evitado é a opção -debug de ser passada para as várias instâncias do Node. É possível fazer o debug fazendo procedimentos mais manuais.
Você pode fazer isso, iniciando a aplicação em segundo plano com o modo debug não ativado:
node app.jsO id do processo de um worker no debug é mais fácil de ser encontrado imprimindo-o quando o worker é executado usando um código do tipo:
console.log(“worker %s pid %s“, cluster.worker && cluster.worker.id, process.pid)
Ele também pode ser encontrado verificando o Painel de Cluster no dashboard da StrongOps.
Em seguida, habilite o modo debug para um único processo de worker, conectando um shell de debug a ele, e em seguida saia do shell. Isto vai deixar a porta de debug aberta, e então o node-inspetor pode se conectar a ele.
% node debug -p 4015
connecting... ok
...
debug> quit
Claro, utilize o ID do processo do worker que você deseja depurar, e não 4015!
Neste caso, execute o node-inspector:
% node-inspector
Node Inspector v0.7.0-2
info - socket.io started
Visit http://127.0.0.1:8080/debug?port=5858 to start debugging.
e abra o seguinte endereço no Chrome:
http://127.0.0.1:8080/debug?port=5858
… e agora você já está debugando um cluster worker.
O fluxo de trabalho acima apenas permite debugar um único worker em um cluster. Mas, mesmo com a versão v0.10, se você estiver disposto a usar alguns recursos internos não documentados, você pode ficar um pouco mais perto das vantagens da versão v0.11. Se você definir a porta de debug no início de todos os seus worker com:
process._debugPort = 5858 + cluster.worker.id
... mais tarde é possível habilitar o modo debug em qualquer um dos seus cluster workers, e eles não vão ter conflito de reutilização da porta 5858.
Feliz debug em aplicação clusterizada!
Pronto para começar a monitorar loops de evento, gerenciar clusters e perseguir os vazamentos de memória? Nós fizemos isso de tal forma que fique bem mais fácil com o StrongOps tanto localmente quanto na sua nuvem favorita, simplesmente com um npm install.
- O que está por vim na versão v0.12 Node? Otimizações de alto desempenho, leia o blog de Ben Noordhuis para saber mais.
- Assista o vídeo na íntegra da apresentação de Bert Belder sobre todos os novos recursos que estão por vim na versão v0.12
- Pronto para desenvolver APIs em Node e deixá-las conectadas aos seus dados? Veja como fica mais fácil começar com o LoopBack, tanto local quanto na nuvem, simplesmente com um npm install.