Hello,
the script xymonclient-linux.sh is using commands like ifconfig, netstat, etc. These commands are marked as depreciated and some of the Linux distributions have removed them already. For example SuSE Linux Enterprise Server 15 has no support for netstat and ifconfig. The replacement are commands from iproute2 package like ip, ss, routel, etc. Are there any plan to replace depreciated commands with new ones?
BR,
Zdenek Tlusty
On 9/18/2019 8:05 AM, Zden?k Tlust? wrote:
Hello,
the script xymonclient-linux.sh is using commands like ifconfig, netstat, etc. These commands are marked as depreciated and some of the Linux distributions have removed them already. For example SuSE Linux Enterprise Server 15 has no support for netstat and ifconfig. The replacement are commands from iproute2 package like ip, ss, routel, etc. Are there any plan to replace depreciated commands with new ones?
Especially with SS and IP, it's something that's on the road map. Unfortunately, doing that in a backwards-compatible way will still keeping the 'linux' OStype/class 'linux' might prove difficult without a lot more text processing. (This flag is split on the receiving side for parsing out what client evaluations to run and how, since the output of SunOS, Linux, BSDs, and other *nixes can vary widely.)
One could either move current OS's to something like "linux-old", or have upgraded scripts under "linux-new", or do a lot of 'awk' calls in xymonclient-linux.sh to try to duplicate previous output more precisely. I'm not sure which is better there.
Regards, -jc
Would it be difficult to have the server-side linux parser look for [ports] and if not found, then look for [ss]; and similarly, [ifconfig] has [ip-addr] as its fallback (assuming "ip addr show" gives similar output - probably doesn't, but you get the idea)?
Minorly tangential, I think sar is more universally available these days than when the client scripts were first created. So I'm wondering if we should make better use of sar, perhaps even have a [sar] section of the client message, that is the first place that xymond goes when looking for statistics.
On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <cleaver at terabithia.org> wrote:
On 9/18/2019 8:05 AM, Zden?k Tlust? wrote:
Hello,
the script xymonclient-linux.sh is using commands like ifconfig, netstat, etc. These commands are marked as depreciated and some of the Linux distributions have removed them already. For example SuSE Linux Enterprise Server 15 has no support for netstat and ifconfig. The replacement are commands from iproute2 package like ip, ss, routel, etc. Are there any plan to replace depreciated commands with new ones?
Especially with SS and IP, it's something that's on the road map. Unfortunately, doing that in a backwards-compatible way will still keeping the 'linux' OStype/class 'linux' might prove difficult without a lot more text processing. (This flag is split on the receiving side for parsing out what client evaluations to run and how, since the output of SunOS, Linux, BSDs, and other *nixes can vary widely.)
One could either move current OS's to something like "linux-old", or have upgraded scripts under "linux-new", or do a lot of 'awk' calls in xymonclient-linux.sh to try to duplicate previous output more precisely. I'm not sure which is better there.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
It might be a little tricky with the way the code path works right now, as we don't really scan back and forth when processing a client message. But as long as the locations within the text area are the same we can probably do a sequential case check around it.
I do agree on 'sar' being generally more available now -- although I've run into EL boxes where it mysteriously isn't present, so I suspect the race to prune minimal sizes for containers may have resulted in its exclusion in some groupings. One of the original use-cases for the compression (and binary safety that it entails) was being able to take raw sar output as a client section. There are a number of ways that could be parsed, although I'm not certain whether there were large output-stability changes in recent versions.
-jc
On Thu, September 19, 2019 7:53 pm, Jeremy Laidman wrote:
Would it be difficult to have the server-side linux parser look for [ports] and if not found, then look for [ss]; and similarly, [ifconfig] has [ip-addr] as its fallback (assuming "ip addr show" gives similar output - probably doesn't, but you get the idea)?
Minorly tangential, I think sar is more universally available these days than when the client scripts were first created. So I'm wondering if we should make better use of sar, perhaps even have a [sar] section of the client message, that is the first place that xymond goes when looking for statistics.
On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <cleaver at terabithia.org> wrote:
On 9/18/2019 8:05 AM, Zden??k Tlust?? wrote:
Hello,
the script xymonclient-linux.sh is using commands like ifconfig, netstat, etc. These commands are marked as depreciated and some of the Linux distributions have removed them already. For example SuSE Linux Enterprise Server 15 has no support for netstat and ifconfig. The replacement are commands from iproute2 package like ip, ss, routel, etc. Are there any plan to replace depreciated commands with new ones?
Especially with SS and IP, it's something that's on the road map. Unfortunately, doing that in a backwards-compatible way will still keeping the 'linux' OStype/class 'linux' might prove difficult without a lot more text processing. (This flag is split on the receiving side for parsing out what client evaluations to run and how, since the output of SunOS, Linux, BSDs, and other *nixes can vary widely.)
One could either move current OS's to something like "linux-old", or have upgraded scripts under "linux-new", or do a lot of 'awk' calls in xymonclient-linux.sh to try to duplicate previous output more precisely. I'm not sure which is better there.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I'm curious how you propose actually using sar data in a client message.? On my system /var/log/sa is 44M of text data.
vmstat (procps) is already used and feeds rrd on the server via the client message; which is a MUCH more compact, long term storage format (The rrds for the same system are only 13M).
The perennially discussed issues around parsing iproute2 output are kind of well cpovered so we'll let that be... And no, SUSE hasn't removed net-tools.? It's just not installed in a very minimal install.
On 9/19/19 7:53 PM, Jeremy Laidman wrote:
Would it be difficult to have the server-side linux parser look for [ports] and if not found, then look for [ss]; and similarly, [ifconfig] has [ip-addr] as its fallback (assuming "ip addr show" gives similar output - probably doesn't, but you get the idea)?
Minorly tangential, I think sar is more universally?available these days than when the client scripts were first created. So I'm wondering if we should make better use of sar, perhaps even have a [sar] section of the client message, that is the first place that xymond goes when looking for statistics.
On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <cleaver at terabithia.org <mailto:cleaver at terabithia.org>> wrote:
On 9/18/2019 8:05 AM, Zden?k Tlust? wrote: > Hello, > > the script xymonclient-linux.sh is using commands like ifconfig, > netstat, etc. These commands are marked as depreciated and some of the > Linux distributions have removed them already. For example SuSE Linux > Enterprise Server 15 has no support for netstat and ifconfig. > The replacement are commands from iproute2 package like ip, ss, > routel, etc. > Are there any plan to replace depreciated commands with new ones? Especially with SS and IP, it's something that's on the road map. Unfortunately, doing that in a backwards-compatible way will still keeping the 'linux' OStype/class 'linux' might prove difficult without a lot more text processing. (This flag is split on the receiving side for parsing out what client evaluations to run and how, since the output of SunOS, Linux, BSDs, and other *nixes can vary widely.) One could either move current OS's to something like "linux-old", or have upgraded scripts under "linux-new", or do a lot of 'awk' calls in xymonclient-linux.sh to try to duplicate previous output more precisely. I'm not sure which is better there. Regards, -jc _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Sat, 21 Sep 2019 at 10:30, Bruce Ferrell <bferrell at baywinds.org> wrote:
I'm curious how you propose actually using sar data in a client message. On my system /var/log/sa is 44M of text data.
Yeah, I could have been clearer in describing what I had in mind.
vmstat (procps) is already used and feeds rrd on the server via the client message; which is a MUCH more compact, long term storage format (The rrds for the same system are only 13M).
If "sar [some options]" can produce equivalent output to (say) "vmstat 300 2", then it's likely to take the same amount of storage and bytes transmitted. But it has the added benefit that the same sar output from Solaris and AIX and Linux can all be parsed by the same code on the Xymon server. So the one client-side command to create [vmstat] in the client message will be universal across a wide range of OSes. If we can replace [vmstat] in this way, we may be able to do the same for [netstat] and [iostat] and a few others (by using sar with other options). We might also introduce an equivalent to [iostatdisk] and other things that don't yet exist in some OSes' client messages.
Adding support for a new OS (eg an exotic Linux-based NAS) becomes much easier if a "sar" package can be installed, or binaries for "sa" and "sar".can be copied onto the device.
The perennially discussed issues around parsing iproute2 output are kind of well cpovered so we'll let that be... And no, SUSE hasn't removed net-tools. It's just not installed in a very minimal install.
On 9/19/19 7:53 PM, Jeremy Laidman wrote:
Would it be difficult to have the server-side linux parser look for [ports] and if not found, then look for [ss]; and similarly, [ifconfig] has [ip-addr] as its fallback (assuming "ip addr show" gives similar output - probably doesn't, but you get the idea)?
Minorly tangential, I think sar is more universally available these days than when the client scripts were first created. So I'm wondering if we should make better use of sar, perhaps even have a [sar] section of the client message, that is the first place that xymond goes when looking for statistics.
On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <cleaver at terabithia.org <mailto:cleaver at terabithia.org>> wrote:
On 9/18/2019 8:05 AM, Zden?k Tlust? wrote: > Hello, > > the script xymonclient-linux.sh is using commands like ifconfig, > netstat, etc. These commands are marked as depreciated and some ofthe > Linux distributions have removed them already. For example SuSE Linux > Enterprise Server 15 has no support for netstat and ifconfig. > The replacement are commands from iproute2 package like ip, ss, > routel, etc. > Are there any plan to replace depreciated commands with new ones?
Especially with SS and IP, it's something that's on the road map. Unfortunately, doing that in a backwards-compatible way will still keeping the 'linux' OStype/class 'linux' might prove difficultwithout a lot more text processing. (This flag is split on the receiving side for parsing out what client evaluations to run and how, since the output of SunOS, Linux, BSDs, and other *nixes can vary widely.)
One could either move current OS's to something like "linux-old", or have upgraded scripts under "linux-new", or do a lot of 'awk' callsin xymonclient-linux.sh to try to duplicate previous output more precisely. I'm not sure which is better there.
Regards, -jc _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 9/22/19 6:31 PM, Jeremy Laidman wrote:
On Sat, 21 Sep 2019 at 10:30, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
I'm curious how you propose actually using sar data in a client message.? On my system /var/log/sa is 44M of text data.Yeah, I could have been clearer in describing what I had in mind.
vmstat (procps) is already used and feeds rrd on the server via the client message; which is a MUCH more compact, long term storage format (The rrds for the same system are only 13M).If "sar [some options]" can produce equivalent output to (say) "vmstat 300 2", then it's likely to take the same amount of storage and bytes transmitted. But it has the added benefit that the same sar output from Solaris and AIX and Linux can all be parsed by the same code on the Xymon server. So the one client-side command to create [vmstat] in the client message will be universal across a wide range of OSes. If we can replace [vmstat] in this way, we may be able to do the same for? [netstat] and [iostat] and a few others (by using sar with other options). We might also introduce an equivalent to [iostatdisk] and other things that don't yet exist in some OSes' client messages.
Interesting idea... but sa doesn't work like that at all.
sar can collect individualized sets of stats, but the default the cron jobs that come in the sysstat package run sa to collect all system stats at "cron interval". Then it has to be sliced and diced after the fact.... It's semi non-trivial to extract "just the latest update changes for the stat set you want" to transmit the the server.? Not that it can't be done, but it's a pain.
SO "just drop sar on... " become "just drop sar and modify it's defaults".? If sar is already there and I'm the admin, I'm going to be a wee touch miffed if someone messes with my system wide, long term stats collection or creates a duplicate, parallel, space gobbling collection dataset at the client.
vm/io/whatever stat collects a sample and sends just that sample. All storage is at the xymon server? MUCH cleaner even if adding the rare/exotic new thing is harder when they come up.? BTW, sar on OS X is a way different beast too, so it violates the premise that the same code works.? but *stat works out of the box.
I've not checked other *BSD variants... Yet.
?Adding support for a new OS (eg an exotic Linux-based NAS) becomes much easier if a "sar" package can be installed, or binaries for "sa" and "sar".can be copied onto the device.
The perennially discussed issues around parsing iproute2 output are kind of well cpovered so we'll let that be... And no, SUSE hasn't removed net-tools.? It's just not installed in a very minimal install. On 9/19/19 7:53 PM, Jeremy Laidman wrote: > Would it be difficult to have the server-side linux parser look for [ports] and if not found, then look for [ss]; and similarly, [ifconfig] has [ip-addr] as its fallback > (assuming "ip addr show" gives similar output - probably doesn't, but you get the idea)? > > Minorly tangential, I think sar is more universally?available these days than when the client scripts were first created. So I'm wondering if we should make better use of sar, > perhaps even have a [sar] section of the client message, that is the first place that xymond goes when looking for statistics. > > On Fri, 20 Sep 2019 at 00:52, Japheth Cleaver <cleaver at terabithia.org <mailto:cleaver at terabithia.org> <mailto:cleaver at terabithia.org <mailto:cleaver at terabithia.org>>> wrote: > >? ? ?On 9/18/2019 8:05 AM, Zden?k Tlust? wrote: >? ? ?> Hello, >? ? ?> >? ? ?> the script xymonclient-linux.sh is using commands like ifconfig, >? ? ?> netstat, etc. These commands are marked as depreciated and some of the >? ? ?> Linux distributions have removed them already. For example SuSE Linux >? ? ?> Enterprise Server 15 has no support for netstat and ifconfig. >? ? ?> The replacement are commands from iproute2 package like ip, ss, >? ? ?> routel, etc. >? ? ?> Are there any plan to replace depreciated commands with new ones? > > >? ? ?Especially with SS and IP, it's something that's on the road map. >? ? ?Unfortunately, doing that in a backwards-compatible way will still >? ? ?keeping the 'linux' OStype/class 'linux' might prove difficult without a >? ? ?lot more text processing. (This flag is split on the receiving side for >? ? ?parsing out what client evaluations to run and how, since the output of >? ? ?SunOS, Linux, BSDs, and other *nixes can vary widely.) > >? ? ?One could either move current OS's to something like "linux-old", or >? ? ?have upgraded scripts under "linux-new", or do a lot of 'awk' calls in >? ? ?xymonclient-linux.sh to try to duplicate previous output more precisely. >? ? ?I'm not sure which is better there. > >? ? ?Regards, >? ? ?-jc > >? ? ?_______________________________________________ >? ? ?Xymon mailing list > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> > http://lists.xymon.com/mailman/listinfo/xymon > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com <mailto:Xymon at xymon.com> > http://lists.xymon.com/mailman/listinfo/xymon _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
On 9/23/2019 4:46 AM, Bruce Ferrell wrote:
On 9/22/19 6:31 PM, Jeremy Laidman wrote:
On Sat, 21 Sep 2019 at 10:30, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
??? I'm curious how you propose actually using sar data in a client message.? On my system /var/log/sa is 44M of text data.
Yeah, I could have been clearer in describing what I had in mind.
??? vmstat (procps) is already used and feeds rrd on the server via the client message; which is a MUCH more compact, long term storage format (The rrds for the same system are ??? only 13M).
If "sar [some options]" can produce equivalent output to (say) "vmstat 300 2", then it's likely to take the same amount of storage and bytes transmitted. But it has the added benefit that the same sar output from Solaris and AIX and Linux can all be parsed by the same code on the Xymon server. So the one client-side command to create [vmstat] in the client message will be universal across a wide range of OSes. If we can replace [vmstat] in this way, we may be able to do the same for [netstat] and [iostat] and a few others (by using sar with other options). We might also introduce an equivalent to [iostatdisk] and other things that don't yet exist in some OSes' client messages.
Interesting idea... but sa doesn't work like that at all.
sar can collect individualized sets of stats, but the default the cron jobs that come in the sysstat package run sa to collect all system stats at "cron interval". Then it has to be sliced and diced after the fact.... It's semi non-trivial to extract "just the latest update changes for the stat set you want" to transmit the the server.? Not that it can't be done, but it's a pain.
SO "just drop sar on... " become "just drop sar and modify it's defaults".? If sar is already there and I'm the admin, I'm going to be a wee touch miffed if someone messes with my system wide, long term stats collection or creates a duplicate, parallel, space gobbling collection dataset at the client.
That's basically how the version I had spec'd out operated. It would be a set of parallel sadc processes writing out to temp files, get turned into textual output by 'sar', and then payloaded up in the client message:
$SADC -F ${SADCOPTS} -L ${SADCFREQ} $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$; $SAR -A -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$ > $XYMONTMP/xymon_sar.$MACHINEDOTS.$$; mv $XYMONTMP/xymon_sar.$MACHINEDOTS.$$ $XYMONTMP/xymon_sar.$MACHINEDOTS; rm -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$
Another option would be to transmit just the sadc binary datafile, but it seemed likely that could vary in structure among differing releases, while sar-processing scripts and tools that can interpret the text feed are pretty numerous.
As a side benefit, having per-minute sar output for the 5 minutes prior to an event occurring in the client message could be useful for postmortems.
The downside, of course, is that the text output is indeed huge. Even if it's transmitted compressed, it's still greatly bumping up your resource utilization. That suggests that the benefits of having full text output in the client message might be outweighed by the space savings in just having clients send direct "sar" data messages back themselves.
vm/io/whatever stat collects a sample and sends just that sample. All storage is at the xymon server? MUCH cleaner even if adding the rare/exotic new thing is harder when they come up.? BTW, sar on OS X is a way different beast too, so it violates the premise that the same code works.? but *stat works out of the box.
Of course OS X has to be different :)
-jc
On 9/23/19 11:14 AM, Japheth Cleaver wrote:
On 9/23/2019 4:46 AM, Bruce Ferrell wrote:
CLIPPAGE HERE
That's basically how the version I had spec'd out operated. It would be a set of parallel sadc processes writing out to temp files, get turned into textual output by 'sar', and then payloaded up in the client message:
$SADC -F ${SADCOPTS} -L ${SADCFREQ} $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$; $SAR -A -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$ > $XYMONTMP/xymon_sar.$MACHINEDOTS.$$; mv $XYMONTMP/xymon_sar.$MACHINEDOTS.$$ $XYMONTMP/xymon_sar.$MACHINEDOTS; rm -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$
Another option would be to transmit just the sadc binary datafile, but it seemed likely that could vary in structure among differing releases, while sar-processing scripts and tools that can interpret the text feed are pretty numerous.
As a side benefit, having per-minute sar output for the 5 minutes prior to an event occurring in the client message could be useful for postmortems.
The downside, of course, is that the text output is indeed huge. Even if it's transmitted compressed, it's still greatly bumping up your resource utilization. That suggests that the benefits of having full text output in the client message might be outweighed by the space savings in just having clients send direct "sar" data messages back themselves.
vm/io/whatever stat collects a sample and sends just that sample. All storage is at the xymon server? MUCH cleaner even if adding the rare/exotic new thing is harder when they come up. BTW, sar on OS X is a way different beast too, so it violates the premise that the same code works.? but *stat works out of the box.
Of course OS X has to be different :)
-jc
Well, BSD in general, but considering BSD *IX is kind of where it all started, which one is the deviant? And shall we discuss SNMP! Oy vey!
participants (4)
-
bferrell＠baywinds.org
-
cleaver＠terabithia.org
-
jeremy＠laidman.org
-
tlusty＠vse.cz