Re: Peers, logs and debugging.
On Tue, Nov 05, 2019 at 11:30:01AM +0100, Frederic Lecaille wrote: > I have missed the case where the listener of the "peers" section is declared > after "log" lines. In such case ->peers_fe is NULL when entering the "log" > line parser. > > So, this last patch is better. Thanks Fred, now merged :-) Willy
Re: Peers, logs and debugging.
> On 5 Nov 2019, at 11:30, Frederic Lecaille wrote: > > On 11/5/19 11:06 AM, Frederic Lecaille wrote: >> On 11/4/19 1:52 PM, Willy Tarreau wrote: >>> Hi Yves, >>> >>> On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote: Hi, Trying to debug why some replications are stuck between peers, I was wondering if it was possible to have low-level logging of connections or at least TCP states in the peers section to figure out what is happening. There are some information using 'show peers', but it will lack some information (like if there was multiple reconnect attempts in a row). >>> >>> Now that our peers sections are full-featured proxies, I think it should >>> not be hard to implement the "log" directive there at least to enable >>> logging of incoming connections. It's probably as simple as just setting >>> the log_wait field to non-zero. And I agree that peers remain one of the >>> least verbose area of the code, yet are responsible for some long head >>> scratching :-/ >>> >>> Willy >>> >> Hi, >> Here is a patch to support "log" directive in "peers" section. >> I hope this will help. >> Fred. > > I have missed the case where the listener of the "peers" section is declared > after "log" lines. In such case ->peers_fe is NULL when entering the "log" > line parser. > > So, this last patch is better. > > Fred. > <0001-MINOR-peers-Add-log-directive-to-peers-section.patch> Thanks, I’ll try this. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Re: Peers, logs and debugging.
On 11/5/19 11:06 AM, Frederic Lecaille wrote:
On 11/4/19 1:52 PM, Willy Tarreau wrote:
Hi Yves,
On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote:
Hi,
Trying to debug why some replications are stuck between peers, I was
wondering if it was possible to have low-level logging of connections
or at
least TCP states in the peers section to figure out what is happening.
There are some information using 'show peers', but it will lack some
information (like if there was multiple reconnect attempts in a row).
Now that our peers sections are full-featured proxies, I think it should
not be hard to implement the "log" directive there at least to enable
logging of incoming connections. It's probably as simple as just setting
the log_wait field to non-zero. And I agree that peers remain one of the
least verbose area of the code, yet are responsible for some long head
scratching :-/
Willy
Hi,
Here is a patch to support "log" directive in "peers" section.
I hope this will help.
Fred.
I have missed the case where the listener of the "peers" section is
declared after "log" lines. In such case ->peers_fe is NULL when
entering the "log" line parser.
So, this last patch is better.
Fred.
>From 408094ce430f762c7c8a56c0e11d011e9a372705 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 5 Nov 2019 09:57:45 +0100
Subject: [PATCH] MINOR: peers: Add "log" directive to "peers" section.
This patch is easy to review: let's call parse_logsrv() function to parse
"log" directive as this is already for other sections for proxies.
This enable us to log incoming TCP connections for the listeners for "peers"
sections.
Update the documentation for "peers" section.
---
doc/configuration.txt | 6 ++
src/cfgparse.c| 11 +++
2 files changed, 17 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d8fe6b650..233255c07 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2138,6 +2138,12 @@ default-server [param*]
enable
This re-enables a disabled peers section which was previously disabled.
+log [len ] [format ] [sample :]
+ [ []]
+ "peers" sections support the same "log" keyword as for the proxies to
+ log information about the "peers" listener. See "log" option for proxies for
+ more details.
+
peer : [param*]
Defines a peer inside a peers section.
If is set to the local peer name (by default hostname, or forced
diff --git a/src/cfgparse.c b/src/cfgparse.c
index eaad6c2cd..2e200e885 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -714,6 +714,17 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
}
err_code |= parse_server(file, linenum, args, curpeers->peers_fe, NULL, 0);
}
+ else if (strcmp(args[0], "log") == 0) {
+ if (init_peers_frontend(file, linenum, NULL, curpeers) != 0) {
+ err_code |= ERR_ALERT | ERR_ABORT;
+ goto out;
+ }
+ if (!parse_logsrv(args, >peers_fe->logsrvs, (kwm == KWM_NO), )) {
+ ha_alert("parsing [%s:%d] : %s : %s\n", file, linenum, args[0], errmsg);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+ }
else if (strcmp(args[0], "peers") == 0) { /* new peers section */
/* Initialize these static variables when entering a new "peers" section*/
bind_line = peer_line = 0;
--
2.20.1
Re: Peers, logs and debugging.
On 11/4/19 1:52 PM, Willy Tarreau wrote:
Hi Yves,
On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote:
Hi,
Trying to debug why some replications are stuck between peers, I was
wondering if it was possible to have low-level logging of connections or at
least TCP states in the peers section to figure out what is happening.
There are some information using 'show peers', but it will lack some
information (like if there was multiple reconnect attempts in a row).
Now that our peers sections are full-featured proxies, I think it should
not be hard to implement the "log" directive there at least to enable
logging of incoming connections. It's probably as simple as just setting
the log_wait field to non-zero. And I agree that peers remain one of the
least verbose area of the code, yet are responsible for some long head
scratching :-/
Willy
Hi,
Here is a patch to support "log" directive in "peers" section.
I hope this will help.
Fred.
>From b0c0c7c4981e83f5a748233ddbaba4d0025a4f71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 5 Nov 2019 09:57:45 +0100
Subject: [PATCH] MINOR: peers: Add "log" directive to "peers" section.
This patch is easy to review: let's call parse_logsrv() function to parse
"log" directive as this is already for other sections for proxies.
This enable us to log incoming TCP connections for the listeners for "peers"
sections.
Update the documentation for "peers" section.
---
doc/configuration.txt | 6 ++
src/cfgparse.c| 7 +++
2 files changed, 13 insertions(+)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d8fe6b650..233255c07 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2138,6 +2138,12 @@ default-server [param*]
enable
This re-enables a disabled peers section which was previously disabled.
+log [len ] [format ] [sample :]
+ [ []]
+ "peers" sections support the same "log" keyword as for the proxies to
+ log information about the "peers" listener. See "log" option for proxies for
+ more details.
+
peer : [param*]
Defines a peer inside a peers section.
If is set to the local peer name (by default hostname, or forced
diff --git a/src/cfgparse.c b/src/cfgparse.c
index eaad6c2cd..5e6bf2c7e 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -714,6 +714,13 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
}
err_code |= parse_server(file, linenum, args, curpeers->peers_fe, NULL, 0);
}
+ else if (strcmp(args[0], "log") == 0) {
+ if (!parse_logsrv(args, >peers_fe->logsrvs, (kwm == KWM_NO), )) {
+ ha_alert("parsing [%s:%d] : %s : %s\n", file, linenum, args[0], errmsg);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+ }
else if (strcmp(args[0], "peers") == 0) { /* new peers section */
/* Initialize these static variables when entering a new "peers" section*/
bind_line = peer_line = 0;
--
2.20.1
Re: Peers, logs and debugging.
> On 4 Nov 2019, at 13:23, Aleksandar Lazic wrote: > > Hi. > > Am 04.11.2019 um 10:47 schrieb Yves Lafon: >> Hi, >> Trying to debug why some replications are stuck between peers, I was >> wondering if it was possible to have low-level logging of connections or at >> least TCP states in the peers section to figure out what is happening. >> There are some information using ’show peers’, but it will lack some >> information (like if there was multiple reconnect attempts in a row). >> Thanks, > > Please can you tell us haproxy -vv, the config and the output of show peers. It was a mix of 2.0.8 and 1.8.22, now only 2.0.8, I’ll wait for the issue to arise again and will send the relevant information, but as I said, having better logging/debugging option to give meaningful traces would be better (as done recently for an h2-related issue with an experimental client) -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Re: Peers, logs and debugging.
Hi Yves, On Mon, Nov 04, 2019 at 10:47:23AM +0100, Yves Lafon wrote: > Hi, > Trying to debug why some replications are stuck between peers, I was > wondering if it was possible to have low-level logging of connections or at > least TCP states in the peers section to figure out what is happening. > There are some information using 'show peers', but it will lack some > information (like if there was multiple reconnect attempts in a row). Now that our peers sections are full-featured proxies, I think it should not be hard to implement the "log" directive there at least to enable logging of incoming connections. It's probably as simple as just setting the log_wait field to non-zero. And I agree that peers remain one of the least verbose area of the code, yet are responsible for some long head scratching :-/ Willy
Re: Peers, logs and debugging.
Hi. Am 04.11.2019 um 10:47 schrieb Yves Lafon: Hi, Trying to debug why some replications are stuck between peers, I was wondering if it was possible to have low-level logging of connections or at least TCP states in the peers section to figure out what is happening. There are some information using ’show peers’, but it will lack some information (like if there was multiple reconnect attempts in a row). Thanks, Please can you tell us haproxy -vv, the config and the output of show peers. Regards Aleks
Peers, logs and debugging.
Hi, Trying to debug why some replications are stuck between peers, I was wondering if it was possible to have low-level logging of connections or at least TCP states in the peers section to figure out what is happening. There are some information using ’show peers’, but it will lack some information (like if there was multiple reconnect attempts in a row). Thanks, -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
