¿Cómo implementó la administración de registros en sus servidores?

Estoy tratando de descubrir cómo otras personas implementan sus sistemas de administración de registros.

Tengo 20-30 servidores Linux y algunas cajas de Windows (la mayoría de ellas virtualizadas). Utilizamos muchos scripts de Perl y Bash para hacer la mayoría de nuestros trabajos automatizados y estoy tratando de estandarizar su registro.

He estado buscando en log4perl y log4sh el registro de scripts y syslog-ng para obtener todos los registros en un servidor de registro centralizado. También he leído sobre splunk, aunque parece que la edición empresarial es bastante costosa y podría superar el límite de licencia gratuita con todos mis servidores.

He visto otras herramientas como muestra y logcheck, pero no estoy muy seguro de cómo encajan todas estas piezas ... ¡Cualquier recomendación sería muy apreciada!

Tengo unos 30 servidores, y solo uso syslog directo para enviar todos los registros a un único servidor de registro. Para la copia de seguridad, todas las máquinas también están configuradas para almacenar sus propios registros localmente durante unos días, utilizando logrotate para encargarse de la rotación y eliminación de registros antiguos.

Cada uno de mis servidores de aplicaciones ejecuta una pequeña secuencia de comandos perl para enviar sus registros a syslog, que luego reenvía a loghost (secuencia de comandos perl a continuación).

Luego, en el registro, tenemos algunos scripts personalizados que son similares al logcheck que básicamente observan los registros entrantes en busca de algo sospechoso.

También tenemos todos los correos electrónicos de cada host que van a un lugar, de modo que si algún programa se queja de esa manera, recibimos todos los mensajes. En teoría, esto podría ir a un único buzón en el que un programa podría actuar y analizar.

Aquí está mi script perl de registro. Funciona canalizando la salida del programa en él, y luego syslogs la salida y la escupe de nuevo para que pueda enviarla a otro lugar (envío a multilog). También puede darle la opción -q para ir a syslog.

#!/usr/bin/perl

use Sys::Syslog;
use Getopt::Long;

$SERVER_NAME = `hostname`;
chomp $SERVER_NAME;
$FACILITY = 'local0';
$PRIORITY = 'info';

GetOptions ('s=s' => \$SERVER_NAME, 'f=s' => \$FACILITY, 'p=s' => \$PRIORITY, 'q+' => \$quiet);

#print "$SERVER_NAME\n$FACILITY\n$PRIORITY\n";

#Sys::Syslog::setlogsock('unix');
openlog ($SERVER_NAME,'ndelay',$FACILITY);

if (!($quiet)) {syslog($PRIORITY,"Logging Started -- Logger version 1.1");}

$| = 1;

while (<>) {
    if (!($quiet)) {print $_ unless $_ =~ /^\s+$/};
    chomp;
    syslog($PRIORITY,$_) if $_;
}

closelog;

$| = 0;

Aunque todavía no lo he implementado, planeo mover todas mis máquinas generadoras de registros a rsyslog e implementar un servidor de tipo bastión que funcionará como el recopilador de registros del sistema. A partir de ahí, creo que la versión gratuita de Splunk puede hacer todo lo que necesito para extraer información.

Ahora solo para implementarlo ...

Yo uso un host syslog central. Cada sistema de borde envía * .debug al loghost central. El host central de syslog ejecuta syslog-ng y tiene reglas para dividir los registros para que cada máquina genere sus propios archivos nombrados para ese día. También descarga todo en un solo archivo, contra el cual ejecuto un descendiente de logcheck.sh.

Una vez al día ejecuto un compactador de registros, que comprime todos los registros anteriores a 7 días y elimina cualquier cosa anterior a 28 días. Entre los dos, proporciona a los registros una vida útil esperada de 35 días en el servidor, lo que significa que todos los registros deben llegar a copias de seguridad mensuales, donde pueden recuperarse hasta por dos años.

Es de almacenamiento intenso, pero parece ser la mejor manera de asegurar la cobertura.

Para el registro centralizado, recomendaría LogZilla . Lo hemos estado usando durante más de un año y nos encanta. La interfaz de usuario es extremadamente fácil de aprender y usar e instalar me llevó aproximadamente una hora.

Incluso si no lo hace, realmente debería intentar alejarse de la supervisión basada en scripts, ya que eso es exactamente lo que obtiene ... la supervisión. Lo que debe tratar de lograr es la gestión. La reparación de problemas en Top Talkers, etc. reducirá en gran medida la cantidad de "incendios" provocados por la supervisión basada en script. Aquí hay un muy buen artículo sobre la administración de syslog:

http://www.cisco.com/en/US/technologies/collateral/tk869/tk769/white_paper_c11-557812.html

Utilizamos un dispositivo de LogLogic para nuestro registro empresarial. Se basa en syslog, por lo que todos los cuadros * nix no tienen problemas para usarlo; Hay una pequeña aplicación que debe instalarse en los servidores de Windows. Puedo buscar cualquier cosa que desee, incluidas las consultas REGEX, y parece ser capaz de manejar una gran cantidad de carga (nuestra configuración de Active Directory solo genera una cantidad alucinante de tráfico).

Para el servidor de registro centralizado, puede echar un vistazo a mi proyecto Octopussy .

Al principio es mucho trabajo, ¡pero después de que puedas hacer muchas cosas con estos registros!

Aquí hay un tutorial que escribí que cubre todos los aspectos del registro y análisis centralizado.

Enlace: http://crunchtools.com/centralizing-log-files/