5. Logrotate

logrotate

Fichero de configuración: /etc/logrotate.conf


 

Dependiendo del número de usuarios y el tipo de servicios corriendo, los ficheros de log pueden crecer mucho y rápidamente. Para mantener el sistema libre de basura, se deben crear particiones separadas para /var o /var/log.
Además, existe software que revisa periódicamente los ficheros de logs de acuerdo a varios criterios, como puede ser el tamaño, y recorta o elimina viejos ficheros de log. El proceso es conocido como rotación (rotation), y el programa que lo realiza es logrotate.

Logrotate no es un demonio, si no que normalmente se ejecuta una vez al día utilizando un servicio como cron o similar.

Logrotate rechaza modificar ficheros de log más de una vez al día, excepto si la decisión depende del tamaño del fichero, se está utilizando un criterio horario o la opción –force.

El fichero /etc/logrotate.conf es solamente una convención puesta en marcha por una invoncación de /etc/cron.daily/logrotate (o similar). Posteriormente se procesan todos los ficheros en el directorio /etc/logrotate.d/, al cual se hace una llamada mediante include en el fichero inicial.

Logrotate revisa todos los ficheros que se le solicitan, no solamente aquellos creados por syslogd.

EJEMPLO:

/var/log/syslog
 {
 rotate 7
 mail nanana@batman.es
 daily
 missingok
 notifempty
 delaycompress
 compress
 postrotate
    invoke-rc.d rsyslog rotate >/dev/null
 endscript
 }

· /var/log/syslog: define qué fichero se debe revisar
Pueden enumerarse diversos ficheros o establecer criterios de búsqueda en shell (shell patterns).
Tras esto, entre los corchetes, se puede ver el bloque de directivas que aplicará logrotate.
Normalmente, los ficheros de configuración contienen directivas que están fuera de los corchetes. Éstas se aplican por defecto a todos los ficheros de log, a menos que haya directivas más específicas para dichos ficheros posteriormente entre corchetes.

· rotate 7: deben mantenerse 7 versiones del fichero de log. Si hay más, se eliminan.  Los ficheros rotados son numerados secuencialmente, es decir, si el fichero actual es /var/log/mail, el siguiente es /var/log/mail.1 y así hasta el último permitido.
Se pueden utilizar fechas en vez de números, con la directiva dateext. Los ficheros serían renombrados tal que var/log/syslog-20150719 (19/7/2015)
Usando este método, se puede controlar exactamente cómo se verá el nombre del archivo mediante %Y, %m, %d y %s.
Utilizando dateformat, logrotate ordena los ficheros léxicamente para encontrar el más antiguo. Esto funciona con -%Y%m%d y -%d%m%Y

· mail nanana@batman.es: si se especifica una dirección de correo con ‘mail’, los ficheros no se eliminarán si no que se enviarán a la dirección de email.

· daily: significa que los ficheros deben rotar diariamente.
Existen además hourly, weekly, monthly y yearly.
Weekly realiza la rotación el primer día de la semana en el sistema inglés, el domingo, o si el equipo ha estado apagado, cuando puede siempre que haya transcurrido dicha semana.
Monthly, se rotan los ficheros en la primera ejecución mensual de logrotate.
Yearly realiza la rotación a principios de año.
Hourly presenta el problema de que por defecto, logrotate se ejecuta una vez al día, por lo que se debe buscar la forma de cambiar el período de ejecución.
Un criterio alternativo es size. Rotará el fichero de log cuando exceda un tamaño X definido. Estos tamaños se definen en bytes por defecto, o con K para Kibibytes, M para Mibibytes y G para Gibibytes.
Se pueden utilizar a la vez time y size. Se hace utilizando maxsize, en este caso el fichero se rota al llegar al tamaño máximo incluso si la fecha especificada no ha llegado o minsize, en cuyo caso el fichero solamente será rotado en la fecha especificada si ha excedido el tamaño dado, los ficheros con menor tamaño serán saltados

· missingok: suprime los mensajes de error si un log no es encontrado
La configuración por defecto es nomissingok

· notifempty: no rota los logs si el fichero está vacío. Por defecto se utiliza ifempty, que sí los rota.

· delaycompress: asegura que una rotación realizada recientemente no es comprimida, solamente las que se realizan en rotaciones posteriores, por lo que la secuencia de ficheros se vería tal que así:

history.log  history.log.1  history.log.2.gz  term.log  term.log.1.gz  term.log.2.gz

mientras que por defecto se realiza lo siguiente:

history.log  history.log.1.gz  history.log.2.gz  term.log  term.log.1.gz  term.log.2.gz

Esto se utiliza si hay alguna posibilidad de que, por ejemplo, rsyslog necesite añadir información al fichero despues de haber sido renombrado. Esto puede suceder porque rsyslog mantiene el fichero abierto, y renombrarlo es irrelevante mientras se está escribiend en él.

· compress: permite que los ficheros rotados sean comprimidos. Se realiza por defecto con gzip, a menos que se utilice un método alternativo con compresscmd. Las opciones que deberá utilizar para comprimir (las que se pueden utilizar en línea de comandos) se definen con compressoptions. Por defecto se utiliza -6.

· postrotate: avisa a rsyslog de que hay un nuevo fichero de logs.

· invoke-rc.d rsyslog rotate >/dev/null: Los comandos del shell son ejecutados por logrotate una vez el fichero de log ha sido rotado.
El comando en sí es irrelevante (este es el que utiliza Debian), la idea es que se envíe una señal SIGHUP al programa que está manejando los logs, de forma que se reinicie y relea el fichero de configuración, otras distribuciones tienen métodos diferentes.

Entre postrotate y endscript puede haber varias líneas con scripts que logrotate concatena y las pasa al intérprete por defecto, /bin/sh como un conjunto. El comando pasa el nombre del fichero de log como parámetro, por lo que se puede utilizar la forma $1.

Los comandos a continuación de postrotate son ejecutados una vez por cada fichero de log enumerado al inicio del bloque de configuración. Se puede utilizar la directiva sharedscripts para garantizar que los comandos son ejecutados, como mucho, una vez para los ficheros que coinciden con el patrón, o ninguna, si no necesitan ser rotados.

Se puede utilizar create para asegurarse que el fichero de log es creado automáticamente después que los comandos son ejecutados. Utiliza el nombre del fichero antiguo, se pueden definir de 3 formas diferentes:

create 600 root adm         Con permisos, propietario y grupo
create root adm             Con propietario y grupo
create                      Sin nada

Si no se espefican ningún parámetro, todas las propiedades son tomadas del fichero anterior. Toda la documentación en logrotate(8).

4. Syslog-NG

Syslog-NG

Fichero de configuración: /etc/syslog-ng/syslog.ng.conf


 

Syslog-NG, de next generation, es una reimplementación de syslog retrocompatible. Las principales ventajas respecto a syslogd son:
· filtrado de mensajes basado en su contenido, no sólo en categorías y prioridades
· se pueden encadenar varios filtros
· sistema más sofisticado de entrada/salida, incluyendo el envío mediante TCP y a subprocesos

 

Configuración:
· Opciones globales (Global options): aplica a todas las fuentes de mensajes de syslog-ng
· Fuentes de mensajes (Message sources): syslog-ng puede leer mensajes de un socket o retransmitidos por UDP como syslogd, pero también, por ejemplo, de ficheros FIFO o sockets TCP. A cada fuente se le asigna un nombre.
· Filtros (Filters): expresoines booleanas basadas en funciones interas que puede referirse al origen, categoría, prioridad o contenido textual del mensaje
· Pozos (Message sinks): syslog-ng incluye todos los de métodos d syslogd y algunos más
· Rutas (Log paths): conecta una o más fuentes, filtros y pozos, si un mensaje llega de la fuente y pasa el filto (o filtros) es enviado al pozo específico

 

Opciones:
Se pueden especificar varias opciones globales que controlan el comportamiento o determinan los valores por defecto de una fuente de mensaje o pozo (las opciones específicas tendrán prioridad sobre éstas).
Si syslog-ng en el host A recibe un mensaje del host B, comprueba la opción keep_hostnames(). Si el valor es sí, B guarda el hostname para el log. Si es no, la salida depende de la opción chain_hostnames(), si esta también es no, A se logeará como hostname, si es sí, se guardará el hosname B/A. Particularmente importante si el log se reenvía a otro host.

 

Fuentes de mensaje:
las fuentes se determinan con la palabra clave source. Para hacer lo mismo que en syslog, se puede incluír la siguiente línea en el fichero de configuración:

 source src { unix-stream("/dev/log"); internal(); };

dice a syslog-ng que escuche en el socket /dev/log. internal(). Se refiere a los mensajes que syslog-ng crea por sí mismo.

Una fuente de syslog-ng correspondiente con la opción remota de syslogd (-r) se parecerá a:

 source s_remote { udp(ip(0.0.0.0) port(514)); };
 dado que es la opción por defecto, también puede ser:
 source s_remote { udp(); };

Con la opción ip() se puede forzar escuchar solamente a una ip. No es posible en syslogd.

La siguiente especificación permite a syslog-ng reemplazar al programa klogd:

 source kmsg { file("/proc/kmsg" log_prefix("kernel: ")); };

Todas las fuentes soportan el parámetro log_msg_size(), que especifica el tamaño máximo en bytes.

 

Filtros:
Usados para cribar o distribuir los logs a varios pozos. Utilizan las funciones internas, que consideran diferentes aspectos de los mensajes. Dichas funciones pueden ser unidas con operadores lógicos tales como and, or y not.
EJEMPLO:
Filtro que acepta todos los mensajes del host «nananana» con el mensaje «Batmaaaaaaaaan»

 filter f_nananana { host("nananana") and match ("Batmaaaaaaaaan"); };

Con las funciones level() o priority() se pueden especificar una o más prioridades separadas por comas, o rangos, como warn, crit, emerg, etc.

 

Pozos:
Al igual que las fuentes, los pozos consisten en varios «drivers» que definen los métodos:

destination d_file { file("/var/log/messages"); };

Se pueden especificar plantillas que describen el formato en que el mensaje deberá ser escrito en el pozo en cuestión. Haciendo esto, se pueden definir «macros» que hacen las diferentes partes del mensaje accesible.
EJEMPLO:

 destination d_file {
 file("/var/log/$YEAR.$MONTH.$DAY/messages"
 template("$HOUR:$MIN:$SEC $TZ $HOST [$LEVEL] $MSG\n")
 template_escape(no)
 create_dirs(yes)
 );
 };

Las macros $YEAR, $MONTH, etc. serán reemplazadas por los valores obvios.
$TZ: time zone
$LEVEL: nivel de prioridad del mensaje
$MSG: el mensaje en sí

La función template_escape() controla si ‘ y » deben ser escapados en la salida (\). Importante si se quiere enviar los logs, por ejemplo, a un servidor SQL.

Como ya hemos dicho, syslog-ng permite el envío de mensajes a otros hosts utilizando TCP, asegurando así que los mensajes son recibidos por el destinatario. Se puede definir un envío mediante TCP de la siguiente forma:

destination d_tcp { tcp("10.11.12.13" port(514); localport(514)); };

La función program() permite el envío de mensajes a programas. Syslog-ng arranca el programa y lo mantiene activo hasta que se detiene al propio syslog-ng o el el programa recibe una seña SIGHUP. No se realiza de esta forma solamente para aumentar la eficiencia, si no que además se evitan ataques DOS (Denial of service), al no abrir múltiples instancias del mismo programa.

 

Rutas de logs:
Sirven para juntar fuentes, filtros y pozos y además evaluar mensajes. Siempre empiezar con la palabra clave log.
EJEMPLO:

# Prerequisites
 source s_all { internal(); unix-stream("/dev/log"); };
 filter f_auth { facility(auth, authpriv); };
 destination df_auth { file("/var/log/auth.log"); };

# auth,authpriv.*
 /var/log/auth.log
 log {
 source(s_all);
 filter(f_auth);
 destination(df_auth);
 };

Esta regla hace que todos los mensajes que tienen que ver con autenticación (facility(auth, authpriv)) sean enviados al fichero /var/log/auth.log

Otro más:

# kern.warn;*.err;authpriv.none
/dev/tty10
filter f_nearly_all {
(facility(kern) and priority(warn .. emerg))
or (not facility(authpriv,kern));
};
destination df_tty { file("/dev/tty10"); };
log {
source(s_all);
filter(f_nearly_all);
destination(df_tty);
};

Todos los mensajes pasan por todos los filtros, y son registrados en todos los coincidentes. Si se quiere que un determinado mensaje no continúe una vez que ha pasado un filtro, puede añadirse la opción flags(final) a esa ruta.

flags(final) no implica que el mensaje sea registrado solamente una vez, ya que puede haber filtros coincidentes anteriores.

Con flags(fallback) se puede declarar una ruta como «ruta por defecto». Esta ruta solamente será considerada para mensajes que no coinciden con ninguna de las rutas que no fueron marcadas con la opción flags(fallback).

 

facility( ⟨category⟩[ , ⟨category⟩ … ] ) Matches messages with one of the listed categories
level( ⟨priority⟩[ , ⟨priority⟩ … ] ) Matches messages with one of the listed priorities
priority( ⟨priority⟩[ , ⟨priority⟩ … ] ) Same as level()
program( ⟨regex⟩ ) Matches messages where the name of the sending program matches ⟨regex⟩
host( ⟨regex⟩ ) Matches messages whose sending host matches ⟨regex⟩
match( ⟨regex⟩ ) Matches messages which match the ⟨regex⟩ themselves
filter( ⟨name⟩ ) Invokes another filtering rule and returns its value
netmask( ⟨IP address⟩ / ⟨netmask⟩ ) Checks whether the IP address is in the given network

Documentación en:
https://www.balabit.com/network-security/syslog-ng

3. Rsyslog

Rsyslog – rocket-fast syslog

Fichero de configuración:  /etc/rsyslog.conf


 

Además de una mayor eficiencia, el objetivo de rsyslog es soportar varias fuentes  y pozos para los mensajes de log. No solamente escribe los mensajes a ficheros de texto y terminales, si no también a una amplia selección de bases de datos.

 

Funciona de la siguiente forma:
Las fuentes pasan los mensajes a los «conjuntos de reglas». Hay un conjunto por defecto, RSYSLOG_DefaultRuleset, pero se pueden definir más.

Cada conjunto de reglas puede contener tantas como se quiera (o ninguna)
Una regla consiste en un filtro y una lista de acciones. Los filtros realizan acciones sí/no acerca de la ejecución de las acciones pertinentes.

Para cada mensaje, todas las reglas se ejecutarán en orden descendente, de primera a la última. Todas las reglas se ejecutarán, aunque haya una orden de detención por el medio.

Una lista puede contener diversas acciones (por lo menos una). Sin lista de acciones, no se admiten más filtros. Las acciones determinan qué sucede con los logs que coinciden.

La apariencia de los logs puede ser controlada mediante plantillas.

 

El fichero de configuración:
En el fichero /etc/rsyslog.conf se pueden encontrar 3 estilos de configuración diferentes:
· La sintaxis tradicional de /etc/syslog.conf (sysklogd)
· Una sintaxis obsoleta de rsyslog. Se reconoce por comandos que comienzan con $
· La sintaxis actual de rsyslog (RainerScript). Bien adaptada a situaciones complejas

Las dos primeras opciones están basadas en líneas, la última no atiende a los saltos de línea. Se recomienda solamente el uso de la última opción para realizar configuraciones en el fichero de rsyslog.

 

Filtros extendidos

:msg, contains, "FOO" /var/log/foo.log

Consisten en:
· «:» en el margen izquierdo
· una propiedad que syslog toma del mensaje, «msg»
· un filtro, aquí, «contains»
· y un término de búsqueda, «FOO»

Además de «msg», el mensaje de log en sí, las propiedades que se pueden incluír son:
· hostname: nombre del equipo que envía el mensaje
· fromhost: nombre del equipo que envía el mensaje a rsyslog
· pri: categoría y prioridad del mensaje como número sin codificar
· pri-text: categoría y prioridad del mensaje como cadena de texto, con el  número añadido (local0.err<133>)
· syslogfacility y syslogseverity así como syslogfacility-text y syslogseverity-text: para acceder directamente a la categoría y prioridad
· timegenerated: cuándo ha sido recibido el mensaje
· inputname: el módulo de rsyslog que ha recibido el mensaje
Y más, revisar la documentación de rsyslog de ser necesairo.

Los operadores de comparación permitidos son:
· contains: contiene la cadena de texto
· isequal: la cadena de texto es igual a la dada
· startswith: la cadena de texto empieza con (más eficiente que utilizar regex, aunque puede que lo que tú consideres el inicio del mensaje y lo que rsyslog considere no sean lo mismo:
EJEMPLO:

<131>Jul 22 14:25:50 root: error found

El mensaje comienza a partir de «:», por lo que la sintaxis sería para filtrar estos errores sería (véase el espacio antes de error)

:msg, startswith, " error" /var/log/error.log

· regex: expresión regular simple de acuerdo a POSIX
· eregex: expresión regular extendida de acuerdo a POSIX

 

Si se desean enviar los mensajes a otra máquina a través de la red, lo que con syslog sería «local0.* @red.example.com», lo cual transmite los mensajes a través de UDP al host de destino, con rsyslog además se permite «local0.* red.example.com», utilizando así TCP. Por supuesto, al otro lado debe haber un rsyslog correctamente configurado, se puede comprobar con la siguiente sintaxis:

module(load="imtcp" MaxSessions="500")
input(type="imtcp" port="514")

Los mensajes se transmisten por defecto al puerto 514/UDP, dicho puerto en TCP está reservado para rsh (remote shell, nadie lo utiliza hoy en día), se puede utilizar otro de la siguiente forma:

local0.* @@red.example.com:10514

Los cambios a implementar del lado del servidor pasan por configurar el puerto de escucha.

 

Siguiente nivel de complejidad, filtros basados en expresiones que pueden contener expresiones arbitrarias tales como booleanas, aritméticas o cadenas de operación, comienzan simepre con if y deben ser definidos en una línea (similar a los condicionales if de bash):

if $syslogfacility-text == "local0" and $msg startswith " FOO" and ($msg contains "BAR" or $msg contains "BAZ") then /var/log/foo.log

Rsyslog soporta un gran número de módulos que determinan lo que sucederá con los logs. Se puede, por ejemplo, enviar los mensajes por correo:

module(load="ommail")
template(name="mailBody" type="string" string="ALERT\\r\\n%msg%")
if $msg contains "disk error" then {
action(type="ommail" server="mail.example.com" port="25"
mailfrom="rsyslog@example.com" mailto="admins@example.com"
subject.text="disk error detected"
body.enable="on" template="mailBody"
action.execonlyonceeveryinterval="3600")
}

Se trata de una implementación primitiva de SMTP que no soporta encriptación ni autenticación, el servidor que lo recibe debe estar configurado acorde a esto.

 

Además, rsyslog acepta por sí mismo los mensajes del kernel con el módulo imklog, por lo que no se necesita klog:

module(load="imklog")

Toda la información en
www.rsyslog.com/doc/master/index.html

2. Registros del Kernel

Logs del kernel

Programas utilizados:

klogd – leer los mensajes del kernel, solamente con syslog
dmesg – leer los logs de arranque del sistema

Ficheros: /proc/ksmg – almacena los mensajes del kernel


 

El kernel no envía los mensajes de registro a syslogd si no que la pone en un «buffer en anillo» interno.

Puede ser leída de dversas formas, mediante una llamada específica del sistema o el «fichero» /porc/ksmg. Tradicionalmente, este fichero es leído por el porgrama klogd.

Si el sistema, por el contrario, utiliza rsyslog, klogd no se instala ya que rsyslog se hace cargo de los mensajes directamente.

Durante el arranque del sistema, syslogd y klogd no se encuentran inmediatamente disponibles, ya que deben ser arrancados como programas, por lo que no pueden registrar los logs de arranque. Para esto puede utilizarse el dmesg.

root@soporte:/# dmesg | head -5
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
[    0.000000] Command line: root=/dev/md1 ro console=tty0 console=ttyS0,57600

Utilizar dmesg permite además borrar el búfer en anillo del kernel (opción -c) y establecer prioridades para notificaciones directas: mensajes que exceden o igualan esta prioridad se envían automáticamente a consola (opción -n). Las prioridades pueden ser de 0 a 7, correspondientes a las de syslogd desde emerg a debug.

1. Syslog

Registros del sistema

Demonio: syslogd

Fichero de configuración: /etc/syslog.conf

Socket: /dev/log


 

Los programas aplicación necesitan mostrar información a los usuarios, una tarea completada, un error o un aviso necesitan ser reportados.
El kernel, el sistema operativo y los servicios de red, entre otros, corrien segundo plano, a diferencia de los programas con interfaz gráfica. Escribir mensajes a la consola del administrador del sistema no garantiza que este los lea, mucho menos en modo multiusuario, por lo que pueden ser fácilmente perdidos.

El demonio Syslog (syslogd) es la solución a este problema.
En vez de emitir el mensaje a la salida directamente, los mensajes del sistema con siginificado especial se emiten mediante la función syslog(). Estos mensajes son aceptados por syslogd en el socket /dev/syslog.

En realidad los mensajes del kernel son gestionados por klogd. Este programa preprocesa los mensajes y se los traslada a syslogd.

Syslogd es, como su nombre indica, un dominio. Normalmente es iniciado mediante un script en el arranque del sistema. Cuando recibe un mensaje, puede escribirlo en un fichero o bien enviarlo a través de la red a otra máquina que centralice los logs de varios equipos.

Las distribuciones más comunes (Debian, Ubuntu, Red Hat…) han estado utilizando durante bastante tiempo una implementación más avanzada llamada ‘rsyslog’, que permite más opciones de configuración.
Algunas distribuciones, como Novell/SUSE utilizan ‘syslog-NG’.

El fichero de configuración de syslog define dónde se guarda la información que recibe de cada uno de los servicios del sistema.
El fichero de configuración de rsyslog es compatible con la configuración de syslog, simplemente ignora las líneas que comienzan por $.

 

Estructura de ejemplo del fichero de configuración syslog.conf

*.=warn;*.=err -/var/log/warn
*.crit /var/log/warn
*.*;mail.none;news.none/td> -/var/log/messages

La primera columna define qué mensajes son seleccionados, la segunda a dónde deben ser enviados.

La primera columna se estructura de la siguiente forma:

aplicación.prioridad;aplicación.prioridad;etc.

· Si se define, por ejemplo, capturar los mensajes del servicio de correo con mail.warn, todos los warnings y mensajes con una prioridad inferior serán capturados y enviados a la salida.
· Si solamente se quiere capturar los warnings, la sintaxis es mail.=warn
· Para capturar todos los mensajes de un servicio, se puede definir con * o debug, mail.* o mail.debug
· Si se desea no capturar los mensajes, la negación se realiza con !, esto actúa para todos los mensajes con nivel inferior a error, mail.!err. Por este motivo, se suele utilizar con la sintaxis mail.*;!mail.err
· Se pueden combinar ! y =, mail.!=err deselecciona solamente los mensajes de error de mail

La segunda columna indica el fichero (en principio) donde se escribe el log, siempre utilizando rutas absolutas:

/var/log/mail

· Un guión (-) al principio hace que, a diferencia del funcionamiento normal de syslogd, los mensajes no sean escritos al momento al disco, lo cual se puede traducir en pérdida de datos en caso de fallo del sistema. (Utilizar para mensajes no relevantes), -/var/log/mail
· Se puede hacer referencia a un fichero de dispositivo /dev/tty10
· Se puede escribir a un fichero FIFO, se debe dar la ruta absoluta con | precediéndola, |/dev/xconsole
· Se puede enviar la información por la red a otro syslogd. Se realiza con @IP.de.destino.
Es la única forma de asegurarse que los logs no son modificados por un posible atacante.
El host de destino debe iniciarse con la opción -r (remote)
· Se pueden enviar los mensajes directamente a los usuarios, se deben separar con una coma. El mensaje se mostrará en terminal si están logueados, fran,root
· Se pueden enviar a todos los usuarios logueados especificando un * en vez del nombre de usuario

Para testear el funcionamiento de syslog, se puede utilizar el programa logger:

root@soporte:/home/fran# logger -p mail.err -t TEST "Hello World"
root@soporte:/home/fran# tail -1 /var/log/mail.err
 Jan 16 20:09:24 1and1soporte TEST: Hello World

 

Prioridad Siginificado
none No prioritario, excluír mensajes de cierta aplicación
0 – debug Estado interno de un programa, para depurar errores
1 – info Registro de operaciones normales del sistema
2 – notice Documentación notable durante operaciones normales del sistema
3 – warning o warn Errores no serios pero que tampoco pertenecen a las tareas normales
4 – err Mensajes de error de todo tipo
5 – crit Errores críticos (no está clara la división entre crit y err)
6 – alert Mensajes que requieren atención inmedata
7 – emerg Último mensaje antes de un fallo del sistema
Aplicación Significado
authpriv Mensajes de seguridad confidenciales del subsistema
cron Mensajes de cron y at
daemon Mensajes de programas demonio sin más especificación
ftp Mensajes de demonios ftp
kernel Mensajes del kernel
lpr Mensajes del susbsistema
mail Mensajes del subsistema de correo
news Mensajes del subsistema usenet
syslog Mensajes de syslogd
user Mensajes sobre usuarios
uucp Mensajes sobre el subsistema UUCP
localr ( 0 ≤ r ≤ 7) De libre uso para mensajes locales