administración de registros de Linux

una práctica recomendada clave para el registro es centralizar o agregar sus registros en una sola ubicación, especialmente si tiene varios servidores o niveles de arquitectura. Las aplicaciones modernas a menudo tienen múltiples niveles de infraestructura que pueden incluir una combinación de servidores locales y servicios en la nube. Tratar de encontrar el archivo correcto para solucionar un error sería increíblemente difícil, y tratar de correlacionar problemas entre sistemas sería aún más difícil., No hay nada más frustrante que descubrir que la información que quería no se capturó en un archivo de registro, o que el archivo de registro que podría haber mantenido la respuesta se perdió después de reiniciar el servidor.

esta sección explica cómo usar los servicios de centralización para recopilar y centralizar sus archivos de registro de Linux.

beneficios

beneficios de centralizar los registros

centralizar los registros hace que la búsqueda a través de los datos de registro sea más fácil y rápida, ya que todos los registros son accesibles en una sola ubicación., En lugar de adivinar qué servidor tiene el archivo correcto, simplemente puede acceder a su repositorio de datos de registro para buscar eventos relevantes. La centralización es una parte clave de las grandes soluciones de administración, ya que les permite analizar, analizar e indexar registros antes de almacenarlos en una sola ubicación. Esto hace que la solución de problemas y la resolución de problemas de producción sea más fácil y rápida. La centralización también ofrece estos beneficios.

• Los registros se respaldan en una ubicación separada, protegiéndolos contra pérdidas accidentales o no intencionales., Esto también los mantiene accesibles en caso de que sus servidores se caigan o dejen de responder.
• no tiene que usar comandos SSH o grep ineficientes, que pueden usar valiosos recursos informáticos para búsquedas complejas.
• Puede reducir la cantidad de espacio en disco utilizado por los archivos de registro.
• Los ingenieros pueden solucionar problemas de producción sin tener acceso directo a los sistemas.

si bien la gestión centralizada de registros es generalmente la mejor opción, todavía hay algunos riesgos, como una mala conectividad de red que conduce a la pérdida de datos, o registros que utilizan una gran cantidad de ancho de banda de red., Discutiremos cómo abordar estos problemas de manera inteligente en las secciones a continuación.

popular

herramientas populares para centralizar registros

La mayoría de los sistemas Linux ya centralizan registros usando un demonio syslog. Como explicamos en la sección Fundamentos del Registro de Linux, syslog es un servicio que recopila archivos de registro de servicios y aplicaciones que se ejecutan en el host. Puede escribir esos registros en un archivo, o reenviarlos a otro servidor a través del protocolo syslog., Hay varias implementaciones de syslog que puede usar, incluyendo:

• Rsyslog-un demonio ligero instalado en la mayoría de las distribuciones de Linux.
• syslog-ng – el segundo demonio syslog más popular para Linux.
• logstash-un agente de mayor peso que puede hacer un procesamiento y análisis más avanzados. Puede leer mensajes syslog usando el plugin de entrada syslog y reenviarlos a cualquier número de destinos de salida.
• fluentd-otro agente con capacidades de procesamiento avanzadas. También soporta la entrada syslog usando el plugin in_syslog.,

Rsyslog es la implementación syslog más popular y viene instalada por defecto en muchas distribuciones de Linux. Si necesita capacidades de filtrado más avanzadas o de análisis personalizado, Logstash es la siguiente opción más popular. Logstash también está estrechamente integrado con Elastic Stack, que proporciona una solución completa de gestión de Registros. Para esta guía, nos centraremos en usar rsyslog ya que es tan ampliamente utilizado.

config

Configurar Rsyslog.conf

el archivo de configuración principal de rsyslog se encuentra en /etc/rsyslog.conf., Puede almacenar archivos de configuración adicionales en /etc / rsyslog.d/ directorio. Por ejemplo, en Ubuntu, este directorio contiene /etc/rsyslog.d/50-default.conf, que indica a rsyslog que escriba los registros del sistema en un archivo. Puede leer más sobre los archivos de configuración en la documentación de rsyslog.

configurar rsyslog implica configurar fuentes de entrada (donde rsyslog recibe registros), así como reglas de destino para dónde y cómo se escriben los registros. Rsyslog ya proporciona valores predeterminados para recibir eventos de syslog, por lo que normalmente solo necesita agregar su servidor de centralización como salida., Rsyslog utiliza RainerScript para su sintaxis de configuración. En este ejemplo, estamos reenviando nuestros registros al servidor en central.example.com sobre el puerto TCP 514.

action(type="omfwd" protocol="tcp" target="central.example.com" port="514")

alternativamente, podríamos enviar nuestros registros a una solución de administración de Registros. Los proveedores de administración de registros basados en la nube como SolarWinds ® Loggly ® le proporcionarán un nombre de host y un puerto al que puede enviar sus registros simplemente cambiando los campos target y port. Consulte la documentación de su proveedor al configurar rsyslog..,

direct

archivos y directorios de Registro

Rsyslog proporciona el módulo imfile, que le permite monitorear archivos de registro para nuevos eventos. Esto le permite especificar un archivo o directorio como fuente de registro. Rsyslog puede monitorear archivos individuales, así como directorios completos.

por ejemplo, queremos monitorear los archivos de registro creados por el servidor Apache. Podemos hacerlo creando un nuevo archivo en /etc/rsyslog.d/ llamado apache.conf, cargar el módulo imfile y agregar los archivos de registro de Apache como entradas.,

El parámetro File admite comodines para monitorear varios archivos, así como directorios.

protocolo

Qué Protocolo: UDP, TCP, o RELP?

hay tres protocolos principales entre los que puede elegir al transmitir datos de registro: UDP, TCP y RELP.

UDP envía mensajes sin garantizar la entrega o un acuse de recibo (ACK). Hace un solo intento de enviar un paquete, y si la entrega falla, no lo vuelve a intentar. Es mucho más rápido y utiliza menos recursos que otros protocolos, pero solo debe usarse en redes confiables como localhost., UDP tampoco admite el cifrado de Registros.

TCP es el protocolo más utilizado para la transmisión a través de Internet, ya que requiere un ACK antes de enviar el siguiente paquete. Si la entrega falla, continuará volviendo a intentarlo hasta que entregue correctamente el mensaje. Sin embargo, TCP requiere un apretón de manos y una conexión activa entre el remitente y el receptor, que utiliza recursos de red adicionales.

RELP (Reliable Event Logging Protocol) está diseñado específicamente para rsyslog y es posiblemente el más confiable de estos tres protocolos., Reconoce la recepción de datos en la capa de aplicación y volverá a enviar si hay un error. Dado que es menos común, deberá asegurarse de que su destino también admita este protocolo.

si rsyslog encuentra un problema al almacenar registros, como una conexión de red no disponible, pondrá en cola los registros hasta que se restaure la conexión. Los registros en cola se almacenan en memoria de forma predeterminada. Sin embargo, la memoria es limitada y si el problema persiste, los registros pueden exceder la capacidad de memoria, lo que puede conducir a la pérdida de datos. Para evitar esto, considere usar colas de disco.,

advertencia: puede perder datos si almacena registros solo en memoria.

que

envío fiable con colas asistidas por disco

Rsyslog puede poner en cola sus registros en el disco cuando la memoria está llena. Las colas asistidas por disco hacen que el transporte de Registros sea más confiable. Aquí hay un ejemplo de cómo configurar una regla de reenvío de registros en rsyslog con una cola asistida por disco.

cifrar

cifrar registros usando TLS

Cuando la seguridad y Privacidad de los datos es una preocupación, debe considerar cifrar sus registros. Los rastreadores y los intermediarios podrían leer sus datos de registro si los transmite a través de Internet en texto claro., Debe cifrar sus registros si contienen información privada, datos de identificación confidenciales o datos regulados por el Gobierno. El demonio rsyslog puede cifrar sus registros utilizando el protocolo TLS y mantener sus datos más seguros.

el proceso de habilitar el cifrado TLS depende de su configuración de registro. Generalmente, implica los siguientes pasos.

1. Crear una Autoridad de certificación (CA). Hay certificados de muestra en el directorio /contrib/gnutls de rsyslog, que son buenos solo para probar, pero necesita crear el suyo propio para la producción., Si está utilizando un servicio de administración de Registros, tendrá uno listo para usted.
2. genere un certificado digital para su servidor para habilitar TLS, o use uno de su proveedor de servicios de administración de Registros.
3. Configure su servicio rsyslog para enviar datos cifrados con TLS a su servicio de administración de Registros.

Aquí hay un ejemplo de configuración de rsyslog con cifrado TLS. Reemplace CERT y DOMAIN_NAME con su propia configuración de servidor.,

$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt$ActionSendStreamDriver gtls$ActionSendStreamDriverMode 1$ActionSendStreamDriverAuthMode x509/name$ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com

Los servicios de administración de Registros como SolarWinds Loggly a menudo proporcionan sus propias CA y certificados, que simplemente necesita hacer referencia en su configuración de rsyslog. Por ejemplo, habilitar TLS con Loggly solo requiere que descargue el certificado Loggly a su /etc / rsyslog.D / directory, actualice su configuración y reinicie el servicio rsyslog.

primero, descargue el certificado.

$ mkdir -pv /etc/rsyslog.d/keys/ca.d$ cd /etc/rsyslog.d/keys/ca.d$ curl -O https://logdog.loggly.com/media/logs-01.loggly.com_sha12.crt

a continuación, abra el archivo de configuración/etc/rsyslog.d/22-loggly.conf y agregue lo siguiente:

finalmente, reinicie rsyslog.,

$ sudo service rsyslog restart

practice

mejores prácticas para el registro de aplicaciones

Además de los registros que Linux crea de forma predeterminada, también es una buena idea centralizar los registros de aplicaciones importantes. Casi todas las aplicaciones de servidor basadas en Linux escriben su información de estado en archivos de registro separados y dedicados. Esto incluye productos de base de datos como PostgreSQL o MySQL, servidores web como Nginx o Apache, firewalls, servicios de impresión y uso compartido de archivos, servidores de directorio y DNS, etc.

Lo primero que hacen los administradores después de instalar una aplicación es configurarla., Las aplicaciones Linux suelen tener un .archivo conf en algún lugar dentro del directorio /etc. También puede estar en otro lugar, pero ese es el primer lugar donde la gente busca archivos de configuración. Dependiendo de cuán compleja o grande sea la aplicación, el número de parámetros configurables puede ser pequeño o en cientos. Consulte la documentación de la aplicación para obtener más información, o utilice el comando localizar para intentar encontrar el archivo usted mismo.

# locate postgresql.conf/usr/pgsql-9.4/share/postgresql.conf.sample/var/lib/pgsql/9.4/data/postgresql.conf

establecer una ubicación estándar para los archivos de Registro

Los sistemas Linux suelen guardar sus archivos de registro en el directorio /var/log., Esto funciona bien, pero compruebe si la aplicación guarda en un directorio específico bajo /var/log. Si lo hace, genial. Si no, es posible que desee crear un directorio dedicado para la aplicación en /var/log. ¿Por qué? Esto se debe a que otras aplicaciones también guardan sus archivos de registro en /var/log y si su aplicación guarda más de un archivo de Registro, tal vez una vez al día o después de cada reinicio del servicio, puede ser un poco difícil rastrear a través de un directorio grande para encontrar el archivo que desea.,

Si tiene más de una instancia de la aplicación ejecutándose en su red, este enfoque también es útil. Piense en una situación en la que puede tener una docena de servidores web funcionando en su red. Si sus registros están almacenados en un servidor syslog central, ¿cómo sabe qué archivo de registro contiene los registros de qué servidor? Al registrar cada servidor en un directorio separado, sabe exactamente dónde buscar al solucionar problemas de cualquier servidor.

Use un nombre de Archivo Estático

muchas aplicaciones agregan datos dinámicos a su nombre de archivo de registro, como la fecha o la marca de tiempo actuales., Esto es útil para dividir automáticamente los registros por fecha, pero hace que sea más difícil para servicios como rsyslog encontrar el archivo más reciente. Un mejor enfoque es utilizar un nombre no cambiante para el archivo de registro y, a continuación, utilizar logrotate para aplicar una marca de tiempo o un número a los archivos de registro más antiguos.

Anexar y rotar Archivos de Registro

Las aplicaciones deben anexar a los archivos de registro existentes en lugar de sobrescribirlos. Esto ayuda a garantizar que se capturan todas las líneas de registro y no se pierden datos, incluso si la aplicación se reinicia. Sin embargo, los archivos de registro pueden llegar a ser muy grandes con el tiempo., Si está tratando de encontrar la causa raíz de un problema, puede terminar buscando a través de decenas de miles de líneas.

recomendamos agregar sus registros a un solo archivo, pero también recomendamos configurar la aplicación para rotar sus archivos de registro cada cierto tiempo. Herramientas como logrotate pueden hacer esto automáticamente copiando el archivo de registro actual a una nueva ubicación, dándole un nombre único y luego truncando el archivo de registro actual., Esto tiene una serie de beneficios que incluyen:

1. Los registros se dividen en archivos por fecha y hora, lo que facilita la búsqueda de registros para una fecha específica
2. Cada archivo de registro es mucho más pequeño, lo que facilita la búsqueda y el envío a través de una red
3. Hacer copias de seguridad de los archivos de registro es mucho más fácil, y eliminar o archivar registros antiguos se puede hacer mucho más rápidamente

la frecuencia con la que rotas los archivos de registro depende de cuántos registros generes. Como regla general, comience rotando sus registros una vez al día.

establecer políticas de retención de archivos de Registro

¿cuánto tiempo se conserva un archivo de registro?, Eso definitivamente se reduce a los requisitos comerciales. Se le podría pedir que mantenga el valor de una semana de información de registro, o puede ser un requisito regulatorio mantener el valor de 10 años de datos. Sea lo que sea, los registros deben ir desde el servidor en un momento u otro.

en nuestra opinión, A menos que se requiera lo contrario, debe mantener al menos un mes de archivos de registro en línea, además de copiarlos en una ubicación secundaria (como un servidor de registro). Cualquier cosa más antigua que eso se puede descargar a un medio separado. Por ejemplo, si está en AWS, sus registros más antiguos se pueden copiar en Glacier.,

almacenar archivos de registro en una unidad separada

Los archivos de registro se escriben constantemente, lo que puede conducir a altas e / s de disco en sistemas ocupados. Como práctica recomendada, debe montar /var/log en un dispositivo de almacenamiento separado. Esto evita que las Escrituras de archivos de registro interfieran con el rendimiento de sus aplicaciones, especialmente en el almacenamiento basado en disco. Esto también evita que los archivos de registro llenen toda la unidad en caso de que se vuelvan demasiado grandes.

formatee sus entradas de Registro

¿Qué información debe capturar en cada entrada de registro?

eso depende de para qué desea usar el registro., ¿Desea usarlo solo con fines de solución de problemas o desea capturar todo lo que está sucediendo? ¿Es un requisito legal capturar lo que cada usuario está ejecutando o viendo?

si está utilizando registros con fines de solución de problemas, guarde solo errores, advertencias o mensajes fatales. No hay razón para capturar mensajes de depuración, por ejemplo. La aplicación puede registrar mensajes de depuración de forma predeterminada, u otro administrador puede haber activado esto para otro ejercicio de solución de problemas, pero debe desactivarlo porque definitivamente puede llenar el espacio rápidamente., Como mínimo, capture la fecha, la hora, el nombre de la aplicación del cliente, la IP de origen o el nombre del host del cliente, la acción realizada y el mensaje en sí.

por ejemplo, considere el comportamiento de registro predeterminado de PostgreSQL. Los registros se almacenan en /var/log/postgresql, y cada archivo comienza con postgresql, seguido de la fecha. Los archivos se rotan diariamente, y los archivos más antiguos se agregan con un número basado en cuándo se rotaron. Cada línea de registro puede tener un prefijo con campos como la marca de tiempo actual, el usuario actual, el nombre de la base de datos, el ID de la sesión y el ID de la transacción., Puede cambiar estas configuraciones editando el archivo de configuración de PostgreSQL (/etc/postgresql/11/main/postgresql.conf en Debian).

de forma predeterminada, cada línea de registro muestra la marca de tiempo y el ID de proceso de PostgreSQL seguido del mensaje de registro.

supervisar los archivos de registro con Imfile

tradicionalmente, la forma más común para que las aplicaciones registren sus datos es con archivos. Los archivos son fáciles de buscar en una sola máquina, pero no se escalan bien con más servidores. Con rsyslog, puede monitorear los cambios en los archivos e importar nuevos eventos en syslog, donde luego puede reenviar los registros a un servidor centralizado., Esto se hace usando el módulo imfile. Para habilitar el módulo, cree un nuevo archivo de configuración en /etc/rsyslog.d/, luego agregue una entrada de archivo como esta.

Agregue sus flujos de salida después de esta configuración, y rsyslog enviará registros desde el archivo especificado al destino de salida.

registro directamente en el zócalo Syslog con Imuxsock

un zócalo es similar a un controlador de archivo UNIX, excepto que lee los datos en la memoria en lugar de escribirlos en el disco. En el caso de syslog, esto le permite enviar registros directamente a syslog sin tener que escribirlos en un archivo primero.,

este enfoque hace un uso eficiente de los recursos del sistema si su servidor está limitado por e/s de disco o si no necesita registros de archivos locales. La desventaja de este enfoque es que el socket tiene un tamaño de cola limitado. Si su demonio syslog se cae o no puede seguir el ritmo, entonces podría perder datos de registro.

para habilitar el registro de sockets en rsyslog, agregue la siguiente línea a su configuración de rsyslog (está habilitada de forma predeterminada).

$ModLoad imuxsock

esto crea un socket en /dev/log socket de forma predeterminada, pero puede cambiar esto modificando SysSock.Name parámetro., También puede configurar opciones como limitación de velocidad y control de flujo. Para obtener más información, consulte la documentación de rsyslog imuxsock.

registros UDP con Imupd

algunas aplicaciones generan datos de registro en formato UDP, que es el protocolo estándar al transferir archivos de registro a través de una red o su host local. Su demonio syslog recibe estos registros y puede procesarlos o transmitirlos en un formato diferente. Alternativamente, puede enviar los registros a otro servidor syslog o a una solución de administración de Registros.,

utilice el siguiente comando para configurar rsyslog para aceptar datos syslog sobre UDP en el puerto estándar 514.

$ModLoad imudp$UDPServerRun 514

Administrar la Configuración en Muchos Servidores

Cuando usted tiene unos pocos servidores, puede configurar manualmente el registro en ellos. Una vez que tenga unas pocas docenas o más servidores, puede aprovechar las herramientas que lo hacen más fácil y escalable. A nivel básico, el objetivo de cada herramienta es habilitar syslog en cada uno de sus servidores, aplicar una configuración y garantizar que los cambios surtan efecto.,

Pssh

Pssh (o SSH paralelo) le permite ejecutar un comando ssh en varios servidores en paralelo. Utilice una implementación pssh solo para un pequeño número de servidores. Si uno de sus servidores falla, entonces tiene que ssh en el servidor fallido y hacer la implementación manualmente. Si tiene varios servidores fallidos, la implementación manual en ellos puede tardar mucho tiempo.

Puppet/Chef

Puppet y Chef son herramientas de gestión de configuración que pueden configurar automáticamente todos sus servidores y llevarlos al mismo estado. Pueden monitorear sus servidores y mantenerlos sincronizados., Puppet y Chef son potentes herramientas capaces de instalar software, crear archivos, reiniciar servicios y más. Si no está seguro de cuál es la más adecuada para su administración de configuración de implementación, puede apreciar la comparación de InfoWorld de las dos herramientas.

algunos proveedores también ofrecen módulos o recetas para configurar syslog. Por ejemplo, Loggly proporciona un módulo Puppet que utiliza rsyslog para reenviar automáticamente los registros de sus agentes. Instale el módulo Loggly Puppet en su Puppet master y, a continuación, añada la siguiente configuración al Manifiesto de Puppet.,

 # Send syslog events to Loggly class { 'loggly::rsyslog': customer_token => 'YOUR_CUSTOMER_TOKEN', }

Una vez que sus agentes se actualicen, comenzarán a iniciar sesión en Loggly.

Kubernetes

Kubernetes es una herramienta de orquestación para administrar contenedores en varios nodos. Kubernetes proporciona una arquitectura de registro completa que recopila y escribe automáticamente registros de contenedores en un archivo en el equipo host. Puede ver los registros de un Pod específico ejecutando el comando kubectl logs <pod name>, que es útil para acceder a los registros de aplicaciones en un servidor remoto.,

muchas soluciones de administración de registros proporcionan agentes que se pueden implementar en Kubernetes para recopilar registros de aplicaciones y registros de host. Por ejemplo, Loggly proporciona un DaemonSet que implementa un Pod de registro en cada nodo de un clúster. El Pod recopila registros de otros Pods y del propio host, e implementarlo como un DaemonSet ayuda a garantizar que siempre haya una instancia ejecutándose en cada nodo. Registrar un clúster de Kubernetes con Loggly es tan fácil como ejecutar los siguientes comandos.

Docker

Docker utiliza contenedores para ejecutar aplicaciones independientes del servidor subyacente., A menudo se usa como tiempo de ejecución del contenedor para orquestadores como Kubernetes, pero se puede usar como una plataforma independiente. ZDNet tiene un artículo en profundidad sobre el uso de Docker en su centro de datos.,

Hay varias maneras de registrar desde contenedores Docker, incluyendo:

• registro a través del controlador de Registro Docker al sistema host (el método recomendado)
• enrutar todos los registros de contenedores a un único contenedor de registro dedicado (así es como funciona el contenedor logspout)
• registro a un contenedor de registro sidecar
• agregar un agente de registro al contenedor

También puede usar contenedores Docker para recopilar registros del host., Si su contenedor tiene un servicio syslog en ejecución, puede enviar registros desde el host al contenedor a través de syslog, o montar los archivos de registro del host dentro del contenedor y usar un agente de monitoreo de archivos para leer los archivos.

agentes o Scripts de proveedores

La mayoría de las soluciones de administración de Registros ofrecen scripts o agentes para que el envío de datos desde uno o más servidores sea relativamente fácil. Los agentes pesados pueden utilizar recursos adicionales del sistema. Algunos proveedores se integran con los demonios rsyslog existentes para reenviar registros sin usar significativamente más recursos., Loggly, por ejemplo, proporciona un script que reenvía los registros de rsyslog a los servidores Loggly ingestion utilizando el módulo omfwd.