Melhor lugar para arquivos de log em um ambiente de TI in-house

Question

Todos os meus utilizadores estão a uma curta caminhada pelo corredor, e todos os meus programas são executados em estações de trabalho na mesma LAN. Alguns anos atrás, eu tinha a equipe de gravação dos arquivos de log para todos os seus programas para uma hierarquia de pasta compartilhada, nomeando cada arquivo de log após o nome da máquina em um sub-diretório chamado após a aplicação.

Mas este acordo não foi tão grande, uma vez que se o servidor de arquivos desceu em seguida, nenhum dos programas em qualquer lugar poderia escrever logs. No entanto, manter registos locais para cada estação de trabalho faria uma dor na bunda para lê-los sempre que tínhamos para depurar um problema.

Nós tentamos fazer um alias de DNS para o servidor de arquivos de log para que pudéssemos apontar para uma máquina de backup quando necessário, mas aliases de DNS não funcionam com compartilhamentos de arquivos do Windows.

Colocar o caminho para a pasta log compartilhada em cada programa não é grande - mesmo que seja configurável em campo -. Porque temos dezenas de programas em dezenas de máquinas

Também olhei para usando o sistema de arquivos distribuídos da Microsoft, mas o preço é ridículo.

Eu gostaria de uma maneira de reunir o registro para muitos programas na rede local em um só lugar para que eu possa cauda e analisá-los sem pagar uma visita para a máquina remota. Usamos Net para todos os nossos programas.

Editar: eu gostaria de evitar a criação de um arquivo-share na estação de trabalho de cada usuário, ou soluções que arrasto para registros todas as noites, desde que eu quero ser capaz de ler os registros frescos na demanda , ou momentos depois de um problema é relatado.

Answer 1

Você pode usar MSMQ . Escrever seus logs para uma fila MSMQ, e depois ter um serviço que pega esses logs para cima e coloca-los em um banco de dados ou em um arquivo em um local central, se quiser. Não seria instantâneo, mas você poderia dizer que ele seja executado sempre que você deseja obter novas entradas de log. Além disso, ele seria confiável, uma vez que usa MSMQ.

Answer 2

Em um ambiente de TI que eu trabalhei em alguns anos atrás, tivemos cada gravação da máquina, de arquivos de log localmente e limpe-os a cada cinco dias. O servidor teria logar-se todas as noites para pegar os logs mais recentes de cada máquina. Se o servidor caiu, seria apenas pegar dois dias de registros de todos. Se um cliente desceu, é log poderia ser agarrado no dia seguinte também.

Answer 3

Nossa loja tem tido uma boa experiência com o armazenamento de registros em uma tabela de banco de dados. Você pode agendar a limpeza como um trabalho de banco de dados sempre que você sentir como ele, para evitar que ele fique muito grande.

Answer 4

Nós usamos a abordagem de log para um local conhecido localmente que é compartilhada. Então é fácil ter um segundo processo de puxar esses logs para processamento posterior (despejo de banco de dados, coleta e arquivo etc). Se as matrizes processo de coleta, então nada é realmente é afetado.

Certifique-se de que você não tem um ponto central de falha. Eu vi exemplos disso que usou um banco de dados de registro central que todos os aplicativos dependia e quando ele desceu tudo mais fez também. Não inteligente.

Answer 5

Você pode ter os arquivos de log escritos para máquina local das pessoas e, em seguida, ter um script que puxa-los para um servidor de arquivos comum como um trabalho em lotes noturno?

Answer 6

Que tal ter logger do seu aplicativo como um serviço de assinante (usando comunicação remota). Em seguida, implementar LogServers que subscrevem a aplicação. Quando o aplicativo tem algo para registro, ele envia para os assinantes. Se houver um problema, como o assinante não responder / morto e você assinantes, gravação não trabalhando localmente, mas soar um alarme. Por exemplo. uma versão multi-máquina das classes TraceListener e depuração.

Você quase certamente deseja que o aplicativo para enviar mensagens de log de um thread diferente para o resto de sua aplicação.

Answer 7

DFS está incluído no Windows Server, e você pode < a href = "http://support.microsoft.com/default.aspx?scid=kb;en-us;281308&Product=win2000" rel = "nofollow noreferrer"> regedit para habilitar NetBIOS com um CNAME.

Eu também tentei Splunk para puxar e log analisar arquivos, mas é um pouco de uma CPU porco e eu não poderia poupar o cavalo-vapor. Caso contrário, porém, era um produto muito bom.

Answer 8

Nós escrevemos uma única aplicação que hospeda outras aplicações (plug-in arquitetura). Quando ocorre uma exceção, as informações necessárias são gravados em um arquivo XML na máquina do usuário (que é nomeado .xml). Ou sobre o nosso pedido ou quando sai do aplicativo, ele envia o XML a um serviço web, onde ele grava os arquivos para um local onde podemos ir e verificá-los.

Se o serviço web é baixo, ele não é grande coisa desde que o arquivo XML ainda está na máquina do usuário e vai ficar carregado na próxima vez que executar o aplicativo.

Answer 9

gravação para um banco de dados também (como CALMA ), assim você só tem que vasculham a log arquivos quando o banco de dados estava para baixo

Answer 10

Eu concordo com craigb 's comentários. Criação de pontos únicos adicionais de falha deve ser evitado em um ambiente de LAN.

A minha preferência é ter registrar os clientes localmente, e depois copiar esses arquivos de log para um local central. Neste caso, se o seu servidor de log cai então não haverá qualquer interrupção grave. Além disso, às vezes escrevendo um arquivo de log para uma rede pode ser gargalo de desempenho.

Outro problema com o servidor de log central é se misbehaves uma aplicação, ele pode derrubar todos os apps. Já vi inúmeros erros, que, quando encontrados causa o programa para inserir um loop infinito e vomitar Registra mensagens até que o dispositivo enche.

Se você realmente, quer o registo central, por razões de conformidade ou qualquer outra coisa, eu seria ou gravação para uma unidade de rede, ou escrever para o soquete na forma de syslogd . Desde syslogd é bastante padrão, você não deve ter nenhum problema definindo um up em um servidor, e há uma abundância de exemplos de código e bibliotecas para escrever a ele. Pode-se até configurar um equilíbrio de carga de hardware para se sentar na frente de dois ou mais syslogd servidores, proporcionando maior disponibilidade do serviço.