Provided by: tenshi_0.13-2+deb7u1~build0.14.04.1_all bug

NAME

       tenshi - Log Monitoring and Reporting tool

SYNOPSIS

       tenshi [ -c <conf file> ] [ -C ] [ -d <debug level> ] [ -f ] [ -h ] [ -p ] [ -P <pid file>
       ]

DESCRIPTION

       tenshi is a log monitoring program, designed to watch one or  more  log  files  for  lines
       matching  user  defined  regular  expressions  and  report  on  the  matches.  The regular
       expressions are assigned to queues which have  an  alert  interval  and  a  list  of  mail
       recipients.

       Queues can be set to send a notification as soon as there is a log line assigned to it, or
       to send periodic reports.

       Additionally, uninteresting fields in the log lines (such as PID numbers)  can  be  masked
       with  the standard regular expression grouping operators ( ). This allows cleaner and more
       readable reports. All reports are separated by hostname and  all  messages  are  condensed
       when possible.

       The  program  reads  a  configuration  file  (tenshi.conf)  and  then  forks  a daemon for
       monitoring the specified log files.

OPTIONS

       -c <conf file>
              Read configuration from file. The default file is /etc/tenshi/tenshi.conf .

       -C     Perform a syntax check of the configuration file. The program exits  after  parsing
              the configuration with either a return code of 0 or an error.

       -d <debug level>
              Enable  debug  messages.  Default  level is 1 if none is specified, level 2 enables
              SMTP connection debug messages. In this  mode  the  main  process  remains  in  the
              foreground.

       -f     Enable foreground mode. In this mode the main process operates normally but remains
              in the foreground, this is needed for some process supervisors.

       -p     Enable profiling mode. In this mode the main process remains in the foreground  and
              expects  log  lines  to be fed to standard in. When it receives an EOF it will stop
              processing. No alerts will be sent in this mode, it is used  solely  for  measuring
              tenshi's line processing speed. For example: time $(cat /var/log/messages|tenshi -p
              > /dev/null)

       -P <pid file>
              Define the file containing the PID of the process,  this  overrides  any  'pidfile'
              option present in the configuration file.

CONFIGURATION FILE

       All  directives are shown with the standard default value where applicable, if omitted the
       default value will be used.

       EXTERNAL CONFIGURATION FILES

       All configuration directives can be optionally split into  different  configuration  files
       and then read with the two following statements.

       include <configuration file>
              Parse the specified configuration file.

       includedir <directory>
              Parse all files inside <directory>. The files will be parsed in alphabetical order,
              keep in mind that regexps order matters so includedir should be used carefully, see
              REGEXP DEFINITIONS for details.

       STATIC OPTIONS

       These  options  will  be  read the first time tenshi reads its config file. They cannot be
       changed by re-reading the config file. If you change one of these options and  HUP  tenshi
       it will die. You have been warned.

       set uid tenshi
              Specify  the effective user ID of the process when in daemon mode. The user must be
              able to read the selected log files, the configuration file and write the specified
              pid  file.  Never  use  privileged users here since it's not usually necessary (log
              files perms can be set accordingly with most syslog implementations).

       set gid tenshi
              Specify the effective group ID of the process when in daemon mode.

       set pidfile /var/run/tenshi.pid
              The file containing the PID of the process, useful for start/stop scripts.

       set logfile <log file path>
              A log file to monitor, this may be specified multiple times to watch more than  one
              log  file.  Depending  on  your  tail  implementation  you  might  need  to use the
              tail_multiple setting for multiple files to work. This mode can be used along  with
              fifo and listen settings.

       set tail /usr/bin/tail -q --follow=name --retry -n 0
              Specify  the path and arguments for the tail binary used for reading the log files.
              The invocation must be tuned against your current  'tail'  implementation.  Default
              values  are  configured  for  standard  GNU  coreutils  tail. The --follow=name and
              --retry  flags  should  deal  properly  with  log  rotation,  if  missing  on  your
              implementation  we  suggest that you use something like 'cp /dev/null logfile' as a
              safe way for clearing the log file upon rotation.

       set tail_multiple <on|off>
              Some tail implementations do not handle more than one log file. When this option is
              enabled  multiple  tail  commands  will be forked, instead of a single command with
              multiple arguments. This option is disabled by default.

       set fifo <fifo path>
              A FIFO file  to  monitor.  This  option  allows  you  to  use  a  syslog-ng  pipe()
              destination  (or  any other syslog implementation that allows FIFO usage). This may
              be specified multiple times to watch more than one fifo file. This option is  meant
              to  be  used  only  when  the  installed 'tail' binary doesn't behave properly with
              FIFOs, please test your tail implementation before using this.  This  mode  can  be
              used along with logfile and listen settings.

       set listen 0.0.0.0:514
              Enables  syslog  server  mode.  With  this option tenshi will bind to the specified
              address:port pair and  read  messages  acting  like  a  syslog  server.  We  always
              recommend  to  filter  the port accordingly and possibly use something like stunnel
              for encrypting the traffic. This mode can be  used  along  with  logfile  and  fifo
              settings.

       DYNAMIC OPTIONS

       These options are set each time the config file is read. tenshi reads its config file once
       on start-up and whenever it receives a HUP.

       set sleep 5
              The loop sleep time for the notification process. The value must be <= 60 seconds.

       set limit <number of lines>
              The maximum number of messages per hostname allowed in a report,  any  lines  after
              the  maximum will be omitted and a warning included. If this option is omitted then
              no limit is applied.

       set pager_limit <number of lines>
              The maximum number of messages per hostname allowed in pager friendly reports,  any
              lines after the maximum will be omitted. If this option is omitted then no limit is
              applied.

       set logprefix <regexp>
              All valid syslog  messages  are  parsed  by  default,  while  non-syslog  ones  are
              discarded  unless  the  special  noprefix  queue  is set. This option allows one to
              define an additional valid prefix for watching other type of logs. If the regexp is
              matched  then  the  prefix  is removed from the log and the first grouped string is
              used for the hostname field. This may be specified multiple  times  to  watch  many
              different non-syslog logs.

       set mask ______
              The  mask  for  strings  enclosed  by  the  grouping  operators ( ). See the REGEXP
              DEFINITIONS section. 'set mask' on its own will set the mask to an empty string.

       set mailserver localhost
              The mail server to be contacted for sending out reports.

       set mailtimeout 10
              The timeout in seconds for mail server reply.

       set subject tenshi report
              The subject of report emails, the queue name is always automatically appended.

       set hidepid <on|off>
              This option turns on automatic stripping of 'foo[1234]:' style PID strings from the
              start  of  log  lines  i.e.  'foo[1234]:'  becomes 'foo:'. This allows you to write
              regexps without worrying about masking the PID. Bear in  mind  that  any  time  you
              change  this  option  you  will  need to re-write your regex rules or they will not
              work. This option is disabled by default.

       set filter <queue> <filter path> <arguments>
              When this option is enabled all reports matching the specified queue will be passed
              as  STDIN to the specified filter, the resulting output is sent via smtp instead of
              the original report. The full path of the filter application must be specified.

       set csv <cron_spec> <filter path> <arguments>
              This feature allows periodic reporting, using a five-field cron-style specification
              like  the set queue option, to the specified filter. The output is pre-formatted as
              CSV (Comma Separated Values) with hostname,log,hits format. This feature was  coded
              for  using  AfterGlow  (http://afterglow.sf.net)  as  a  filter and graphing tenshi
              output. Check the FAQ for sample usage.

       set sort_order <descending|ascending>
              The sorting order for reports. It can be either descending or ascending, the number
              of  messages  is  used  as a key for sorting the log messages. The default order is
              ascending.

       set resolve <on|off>
              This option turns on resolution of the fully qualified domain name for the hostname
              passed  along  with  log messages and, if found, reports it along with the original
              one. This only affects reports and not  pager  messages.  The  name  resolution  is
              cached  in  order  to avoid re-resolving addresses that have been seen already, you
              have to restart or HUP tenshi in order to flush the cache. This option is  disabled
              by default.

       set threshold <queue> <count> <regex>
              This  option can be used to discard lines from a report that have a count below the
              given threshold. If a line matches the regex in the given queue but has fewer  hits
              than  count, it is discarded and omitted from the report. Note that this matches on
              the content of the lines that will actually appear in the report,  in  contrast  to
              queue escalation which uses a count based on the regex that is matched.

       QUEUES OPTIONS

       All  messages  are  assigned to queues. Every queue is processed periodically according to
       its notification interval. There are four default builtin queues, trash to which  unwanted
       messages can be assigned (think /dev/null), repeat which is used for smart repeat messages
       handling, group and group_host , see  REGEXP  DEFINITIONS  for  details.  There's  also  a
       special noprefix queue, read further for details about it.

       All  queues  are  automatically flushed before shutdown when a SIGTERM is received. Please
       see section SIGNALS for additional information.

       The syntax is the following:

       set queue <queue_name> <mail_from> [pager:]<mail_to> <cron_spec> [<subject>]

       <queue_name>
              The queue name. Can be any alphanumeric character string  except  for  the  builtin
              queues name.

       <mail_from>
              The mail sender for reports related to the queue.

       <mail_to>
              The  mail  recipient(s)  for  reports related to the queue. Multiple address can be
              specified, separated by commas. Using the pager: prefix enables  a  pager  friendly
              report.

       [<cron_spec>]
              This  is  a  five-field  cron-style  specification  for  when the reports should be
              emailed. Ranges and skip values are supported as per the de  facto  crontab  syntax
              with  a few exceptions. Please see crontab man page for crontab syntax explanation.
              The supported day names are: Mon, Tue, Wed, Thu, Fri, Sat, Sun. Monday is 1, Sunday
              0  or  7.  Supported  month names are: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep,
              Oct, Nov, Dec. Day and Month names are not case sensitive. Additionally, 'now'  can
              be specified for immediate notifications.

       <subject>
              This  is  the  subject  for  to use for email reports regarding this queue. If this
              isn't specified then the default subject will be used.

       The special noprefix queue can  be  used  and  defined  like  any  other  queue  with  the
       difference that it will get all messages that don't match any configured prefix.

       Examples:
       set queue report tenshi@localhost sysadmin@localhost [0 9-17 * * *]
       set queue report tenshi@localhost sysadmin@localhost [30 18 * * *]
       set queue report tenshi@localhost sysadmin@localhost [*/10 * * * *]
       set   queue  critical  tenshi@localhost  sysadmin@localhost,noc@localhost  [now]  CRITICAL
       WARNING -
       set queue pager tenshi@localhost  pager:sysadmin_pager@localhost,pager:noc_pager@localhost
       [now] ALERT

       REGEXP DEFINITIONS

       All  valid  syslog  messages  are  matched  against standard perl regexps, all regexps are
       defined with the following syntax:

       <queue_name>[,<queue_name>[:<escalation_number>]..] <regexp>

       The regexps are evaluated in order so  a  matched  message  is  not  checked  against  the
       subsequent  regexps.  Keep  this  in  mind  when  assembling  the configuration file. It's
       advisable to catch all messages by placing an all  matching  regexp  at  the  end  of  the
       configuration  file.  It's  also  good  for  performance  having trash rules not logically
       connected with other matching rules at the beginning of the section. Multiple  queues  can
       be  defined  with  a  comma  separated list, builtin queues cannot be used when using this
       syntax.

       If an escalation number is provided for a queue, the matched message will only  be  placed
       into  the  queue when <escalation_number> messages have matched the regexp. The queue will
       receive the message that matched the regexp at the time of escalation, with a count  equal
       to the escalation number. The count of messages matching the regexp will be reset when the
       left most queue mentioned in the queue list is mailed. The left most queue cannot have  an
       escalation  number  unless  it  is the only queue listed. When the number of messages that
       match the regexp reaches the greatest escalation number mentioned, escalation  will  begin
       again  into  the  escalation  queues, modulus the greatest escalation number. For example,
       using the queues `a,b:10,c:50', when 10 messages match the regexp, a message will go  into
       b,  when  50 match, one will go into c. At 60, another will go into b, and at 100, another
       into c, 110 to b, 150 to c, and so  on.  Escalation  numbers  must  be  positive  integers
       greater  than  zero  and must be listed in increasing order from left to right. All queues
       without escalation numbers must be listed  more  left  than  the  queues  with  escalation
       numbers.

       The  standard  grouping  operators ( ) can be used for string masking, literal "(" and ")"
       can be protected with the standard quotation operator "\". There's a lot of  documentation
       about regular expressions, a good start could be perl perlre and perlretut manual pages.
       You  can  also  use  the (?: ) operators to use groups without masking. This allows you to
       match, for example, output from several programs in a similar format.  There is an example
       of this below (the sudo/su line).

       The  builtin  queue  repeat  can  be used for special handling of "last message repeated x
       times" style log lines. When the assigned regexps are matched the line count for the  last
       line  received from the same host is incremented by the first grouped string. Keep in mind
       that it is possible for syslog lines to be received from remote hosts  out  of  order.  If
       this happens you should not use this feature because tenshi will mis-report line counts.

       The  builtin  queue  group  can  be  used to group sets of regex together to speed up line
       matching. If a line fails to match a regex assigned to the group queue  then  tenshi  will
       skip  all  the  regex up until the next group_end statement. Nested groups are allowed. An
       example of this is included below.

       The builtin group_host queue can be used for selective hostname matching. Like  the  group
       queue  it  is  also  terminated with the group_end statement. All regex definitions within
       that group will only apply if the hostname associated to the log entries matches the regex
       passed to the group_host definition.

       The  regexps  below  assume  hidepid is turned on. If you have it turned off then you will
       need to add in \[(.+)\] to the regex following the progam name to get them to work.
       For example: mail ^sendmail: (.+): to=(.+),(.+)delay=(.+) becomes: mail ^sendmail\[(.+)\]:
       (.+): to=(.+),(.+)delay=(.+)

       Examples:

       trash ^xinetd

       repeat ^(?:last message repeated|above message repeats) (\d+) time

       group ^sendmail:
       mail ^sendmail: (.+): to=(.+),(.+)delay=(.+)
       mail ^sendmail: (.+): to=(.+),(.+)relay=(.+),(.+)stat=Sent
       group_end

       group_host mailserver1
       mail1 ^sendmail
       mail1 ^sendmail:.+
       critical,mail1 ^sendmail:.+SYSERR.+
       group_end

       mail ^ipop3d: Login user=(.+)

       critical,report ^sshd: Illegal user

       general,urgent:200,critical:1000 ^sshd: Illegal user

       root ^sshd\(pam_unix\): session opened for user root by root\(uid=0\)

       report ^sshd: Accepted rsa for (.+) from (.+) port (.+)

       trash ^sshd

       critical ^(?:sudo|su):

       critical,pager ^Oops

       misc .*

SIGNALS

       tenshi  can  handle  different  signals  sent to the process, here's the list of supported
       ones:

       TERM   flush all queues and then exit

       INT    flush all queues and then exit

       USR1   flush any queues which have reached their notification interval

       USR2   force all queues to be flushed, even if they have not  reached  their  notification
              interval

       HUP    force  all  queues  to be flushed, even if they have not reached their notification
              interval, re-read the config file and continue as normal.

       WARNING: If you change a STATIC OPTION in the config file and send tenshi a  HUP  it  will
       die. You will need to restart tenshi for changes to STATIC OPTIONs to take effect.

EXAMPLES

       See the included tenshi.conf.

REQUIREMENTS

       tenshi needs a working 'tail' implementation when not using FIFO mode.

       It  also  requires  Net::SMTP module for mailing reports, which should be included in your
       perl installation, and IO::BufferedSelect. If you miss any of them you can  grab  them  at
       CPAN (http://www.cpan.org) or using the CPAN shell (`perl -e shell -MCPAN`).

BUGS

       Double  quotation characters present in your logs might break csv output (depending on how
       you pipe/process it in the filter) since there's no escape code (yet).

       Please report any bugs you find at <tenshi@inversepath.com>

LICENSE

       tenshi is distributed under the terms of the following ISC-style license:

       Permission to use, copy, modify, and distribute this software  for  any  purpose  with  or
       without  fee  is  hereby  granted,  provided  that  the  above  copyright  notice and this
       permission notice appear in all copies.

       THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES  WITH  REGARD  TO
       THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT
       SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES  OR
       ANY  DAMAGES  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
       OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE
       USE OR PERFORMANCE OF THIS SOFTWARE.

DISTRIBUTION

       The tenshi project page is http://www.inversepath.com/tenshi.html

NOTES

       tenshi  was  once known as wasabi but the name was changed as we were informed that wasabi
       is a registered a trademark relating to another piece of software.

SEE ALSO

       It   should   be   noted   that   tenshi   was   initially   a   perl   rewrite   of   oak
       (http://www.ktools.org).

       Friedl, Jeffrey E. F. Mastering Regular Expressions, 2nd Edition. O'Reilly

AUTHORS

       Copyright 2004-2011 Andrea Barisani <andrea@inversepath.com>