Avaliação do Apache Nutch: Quatro limites que determinam se ele funciona e o que encontra

O Apache Nutch é um crawler da Apache Software Foundation cujo desenvolvimento começou em 2004. Trata-se de um sistema em JVM baseado em Hadoop, organizado como um ciclo em vez de um único comando de streaming: URLs iniciais são injectadas em um banco de dados persistente, seguidas por rodadas de generate → fetch → parse → updatedb, com espaço para plugins de protocolo, parser, filtro de URL e scoring. O resultado normalmente alimenta um índice de busca, como Solr ou Elasticsearch, em vez de um CSV.

Executei Nutch 1.22 em um site de teste local controlado — um site que registra cada requisição no lado do servidor, então os resultados são avaliados pelo que o servidor realmente recebeu, e não pelo que o crawler afirmou ter feito. Quatro limites definiram a execução: a versão do JDK, http.agent.name, o escopo do crawl e se parse-js aparece em plugin.includes. O ciclo completo foi repetido várias vezes com a configuração testada; se você troca o JDK ou deixa a identidade do agente sem definição, ele para antes de buscar páginas úteis.

O limite do JDK aparece antes mesmo de qualquer crawl começar. O Nutch 1.22 não iniciou aqui no JDK 26.0.1: o primeiro job do Hadoop morreu dentro de Subject.getSubject() depois que o Java removeu o caminho do SecurityManager. O Nutch inclui Hadoop 3.4.2, enquanto a correção foi incluída no Hadoop 3.4.3 sete dias depois do lançamento do Nutch 1.22. Em paralelo, parse-js mudou a recuperação de dois literais em arquivos JavaScript de 0/2 para 2/2 sem executar navegador algum.

Para que o Nutch serve — e para que não serve

Nutch não é um scraper. Extração estruturada de campos não é o trabalho dele: ele descobre e busca URLs em volume, mantém um banco de dados persistente dessas URLs e de seus estados (o crawldb), e entrega segmentos que outra ferramenta transforma em índice. Aponte-o para um catálogo esperando uma tabela com nomes e preços e você receberá um crawldb no lugar.

Essa arquitetura explica quase tudo que vem a seguir. O Nutch surgiu cerca de duas décadas antes da era dos crawlers de binário único e foi construído para o problema que o Hadoop também resolveu: rastrear mais páginas do que cabem em uma máquina. Rodá-lo em um notebook contra um fixture de 12 páginas é como alugar um trem de carga para mover uma estante — é informativo sobre o trem, mas injusto exigir ergonomia de bicicleta.

A versão atual é 1.22, anunciada em 17 de fevereiro de 2026. O projeto é Apache-2.0, o repositório estava com 3.272 estrelas e 8 issues abertas quando consultei em 27 de julho de 2026, e o branch principal tinha recebido push quatro dias antes disso. Este é um projeto mantido, não abandonado — e esse é o ângulo correto para entender o problema do JDK: uma janela de empacotamento que se fechou uma semana cedo demais, não negligência.

A matriz de versões: JDK 24+, Hadoop 3.4.2 e uma correção de duas linhas

O bloqueio é uma interação entre três versões, e a única parte sob seu controle é em qual JDK o Nutch roda. O primeiro job do Hadoop, no JDK padrão da máquina, morreu na inicialização:

java.lang.UnsupportedOperationException: getSubject is not supported
    at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
    at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:588)
    at org.apache.nutch.crawl.Injector.inject(Injector.java:473)

Código de retorno 255. Zero páginas buscadas. bin/nutch inject nem chega à rede — ele inicializa um LocalJobRunner do Hadoop, que pergunta quem é o usuário atual, o que chama Subject.getSubject(), que o JEP 486 transformou em exceção incondicional quando o JDK 24 removeu permanentemente o SecurityManager. No meu ambiente, o JDK era OpenJDK 26.0.1, muito além desse corte.

A saída tradicional também não funciona. Adicionar -Djava.security.manager=allow, a flag que antes reativava o comportamento antigo, é rejeitado pela VM antes mesmo de o código do Nutch ser carregado:

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security
Manager. Enabling a Security Manager is not supported.

Isso retorna código 1 e é um beco sem saída por design — a flag foi removida junto com a funcionalidade.

A causa raiz está na versão do Hadoop embutida no Nutch 1.22. O problema de getSubject está registrado como HADOOP-19212 e corrigido no Hadoop 3.4.3 e 3.5.0; o Nutch 1.22 inclui hadoop-common-3.4.2. O Nutch 1.22 foi lançado em 17 de fevereiro de 2026, e o Hadoop 3.4.3 veio cerca de uma semana depois.

E também não se trata de uma dependência obrigatória de cluster Hadoop ou de Solr. É comum presumir que o Nutch precise de um cluster Hadoop e de um Solr em execução para fazer qualquer coisa. Não precisa. O modo local executa o LocalJobRunner do Hadoop em processo — sem daemon HDFS, sem YARN, sem cluster. O ciclo inteiro inject → generate → fetch → parse → updatedb roda em uma única máquina, sem mais nada instalado. A barreira do JDK é puramente uma questão de versão de biblioteca empacotada, e ela bloqueia você antes mesmo de essa discussão de infraestrutura começar.

A matriz prática de versões, com os três cenários medidos:

A correção leva dois comandos. Instale um JDK LTS e aponte o Nutch para ele:

brew install openjdk@17
export NUTCH_JAVA_HOME=/opt/homebrew/opt/openjdk@17

Como é keg-only, isso não altera o JDK padrão do sistema. O próprio CI do Nutch usa Java 17, e o projeto anunciou publicamente que a 1.22 é a última versão que roda em Java 11 e que a 1.23 exigirá Java 17. Então um JDK LTS não é gambiarra — é a configuração suportada. O desencontro é entre o que o Nutch suporta e o que brew install openjdk entrega em 2026, e essas são duas questões diferentes que acabam colidindo no primeiro comando.

Daqui em diante tudo rodou no OpenJDK 17.0.20, onde o ciclo inteiro ficou limpo.

Configuração, medida: 396 MB e uma propriedade que bloqueia tudo

“Pesado” é o adjetivo que todo mundo usa, e ele não vale nada sem uma medida. Eis o que a distribuição binária descompactada do Nutch 1.22 realmente contém:

Para comparação, um crawler Go moderno como o katana vem como um único binário de cerca de 50 MB, sem JVM e sem jars externos.

Depois vem a barreira que ninguém avisa. O nutch-site.xml fornecido vem vazio, e http.agent.name tem como padrão uma string vazia. Com esse valor sem definição, meu primeiro crawl buscou zero caminhos e registrou:

ERROR Fetcher: No agents listed in 'http.agent.name' property.

Definir apenas essa propriedade — nada mais — fez a busca passar a funcionar. Com a propriedade vazia, o comando terminou sem buscar páginas e o log exibiu o erro acima; ele não ficou silencioso.

A configuração mínima viável acabou sendo três artefatos: conf/nutch-site.xml (nome do agente, conjunto de plugins, escopo), conf/regex-urlfilter.txt (escopo por host) e um arquivo com URLs iniciais. Não é muita coisa. Só são três arquivos a mais do que crawler run <url>.

O que ele encontrou: o toggle de plugin que importa

O site de teste tinha três classes de endpoints propositalmente diferentes, e o comportamento do Nutch se separou claramente entre elas:

• Classe A — links HTML comuns (4 páginas, além de uma cadeia com 3 níveis de profundidade)
• Classe B — endpoints que existem apenas como literais de string dentro de um arquivo JavaScript vinculado: um como argumento de função, fetch('/api/js-endpoint-7'), e outro como atribuição, const other = "/api/js-endpoint-8"
• Classe C — um endpoint que só existe depois que o JavaScript roda e o injeta no DOM

Resultados, com base nos logs de acesso do servidor, repetidos três vezes:

Idêntico nas três repetições. Determinístico.

O salto da classe B é o ponto mais subestimado. O Nutch encontrou os dois endpoints embutidos em JavaScript sem executar navegador algum, usando a varredura baseada em regex do plugin parse-js sobre o conteúdo JavaScript. O arquivo app.js em si foi buscado nas duas configurações — o Nutch trata <script src> como outlink independentemente do resto — então toda a diferença está em alguém ler o conteúdo do arquivo em busca de strings com aparência de URL. Ative o plugin, e ele captura as duas formas literais.

Neste fixture, o padrão do Nutch e o modo padrão do katana alcançaram o mesmo conjunto da classe A, enquanto o Nutch com parse-js e o katana com -jc alcançaram as classes A e B sem navegador. A versão do Katana e o comando completo não foram registrados neste artigo, então esse resultado é contexto, não um benchmark estrito entre produtos.

Classe C é o teto honesto. Nenhuma configuração estática chegou até ela, o que era esperado: recuperar um endpoint que só existe depois da execução do script exige de fato executar o script. Tentei trocar protocol-http por protocol-htmlunit, o protocolo do Nutch em Java puro que executa JavaScript. Ele carregou e rodou sem travar, mas no mesmo harness de quatro rodadas concluiu apenas uma rodada, buscou só a página inicial e app.js, não atingiu A/B/C, e a segunda rodada relatou 0 records selected for fetching. Isso é uma prova subconfigurada, não um veredito sobre a capacidade do HtmlUnit. O que fica demonstrado é mais estreito: substituir por um protocolo que executa JavaScript não é uma troca plug-and-play, e a classe C permaneceu inalcançada em todas as configurações que testei.

Controle de crawl e comportamento em falhas

Profundidade não é uma flag. Não existe --depth 3 no Nutch; profundidade é a quantidade de rodadas generate → fetch → parse → updatedb que você executa, porque a rodada R busca a fronteira descoberta na rodada R-1. Minha cadeia de profundidade confirmou isso com precisão:

É limpo e mecânico, mas significa que profundidade é uma contagem de loop no seu script, e não um parâmetro.

Agora vem a armadilha. O padrão incluído do Nutch é db.ignore.external.links=false, combinado com um filtro de URL permissivo +. — o que significa que um crawl padrão do Nutch seguirá links para fora do host inicial. Se eu colocava uma página com um link interno e outro para um hostname diferente, o crawl buscava o host externo. Dois sinais independentes concordaram: o próprio crawldb do Nutch marcou isso como db_fetched, e o contador de requisições do outro host registrou o acesso.

Manter o crawl dentro do escopo é opcional, e as duas soluções funcionam de forma verificável:

Se você estiver rastreando um único site, defina uma dessas opções antes da primeira execução real. Um cuidado metodológico: este teste específico é sensível à carga no servidor local, então essas três linhas vêm de uma execução em que nada mais tocava o fixture. O comportamento em si é mecanicamente claro e apoiado por dois sinais independentes; os valores específicos da tabela são de uma execução limpa, não de uma média de várias.

Sitemaps são uma etapa separada. A educação básica está ligada — um crawl normal buscou /robots.txt — mas o sitemap precisa do próprio comando:

É um modelo diferente de crawlers que puxam arquivos conhecidos inline, e isso custa um comando extra, mas faz o trabalho por completo.

Dois comportamentos menores se mantiveram bem.

Tratamento de erros: um crawl sobre uma página com links para um 500 e um 404 concluiu todas as rodadas sem problemas, ainda buscou todas as quatro páginas da classe A e registrou cada falha de forma distinta:

Nada desandou.

Cortesia/politeness: com uma thread por fila, a distância entre buscas no mesmo host acompanhou a configuração:

O ajuste faz exatamente o que promete. O padrão incluído é 5,0 segundos, o que é conservador e, de novo, provavelmente correto para uma ferramenta feita para rastrear servidores de terceiros.

O imposto do modo em lote, em segundos

Cada comando do Nutch inicia uma JVM nova. Esse único fato domina o perfil de tempo muito mais do que qualquer coisa relacionada à busca em si.

O piso efetivo por job — startup da JVM mais inicialização do Hadoop, medido como a fase mais barata de trabalho trivial — é de cerca de 1,77 segundos. Multiplique isso por quatro comandos por rodada, some o inject inicial e o quadro de um crawl completo fica assim:

Essa diferença não tem a ver com throughput de fetch; as duas ferramentas pedem o mesmo conjunto pequeno de páginas. É arquitetural. O Nutch paga um custo fixo de processo por fase porque essas fases são projetadas como jobs MapReduce. Em um crawl local pequeno, a configuração domina. Esse custo fixo tende a virar uma fatia menor em um trabalho mais longo, mas este teste não mediu em que escala Nutch e katana se cruzam, nem se a proporção se inverte.

Prós e contras

Prós

• Descoberta estática determinística: classe HTML 4/4, cadeia de profundidade 3/3, idêntico nas três execuções repetidas.
• parse-js recupera endpoints de literais em arquivos JavaScript (2/2) sem navegador, capturando tanto a forma de argumento de função quanto a de atribuição.
• Dois controles de escopo verificados que contêm completamente um crawl (db.ignore.external.links e filtro de host em regex-urlfilter).
• A ingestão de sitemap via bin/nutch sitemap obteve recall total 2/2 em endpoints que um crawl normal não encontrou.
• Robustez diante de falhas: 500 e 404 foram tratados com estados distintos no crawldb, e o crawl continuou.
• Nesta execução local, o intervalo observado no mesmo host foi consistente com o atraso configurado de 1,0 segundo; o padrão incluído é 5,0 segundos.
• Apache-2.0, mantido ativamente, 78 plugins e um crawldb persistente que acompanha o estado por URL ao longo das rodadas.
• Roda em modo local sem cluster, sem HDFS e sem necessidade de Solr.

Contras

• Não roda em JDK 24 ou mais novo, onde a remoção do SecurityManager causa a falha (eu medi o erro no 26.0.1) — o Hadoop 3.4.2 embutido é anterior à correção upstream e a flag de escape sumiu, então fixar um JDK LTS é um pré-requisito duro, não preferência.
• ≈396 MB descompactado, 188 jars de biblioteca, 78 diretórios de plugins, 35 arquivos de configuração.
• Uma JVM nova por comando significa ~1,77 s de overhead fixo por fase; ~45 s para um crawl de profundidade 4 com 12 páginas contra ~13 s para um crawler de binário único no mesmo terreno.
• O padrão incluído segue links para hosts externos; permanecer em um único site é opcional.
• http.agent.name vem vazio e o fetcher se recusa a rodar até você definir esse valor.
• Sem flag de profundidade — a profundidade é uma contagem de loops que você mesmo administra.
• Endpoints de DOM em runtime ficaram inalcançáveis em todas as configurações testadas, e trocar para o protocolo que executa JavaScript não foi uma troca imediata.
• Testei o modo local em um único host com um fixture pequeno. Modo distribuído/HDFS, indexação Solr, hostdb, resume e agendamento de recrawl incremental ficaram fora desta passagem — considere-os não testados aqui, não endossados.

Quem deve usar e quem deve desistir

O Nutch vale a pena quando o crawl em si é a parte difícil. Se você está montando um índice de busca, executando um crawl amplo em múltiplos domínios, precisa de um banco de dados persistente de URLs com estado por URL e semântica de retry, ou espera distribuir o trabalho entre máquinas no futuro, esta é uma infraestrutura que faz exatamente esse trabalho desde antes de a maioria das alternativas existir. O sistema de plugins permite alterar comportamento de protocolo, parser, filtro e scoring sem precisar bifurcar nada. Os padrões de cortesia são conservadores de um jeito que sugere que os mantenedores pensaram bastante em como ser bons cidadãos da rede.

Desista se quiser dados estruturados a partir de meia dúzia de páginas. O Nutch vai buscá-las e parseá-las, depois lhe entregará um crawldb e segmentos e esperará que você traga um indexador. Desista se seus alvos forem aplicativos single-page renderizados no cliente — a classe C permaneceu inalcançada em tudo que rodei. Desista se sua equipe não trabalha com JVM, porque você estaria adicionando um toolchain Java, um pin de JDK LTS e 396 MB de jars a uma stack que hoje não tem nada disso. E se a tarefa for “rastrear um site, quatro níveis de profundidade, uma vez por semana”, você gastará mais tempo no loop de rodadas e nos arquivos de configuração do que o crawl merece.

Para a maioria das pessoas procurando um scraper, esse último caso é o caso real. O que não é uma crítica ao Nutch — é um desencontro entre a ferramenta e a tarefa. Se você quiser uma visão do campo mais amplo, nosso panorama de scrapers open source e os melhores projetos de web scraping no GitHub cobrem melhor a faixa mais leve do espectro.

Alternativas, inclusive onde nossa própria stack se encaixa

Primeiro, o enquadramento justo: o Nutch é gratuito, licenciado pela Apache, hospedado por você e seu para rodar para sempre sem custo por requisição. Isso é uma vantagem real, e nada abaixo apaga isso.

Review relacionada: Avaliação do Browsertrix Crawler.

Dentro do mundo open source, a comparação depende do que você quer otimizar. Se você quer um framework em Python com controle de crawl e filosofia request-first, o Scrapy é um análogo mais próximo para muitos projetos; este artigo não mediu o tamanho da instalação dele na mesma base. Se você quer um crawler Go compacto e sem navegador, o Colly é outra forma a considerar. Se o seu problema é transformar páginas em conteúdo pronto para LLM, em vez de descobrir URLs, o Crawl4AI mira outra camada.

Um serviço gerenciado como Thunderbit coloca fetch, rendering e extração atrás de uma API, enquanto o Nutch mantém o estado do crawl e a infraestrutura sob seu controle. O Thunderbit não foi executado neste fixture, então esta é uma comparação de modelo de propriedade, não uma afirmação sobre recall equivalente ou desempenho em páginas dinâmicas.

A troca é controle versus sobrecarga, e isso não é sutil. O Nutch lhe dá controle total, um crawldb persistente, escalabilidade em cluster por design e custo marginal zero — em troca de uma JVM, um pin de JDK LTS, 396 MB de jars, um loop de rodadas e sua própria camada de indexação. Uma API gerenciada lhe entrega saída estruturada na primeira chamada e zero infraestrutura — em troca de precificação por chamada e menos controle sobre a fronteira do crawl. Se sua tarefa é “indexar 50 milhões de páginas”, o modelo do Nutch está correto e uma API seria absurda. Se sua tarefa é “obter registros estruturados de 200 páginas de produto até quinta-feira”, o inverso é verdadeiro.

Experimente o Thunderbit para extração de dados da web

Veredito

O Apache Nutch merece avaliação se você está operando um crawl contínuo e multi-domínio e já trabalha com infraestrutura JVM. Neste fixture, a descoberta estática foi determinística entre repetições, parse-js encontrou os dois endpoints literais em JavaScript, as falhas permaneceram representadas no crawldb e o espaçamento observado entre requisições bateu com o atraso configurado.

Avalie o custo de entrada com honestidade. O Nutch 1.22 falhou aqui no JDK 26.0.1; o OpenJDK 17.0.20 é a configuração LTS realmente verificada nesta análise, enquanto Java 21 não foi testado. Depois, defina http.agent.name, determine seu escopo explicitamente e considere o piso fixo observado de ~1,77 segundo por fase nesta execução local pequena. Se essa troca faz sentido depende da duração, da amplitude e da necessidade de estado persistente do crawl.

Experimente o Thunderbit para extração de dados da web Get Started Free

FAQs

Por que o Apache Nutch falha com "getSubject is not supported"? No JDK 24 ou mais novo, o JEP 486 fez Subject.getSubject() lançar exceção de forma incondicional, enquanto o Hadoop 3.4.2 embutido ainda o chamava. Por isso, o primeiro job do Hadoop morre antes de qualquer página ser buscada, e a antiga saída -Djava.security.manager=allow já não inicia a VM. Use a configuração verificada com Java 17 e defina NUTCH_JAVA_HOME; Java 21 pode ser suportado, mas este review não executou o ciclo completo nele.

Em qual versão do Java devo rodar o Nutch 1.22? Java 17 é a resposta mais segura — o próprio CI do Nutch aponta para ele, e ele funcionou perfeitamente nos meus testes com OpenJDK 17.0.20. Java 11 também continua suportado para a 1.22, embora o projeto já tenha anunciado que a 1.23 exigirá Java 17. Qualquer versão a partir do JDK 24 não vai funcionar. Uma instalação Homebrew keg-only (brew install openjdk@17) mais NUTCH_JAVA_HOME mantém o JDK padrão do sistema intacto.

O Nutch consegue rastrear sites pesados em JavaScript? Parcialmente, e essa distinção importa. Com o plugin parse-js ativado, o Nutch encontrou os dois endpoints que existiam apenas como literais de string dentro de um arquivo JavaScript vinculado — 2/2, sem navegador envolvido. Sem o conjunto de plugins padrão, não encontrou nenhum deles. Mas um endpoint que só aparece depois que o JavaScript executa e modifica o DOM ficou inalcançável em toda configuração estática que testei, e trocar para o protocolo HtmlUnit não foi uma substituição imediata na minha execução. Para apps renderizados no cliente, planeje um protocolo que execute JavaScript mais trabalho real de configuração, ou use outra ferramenta.

O Nutch precisa de Hadoop e Solr instalados? Não. O modo local executa o LocalJobRunner do Hadoop em processo — sem cluster, sem daemon HDFS, sem YARN — e o ciclo inteiro inject → generate → fetch → parse → updatedb funciona em uma máquina só, sem mais nada instalado. Solr é o destino usual para indexação, mas o crawl em si não exige isso. Dito isso, os jars do Hadoop vêm embutidos (13 deles, versão 3.4.2), e é exatamente por isso que o problema de compatibilidade com o JDK existe.

Como faço para impedir que o Nutch rastreie outros sites? Defina isso explicitamente, porque o padrão incluído não faz isso. O Nutch 1.22 traz db.ignore.external.links=false com um filtro de URL permissivo, e no meu teste o crawl padrão seguiu um link para outro host e o buscou. Defina db.ignore.external.links=true em nutch-site.xml, ou adicione uma regra de host em conf/regex-urlfilter.txt (por exemplo +^https://example\.com/ seguido de -.). Ambas contiveram completamente o crawl nos testes, confirmado tanto pelo crawldb do Nutch quanto pelo log de requisições do outro servidor.