4.3.1.1. Sistema tradicional¶
En este sistema los registros se almacenan bajo /var/log
a través de una
doble vía:
Los mensajes de algunas aplicaciones se envían a un demonio encargado de procesarlos para que este los escriba en el log correspondiente.
Otras aplicaciones escriben directamente los mensajes en sus propios ficheros de registro (que, por lo general, también están bajo
/var/log
).
En los sistemas debian este demonio se llama rsyslog, que es una variante avanzada del tradicional syslogd. El resto del epígrafe se dedicará a describir cómo se clasifican los logs y qué hace con ellos el deminio que los gestiona.
4.3.1.1.1. Clasificación¶
Es obvio que todos los mensajes ni tienen la misma naturaleza ni tienen la misma gravedad. Por este motivo, cada mensaje es de una determinada facility (o sea, de una determinada categoría o naturaleza, si queremos traducir libremente al término inglés) y de un determinado nivel.
Según su naturaleza los mensajes pueden ser de los siguientes tipos:
Código |
Término |
Linux |
Descripción |
---|---|---|---|
0 |
kern |
Sí |
Mensajes del núcleo |
1 |
user |
Sí |
Mensajes de procesos de usuario |
2 |
Sí |
Mensajes del sistema de correo |
|
3 |
daemon |
Sí |
Mensajes de los demonios del sistema |
4 |
auth[1] |
Sí |
Mensajes de procesos de autenticación. |
5 |
syslog |
Sí |
Mensajes del propio sistema de logs |
6 |
lpr |
Sí |
Mensajes del sistema de impresión |
7 |
news |
Sí |
Mensajes del sistema encargado de acceder a USENET[2] |
8 |
uucp |
Sí |
Mensajes relacionados con el antiguo protocolo UUCP |
9 |
cron |
Sí |
Mensajes de los demonios de planificación de tareas. |
10 |
authpriv |
Sí |
Mensajes de procesos de autenticación |
11 |
ftp |
Sí |
Mensaje del servicio de FTP. |
12 |
ntp |
No |
Mensajes del servicio NTP. |
13 |
logaudit |
No |
Mensajes del servicio audit. |
14 |
logalert |
No |
log alert |
15 |
clock |
No |
Mensajes del demonio del reloj. |
16 |
local0 |
Sí |
Uso local (0) |
17 |
local1 |
Sí |
Uso local (1) |
18 |
local2 |
Sí |
Uso local (2) |
19 |
local3 |
Sí |
Uso local (3) |
20 |
local4 |
Sí |
Uso local (4) |
21 |
local5 |
Sí |
Uso local (5) |
22 |
local6 |
Sí |
Uso local (6) |
23 |
local7 |
Sí |
Uso local (7) |
Y según su nivel:
Valor |
Término |
Descripción |
---|---|---|
0 |
emerg |
Aciso de circunstancia que vuelve inservible el sistema. |
1 |
alert |
Aviso de circunstancia que debe ser inmediatamente subsanada. |
2 |
crit |
Aviso de error crítico. |
3 |
err |
Aviso de error. |
4 |
warning |
Advertencia de que algo puede ir mal o acabar mal. |
5 |
notice |
Notificación de que ocurre algo anormal. |
6 |
info |
Notificación de funcionamiento normal. |
7 |
debug |
Notificaciones para depurar el comportamiento de un programa. |
4.3.1.1.2. Ficheros¶
Bajo /var/log
hay distintos ficheros: algunos debidos a la activdad de
servicios que escriben sus propios registros al margen de rsyslogd y
otros debidos a la actividad de este.
En principio, rsyslog registra todos los mensajes en el fichero /var/log/syslog, pero mediante su configuración puede hacerse que los mensajes dependiendo de su categoría y nivel se escriban en uno u otro fichero particular. Lo habitual es lo siguiente:
syslog
Contiene todos los mensajes, excepto los de autenticación.
auth.log
Contiene los mensajes de autenticación.
kern.log
Contiene todos los mensajes del núcleo[3].
messages
Contiene los mensajes del núcleo de los niveles 4-6 (warning, notice e info).
daemon.log
Contiene los mensajes de la facility daemon.
mail.log
Contiene todos los mensajes relativos al funcionamiento del servicio de correo. Hay otros,
mail.info
,mail.err
ymail.warn
que almacenan su facility correspondiente.user.log
Contiene todos los mensajes de las aplicaciones de usuario.
lpr.log
Contiene todos los mensajes referentes al servicio de impresión.
Esta es la configuración pretederminada en debian. El resto de ficheros que
encontramos, bien se debe a que se haya alterado esta configuración, bien a que
haya otros servicios que registren por su cuenta. Dentro de /var/log
y
entre los ficheros que no gestiona rsyslog, se cuentan:
btmp
Que registra los accesos fallidos al sistema.
wtmp
Que registra los accesos al sistema.
Estos ficheros, a diferencia de los restantes, tienen un formato binario y pueden leerse a través del comando utmpdump:
# utmpdump /var/log/btmp | more
4.3.1.1.3. Consulta¶
Los registros son ficheros de texto plano de modo que el acceso a los mensajes se puede realizar con cualquier orden que permite acceder a su contenido. El simple cat (o more o less, si se quiere paginar) sirve para este propósito. Sin embargo, estos ficheros suelen contener gran cantidad de mensajes de distintos servicios, por lo que lo más adecuado es buscar herramientas que nos permitan filtrar mediante el uso de expresiones regulares.
Para esta labor de filtrado, conviene conocer cuál es el formato que el demonio da a estos mensajes. Tal formato se puede configurar al gusto, pero rsyslog tiene configuradas algunas plantillas de las cuales la predefinida en debian es RSYSLOG_TradicionalFileFormat, que presenta el siguiente aspecto:
<fecha y hora> <nombre_maquina> <nombre_proceso>[<PID>]: <texto del mensaje>
Cuando filtramos, necesitamos conocer cuál es el fichero adecuado y cuál es el conjunto de mensajes que deseamos ver. Por ejemplo, si nuestra intención fuera mirar los mensajes que genera el servidor DHCP, podríamos filtrar del siguiente modo:
# egrep '\bdhcpd\b' /var/log/syslog | more
La información que obtenemos de los registros puede ser muy precisa: basta con ser capaz de formar la expresión regular adecuada. Por ejemplo, todas las IP que ha concedido el servidor DHCP podrían mostrarse de esta forma:
$ sed -r '/\bdhcpd\b.*DHCPACK on/!d ; s:.*DHCPACK on ([^ ]+).*:\1:' /var/log/syslog | sort | uniq
Aunque hay que tener cierto espíritu crítico con lo obtenido. Saldrán en este listado todas las IPs concedidas desde que se empezó a escribir el fichero, con lo que el listado puede no coincidir en absoluto con direcciones IP ocupadas.
4.3.1.1.4. Configuración¶
Nota
Para hacer probaturas es muy útil el comando logger que permite enviar al demonio mensajes de la categoría y nivel que indiquemos:
$ logger -p mail.info -s "Esto es un mensaje manual que escribo yo"
El demonio lee su configuración del fichero /etc/rsyslog.conf
. Sin
embargo, puede tener una directiva IncludeConfig que permite leer el
contenido de otros ficheros, de suerte que es común que también exista un
directorio /etc/rsyslog.d
, en el que incluir configuración adicional de
forma modular.
Otro aspecto a tener en cuenta en la definición de este fichero es que desde la versión 6, hay dos sintaxis para el fichero, la tradicional y una nueva.
4.3.1.1.4.1. Tradicional¶
Existen tres tipos de líneas:
Los comentarios, que todas aquellas líneas que empiezan por un asterisco.
Las directivas que empiezan por un dolar.
Las reglas que permiten indicar qué hacer con cada mensaje.
4.3.1.1.4.1.1. Directivas¶
Hay de muy diversos tipos. Algunas muy útiles son:
Hacer escuchar al demonio en un socket adicional (útil cuando tenemos demonios enjaulados):
$AddUnixListenSocket /var/spool/postfix/dev/log
Define el propietario y los permisos de los ficheros (y directorios) que puedan crear las acciones:
# Definimos esta máscara inicial para que # los permisos definidos a continuación sean # los que expresamente indicamos. $Umask 0000 $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755
Estas directivas afectan a todas las acciones que tengan por debajo. Pueden volver a definirse más adelante otra vez y, en ese caso, afectarán a las acciones que se añadan a continuación. Por ejemplo:
$FileCreateMode 0640 *.* /var/log/log1 $FileCreateMode 0644 *.* /var/log/log2
log1
se creará con permisos 0640 ylog2
con permisos 0644.Cargar los ficheros contenidos en
/etc/rsyslog.d
:$IncludeConfig /etc/rsyslog.d/*.conf
Define una plantilla predeterminada para el formato de línea de los ficheros:
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
4.3.1.1.4.1.2. Reglas¶
Las reglas indican qué se hará con cada mensaje. Cada regla consta de dos
partes: el selector, que indica a qué mensajes afecta; y la
acción, qeu indica qué hacer (habitualmente, escribirlos en un
fichero de registro bajo /var/log
.
Para seleccionar mensajes se usan la categoría y el nivel:
Todos los mensajes:
*.*
Todos los mensajes de nivel info:
*.=info
Todos los mensajes hasta el nivel info (es decir, que sólo quedan fuera los de nivel debug*):
*.info
Todos los mensajes de la categoría mail:
mail.*
Los mensajes de la categoría mail y la prioridad info:
mail.=info
Todos los mensajes de las categorías mail y news:
mail,news.*
Los mensajes de las categorías mail y news hasta notice:
mail,news.notice
Los mensajes de la categoría mail y nivel info, y de la categoría news y nivel err:
mail.info;news.=err
Este último ejemplo muestra como hacer la unión de dos selectores
independientes: separarlos con punto y coma. Ahora bien hay forma también de
hacer la diferencia entre dos selectores. Para ello hay que seleccionar primero
un conjunto de mensajes y, tras el punto y coma, seleccionar otro conjunto que
lo contiene, añadiendo a la parte correspondiente al nivel la exclamación (!
)
o el nivel especial none, que implica que se desechan todos los mensajes de la
categoría:
Todos los mensajes exceptos los de authpriv y auth:
*.*;auth,authpriv.none
Todos los mensajes, excepto los de la depuración:
*.*;*.!=debug
Todos los mensajes, excepto los de news hay que estén entre el nivel emerg al nivel warning:
*.*;*.!warning
Por su parte la acción, si lo que se quiere es enviar los ficheros exige escribir la ruta absoluta. Una regla completa quedaría pues así:
auth,authpriv.* /var/log/auth.log
A veces se encuentra antepuesto un signo menos (-
) a la ruta. Esto indicaba
que se quería deshabilitar la sincronización del fichero en cada escritura. En
las versiones modernas de rsyslog la sincronización está deshabilitada por
defecto, con lo que el signo, no tiene ninguna relevancia.
Es importante tener presente que el hecho de que un mensaje se seleccione en una regla, no significa que el demonio ejecute la acción y deje de probar las reglas siguientes. Por ejemplo, las líneas:
auth,authpriv.* /var/log/auth.log
*.* /var/log/syslog
provocarían que los mensajes relacionados con la autenticación se escribieran
también en /var/sys/log
. Ahora bien, si se usa como acción la virgulilla
(~
), entonces sí se desechan los mensajes:
auth,authpriv.* /var/log/auth.log
auth,authoriv.* ~
*.* /var/log/syslog
Sí impediría que se escribieran los mensajes en el segundo registro (y en todos los que se mentaran sucesivamente).
Además, se puede sustituir el selector por el ampersand (&
), lo que
significa que para la nueva acción se usará el mismo selector que para la
anterior. las siguientes líneas tienen el mismo efecto que las anteriores:
auth,authpriv.* /var/log/auth.log
& ~
*.* /var/log/syslog
Por último, para usar un formato de línea distinto en un fichero en particular puede usarse la siguiente sintaxis:
auth,authpriv.* /var/log/auth.log;RSYSLOG_TraditionalFileFormat
4.3.1.1.4.1.3. Nuevo formato¶
A partir de su versión 6, rsyslog usa un nuevo formato (RainerScript) para escribir su configuración, aunque se puede seguir usando el antiguo e incluso incluir sentencias de uno u otro estilo dentro del mismo fichero.
4.3.1.1.5. Rotación¶
Los registros dentro de /var/log
son persistentes, de manera que crecen
indefinidamente, a menos que pongamos los medios para evitarlo. Con este
propósito existe el servicio logrotate.
La rotación de logs consiste en copiar cada cierto tiempo los registros antiguos a otro fichero y vaciar el fichero de registro. Por ejemplo, supongamos que definimos que todos los días se realiza esta rotación. En ese caso ocurrirá lo siguiente:
El primer día tendremos un único fichero
syslog
.El segundo día tendremos dos ficheros
syslog.1
, que contendrá los registros del día anterior; ysyslog
, sin estos registros, empezará a recoger los del día presente.El tercer día, se comprimirá y renombrará
syslog.1
asyslog.2.gz
, el contenido desyslog
pasará asyslog.1
y, una vez vaciadosyslog
se comenzará a registrar en él.El proceso antes descrito se repite todos los días, de manera que cada vez aparecen más ficheros que almacenan registros antiguos de
syslog
. Sin embargo, al programa de rotación se le puede indicar un límite máximo de manera que, pasado este, se desecharán los registros. Si este límite fueran diez días, entonces nunca se llegaría a crearsyslog.10.gz
.
logrotate no es un demonio que se ejecute permanentemente en el
ordenador, sino que en /etc/cron.daily
hay un script que lo invoca a
diario. Su configuración se hace en /etc/logrotate.conf
o, de forma
modular, en ficheros creados dentro de /etc/logrotate.d
.
En logrotate.conf
suele guardarse la configuración predeterminada para
la rotación, mientras que en cada fichero de file:/etc/logrotate.d se guarda
la configuración particular para un registro que no queremos que siga la
predeterminada. Es bastante común que los paquetes de aplicaciones que generan
logs incluyan un fichero particular para los suyos propios.
En /etc/logrotate.conf
podríamos encontrar el siguiente contenido:
# Rotación semanal
weekly
# Conserva 4 semanas
rotate 4
# Compresión (con xz, pero no se comprime por defecto)
#compress
compresscmd /usr/bin/xz
compressext .xz
# Ficheros de configuración modular:
include /etc/logrotate.d
# Rotación para los ficheros wtmp y btmp
# [...]
La rotación de los registros de cada servicio es probable que la encontremos en
un fichero propio dentro de /etc/logrotate.d
. Por ejemplo:
# /etc/logrotate.d/apt
/var/log/apt/*.log {
rotate 12
monthly
compress
notifempty
}
En este ejemplo, cualquier fichero log dentro de /var/log/apt
,
queremos que rote mensualmente (monthly), que se compriman los registros
rotados, y que si el fichero de log está vacío, no se realice rotación
(notifempty).
Algunas de las directivas que podemos incluir son las siguientes:
hourly
,daily
,weekly
,monthly
,yearly
Frecuencia con la que se realizará la rotación.
copytruncate
En vez de mover el fichero y crear uno nuevo, hace copia y trunca a 0. Con esto se consigue que el fichero en el que el servicio apunta los registros sea el mismo, lo cual es necesario si el servicio está activo en todo momento y no podemos reiniciarlo.
create
<permisos> <usuario> <grupo>Indica cómo crear el nuevo fichero después de haber movido el anterior:
create 0640 root adm
delaycompress
Retrasa un ciclo la compresión. Esto hace que la rotación .1 no esté comprimida.
maxsize
<tamaño>Tamaño máximo en bytes que puede alcanzar el registro. Si lo alcanza, se rotará el fichero, aunque no se haya cumplido la frencuencia. Pueden usarse las unidades k, M o G:
maxsize 1M
minsize
<tamaño>Tamaño mínimo en bytes a partir del cual se procederá a la rotación. Si no se ha llegado a este tamaño, no se rotará, aunque toque según la frecuencia.
size
<tamaño>Tamaño a partir del cual se procederá a la rotación. La diferencia con maxsize es que con esta opción no se atiende a la frecuencia en absoluto.
missingok
Si no existe el fichero log no se produce ningún error.
rotate
NNúmero de rotaciones que sufren los registros.
prerotate
/endscript
Ejecuta las órdenes entre estas dos directivas antes de proceder a la rotación.
postrotate
/endscript
Ejecuta las órdenes entre estas dos directivas tras realizar a la rotación:
postrotate invoke-rc.d nginx rotate >/dev/null 2>&1 endscript
sharedscripts
Está relacionado con las dos directivas anteriores. Cuando se incluye, no ejecuta los comandos para la rotación de cada fichero, sino una sola vez para todos los ficheros que se han expresado en el bloque.
Nota
Es preciso indicar explícitamente a través de la configuración que se
quiere rotar un fichero de registro. Dicho de otro modo, logrotate
no rota cualquier fichero que se encuentre bajo /var/log
, sino sólo
aquellos explicitamente citados en su configuración.
Notas al pie