Saudações !!!
Trata-se de um requisito específico sobre o rsync que estamos tentando alcançar. Tentamos conseguir isso usando várias opções de rsync. No entanto, estamos encontrando problemas diferentes com diferentes opções de rsync.
Antecedentes: • Temos logs de um processo (em execução no AIX) dos quais estão sendo registrados em A.log (presente no diretório logs). • A.log é rotacionado para A.CURRENT_DATE_TIME.log quando atinge 100 MB e um novo A.log é criado. • Estamos transferindo esses logs para um servidor centralizado usando rsync. Estamos usando o rsync no diretório de logs completo. • INODE dos arquivos no servidor de origem e no servidor de destino são diferentes. • Uma vez que os logs estejam no servidor centralizado, a ideia é fazer com que esses logs sejam lidos/indexados por um processo de log centralizado que coletará a entrada deste servidor centralizado.
Problema: • Embora A.log (servidor de destino) seja fornecido como entrada para o processo de log centralizado, ele considera o INODE do arquivo e não o nome real do arquivo. • Assim, quando o arquivo A.log é transferido, o novo A.log possui um novo INODE que não é detectado pelo processo centralizado. Isso estava acontecendo quando estávamos usando as opções -u –r –t com rsync. Portanto, neste caso, o INODE do arquivo estava mudando sempre que o rsync acontecia e também quando acontecia o rollover. Conseqüentemente, o processo interrompe a indexação enquanto procura o INODE antigo que não está presente.
• A ideia é usar o rsync com uma combinação de opções que não alterariam o INODE do arquivo no momento do rsync, mas deveriam alterar o INODE no momento do rollover quando A.log gira para A.CURRENT_DATE_TIME.log. Portanto, para conseguir isso, incluímos a opção –inplace e podemos reter o INODE nas alterações de rsync e INODE no momento da rotação do arquivo. No entanto, isso nos dá um problema diferente agora, onde o nome do arquivo não muda e sempre permanece A.log. Assim que o processo terminar de indexar o A.log, ele será interrompido.
Seria ótimo se alguém pudesse sugerir algo que pudesse nos ajudar a atingir os requisitos mencionados.
Atenciosamente, Administrador de Middleware Puneet Sinha
Responder1
Eu não recomendo confiar no inode. Ele mudará sempre que o arquivo for movido da máquina de origem para a máquina de destino. Também mudará se os arquivos forem restaurados de backups. Se o sistema de processamento de log depender do inode, se você restaurar a partir de backups, o sistema não funcionará conforme o esperado.
Minha recomendação é NÃO copiar A.log, mas apenas copiar A.CURRENT_DATE_TIME.log. Isso simplificará o projeto.
Suspeito que o sistema de processamento de log no servidor de destino esteja examinando o inode para determinar se o arquivo visto anteriormente como A.log agora é A.CURRENT_DATE_TIME.log. Isso não será confiável.
A solução acima tem 1 problema: O tempo que leva para uma linha no arquivo de log ser gerada até o momento em que é processada pelo processo de log centralizado aumentará. Por exemplo, se levar 3 dias para A.log crescer para 100 MB, nada desse arquivo entrará no processo de log centralizado por até 3 dias. Se os logs não puderem ser atrasados por mais de 2 horas, eu os rotacionaria a cada 1 hora. Dessa forma, você sabe que está dentro do objetivo de 2 horas.