MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
/*
* Event sink management
*
* Copyright ( C ) 2000 - 2019 Willy Tarreau - w @ 1 wt . eu
*
* This library is free software ; you can redistribute it and / or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation , version 2.1
* exclusively .
*
* This library is distributed in the hope that it will be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the GNU
* Lesser General Public License for more details .
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library ; if not , write to the Free Software
* Foundation , Inc . , 51 Franklin Street , Fifth Floor , Boston , MA 02110 - 1301 USA
*/
2022-08-11 10:38:20 -04:00
# include <sys/mman.h>
# include <errno.h>
# include <fcntl.h>
2020-06-05 11:27:29 -04:00
# include <import/ist.h>
2020-05-27 06:58:42 -04:00
# include <haproxy/api.h>
2022-04-04 05:29:28 -04:00
# include <haproxy/applet.h>
2020-06-04 18:00:29 -04:00
# include <haproxy/cfgparse.h>
2020-06-04 14:19:54 -04:00
# include <haproxy/cli.h>
2020-06-05 11:27:29 -04:00
# include <haproxy/errors.h>
2020-05-27 12:01:47 -04:00
# include <haproxy/list.h>
2020-06-04 16:01:04 -04:00
# include <haproxy/log.h>
2021-05-08 14:20:21 -04:00
# include <haproxy/proxy.h>
2020-06-03 13:43:35 -04:00
# include <haproxy/ring.h>
2022-05-27 03:25:10 -04:00
# include <haproxy/sc_strm.h>
2020-06-04 11:37:26 -04:00
# include <haproxy/signal.h>
2020-06-03 14:02:28 -04:00
# include <haproxy/sink.h>
2022-05-27 03:47:12 -04:00
# include <haproxy/stconn.h>
2020-06-09 03:07:15 -04:00
# include <haproxy/time.h>
2021-05-08 07:05:30 -04:00
# include <haproxy/tools.h>
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
struct list sink_list = LIST_HEAD_INIT ( sink_list ) ;
2022-09-13 10:16:30 -04:00
/* sink proxies list */
struct proxy * sink_proxies_list ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
struct sink * cfg_sink ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
struct sink * sink_find ( const char * name )
{
struct sink * sink ;
list_for_each_entry ( sink , & sink_list , sink_list )
if ( strcmp ( sink - > name , name ) = = 0 )
return sink ;
return NULL ;
}
/* creates a new sink and adds it to the list, it's still generic and not fully
* initialized . Returns NULL on allocation failure . If another one already
* exists with the same name , it will be returned . The caller can detect it as
* a newly created one has type SINK_TYPE_NEW .
*/
2020-07-06 09:54:06 -04:00
static struct sink * __sink_new ( const char * name , const char * desc , int fmt )
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
{
struct sink * sink ;
sink = sink_find ( name ) ;
if ( sink )
goto end ;
2020-05-28 05:13:15 -04:00
sink = calloc ( 1 , sizeof ( * sink ) ) ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
if ( ! sink )
goto end ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
sink - > name = strdup ( name ) ;
2021-01-03 13:54:11 -05:00
if ( ! sink - > name )
goto err ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
sink - > desc = strdup ( desc ) ;
2021-01-03 13:54:11 -05:00
if ( ! sink - > desc )
goto err ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
sink - > fmt = fmt ;
sink - > type = SINK_TYPE_NEW ;
2019-11-15 09:10:12 -05:00
sink - > maxlen = BUFSIZE ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
/* address will be filled by the caller if needed */
2019-08-20 05:57:52 -04:00
sink - > ctx . fd = - 1 ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
sink - > ctx . dropped = 0 ;
2021-04-21 01:32:39 -04:00
LIST_APPEND ( & sink_list , & sink - > sink_list ) ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
end :
return sink ;
2021-01-03 13:54:11 -05:00
err :
2021-02-20 04:46:51 -05:00
ha_free ( & sink - > name ) ;
ha_free ( & sink - > desc ) ;
ha_free ( & sink ) ;
2021-01-03 13:54:11 -05:00
return NULL ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
}
2019-08-20 05:57:52 -04:00
/* creates a sink called <name> of type FD associated to fd <fd>, format <fmt>,
* and description < desc > . Returns NULL on allocation failure or conflict .
* Perfect duplicates are merged ( same type , fd , and name ) .
*/
2020-07-06 09:54:06 -04:00
struct sink * sink_new_fd ( const char * name , const char * desc , enum log_fmt fmt , int fd )
2019-08-20 05:57:52 -04:00
{
struct sink * sink ;
sink = __sink_new ( name , desc , fmt ) ;
if ( ! sink | | ( sink - > type = = SINK_TYPE_FD & & sink - > ctx . fd = = fd ) )
goto end ;
if ( sink - > type ! = SINK_TYPE_NEW ) {
sink = NULL ;
goto end ;
}
sink - > type = SINK_TYPE_FD ;
sink - > ctx . fd = fd ;
end :
return sink ;
}
2019-08-23 09:47:49 -04:00
/* creates a sink called <name> of type BUF of size <size>, format <fmt>,
* and description < desc > . Returns NULL on allocation failure or conflict .
* Perfect duplicates are merged ( same type and name ) . If sizes differ , the
* largest one is kept .
*/
2020-07-06 09:54:06 -04:00
struct sink * sink_new_buf ( const char * name , const char * desc , enum log_fmt fmt , size_t size )
2019-08-23 09:47:49 -04:00
{
struct sink * sink ;
sink = __sink_new ( name , desc , fmt ) ;
if ( ! sink )
goto fail ;
if ( sink - > type = = SINK_TYPE_BUFFER ) {
/* such a buffer already exists, we may have to resize it */
if ( ! ring_resize ( sink - > ctx . ring , size ) )
goto fail ;
goto end ;
}
if ( sink - > type ! = SINK_TYPE_NEW ) {
/* already exists of another type */
goto fail ;
}
sink - > ctx . ring = ring_new ( size ) ;
if ( ! sink - > ctx . ring ) {
2021-04-21 01:32:39 -04:00
LIST_DELETE ( & sink - > sink_list ) ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
free ( sink - > name ) ;
free ( sink - > desc ) ;
2019-08-23 09:47:49 -04:00
free ( sink ) ;
goto fail ;
}
sink - > type = SINK_TYPE_BUFFER ;
end :
return sink ;
fail :
return NULL ;
}
2023-08-24 14:46:12 -04:00
/* tries to send <nmsg> message parts from message array <msg> to sink <sink>.
2023-08-25 03:50:27 -04:00
* Formatting according to the sink ' s preference is done here , unless sink - > fmt
* is unspecified , in which case the caller formatting will be used instead .
* Lost messages are NOT accounted for . It is preferable to call sink_write ( )
* instead which will also try to emit the number of dropped messages when there
* are any .
2023-08-24 14:46:12 -04:00
*
* It will stop writing at < maxlen > instead of sink - > maxlen if < maxlen > is
* positive and inferior to sink - > maxlen .
2023-06-26 10:44:41 -04:00
*
* It returns > 0 if it could write anything , < = 0 otherwise .
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
*/
2023-08-24 14:46:12 -04:00
ssize_t __sink_write ( struct sink * sink , struct log_header hdr ,
size_t maxlen , const struct ist msg [ ] , size_t nmsg )
2020-07-06 09:54:06 -04:00
{
struct ist * pfx = NULL ;
2019-08-27 08:21:02 -04:00
size_t npfx = 0 ;
2020-05-06 08:33:46 -04:00
2020-07-06 09:54:06 -04:00
if ( sink - > fmt = = LOG_FORMAT_RAW )
2020-05-06 08:33:46 -04:00
goto send ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
2023-08-25 03:50:27 -04:00
if ( sink - > fmt ! = LOG_FORMAT_UNSPEC )
hdr . format = sink - > fmt ; /* sink format prevails over log one */
2023-08-24 14:46:12 -04:00
pfx = build_log_header ( hdr , & npfx ) ;
2020-05-06 08:33:46 -04:00
send :
2023-06-26 10:44:41 -04:00
if ( ! maxlen )
maxlen = ~ 0 ;
2019-08-20 05:57:52 -04:00
if ( sink - > type = = SINK_TYPE_FD ) {
2023-06-26 10:44:41 -04:00
return fd_write_frag_line ( sink - > ctx . fd , MIN ( maxlen , sink - > maxlen ) , pfx , npfx , msg , nmsg , 1 ) ;
2019-08-23 09:47:49 -04:00
}
else if ( sink - > type = = SINK_TYPE_BUFFER ) {
2023-06-26 10:44:41 -04:00
return ring_write ( sink - > ctx . ring , MIN ( maxlen , sink - > maxlen ) , pfx , npfx , msg , nmsg ) ;
2019-08-20 05:57:52 -04:00
}
2019-08-27 10:41:06 -04:00
return 0 ;
}
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
2023-08-24 14:46:12 -04:00
/* Tries to emit a message indicating the number of dropped events.
* The log header of the original message that we tried to emit is reused
* here with the only difference that we override the log level . This is
* possible since the announce message will be sent from the same context .
*
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
* In case of success , the amount of drops is reduced by as much .
* The function ensures that a single thread will do that work at once , other
* ones will only report a failure if a thread is dumping , so that no thread
* waits . A pair od atomic OR and AND is performed around the code so the
* caller would be advised to only call this function AFTER having verified
* that sink - > ctx . dropped is not zero in order to avoid a memory write . On
* success , > 0 is returned , otherwise < = 0 on failure , indicating that it could
* not eliminate the pending drop counter . It may loop up to 10 times trying
* to catch up with failing competing threads .
2019-08-27 10:41:06 -04:00
*/
2023-08-24 14:46:12 -04:00
int sink_announce_dropped ( struct sink * sink , struct log_header hdr )
2019-08-27 10:41:06 -04:00
{
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
static THREAD_LOCAL char msg_dropped1 [ ] = " 1 event dropped " ;
static THREAD_LOCAL char msg_dropped2 [ ] = " 0000000000 events dropped " ;
uint dropped , last_dropped ;
2019-08-27 10:41:06 -04:00
struct ist msgvec [ 1 ] ;
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
uint retries = 10 ;
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
int ret = 0 ;
/* Explanation. ctx.dropped is made of:
* bit0 = 1 if dropped dump in progress
* bit1 . .31 = dropped counter
* If non - zero there have been some drops . If not & 1 , it means
* nobody ' s taking care of them and we ' ll have to , otherwise
* another thread is already on them and we can just pass and
* count another drop ( hence add 2 ) .
*/
dropped = HA_ATOMIC_FETCH_OR ( & sink - > ctx . dropped , 1 ) ;
if ( dropped & 1 ) {
/* another thread was already on it */
goto leave ;
}
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
last_dropped = 0 ;
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
dropped > > = 1 ;
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
while ( 1 ) {
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
while ( unlikely ( dropped > last_dropped ) & & retries - - > 0 ) {
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
/* try to aggregate multiple messages if other threads arrive while
* we ' re producing the dropped message .
*/
uint msglen = sizeof ( msg_dropped1 ) ;
const char * msg = msg_dropped1 ;
last_dropped = dropped ;
if ( dropped > 1 ) {
msg = ultoa_r ( dropped , msg_dropped2 , 11 ) ;
msg_dropped2 [ 10 ] = ' ' ;
msglen = msg_dropped2 + sizeof ( msg_dropped2 ) - msg ;
}
msgvec [ 0 ] = ist2 ( msg , msglen ) ;
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
dropped = HA_ATOMIC_LOAD ( & sink - > ctx . dropped ) > > 1 ;
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
}
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
OPTIM: sink: try to merge "dropped" messages faster
When a reader doesn't read fast enough and causes drops, subsequent
threads try to produce a "dropped" message. But it takes time to
produce and emit this message, in part due to the use of chunk_printf()
that relies on vfprintf() which has to parse the printf format, and
during this time other threads may continue to increment the counter.
This is the reason why this is currently performed in a loop. When
reading what is received, it's common to see a large count followed
by one or two single-digit counts, indicating that we could possibly
have improved that by writing faster.
Let's improve the situation a little bit. First we're now using a
static message prefixed with enough space to write the digits, and a
call to ultoa_r() fills these digits from right to left so that we
don't have to process a format string nor perform a copy of the message.
Second, we now re-check the counter immediately after having prepared
the message so that we still get an opportunity for updating it. In
order to avoid too long loops, this is limited to 10 iterations.
Tests show that the number of single-digit "dropped" counters on output
now dropped roughly by 15-30%. Also, it was observed that with 8 threads,
there's almost never more than one retry.
2024-03-01 11:59:59 -05:00
if ( ! dropped )
break ;
last_dropped = 0 ;
2023-08-24 14:46:12 -04:00
hdr . level = LOG_NOTICE ; /* override level but keep original log header data */
2020-07-06 09:54:06 -04:00
2023-08-24 14:46:12 -04:00
if ( __sink_write ( sink , hdr , 0 , msgvec , 1 ) < = 0 )
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
goto done ;
2019-08-27 10:41:06 -04:00
/* success! */
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
HA_ATOMIC_SUB ( & sink - > ctx . dropped , dropped < < 1 ) ;
2019-08-27 10:41:06 -04:00
}
OPTIM: sink: drop the sink lock used to count drops
The sink lock was made to prevent event producers from passing while
there were other threads trying to print a "dropped" message, in order
to guarantee the absence of reordering. It has a serious impact however,
which is that all threads need to take the read lock when producing a
regular trace even when there's no reader.
This patch takes a different approach. The drop counter is shifted left
by one so that the lowest bit is used to indicate that one thread is
already taking care of trying to dump the counter. Threads only read
this value normally, and will only try to change it if it's non-null,
in which case they'll first check if they are the first ones trying to
dump it, otherwise will simply count another drop and leave. This has
a large benefit. First, it will avoid the locking that causes stalls
as soon as a slow reader is present. Second, it avoids any write on the
fast path as long as there's no drop. And it remains very lightweight
since we just need to add +2 or subtract 2*dropped in operations, while
offering the guarantee that the sink_write() has succeeded before
unlocking the counter.
While a reader was previously limiting the traffic to 11k RPS under
4C/8T, now we reach 36k RPS vs 14k with no reader, so readers will no
longer slow the traffic down and will instead even speed it up due to
avoiding the contention down the chain in the ring. The locking cost
dropped from ~75% to ~60% now (it's in ring_write now).
2024-03-01 13:22:04 -05:00
/* done! */
ret = 1 ;
done :
/* unlock the counter */
HA_ATOMIC_AND ( & sink - > ctx . dropped , ~ 1 ) ;
leave :
return ret ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
}
2019-08-26 12:17:04 -04:00
/* parse the "show events" command, returns 1 if a message is returned, otherwise zero */
static int cli_parse_show_events ( char * * args , char * payload , struct appctx * appctx , void * private )
{
struct sink * sink ;
2022-05-05 09:18:57 -04:00
uint ring_flags ;
2019-08-30 05:17:01 -04:00
int arg ;
2019-08-26 12:17:04 -04:00
args + + ; // make args[1] the 1st arg
if ( ! * args [ 1 ] ) {
/* no arg => report the list of supported sink */
2019-08-30 05:17:01 -04:00
chunk_printf ( & trash , " Supported events sinks are listed below. Add -w(wait), -n(new). Any key to stop \n " ) ;
2019-08-26 12:17:04 -04:00
list_for_each_entry ( sink , & sink_list , sink_list ) {
chunk_appendf ( & trash , " %-10s : type=%s, %u dropped, %s \n " ,
sink - > name ,
sink - > type = = SINK_TYPE_NEW ? " init " :
sink - > type = = SINK_TYPE_FD ? " fd " :
sink - > type = = SINK_TYPE_BUFFER ? " buffer " : " ? " ,
sink - > ctx . dropped , sink - > desc ) ;
}
trash . area [ trash . data ] = 0 ;
return cli_msg ( appctx , LOG_WARNING , trash . area ) ;
}
if ( ! cli_has_level ( appctx , ACCESS_LVL_OPER ) )
return 1 ;
sink = sink_find ( args [ 1 ] ) ;
if ( ! sink )
return cli_err ( appctx , " No such event sink " ) ;
if ( sink - > type ! = SINK_TYPE_BUFFER )
return cli_msg ( appctx , LOG_NOTICE , " Nothing to report for this sink " ) ;
2022-05-05 09:18:57 -04:00
ring_flags = 0 ;
2019-08-30 05:17:01 -04:00
for ( arg = 2 ; * args [ arg ] ; arg + + ) {
if ( strcmp ( args [ arg ] , " -w " ) = = 0 )
2022-05-05 09:18:57 -04:00
ring_flags | = RING_WF_WAIT_MODE ;
2019-08-30 05:17:01 -04:00
else if ( strcmp ( args [ arg ] , " -n " ) = = 0 )
2022-05-05 09:18:57 -04:00
ring_flags | = RING_WF_SEEK_NEW ;
2019-08-30 05:17:01 -04:00
else if ( strcmp ( args [ arg ] , " -nw " ) = = 0 | | strcmp ( args [ arg ] , " -wn " ) = = 0 )
2022-05-05 09:18:57 -04:00
ring_flags | = RING_WF_WAIT_MODE | RING_WF_SEEK_NEW ;
2019-08-30 05:17:01 -04:00
else
return cli_err ( appctx , " unknown option " ) ;
}
2022-05-05 09:18:57 -04:00
return ring_attach_cli ( sink - > ctx . ring , appctx , ring_flags ) ;
2019-08-26 12:17:04 -04:00
}
2020-06-21 12:42:57 -04:00
/* Pre-configures a ring proxy to emit connections */
2020-05-28 05:13:15 -04:00
void sink_setup_proxy ( struct proxy * px )
{
2024-04-30 06:04:57 -04:00
px - > be_counters . last_change = ns_to_sec ( now_ns ) ;
BUG/MINOR: sink: Only use backend capability for the sink proxies
When a ring section is parsed, a proxy is created. For now, it has the
frontend (PR_CAP_FE) and the internal (PR_CAP_INT) capabilities, in addition
to the expected backend capability (PR_CAP_BE).
PR_CAP_INT capability was added to silent warning triggered because of
PR_CAP_FE capability. Indeed, Because the proxy is declared as a frontend,
warnings about missing bind lines and missing client timeout should be
triggered during the configuration parsing. These warnings are inhibited
because PR_CAP_INT capability is set. It is an issue on the 2.4 because
PR_CAP_INT capability does not exist. So warnings are always emitted.
But the true bug is that these proxies should not have PR_CAP_FE and
PR_CAP_INT capabilities. Removing these capabilities is enough to remove any
warnings on the 2.4, with no regression on higher versions. However, it may
be a good idea to eval if a dedicated frontend for sinks should be added or
not. This way, a true frontend would be used to start the sink applets. In
addition, proxies capabilities/modes have to be reviewed to have a less
ambiguous API. For instance a dedicate mode for sinks (PR_MODE_SINK ?) may
be added. Finally, it could be very nice to have all proxies in the same
list, including internal ones.
This patch should fix the issue #1900. It must be backported as far as 2.4.
2022-10-24 09:10:18 -04:00
px - > cap = PR_CAP_BE ;
2020-05-28 05:13:15 -04:00
px - > maxconn = 0 ;
px - > conn_retries = 1 ;
px - > timeout . server = TICK_ETERNITY ;
px - > timeout . client = TICK_ETERNITY ;
px - > timeout . connect = TICK_ETERNITY ;
px - > accept = NULL ;
px - > options2 | = PR_O2_INDEPSTR | PR_O2_SMARTCON | PR_O2_SMARTACC ;
2022-09-13 10:16:30 -04:00
px - > next = sink_proxies_list ;
sink_proxies_list = px ;
2020-05-28 05:13:15 -04:00
}
/*
2022-05-04 14:42:23 -04:00
* IO Handler to handle message push to syslog tcp server .
* It takes its context from appctx - > svcctx .
2020-05-28 05:13:15 -04:00
*/
static void sink_forward_io_handler ( struct appctx * appctx )
{
2022-05-27 05:08:15 -04:00
struct stconn * sc = appctx_sc ( appctx ) ;
2022-05-04 14:42:23 -04:00
struct sink_forward_target * sft = appctx - > svcctx ;
2023-09-14 18:29:53 -04:00
struct sink * sink = sft - > sink ;
2020-05-28 05:13:15 -04:00
struct ring * ring = sink - > ctx . ring ;
2024-02-27 11:01:45 -05:00
size_t ofs , last_ofs ;
2020-05-28 05:13:15 -04:00
int ret = 0 ;
2024-02-14 01:56:50 -05:00
if ( unlikely ( se_fl_test ( appctx - > sedesc , ( SE_FL_EOS | SE_FL_ERROR ) ) ) ) {
2023-03-31 05:25:55 -04:00
goto out ;
2024-02-14 01:56:50 -05:00
}
2023-03-31 05:25:55 -04:00
2020-06-21 12:42:57 -04:00
/* if stopping was requested, close immediately */
2020-05-28 05:13:15 -04:00
if ( unlikely ( stopping ) )
goto close ;
/* if the connection is not established, inform the stream that we want
* to be notified whenever the connection completes .
*/
2022-05-27 04:44:25 -04:00
if ( sc_opposite ( sc ) - > state < SC_ST_EST ) {
2022-05-25 12:21:43 -04:00
applet_need_more_data ( appctx ) ;
2022-05-24 10:49:03 -04:00
se_need_remote_conn ( appctx - > sedesc ) ;
2022-05-25 09:42:03 -04:00
applet_have_more_data ( appctx ) ;
2023-03-31 05:25:55 -04:00
goto out ;
2020-05-28 05:13:15 -04:00
}
HA_SPIN_LOCK ( SFT_LOCK , & sft - > lock ) ;
if ( appctx ! = sft - > appctx ) {
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
goto close ;
}
2024-02-28 11:04:40 -05:00
MT_LIST_DELETE ( & appctx - > wait_entry ) ;
2020-05-28 05:13:15 -04:00
2024-02-27 11:01:45 -05:00
ret = ring_dispatch_messages ( ring , appctx , & sft - > ofs , & last_ofs , 0 , applet_append_line ) ;
2020-05-28 05:13:15 -04:00
if ( ret ) {
/* let's be woken up once new data arrive */
2024-02-28 11:04:40 -05:00
MT_LIST_APPEND ( & ring - > waiters , & appctx - > wait_entry ) ;
2024-03-06 10:50:40 -05:00
ofs = ring_tail ( ring ) ;
2022-08-04 11:18:54 -04:00
if ( ofs ! = last_ofs ) {
/* more data was added into the ring between the
* unlock and the lock , and the writer might not
* have seen us . We need to reschedule a read .
*/
applet_have_more_data ( appctx ) ;
} else
applet_have_no_more_data ( appctx ) ;
2020-05-28 05:13:15 -04:00
}
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
2023-03-31 05:25:55 -04:00
out :
2020-05-28 05:13:15 -04:00
/* always drain data from server */
2022-05-27 04:44:25 -04:00
co_skip ( sc_oc ( sc ) , sc_oc ( sc ) - > output ) ;
2020-05-28 05:13:15 -04:00
return ;
close :
2023-03-31 05:25:55 -04:00
se_fl_set ( appctx - > sedesc , SE_FL_EOS | SE_FL_EOI ) ;
2020-05-28 05:13:15 -04:00
}
2020-05-29 19:42:45 -04:00
/*
* IO Handler to handle message push to syslog tcp server
* using octet counting frames
2022-05-04 14:42:23 -04:00
* It takes its context from appctx - > svcctx .
2020-05-29 19:42:45 -04:00
*/
static void sink_forward_oc_io_handler ( struct appctx * appctx )
{
2022-05-27 05:08:15 -04:00
struct stconn * sc = appctx_sc ( appctx ) ;
2022-05-04 14:42:23 -04:00
struct sink_forward_target * sft = appctx - > svcctx ;
2023-09-14 18:29:53 -04:00
struct sink * sink = sft - > sink ;
2020-05-29 19:42:45 -04:00
struct ring * ring = sink - > ctx . ring ;
2024-02-27 11:05:11 -05:00
size_t ofs , last_ofs ;
2020-05-29 19:42:45 -04:00
int ret = 0 ;
2023-03-31 05:25:55 -04:00
if ( unlikely ( se_fl_test ( appctx - > sedesc , ( SE_FL_EOS | SE_FL_ERROR | SE_FL_SHR | SE_FL_SHW ) ) ) )
goto out ;
2020-06-21 12:42:57 -04:00
/* if stopping was requested, close immediately */
2020-05-29 19:42:45 -04:00
if ( unlikely ( stopping ) )
goto close ;
/* if the connection is not established, inform the stream that we want
* to be notified whenever the connection completes .
*/
2022-05-27 04:44:25 -04:00
if ( sc_opposite ( sc ) - > state < SC_ST_EST ) {
2022-05-25 12:21:43 -04:00
applet_need_more_data ( appctx ) ;
2022-05-24 10:49:03 -04:00
se_need_remote_conn ( appctx - > sedesc ) ;
2022-05-25 09:42:03 -04:00
applet_have_more_data ( appctx ) ;
2023-03-31 05:25:55 -04:00
goto out ;
2020-05-29 19:42:45 -04:00
}
HA_SPIN_LOCK ( SFT_LOCK , & sft - > lock ) ;
if ( appctx ! = sft - > appctx ) {
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
goto close ;
}
2024-02-28 11:04:40 -05:00
MT_LIST_DELETE ( & appctx - > wait_entry ) ;
2020-05-29 19:42:45 -04:00
2024-02-27 11:05:11 -05:00
ret = ring_dispatch_messages ( ring , appctx , & sft - > ofs , & last_ofs , 0 , syslog_applet_append_event ) ;
2020-05-29 19:42:45 -04:00
if ( ret ) {
/* let's be woken up once new data arrive */
2024-02-28 11:04:40 -05:00
MT_LIST_APPEND ( & ring - > waiters , & appctx - > wait_entry ) ;
2024-03-06 10:50:40 -05:00
ofs = ring_tail ( ring ) ;
2024-02-27 11:32:44 -05:00
if ( ofs ! = last_ofs ) {
/* more data was added into the ring between the
* unlock and the lock , and the writer might not
* have seen us . We need to reschedule a read .
*/
applet_have_more_data ( appctx ) ;
} else
applet_have_no_more_data ( appctx ) ;
2020-05-29 19:42:45 -04:00
}
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
2023-03-31 05:25:55 -04:00
out :
2020-05-29 19:42:45 -04:00
/* always drain data from server */
2022-05-27 04:44:25 -04:00
co_skip ( sc_oc ( sc ) , sc_oc ( sc ) - > output ) ;
2020-05-29 19:42:45 -04:00
return ;
close :
2023-03-31 05:25:55 -04:00
se_fl_set ( appctx - > sedesc , SE_FL_EOS | SE_FL_EOI ) ;
goto out ;
2020-05-29 19:42:45 -04:00
}
2020-05-28 05:13:15 -04:00
void __sink_forward_session_deinit ( struct sink_forward_target * sft )
{
struct sink * sink ;
2023-09-14 18:29:53 -04:00
sink = sft - > sink ;
2020-05-28 05:13:15 -04:00
if ( ! sink )
return ;
2024-02-28 11:04:40 -05:00
MT_LIST_DELETE ( & sft - > appctx - > wait_entry ) ;
2020-05-28 05:13:15 -04:00
sft - > appctx = NULL ;
task_wakeup ( sink - > forward_task , TASK_WOKEN_MSG ) ;
}
2022-05-12 09:34:48 -04:00
static int sink_forward_session_init ( struct appctx * appctx )
{
struct sink_forward_target * sft = appctx - > svcctx ;
struct stream * s ;
struct sockaddr_storage * addr = NULL ;
if ( ! sockaddr_alloc ( & addr , & sft - > srv - > addr , sizeof ( sft - > srv - > addr ) ) )
goto out_error ;
2023-11-09 09:00:34 -05:00
/* srv port should be learned from srv->svc_port not from srv->addr */
set_host_port ( addr , sft - > srv - > svc_port ) ;
2022-05-12 09:34:48 -04:00
2023-09-14 19:49:08 -04:00
if ( appctx_finalize_startup ( appctx , sft - > srv - > proxy , & BUF_NULL ) = = - 1 )
2022-05-12 09:34:48 -04:00
goto out_free_addr ;
s = appctx_strm ( appctx ) ;
2022-05-17 13:40:40 -04:00
s - > scb - > dst = addr ;
2023-03-16 09:40:03 -04:00
s - > scb - > flags | = ( SC_FL_RCV_ONCE | SC_FL_NOLINGER ) ;
2022-05-12 09:34:48 -04:00
s - > target = & sft - > srv - > obj_type ;
s - > flags = SF_ASSIGNED ;
s - > do_log = NULL ;
s - > uniq_id = 0 ;
2023-02-22 08:22:56 -05:00
applet_expect_no_data ( appctx ) ;
2022-05-12 09:34:48 -04:00
sft - > appctx = appctx ;
return 0 ;
out_free_addr :
sockaddr_free ( & addr ) ;
out_error :
return - 1 ;
}
2020-05-28 05:13:15 -04:00
static void sink_forward_session_release ( struct appctx * appctx )
{
2022-05-04 14:42:23 -04:00
struct sink_forward_target * sft = appctx - > svcctx ;
2020-05-28 05:13:15 -04:00
if ( ! sft )
return ;
HA_SPIN_LOCK ( SFT_LOCK , & sft - > lock ) ;
if ( sft - > appctx = = appctx )
__sink_forward_session_deinit ( sft ) ;
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
}
static struct applet sink_forward_applet = {
. obj_type = OBJ_TYPE_APPLET ,
. name = " <SINKFWD> " , /* used for logging */
. fct = sink_forward_io_handler ,
2022-05-12 09:34:48 -04:00
. init = sink_forward_session_init ,
2020-05-28 05:13:15 -04:00
. release = sink_forward_session_release ,
} ;
2020-05-29 19:42:45 -04:00
static struct applet sink_forward_oc_applet = {
. obj_type = OBJ_TYPE_APPLET ,
. name = " <SINKFWDOC> " , /* used for logging */
. fct = sink_forward_oc_io_handler ,
2022-05-12 09:34:48 -04:00
. init = sink_forward_session_init ,
2020-05-29 19:42:45 -04:00
. release = sink_forward_session_release ,
} ;
2020-05-28 05:13:15 -04:00
/*
* Create a new peer session in assigned state ( connect will start automatically )
2022-05-04 14:42:23 -04:00
* It sets its context into appctx - > svcctx .
2020-05-28 05:13:15 -04:00
*/
static struct appctx * sink_forward_session_create ( struct sink * sink , struct sink_forward_target * sft )
{
struct appctx * appctx ;
2020-05-29 19:42:45 -04:00
struct applet * applet = & sink_forward_applet ;
if ( sft - > srv - > log_proto = = SRV_LOG_PROTO_OCTET_COUNTING )
applet = & sink_forward_oc_applet ;
2020-05-28 05:13:15 -04:00
2022-05-16 11:09:48 -04:00
appctx = appctx_new_here ( applet , NULL ) ;
2022-01-19 08:50:11 -05:00
if ( ! appctx )
2022-03-23 06:01:09 -04:00
goto out_close ;
2022-05-04 14:42:23 -04:00
appctx - > svcctx = ( void * ) sft ;
2020-05-28 05:13:15 -04:00
2022-05-12 09:34:48 -04:00
if ( appctx_init ( appctx ) = = - 1 )
2022-05-11 06:22:10 -04:00
goto out_free_appctx ;
2022-03-23 06:01:09 -04:00
2020-05-28 05:13:15 -04:00
return appctx ;
/* Error unrolling */
out_free_appctx :
2022-05-12 09:34:48 -04:00
appctx_free_on_early_error ( appctx ) ;
2020-05-28 05:13:15 -04:00
out_close :
return NULL ;
}
/*
2023-11-21 13:54:16 -05:00
* Task to handle connections to forward servers
2020-05-28 05:13:15 -04:00
*/
2021-03-02 10:09:26 -05:00
static struct task * process_sink_forward ( struct task * task , void * context , unsigned int state )
2020-05-28 05:13:15 -04:00
{
struct sink * sink = ( struct sink * ) context ;
struct sink_forward_target * sft = sink - > sft ;
task - > expire = TICK_ETERNITY ;
if ( ! stopping ) {
while ( sft ) {
HA_SPIN_LOCK ( SFT_LOCK , & sft - > lock ) ;
/* if appctx is NULL, start a new session */
if ( ! sft - > appctx )
sft - > appctx = sink_forward_session_create ( sink , sft ) ;
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
sft = sft - > next ;
}
}
else {
while ( sft ) {
HA_SPIN_LOCK ( SFT_LOCK , & sft - > lock ) ;
/* awake applet to perform a clean close */
if ( sft - > appctx )
appctx_wakeup ( sft - > appctx ) ;
HA_SPIN_UNLOCK ( SFT_LOCK , & sft - > lock ) ;
sft = sft - > next ;
}
}
return task ;
}
/*
2023-11-21 13:54:16 -05:00
* Init task to manage connections to forward servers
2020-05-28 05:13:15 -04:00
*
* returns 0 in case of error .
*/
int sink_init_forward ( struct sink * sink )
{
2021-10-01 12:23:30 -04:00
sink - > forward_task = task_new_anywhere ( ) ;
2020-05-28 05:13:15 -04:00
if ( ! sink - > forward_task )
return 0 ;
sink - > forward_task - > process = process_sink_forward ;
sink - > forward_task - > context = ( void * ) sink ;
sink - > forward_sighandler = signal_register_task ( 0 , sink - > forward_task , 0 ) ;
task_wakeup ( sink - > forward_task , TASK_WOKEN_INIT ) ;
return 1 ;
}
2022-08-31 12:52:17 -04:00
/* This tries to rotate a file-backed ring, but only if it contains contents.
* This way empty rings will not cause backups to be overwritten and it ' s safe
* to reload multiple times . That ' s only best effort , failures are silently
* ignored .
*/
void sink_rotate_file_backed_ring ( const char * name )
{
MAJOR: ring: insert an intermediary ring_storage level
We'll need to add more complex structures in the ring, such as wait
queues. That's far too much to be stored into the area in case of
file-backed contents, so let's split the ring definition and its
storage once for all.
This patch introduces a struct ring_storage which is assigned to
ring->storage, which contains minimal information to represent the
storage layout, i.e. for now only the buffer, and all the rest
remains in the ring itself. The storage is appended immediately after
it and the buffer's pointer always points to that area. It has the
benefit of remaining 100% compatible with the existing file-backed
layout. In memory, the allocation loses the size of a struct buffer.
It's not even certain it's worth placing the size there, given that it's
constant and that a dump of a ring wouldn't really need it (the file size
is sufficient). But for now everything comes with the struct buffer, and
later this will change once split into head and tail. Also this area may
be completed with more information in the future (e.g. storage version,
format, endianness, word size etc).
2024-03-03 11:20:10 -05:00
struct ring_storage storage ;
2022-08-31 12:52:17 -04:00
char * oldback ;
int ret ;
int fd ;
fd = open ( name , O_RDONLY ) ;
if ( fd < 0 )
return ;
/* check for contents validity */
MAJOR: ring: insert an intermediary ring_storage level
We'll need to add more complex structures in the ring, such as wait
queues. That's far too much to be stored into the area in case of
file-backed contents, so let's split the ring definition and its
storage once for all.
This patch introduces a struct ring_storage which is assigned to
ring->storage, which contains minimal information to represent the
storage layout, i.e. for now only the buffer, and all the rest
remains in the ring itself. The storage is appended immediately after
it and the buffer's pointer always points to that area. It has the
benefit of remaining 100% compatible with the existing file-backed
layout. In memory, the allocation loses the size of a struct buffer.
It's not even certain it's worth placing the size there, given that it's
constant and that a dump of a ring wouldn't really need it (the file size
is sufficient). But for now everything comes with the struct buffer, and
later this will change once split into head and tail. Also this area may
be completed with more information in the future (e.g. storage version,
format, endianness, word size etc).
2024-03-03 11:20:10 -05:00
ret = read ( fd , & storage , sizeof ( storage ) ) ;
2022-08-31 12:52:17 -04:00
close ( fd ) ;
MAJOR: ring: insert an intermediary ring_storage level
We'll need to add more complex structures in the ring, such as wait
queues. That's far too much to be stored into the area in case of
file-backed contents, so let's split the ring definition and its
storage once for all.
This patch introduces a struct ring_storage which is assigned to
ring->storage, which contains minimal information to represent the
storage layout, i.e. for now only the buffer, and all the rest
remains in the ring itself. The storage is appended immediately after
it and the buffer's pointer always points to that area. It has the
benefit of remaining 100% compatible with the existing file-backed
layout. In memory, the allocation loses the size of a struct buffer.
It's not even certain it's worth placing the size there, given that it's
constant and that a dump of a ring wouldn't really need it (the file size
is sufficient). But for now everything comes with the struct buffer, and
later this will change once split into head and tail. Also this area may
be completed with more information in the future (e.g. storage version,
format, endianness, word size etc).
2024-03-03 11:20:10 -05:00
if ( ret ! = sizeof ( storage ) )
2022-08-31 12:52:17 -04:00
goto rotate ;
2024-02-27 03:17:45 -05:00
/* check that it's the expected format before touching it */
if ( storage . rsvd ! = sizeof ( storage ) )
return ;
2022-08-31 12:52:17 -04:00
/* contents are present, we want to keep them => rotate. Note that
* an empty ring buffer has one byte ( the marker ) .
*/
2024-02-27 03:17:45 -05:00
if ( storage . head ! = 0 | | storage . tail ! = 1 )
2022-08-31 12:52:17 -04:00
goto rotate ;
/* nothing to keep, let's scratch the file and preserve the backup */
return ;
rotate :
oldback = NULL ;
memprintf ( & oldback , " %s.bak " , name ) ;
if ( oldback ) {
/* try to rename any possibly existing ring file to
* " .bak " and delete remains of older ones . This will
* ensure we don ' t wipe useful debug info upon restart .
*/
unlink ( oldback ) ;
if ( rename ( name , oldback ) < 0 )
unlink ( oldback ) ;
ha_free ( & oldback ) ;
}
}
2023-07-06 10:55:55 -04:00
/* helper function to completely deallocate a sink struct
*/
static void sink_free ( struct sink * sink )
{
struct sink_forward_target * sft_next ;
if ( ! sink )
return ;
if ( sink - > type = = SINK_TYPE_BUFFER ) {
if ( sink - > store ) {
2024-05-21 05:13:46 -04:00
size_t size = ( ring_allocated_size ( sink - > ctx . ring ) + 4095UL ) & - 4096UL ;
void * area = ring_allocated_area ( sink - > ctx . ring ) ;
2023-07-06 10:55:55 -04:00
msync ( area , size , MS_SYNC ) ;
munmap ( area , size ) ;
ha_free ( & sink - > store ) ;
}
2024-03-26 10:12:19 -04:00
ring_free ( sink - > ctx . ring ) ;
2023-07-06 10:55:55 -04:00
}
LIST_DEL_INIT ( & sink - > sink_list ) ; // remove from parent list
task_destroy ( sink - > forward_task ) ;
free_proxy ( sink - > forward_px ) ;
ha_free ( & sink - > name ) ;
ha_free ( & sink - > desc ) ;
while ( sink - > sft ) {
sft_next = sink - > sft - > next ;
ha_free ( & sink - > sft ) ;
sink - > sft = sft_next ;
}
ha_free ( & sink ) ;
}
2023-07-06 10:43:40 -04:00
/* Helper function to create new high-level ring buffer (as in ring section from
2023-09-14 19:49:08 -04:00
* the config ) : will create a new sink of buf type , and a new forward proxy ,
* which will be stored in forward_px to know that the sink is responsible for
* it .
2023-07-06 10:43:40 -04:00
*
* Returns NULL on failure
*/
static struct sink * sink_new_ringbuf ( const char * id , const char * description ,
const char * file , int linenum , char * * err_msg )
{
struct sink * sink ;
struct proxy * p = NULL ; // forward_px
/* allocate new proxy to handle forwards */
p = calloc ( 1 , sizeof ( * p ) ) ;
if ( ! p ) {
memprintf ( err_msg , " out of memory " ) ;
goto err ;
}
init_new_proxy ( p ) ;
sink_setup_proxy ( p ) ;
p - > id = strdup ( id ) ;
p - > conf . args . file = p - > conf . file = strdup ( file ) ;
p - > conf . args . line = p - > conf . line = linenum ;
sink = sink_new_buf ( id , description , LOG_FORMAT_RAW , BUFSIZE ) ;
2023-09-14 05:41:46 -04:00
if ( ! sink ) {
2023-07-06 10:43:40 -04:00
memprintf ( err_msg , " unable to create a new sink buffer for ring '%s' " , id ) ;
goto err ;
}
2023-09-13 11:34:58 -04:00
/* link sink to proxy */
2023-07-06 10:43:40 -04:00
sink - > forward_px = p ;
return sink ;
err :
free_proxy ( p ) ;
return NULL ;
}
2023-09-18 11:14:22 -04:00
/* helper function: add a new server to an existing sink
*
* Returns 1 on success and 0 on failure
*/
static int sink_add_srv ( struct sink * sink , struct server * srv )
{
struct sink_forward_target * sft ;
/* allocate new sink_forward_target descriptor */
sft = calloc ( 1 , sizeof ( * sft ) ) ;
if ( ! sft ) {
ha_alert ( " memory allocation error initializing server '%s' in ring '%s'. \n " , srv - > id , sink - > name ) ;
return 0 ;
}
sft - > srv = srv ;
sft - > appctx = NULL ;
sft - > ofs = ~ 0 ; /* init ring offset */
sft - > sink = sink ;
sft - > next = sink - > sft ;
HA_SPIN_INIT ( & sft - > lock ) ;
/* mark server attached to the ring */
if ( ! ring_attach ( sink - > ctx . ring ) ) {
ha_alert ( " server '%s' sets too many watchers > 255 on ring '%s'. \n " , srv - > id , sink - > name ) ;
ha_free ( & sft ) ;
return 0 ;
}
sink - > sft = sft ;
return 1 ;
}
2023-07-10 09:04:40 -04:00
/* Finalize sink struct to ensure configuration consistency and
* allocate final struct members
*
* Returns ERR_NONE on success , ERR_WARN on warning
* Returns a composition of ERR_ALERT , ERR_ABORT , ERR_FATAL on failure
*/
static int sink_finalize ( struct sink * sink )
{
int err_code = ERR_NONE ;
struct server * srv ;
if ( sink & & ( sink - > type = = SINK_TYPE_BUFFER ) ) {
if ( ! sink - > maxlen )
sink - > maxlen = ~ 0 ; // maxlen not set: no implicit truncation
else if ( sink - > maxlen > ring_max_payload ( sink - > ctx . ring ) ) {
/* maxlen set by user however it doesn't fit: set to max value */
ha_warning ( " ring '%s' event max length '%u' exceeds max payload size, forced to '%lu'. \n " ,
sink - > name , sink - > maxlen , ( unsigned long ) ring_max_payload ( sink - > ctx . ring ) ) ;
sink - > maxlen = ring_max_payload ( sink - > ctx . ring ) ;
err_code | = ERR_WARN ;
}
/* prepare forward server descriptors */
if ( sink - > forward_px ) {
2023-09-18 11:14:22 -04:00
/* sink proxy is set: register all servers from the proxy */
2023-07-10 09:04:40 -04:00
srv = sink - > forward_px - > srv ;
while ( srv ) {
2023-09-18 11:14:22 -04:00
if ( ! sink_add_srv ( sink , srv ) ) {
2023-07-10 09:04:40 -04:00
err_code | = ERR_ALERT | ERR_FATAL ;
break ;
}
srv = srv - > next ;
}
2023-09-18 11:21:19 -04:00
}
/* init forwarding if at least one sft is registered */
if ( sink - > sft & & sink_init_forward ( sink ) = = 0 ) {
ha_alert ( " error when trying to initialize sink buffer forwarding. \n " ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
2023-07-10 09:04:40 -04:00
}
2024-05-20 09:16:10 -04:00
if ( ! sink - > store ) {
/* virtual memory backed sink */
vma_set_name ( ring_allocated_area ( sink - > ctx . ring ) ,
ring_allocated_size ( sink - > ctx . ring ) ,
" ring " , sink - > name ) ;
}
2023-07-10 09:04:40 -04:00
}
return err_code ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
/*
* Parse " ring " section and create corresponding sink buffer .
*
* The function returns 0 in success case , otherwise , it returns error
* flags .
*/
int cfg_parse_ring ( const char * file , int linenum , char * * args , int kwm )
{
int err_code = 0 ;
2023-07-06 10:43:40 -04:00
char * err_msg = NULL ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
const char * inv ;
2022-08-11 10:12:11 -04:00
if ( strcmp ( args [ 0 ] , " ring " ) = = 0 ) { /* new ring section */
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
if ( ! * args [ 1 ] ) {
ha_alert ( " parsing [%s:%d] : missing ring name. \n " , file , linenum ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
inv = invalid_char ( args [ 1 ] ) ;
if ( inv ) {
ha_alert ( " parsing [%s:%d] : invalid ring name '%s' (character '%c' is not permitted). \n " , file , linenum , args [ 1 ] , * inv ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
if ( sink_find ( args [ 1 ] ) ) {
ha_alert ( " parsing [%s:%d] : sink named '%s' already exists. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2023-07-06 10:43:40 -04:00
cfg_sink = sink_new_ringbuf ( args [ 1 ] , args [ 1 ] , file , linenum , & err_msg ) ;
if ( ! cfg_sink ) {
ha_alert ( " parsing [%s:%d] : %s. \n " , file , linenum , err_msg ) ;
ha_free ( & err_msg ) ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2023-07-06 10:43:40 -04:00
2023-06-23 12:44:53 -04:00
/* set maxlen value to 0 for now, we rely on this in postparsing
* to know if it was explicitly set using the " maxlen " parameter
*/
cfg_sink - > maxlen = 0 ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
}
else if ( strcmp ( args [ 0 ] , " size " ) = = 0 ) {
2023-07-06 10:43:40 -04:00
size_t size ;
2022-08-11 10:12:11 -04:00
if ( ! cfg_sink | | ( cfg_sink - > type ! = SINK_TYPE_BUFFER ) ) {
ha_alert ( " parsing [%s:%d] : 'size' directive not usable with this type of sink. \n " , file , linenum ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
size = atol ( args [ 1 ] ) ;
if ( ! size ) {
ha_alert ( " parsing [%s:%d] : invalid size '%s' for new sink buffer. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2024-02-28 03:37:47 -05:00
if ( size > RING_TAIL_LOCK ) {
ha_alert ( " parsing [%s:%d] : too large size '%llu' for new sink buffer, the limit on this platform is %llu bytes. \n " , file , linenum , ( ullong ) size , ( ullong ) RING_TAIL_LOCK ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2022-08-11 10:38:20 -04:00
if ( cfg_sink - > store ) {
ha_alert ( " parsing [%s:%d] : cannot resize an already mapped file, please specify 'size' before 'backing-file'. \n " , file , linenum ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2024-03-14 01:48:41 -04:00
if ( size < ring_data ( cfg_sink - > ctx . ring ) ) {
ha_warning ( " parsing [%s:%d] : ignoring new size '%llu' that is smaller than contents '%llu' for ring '%s'. \n " ,
file , linenum , ( ullong ) size , ( ullong ) ring_data ( cfg_sink - > ctx . ring ) , cfg_sink - > name ) ;
2023-06-22 10:57:29 -04:00
err_code | = ERR_WARN ;
2022-08-11 10:12:11 -04:00
goto err ;
}
if ( ! ring_resize ( cfg_sink - > ctx . ring , size ) ) {
ha_alert ( " parsing [%s:%d] : fail to set sink buffer size '%llu' for ring '%s'. \n " , file , linenum ,
2024-03-06 10:50:40 -05:00
( ullong ) ring_size ( cfg_sink - > ctx . ring ) , cfg_sink - > name ) ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
}
2022-08-11 10:38:20 -04:00
else if ( strcmp ( args [ 0 ] , " backing-file " ) = = 0 ) {
/* This tries to mmap file <file> for size <size> and to use it as a backing store
* for ring < ring > . Existing data are delete . NULL is returned on error .
*/
const char * backing = args [ 1 ] ;
size_t size ;
void * area ;
int fd ;
if ( ! cfg_sink | | ( cfg_sink - > type ! = SINK_TYPE_BUFFER ) ) {
ha_alert ( " parsing [%s:%d] : 'backing-file' only usable with existing rings. \n " , file , linenum ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
if ( cfg_sink - > store ) {
ha_alert ( " parsing [%s:%d] : 'backing-file' already specified for ring '%s' (was '%s'). \n " , file , linenum , cfg_sink - > name , cfg_sink - > store ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2022-08-31 12:52:17 -04:00
/* let's check if the file exists and is not empty. That's the
* only condition under which we ' ll trigger a rotate , so that
* config checks , reloads , or restarts that don ' t emit anything
* do not rotate it again .
*/
sink_rotate_file_backed_ring ( backing ) ;
2022-08-12 09:38:20 -04:00
2022-08-12 09:03:12 -04:00
fd = open ( backing , O_RDWR | O_CREAT , 0600 ) ;
2022-08-11 10:38:20 -04:00
if ( fd < 0 ) {
ha_alert ( " parsing [%s:%d] : cannot open backing-file '%s' for ring '%s': %s. \n " , file , linenum , backing , cfg_sink - > name , strerror ( errno ) ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2024-03-06 10:50:40 -05:00
size = ( ring_size ( cfg_sink - > ctx . ring ) + 4095UL ) & - 4096UL ;
2022-08-11 10:38:20 -04:00
if ( ftruncate ( fd , size ) ! = 0 ) {
close ( fd ) ;
ha_alert ( " parsing [%s:%d] : could not adjust size of backing-file for ring '%s': %s. \n " , file , linenum , cfg_sink - > name , strerror ( errno ) ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
area = mmap ( NULL , size , PROT_READ | PROT_WRITE , MAP_SHARED , fd , 0 ) ;
if ( area = = MAP_FAILED ) {
close ( fd ) ;
ha_alert ( " parsing [%s:%d] : failed to use '%s' as a backing file for ring '%s': %s. \n " , file , linenum , backing , cfg_sink - > name , strerror ( errno ) ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
/* we don't need the file anymore */
close ( fd ) ;
cfg_sink - > store = strdup ( backing ) ;
/* never fails */
ring_free ( cfg_sink - > ctx . ring ) ;
MAJOR: ring: insert an intermediary ring_storage level
We'll need to add more complex structures in the ring, such as wait
queues. That's far too much to be stored into the area in case of
file-backed contents, so let's split the ring definition and its
storage once for all.
This patch introduces a struct ring_storage which is assigned to
ring->storage, which contains minimal information to represent the
storage layout, i.e. for now only the buffer, and all the rest
remains in the ring itself. The storage is appended immediately after
it and the buffer's pointer always points to that area. It has the
benefit of remaining 100% compatible with the existing file-backed
layout. In memory, the allocation loses the size of a struct buffer.
It's not even certain it's worth placing the size there, given that it's
constant and that a dump of a ring wouldn't really need it (the file size
is sufficient). But for now everything comes with the struct buffer, and
later this will change once split into head and tail. Also this area may
be completed with more information in the future (e.g. storage version,
format, endianness, word size etc).
2024-03-03 11:20:10 -05:00
cfg_sink - > ctx . ring = ring_make_from_area ( area , size , 1 ) ;
2022-08-11 10:38:20 -04:00
}
2020-05-28 05:13:15 -04:00
else if ( strcmp ( args [ 0 ] , " server " ) = = 0 ) {
2022-11-16 12:56:34 -05:00
if ( ! cfg_sink | | ( cfg_sink - > type ! = SINK_TYPE_BUFFER ) ) {
ha_alert ( " parsing [%s:%d] : unable to create server '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2021-03-08 10:36:46 -05:00
err_code | = parse_server ( file , linenum , args , cfg_sink - > forward_px , NULL ,
SRV_PARSE_PARSE_ADDR | SRV_PARSE_INITIAL_RESOLVE ) ;
2020-05-28 05:13:15 -04:00
}
else if ( strcmp ( args [ 0 ] , " timeout " ) = = 0 ) {
if ( ! cfg_sink | | ! cfg_sink - > forward_px ) {
ha_alert ( " parsing [%s:%d] : unable to set timeout '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
if ( strcmp ( args [ 1 ] , " connect " ) = = 0 | |
strcmp ( args [ 1 ] , " server " ) = = 0 ) {
const char * res ;
unsigned int tout ;
if ( ! * args [ 2 ] ) {
ha_alert ( " parsing [%s:%d] : '%s %s' expects <time> as argument. \n " ,
file , linenum , args [ 0 ] , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
res = parse_time_err ( args [ 2 ] , & tout , TIME_UNIT_MS ) ;
if ( res = = PARSE_TIME_OVER ) {
ha_alert ( " parsing [%s:%d]: timer overflow in argument <%s> to <%s %s>, maximum value is 2147483647 ms (~24.8 days). \n " ,
file , linenum , args [ 2 ] , args [ 0 ] , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
else if ( res = = PARSE_TIME_UNDER ) {
ha_alert ( " parsing [%s:%d]: timer underflow in argument <%s> to <%s %s>, minimum non-null value is 1 ms. \n " ,
file , linenum , args [ 2 ] , args [ 0 ] , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
else if ( res ) {
ha_alert ( " parsing [%s:%d]: unexpected character '%c' in argument to <%s %s>. \n " ,
file , linenum , * res , args [ 0 ] , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2022-10-19 10:26:21 -04:00
if ( args [ 1 ] [ 0 ] = = ' c ' )
2020-05-28 05:13:15 -04:00
cfg_sink - > forward_px - > timeout . connect = tout ;
else
cfg_sink - > forward_px - > timeout . server = tout ;
}
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
else if ( strcmp ( args [ 0 ] , " format " ) = = 0 ) {
if ( ! cfg_sink ) {
ha_alert ( " parsing [%s:%d] : unable to set format '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
2020-07-06 09:54:06 -04:00
cfg_sink - > fmt = get_log_format ( args [ 1 ] ) ;
if ( cfg_sink - > fmt = = LOG_FORMAT_UNSPEC ) {
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
ha_alert ( " parsing [%s:%d] : unknown format '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
}
else if ( strcmp ( args [ 0 ] , " maxlen " ) = = 0 ) {
if ( ! cfg_sink ) {
ha_alert ( " parsing [%s:%d] : unable to set event max length '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
cfg_sink - > maxlen = atol ( args [ 1 ] ) ;
if ( ! cfg_sink - > maxlen ) {
ha_alert ( " parsing [%s:%d] : invalid size '%s' for new sink buffer. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
}
else if ( strcmp ( args [ 0 ] , " description " ) = = 0 ) {
if ( ! cfg_sink ) {
ha_alert ( " parsing [%s:%d] : unable to set description '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
if ( ! * args [ 1 ] ) {
ha_alert ( " parsing [%s:%d] : missing ring description text. \n " , file , linenum ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
free ( cfg_sink - > desc ) ;
cfg_sink - > desc = strdup ( args [ 1 ] ) ;
if ( ! cfg_sink - > desc ) {
ha_alert ( " parsing [%s:%d] : fail to set description '%s'. \n " , file , linenum , args [ 1 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
}
2020-05-29 09:47:52 -04:00
else {
ha_alert ( " parsing [%s:%d] : unknown statement '%s'. \n " , file , linenum , args [ 0 ] ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto err ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
err :
return err_code ;
}
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
/* Creates a new sink buffer from a logger.
2021-04-02 04:41:36 -04:00
*
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
* It uses the logger ' s address to declare a forward
2021-04-02 04:41:36 -04:00
* server for this buffer . And it initializes the
* forwarding .
*
* The function returns a pointer on the
* allocated struct sink if allocate
* and initialize succeed , else if it fails
* it returns NULL .
*
* Note : the sink is created using the name
2023-09-11 10:10:37 -04:00
* specified into logger - > target . ring_name
2021-04-02 04:41:36 -04:00
*/
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
struct sink * sink_new_from_logger ( struct logger * logger )
2021-04-02 04:41:36 -04:00
{
struct sink * sink = NULL ;
struct server * srv = NULL ;
2023-07-06 10:43:40 -04:00
char * err_msg = NULL ;
2021-04-02 04:41:36 -04:00
2023-07-06 10:43:40 -04:00
/* prepare description for the sink */
chunk_reset ( & trash ) ;
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
chunk_printf ( & trash , " created from log directive declared into '%s' at line %d " , logger - > conf . file , logger - > conf . line ) ;
2023-07-06 10:43:40 -04:00
/* allocate a new sink buffer */
2023-09-11 10:10:37 -04:00
sink = sink_new_ringbuf ( logger - > target . ring_name , trash . area , logger - > conf . file , logger - > conf . line , & err_msg ) ;
2023-07-06 10:43:40 -04:00
if ( ! sink ) {
ha_alert ( " %s. \n " , err_msg ) ;
ha_free ( & err_msg ) ;
2021-04-02 04:41:36 -04:00
goto error ;
2023-07-06 10:43:40 -04:00
}
2021-04-02 04:41:36 -04:00
2023-08-25 03:50:27 -04:00
/* ring format normally defaults to RAW, but here we set ring format
* to UNSPEC to inherit from caller format in sink_write ( ) since we
* cannot customize implicit ring settings
*/
sink - > fmt = LOG_FORMAT_UNSPEC ;
2023-07-06 10:43:40 -04:00
2023-08-25 03:50:27 -04:00
/* for the same reason, we disable sink->maxlen to inherit from caller
* maxlen in sink_write ( )
*/
sink - > maxlen = 0 ;
2021-04-02 04:41:36 -04:00
2023-07-06 10:43:40 -04:00
/* Set default connect and server timeout for sink forward proxy */
sink - > forward_px - > timeout . connect = MS_TO_TICKS ( 1000 ) ;
sink - > forward_px - > timeout . server = MS_TO_TICKS ( 5000 ) ;
2022-10-24 09:53:01 -04:00
2021-04-02 04:41:36 -04:00
/* allocate a new server to forward messages
* from ring buffer
*/
2023-07-06 10:43:40 -04:00
srv = new_server ( sink - > forward_px ) ;
2021-04-02 04:41:36 -04:00
if ( ! srv )
goto error ;
/* init server */
2023-09-11 10:10:37 -04:00
srv - > id = strdup ( logger - > target . ring_name ) ;
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
srv - > conf . file = strdup ( logger - > conf . file ) ;
srv - > conf . line = logger - > conf . line ;
2023-09-11 10:10:37 -04:00
srv - > addr = * logger - > target . addr ;
2023-11-09 09:14:36 -05:00
srv - > svc_port = get_host_port ( logger - > target . addr ) ;
2021-04-02 04:41:36 -04:00
HA_SPIN_INIT ( & srv - > lock ) ;
/* process per thread init */
2021-06-15 09:33:20 -04:00
if ( srv_init_per_thr ( srv ) = = - 1 )
2021-04-02 04:41:36 -04:00
goto error ;
2023-07-06 10:43:40 -04:00
/* link srv with sink forward proxy: the servers are linked
* backwards first into proxy
*/
srv - > next = sink - > forward_px - > srv ;
sink - > forward_px - > srv = srv ;
2021-04-02 04:41:36 -04:00
2023-07-10 09:04:40 -04:00
if ( sink_finalize ( sink ) & ERR_CODE )
2023-07-06 10:43:40 -04:00
goto error_final ;
2021-04-02 04:41:36 -04:00
return sink ;
2023-07-06 10:43:40 -04:00
error :
srv_drop ( srv ) ;
2021-04-02 04:41:36 -04:00
2023-07-06 10:43:40 -04:00
error_final :
sink_free ( sink ) ;
2021-04-02 04:41:36 -04:00
return NULL ;
}
2023-09-14 05:35:27 -04:00
/* This function is pretty similar to sink_from_logger():
* But instead of creating a forward proxy and server from a logger struct
* it uses already existing srv to create the forwarding sink , so most of
* the initialization is bypassed .
*
* The function returns a pointer on the
* allocated struct sink if allocate
* and initialize succeed , else if it fails
* it returns NULL .
*
* < from > allows to specify a string that will be inserted into the sink
* description to describe where it was created from .
* Note : the sink is created using the name
* specified into srv - > id
*/
struct sink * sink_new_from_srv ( struct server * srv , const char * from )
{
struct sink * sink = NULL ;
2023-10-04 04:32:45 -04:00
int bufsize = ( srv - > log_bufsize ) ? srv - > log_bufsize : BUFSIZE ;
2023-09-14 05:35:27 -04:00
/* prepare description for the sink */
chunk_reset ( & trash ) ;
chunk_printf ( & trash , " created from %s declared into '%s' at line %d " , from , srv - > conf . file , srv - > conf . line ) ;
/* directly create a sink of BUF type, and use UNSPEC log format to
* inherit from caller fmt in sink_write ( )
*/
2023-10-04 04:32:45 -04:00
sink = sink_new_buf ( srv - > id , trash . area , LOG_FORMAT_UNSPEC , bufsize ) ;
2023-09-14 05:35:27 -04:00
if ( ! sink ) {
ha_alert ( " unable to create a new sink buffer for server '%s'. \n " , srv - > id ) ;
goto error ;
}
/* we disable sink->maxlen to inherit from caller
* maxlen in sink_write ( )
*/
sink - > maxlen = 0 ;
/* add server to sink */
if ( ! sink_add_srv ( sink , srv ) )
goto error ;
if ( sink_finalize ( sink ) & ERR_CODE )
goto error ;
return sink ;
error :
sink_free ( sink ) ;
return NULL ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
/*
* Post parsing " ring " section .
*
* The function returns 0 in success case , otherwise , it returns error
* flags .
*/
int cfg_post_parse_ring ( )
{
2023-07-10 09:04:40 -04:00
int err_code ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
2023-07-10 09:04:40 -04:00
err_code = sink_finalize ( cfg_sink ) ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
cfg_sink = NULL ;
return err_code ;
}
MEDIUM: tree-wide: logsrv struct becomes logger
When 'log' directive was implemented, the internal representation was
named 'struct logsrv', because the 'log' directive would directly point
to the log target, which used to be a (UDP) log server exclusively at
that time, hence the name.
But things have become more complex, since today 'log' directive can point
to ring targets (implicit, or named) for example.
Indeed, a 'log' directive does no longer reference the "final" server to
which the log will be sent, but instead it describes which log API and
parameters to use for transporting the log messages to the proper log
destination.
So now the term 'logsrv' is rather confusing and prevents us from
introducing a new level of abstraction because they would be mixed
with logsrv.
So in order to better designate this 'log' directive, and make it more
generic, we chose the word 'logger' which now replaces logsrv everywhere
it was used in the code (including related comments).
This is internal rewording, so no functional change should be expected
on user-side.
2023-09-11 09:06:53 -04:00
/* function: resolve a single logger target of BUFFER type
2023-06-22 12:33:39 -04:00
*
* Returns err_code which defaults to ERR_NONE and can be set to a combination
* of ERR_WARN , ERR_ALERT , ERR_FATAL and ERR_ABORT in case of errors .
2023-08-17 11:38:30 -04:00
* < msg > could be set at any time ( it will usually be set on error , but
2023-11-21 13:54:16 -05:00
* could also be set when no error occurred to report a diag warning ) , thus is
2023-08-17 11:38:30 -04:00
* up to the caller to check it and to free it .
2023-06-22 12:33:39 -04:00
*/
2023-09-11 10:10:37 -04:00
int sink_resolve_logger_buffer ( struct logger * logger , char * * msg )
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
{
2023-09-11 10:10:37 -04:00
struct log_target * target = & logger - > target ;
2020-11-06 09:24:23 -05:00
int err_code = ERR_NONE ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
struct sink * sink ;
2023-09-11 10:10:37 -04:00
BUG_ON ( target - > type ! = LOG_TARGET_BUFFER | | ( target - > flags & LOG_TARGET_FL_RESOLVED ) ) ;
2023-09-13 13:28:34 -04:00
if ( target - > addr ) {
sink = sink_new_from_logger ( logger ) ;
if ( ! sink ) {
memprintf ( msg , " cannot be initialized (failed to create implicit ring) " ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto end ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
}
2023-09-13 13:28:34 -04:00
ha_free ( & target - > addr ) ; /* we no longer need this */
}
else {
sink = sink_find ( target - > ring_name ) ;
if ( ! sink ) {
2023-08-17 11:38:30 -04:00
memprintf ( msg , " uses unknown ring named '%s' " , target - > ring_name ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto end ;
}
2023-09-13 13:28:34 -04:00
else if ( sink - > type ! = SINK_TYPE_BUFFER ) {
memprintf ( msg , " uses incompatible ring '%s' " , target - > ring_name ) ;
err_code | = ERR_ALERT | ERR_FATAL ;
goto end ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
}
2023-09-13 13:28:34 -04:00
/* consistency checks */
2023-09-11 10:10:37 -04:00
if ( sink & & logger - > maxlen > ring_max_payload ( sink - > ctx . ring ) ) {
2023-08-17 11:38:30 -04:00
memprintf ( msg , " uses a max length which exceeds ring capacity ('%s' supports %lu bytes at most) " ,
target - > ring_name , ( unsigned long ) ring_max_payload ( sink - > ctx . ring ) ) ;
}
2023-09-11 10:10:37 -04:00
else if ( sink & & logger - > maxlen > sink - > maxlen ) {
2023-08-17 11:38:30 -04:00
memprintf ( msg , " uses a ring with a smaller maxlen than the one specified on the log directive ('%s' has maxlen = %d), logs will be truncated according to the lowest maxlen between the two " ,
target - > ring_name , sink - > maxlen ) ;
}
end :
2023-09-11 10:10:37 -04:00
ha_free ( & target - > ring_name ) ; /* sink is resolved and will replace ring_name hint */
2023-08-17 11:38:30 -04:00
target - > sink = sink ;
2023-06-22 12:33:39 -04:00
return err_code ;
}
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
2019-08-20 05:57:52 -04:00
static void sink_init ( )
{
2020-07-06 09:54:06 -04:00
sink_new_fd ( " stdout " , " standard output (fd#1) " , LOG_FORMAT_RAW , 1 ) ;
sink_new_fd ( " stderr " , " standard output (fd#2) " , LOG_FORMAT_RAW , 2 ) ;
sink_new_buf ( " buf0 " , " in-memory ring buffer " , LOG_FORMAT_TIMED , 1048576 ) ;
2019-08-23 09:47:49 -04:00
}
static void sink_deinit ( )
{
struct sink * sink , * sb ;
2023-01-24 06:11:41 -05:00
2023-07-06 10:55:55 -04:00
list_for_each_entry_safe ( sink , sb , & sink_list , sink_list )
sink_free ( sink ) ;
2019-08-20 05:57:52 -04:00
}
INITCALL0 ( STG_REGISTER , sink_init ) ;
2019-08-23 09:47:49 -04:00
REGISTER_POST_DEINIT ( sink_deinit ) ;
2019-08-20 05:57:52 -04:00
2019-08-26 12:17:04 -04:00
static struct cli_kw_list cli_kws = { { } , {
2021-05-07 05:38:37 -04:00
{ { " show " , " events " , NULL } , " show events [<sink>] [-w] [-n] : show event sink state " , cli_parse_show_events , NULL , NULL } ,
2019-08-26 12:17:04 -04:00
{ { } , }
} } ;
INITCALL1 ( STG_REGISTER , cli_register_kw , & cli_kws ) ;
MEDIUM: ring: new section ring to declare custom ring buffers.
It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
ring <ringname>
Creates a new ring-buffer with name <ringname>.
description <text>
The descritpition is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
format <format>
Format used to store events into the ring buffer.
Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :
iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.
raw A message containing only the text. The level, PID, date, time,
process name and system name are omitted. This is designed to be
used in containers or during development, where the severity
only depends on the file descriptor used (stdout/stderr). This
is the default.
rfc3164 The RFC3164 syslog message format. This is the default.
(https://tools.ietf.org/html/rfc3164)
rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
short A message containing only a level between angle brackets such as
'<3>', followed by the text. The PID, date, time, process name
and system name are omitted. This is designed to be used with a
local log server. This format is compatible with what the systemd
logger consumes.
timed A message containing only a level between angle brackets such as
'<3>', followed by ISO date and by the text. The PID, process
name and system name are omitted. This is designed to be
used with a local log server.
maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
Example:
global
log ring@myring local7
ring myring
description "My local buffer"
format rfc3164
maxlen 1200
Note: ring names are resolved during post configuration processing.
2020-05-25 09:01:04 -04:00
/* config parsers for this section */
REGISTER_CONFIG_SECTION ( " ring " , cfg_parse_ring , cfg_post_parse_ring ) ;
MINOR: sink: create definitions a minimal code for event sinks
The principle will be to be able to dispatch events to various destinations
called "sinks". This is already done in part in logs where log servers can
be either a UDP socket or a file descriptor. This will be needed with the
new trace subsystem where we may also want to add ring buffers. And it turns
out that all such destinations make sense at all places. Logs may need to be
sent to a TCP server via a ring buffer, or consulted from the CLI. Trace
events may need to be sent to stdout/stderr as well as to remote log servers.
This patch creates a new structure "sink" aiming at addressing these similar
needs. The goal is to merge together what is common to all of them, such as
the output format, the dropped events count, etc, and also keep separately
the target identification (network address, file descriptor). Provisions
were made to have a "waiter" on the sink. For a TCP log server it will be
the task to wake up after writing to the log buffer. For a ring buffer, it
could be the list of watchers on the CLI running a "tail" operation and
waiting for new events. A lock was also placed in the struct since many
operations will require some locking, including the FD ones. The output
formats covers those in use by logs and two extra ones prepending the ISO
time in front of the message (convenient for stdio/buffer).
For now only the generic infrastructure is present, no type-specific
output is implemented. There's the sink_write() function which prepares
and formats a message to be sent, trying hard to avoid copies and only
using pointer manipulation, where the type-specific code just has to be
added. Dropped messages are already counted (for now 100% drop). The
message is put into an iovec array as it will be trivial to use with
file descriptors and sockets.
2019-08-11 10:38:56 -04:00
/*
* Local variables :
* c - indent - level : 8
* c - basic - offset : 8
* End :
*/