Kafka-backup: Ainda outro NPE

JFYI, eu limpei tudo e comecei com um novo backup. Sinta-se à vontade para encerrar este problema.

Hmm ... Isso é estranho ... As linhas de código relevantes são estas aqui: https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkaskTackup/sink/sink # L121 -L122

partitionWriters foram preenchidos na chamada open() em https://github.com/itadventurer/kafka-backup/blob/f30b9ad963c8a7d266c8eacd50bd7c5c3ddbbc16/src/main/java/de/azapps/kafkabackup/sink BackupSinkTask.java # L107
Que é chamado para cada TopicPartition para abrir ... Não faz sentido para mim por que isso acontece :(

Você ainda tem seus dados disponíveis para depuração adicional? Seria interessante tentar reproduzir. Devemos pelo menos mostrar um erro significativo em vez de apenas lançar um NPE ...

Oi! Sim, ainda tenho backup de diretório antigo. Embora seu uso possa afetar o estado atual de backup do cluster, acho que não alterei o nome do coletor.

Meu palpite aqui é que este diretório de destino foi quebrado de alguma forma durante as tentativas de habilitação do eCryptfs. Talvez algum arquivo tenha sido alterado acidentalmente ou algo assim.

Hmm ... Ele contém informações confidenciais? Se não, sinta-se à vontade para enviá-lo para https://send.firefox.com/ e me enviar um link. Eu tentaria reproduzir o erro.
Caso contrário, você pode tentar reproduzi-lo com um novo cluster ou fecharemos o problema por enquanto, esperando que você esteja certo;)

Aconteceu hoje em outro cluster também ...
Eu tenho o cronjob de backup do Azure que está interrompendo o kafka-backup, depois desmontando o eCryptfs, depois fazendo azcopy sync , montando novamente o eCryptfs e iniciando o kafka-backup.
Hoje à noite umount etapa falhou, então o script falhou também ( set -e ). Acho que esta é a hora em que o problema acontece. Embora eu precise verificar novamente a linha do tempo com cuidado. Atualizará este problema mais tarde.

UPD. Eu fiz a verificação dos logs agora mesmo. NPE aconteceu mais cedo, na verdade. Kafka-backup foi eliminado por OOM várias vezes ... Parece que -Xmx1024M ou Docker memory_limit=1152M não é suficiente para este cluster :( Alguma ideia sobre como calcular o tamanho HEAP / RAM para kafka-backup ?

Você quer que eu faça alguma depuração nesses dados? Não consigo fazer upload porque contém dados confidenciais da empresa ...

BTW pode afundar com falha fazer com que o kafka-connect saia? Seria bom se todo o processo de conexão autônomo falhasse em caso de falha de coletor único (quando nenhum outro coletor / conector existe).

BTW pode afundar com falha fazer com que o kafka-connect saia? Seria bom se todo o processo de conexão autônomo falhasse em caso de falha de coletor único (quando nenhum outro coletor / conector existe).
Veja # 46

UPD. Eu fiz a verificação dos logs agora mesmo. NPE aconteceu mais cedo, na verdade. Kafka-backup foi eliminado por OOM várias vezes ... Parece -Xmx1024M ou Docker memory_limit = 1152M não é suficiente para este cluster :( Alguma ideia sobre como calcular o tamanho HEAP / RAM para kafka-backup?

Desculpe, perdi a atualização. Sinta-se à vontade para adicionar outro comentário;)

Não tenho ideia de como calcular isso agora. Abri um novo tíquete # 47 para essa discussão

Você quer que eu faça alguma depuração nesses dados? Não consigo fazer upload porque contém dados confidenciais da empresa ...

Sim por favor! Isso seria incrível!

Você quer que eu faça alguma depuração nesses dados? Não consigo fazer upload porque contém dados confidenciais da empresa ...

Sim por favor! Isso seria incrível!

Não sou especialista em depuração de java, infelizmente ... embora eu possa executar algo se você me orientar sobre isso.

Ok, vou tentar pensar como fazer isso nos próximos dias, talvez eu mesmo encontre o problema por acaso: alegria: (quero escrever mais testes)
Talvez se fosse possível reproduzir isso com dados externos à empresa, seria incrível!

De acordo com o que vi aqui, sugiro que você interrompa o processo de backup kafka kill -9 algumas vezes. Eu acho que você pode chegar ao estado :) Eu realmente espero que não esteja relacionado ao eCryptfs ...

Eu vi isso hoje em minha configuração de teste também ... Atualmente não estou conseguindo reproduzi-lo. Vou tentar novamente nos próximos dias ...

Acerte novamente depois de algumas horas de # 88 e um OOM ..

Vi isso hoje à noite no desligamento do serviço de backup kafka antes de fazer o backup do blobstore do Azure:

May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,572] INFO WorkerSinkTask{id=chrono_prod-backup-sink-0} Committing offsets synchronously using sequence number 2782: {xxx-4=OffsetAndMetadata{offset=911115, leaderEpoch=null, metadata=''}, yyy-5=OffsetAndMetadata{offset=11850053, leaderEpoch=null, metadata=''}, [...]
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,622] ERROR WorkerSinkTask{id=chrono_prod-backup-sink-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:179)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: org.apache.kafka.common.errors.WakeupException
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.maybeTriggerWakeup(ConsumerNetworkClient.java:511)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:275)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:233)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:212)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync(ConsumerCoordinator.java:937)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1473)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1431)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommitSync(WorkerSinkTask.java:333)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommit(WorkerSinkTask.java:361)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:432)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions(WorkerSinkTask.java:591)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:196)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:177)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:227)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: #011at java.base/java.lang.Thread.run(Unknown Source)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,634] ERROR WorkerSinkTask{id=chrono_prod-backup-sink-0} Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:180)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,733] INFO Stopped BackupSinkTask (de.azapps.kafkabackup.sink.BackupSinkTask:139)
May 30 19:19:24 backupmgrp1 docker/kafka-backup-chrono_prod[16472]: [2020-05-30 19:19:24,771] INFO [Consumer clientId=connector-consumer-chrono_prod-backup-sink-0, groupId=connect-chrono_prod-backup-sink] Revoke previously assigned partitions [...]

: pensando: talvez eu deva tentar reproduzi-lo deixando executar o Kafka Backup por algumas horas e produzindo muitos dados ... preciso pensar em como depurar isso da maneira mais significativa ...

Acho que ajudaria um pouco se você pudesse monitorar a configuração do Kafka Backup. Talvez vejamos algo útil nas métricas: pensando:

Eu reproduzo o mesmo erro:

[2020-07-10 11:05:21,755] ERROR WorkerSinkTask{id=backup-sink-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask)
java.lang.NullPointerException
    at de.azapps.kafkabackup.sink.BackupSinkTask.close(BackupSinkTask.java:122)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets(WorkerSinkTask.java:397)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions(WorkerSinkTask.java:591)
    at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:196)
    at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:177)
    at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:227)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Estou usando uma configuração de pod en k8s e sistema de arquivos de compartilhamento de arquivos do Azure para armazenar o backup. Vou tentar adicionar alguns logs neste momento.