Trends graph limit
list Mario Andre
Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Tom Schmidt
Mario,
I don't see any such limit, as my xymon server has 27 graphs under its
trends.
Tom Schmidt
▸
On Thu, May 30, 2024 at 5:05?PM Mario <user-82c7780661a4@xymon.invalid> wrote:
Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Mario Andre
Hello Tom, I think I have the same issue described by Jeremy here https://lists.xymon.com/archive/2023-August/048118.html and replied by JC here https://lists.xymon.com/archive/2023-September/048122.html In my old Xymon server version I have no issues with trends column. Thanks & regards, Mario
▸
On Thu, May 30, 2024 at 9:25?PM Tom Schmidt <user-d34f6118b459@xymon.invalid> wrote:
Mario, I don't see any such limit, as my xymon server has 27 graphs under its trends. Tom Schmidt On Thu, May 30, 2024 at 5:05?PM Mario <user-82c7780661a4@xymon.invalid> wrote:Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Jeremy Laidman
Weird flex, I know, but we have trends pages exceeding 100 graphs. One pair of hosts has 144 graphs each. The code has no constraint on the number of graphs. The limitations are likely to be memory on the server and the client. The fix we applied here (described in my post last August) has been entirely successful in preventing the core dump. At the time, JC asked for a core dump to confirm the fault/fix, but I haven't been able to provide this due to my workload and other things going on around me at the time. It's non-trivial for me to arrange for another core dump at this time. J
▸
On Sat, 1 Jun 2024 at 06:27, Mario <user-82c7780661a4@xymon.invalid> wrote:
Hello Tom, I think I have the same issue described by Jeremy here https://lists.xymon.com/archive/2023-August/048118.html and replied by JC here https://lists.xymon.com/archive/2023-September/048122.html In my old Xymon server version I have no issues with trends column. Thanks & regards, Mario On Thu, May 30, 2024 at 9:25?PM Tom Schmidt <user-d34f6118b459@xymon.invalid> wrote:Mario, I don't see any such limit, as my xymon server has 27 graphs under its trends. Tom Schmidt On Thu, May 30, 2024 at 5:05?PM Mario <user-82c7780661a4@xymon.invalid> wrote:Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Mario Andre
Hello Jeremy,
The fix you have applied was just change line 213 in
xymon-4.3.30/web/svcstatus-trends.c
from
SBUF_REALLOC(rrdlink, rrdlink_buflen +
strlen(partlink) + 4096);
to
SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096);
and recompile?
Thanks & regards,
Mario
▸
On Fri, May 31, 2024 at 7:28?PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:
Weird flex, I know, but we have trends pages exceeding 100 graphs. One pair of hosts has 144 graphs each. The code has no constraint on the number of graphs. The limitations are likely to be memory on the server and the client. The fix we applied here (described in my post last August) has been entirely successful in preventing the core dump. At the time, JC asked for a core dump to confirm the fault/fix, but I haven't been able to provide this due to my workload and other things going on around me at the time. It's non-trivial for me to arrange for another core dump at this time. J On Sat, 1 Jun 2024 at 06:27, Mario <user-82c7780661a4@xymon.invalid> wrote:Hello Tom, I think I have the same issue described by Jeremy here https://lists.xymon.com/archive/2023-August/048118.html and replied by JC here https://lists.xymon.com/archive/2023-September/048122.html In my old Xymon server version I have no issues with trends column. Thanks & regards, Mario On Thu, May 30, 2024 at 9:25?PM Tom Schmidt <user-d34f6118b459@xymon.invalid> wrote:Mario, I don't see any such limit, as my xymon server has 27 graphs under its trends. Tom Schmidt On Thu, May 30, 2024 at 5:05?PM Mario <user-82c7780661a4@xymon.invalid> wrote:Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Jeremy Laidman
Mario No that's not correct. All I did was add "+strlen(onelink)" to the existing line that calls SBUF_REALLOC(). So it went from this: SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+4096); to this: SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096); Then recompile. Rather than doing a "make install", I would have copied just the svcstatus.sh file produced by the compile, in place of the existing file (after making a backup), and set the ownership and permissions to match. Actually, I probably would have tested it first, by copying the new file into place with a different filename, and adjusting the url for a Trends page in my browser to use the new filename. Then when the trends page showed correctly, replaced the original file. Cheers Jeremy
▸
On Mon, 3 June 2024, 02:30 Mario, <user-82c7780661a4@xymon.invalid> wrote:
Hello Jeremy, The fix you have applied was just change line 213 in xymon-4.3.30/web/svcstatus-trends.c from SBUF_REALLOC(rrdlink, rrdlink_buflen + strlen(partlink) + 4096); to SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096); and recompile? Thanks & regards, Mario On Fri, May 31, 2024 at 7:28?PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:Weird flex, I know, but we have trends pages exceeding 100 graphs. One pair of hosts has 144 graphs each. The code has no constraint on the number of graphs. The limitations are likely to be memory on the server and the client. The fix we applied here (described in my post last August) has been entirely successful in preventing the core dump. At the time, JC asked for a core dump to confirm the fault/fix, but I haven't been able to provide this due to my workload and other things going on around me at the time. It's non-trivial for me to arrange for another core dump at this time. J On Sat, 1 Jun 2024 at 06:27, Mario <user-82c7780661a4@xymon.invalid> wrote:Hello Tom, I think I have the same issue described by Jeremy here https://lists.xymon.com/archive/2023-August/048118.html and replied by JC here https://lists.xymon.com/archive/2023-September/048122.html In my old Xymon server version I have no issues with trends column. Thanks & regards, Mario On Thu, May 30, 2024 at 9:25?PM Tom Schmidt <user-d34f6118b459@xymon.invalid> wrote:Mario, I don't see any such limit, as my xymon server has 27 graphs under its trends. Tom Schmidt On Thu, May 30, 2024 at 5:05?PM Mario <user-82c7780661a4@xymon.invalid> wrote:Hello All, Do trends column have a limitation in number of graphs to load? I can see that is stopping after loading 21 graphs. Is it configurable? My Xymon version is 4.3.30 Thanks in advance. Br, Mario
list Jeremy Laidman
Sorry, my memory can't be trusted.
▸
On Mon, 3 Jun 2024 at 08:51, Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:
Rather than doing a "make install", I would have copied just the svcstatus.sh file produced by the compile, in place of the existing file (after making a backup), and set the ownership and permissions to match.
The binary that is produced by compiling is called "svcstatus.cgi", not "svcstatus.sh". J
list Mario Andre
Hello Jeremy, Thank you very much for the patch! Best regards, Mario
▸
On Sun, Jun 2, 2024 at 8:40?PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:
Sorry, my memory can't be trusted. On Mon, 3 Jun 2024 at 08:51, Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:Rather than doing a "make install", I would have copied just the svcstatus.sh file produced by the compile, in place of the existing file (after making a backup), and set the ownership and permissions to match.The binary that is produced by compiling is called "svcstatus.cgi", not "svcstatus.sh". J
list Jeremy Laidman
No problem, happy I could help.
As a bonus, for those who have so many trends graphs that it was triggering
this issue, you may benefit from this hack. I use a wrapper script around
my svcstatus.cgi binary, which adds searchable text onto the trends page,
naming each graph suitably. This makes it much easier to jump to a
particular graph, rather than having to scroll and scroll, and read all of
the graph titles until I find the one I'm looking for. Instead, I just
press "ctrl-F" in my browser, and type (eg) "dnscache" to jump to those
graphs.
[image: image.png]
The script is quite simple, and is mostly the original wrapper script from
a previous version of Xymon that didn't use cgiwrap:
#!/bin/sh
# This is a wrapper for the Xymon svcstatus.cgi script
. /usr/lib/xymon/server/etc/cgioptions.cfg
exec /usr/lib/xymon/server/bin/svcstatus.cgi $CGI_SVC_OPTS |
sed '/begindata/,/Status report info/{s/<table summary="\([^"]*\)
Graph">/<table summary="\1">\1/;}'
I've removed (renamed, actually) the svcstatus.sh hard link in the cgi-bin
directory, that was linking to the cgiwrap binary, and replaced it with
this script. It mostly does what the cgiwrap binary does, in setting up the
environment, and calling svcstatus.cgi, but it also uses sed on the HTML
output to insert the graph tags. I probably should replace svcstatus.cgi
instead of svcstatus.sh with an equivalent, but this is working how I have
it, so I'm not changing anything.
J
▸
On Mon, 3 Jun 2024 at 22:27, Mario <user-82c7780661a4@xymon.invalid> wrote:
Hello Jeremy, Thank you very much for the patch! Best regards, Mario On Sun, Jun 2, 2024 at 8:40?PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:Sorry, my memory can't be trusted. On Mon, 3 Jun 2024 at 08:51, Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:Rather than doing a "make install", I would have copied just the svcstatus.sh file produced by the compile, in place of the existing file (after making a backup), and set the ownership and permissions to match.The binary that is produced by compiling is called "svcstatus.cgi", not "svcstatus.sh". J
Attachments (1)
attachment.png