August 2006 - Xymon - Xymon mailman web

Patch not done yet? was RE: rrd-data.log
by brodie＠mcw.edu 03 Aug '06

03 Aug '06

Hi Henrik: Below are snippets from rrd that are still causing the "Duplicate Error" on my end, even after applying the patch. In the cases where there's netstat and ifstat data shown together, I had to include both because those chunks of data came out right at the time the duplicate error appeared. Too hard to time/see which of those 2 chunks of data cause the problem. In other cases, only ifstat data caused the problem. Where I have large chunks of whitespace- that separates "instances" of the duplicate error occurring. =========== @@data#348|1154533834.591188|192.168.224.202||wolf13.hmgc.mcw.edu|netsta t data wolf13,hmgc,mcw,edu.netstat linux Ip: 56731 total packets received 0 forwarded 0 incoming packets discarded 56067 incoming packets delivered 65344 requests sent out Icmp: 648 ICMP messages received 0 input ICMP message failed. ICMP input histogram: destination unreachable: 89 echo requests: 559 648 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 89 echo replies: 559 Tcp: 4630 active connections openings 1 passive connection openings 1 failed connection attempts 0 connection resets received 0 connections established 46150 segments received 54675 segments send out 85 segments retransmited 0 bad segments received. 1 resets sent Udp: 9933 packets received 0 packets to unknown port received. 0 packet receive errors 10021 packets sent TcpExt: ArpFilter: 0 4616 TCP sockets finished time wait in fast timer 908 delayed acks sent 557 packets directly queued to recvmsg prequeue. 507580 packets directly received from backlog 554 packets directly received from prequeue 19157 packets header predicted 426 packets header predicted and directly queued to user TCPPureAcks: 7526 TCPHPAcks: 9608 TCPRenoRecovery: 0 TCPSackRecovery: 0 TCPSACKReneging: 0 TCPFACKReorder: 0 TCPSACKReorder: 0 TCPRenoReorder: 0 TCPTSReorder: 0 TCPFullUndo: 0 TCPPartialUndo: 0 TCPDSACKUndo: 0 TCPLossUndo: 35 TCPLoss: 0 TCPLostRetransmit: 0 TCPRenoFailures: 0 TCPSackFailures: 0 TCPLossFailures: 0 TCPFastRetrans: 0 TCPForwardRetrans: 0 TCPSlowStartRetrans: 0 TCPTimeouts: 85 TCPRenoRecoveryFail: 0 TCPSackRecoveryFail: 0 TCPSchedulerFailed: 0 TCPRcvCollapsed: 0 TCPDSACKOldSent: 0 TCPDSACKOfoSent: 0 TCPDSACKRecv: 0 TCPDSACKOfoRecv: 0 TCPAbortOnSyn: 0 TCPAbortOnData: 0 TCPAbortOnClose: 0 TCPAbortOnMemory: 0 TCPAbortOnTimeout: 0 TCPAbortOnLinger: 0 TCPAbortFailed: 0 TCPMemoryPressures: 0 @@ @@data#349|1154533834.591337|192.168.224.202||wolf13.hmgc.mcw.edu|ifstat data wolf13,hmgc,mcw,edu.ifstat linux eth1 Link encap:Ethernet HWaddr 00:30:6E:F3:0B:46 inet addr:192.168.96.113 Bcast:192.168.96.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:72022 errors:0 dropped:0 overruns:0 frame:0 TX packets:71139 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21476056 (20.4 Mb) TX bytes:17076949 (16.2 Mb) Interrupt:56 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:189 errors:0 dropped:0 overruns:0 frame:0 TX packets:189 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16228 (15.8 Kb) TX bytes:16228 (15.8 Kb) @@ @@data#507|1154533965.074399|192.168.224.202||bc1s2.phys.mcw.edu|ifstat data bc1s2,phys,mcw,edu.ifstat linux eth1 Link encap:Ethernet HWaddr 00:0D:60:1E:0E:DD inet addr:192.168.224.111 Bcast:192.168.224.255 Mask:255.255.255.0 inet6 addr: fe80::20d:60ff:fe1e:edd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:43166350 errors:0 dropped:0 overruns:0 frame:0 TX packets:6166704 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:14398847028 (13731.8 Mb) TX bytes:2587305933 (2467.4 Mb) Interrupt:45 Memory:c0010000-c0020000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:104 errors:0 dropped:0 overruns:0 frame:0 TX packets:104 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9752 (9.5 Kb) TX bytes:9752 (9.5 Kb) @@ @@data#740|1154534133.480180|192.168.224.202||dunn.hmgc.mcw.edu|netstat data dunn,hmgc,mcw,edu.netstat linux Ip: 9154191 total packets received 0 forwarded 0 incoming packets discarded 8170997 incoming packets delivered 15226980 requests sent out Icmp: 8961 ICMP messages received 9 input ICMP message failed. ICMP input histogram: destination unreachable: 16 echo requests: 8945 13860 ICMP messages sent 0 ICMP messages failed ICMP output histogram: destination unreachable: 4915 echo replies: 8945 Tcp: 33598 active connections openings 15245 passive connection openings 4 failed connection attempts 106 connection resets received 10 connections established 7841472 segments received 15058779 segments send out 412 segments retransmited 0 bad segments received. 2935 resets sent Udp: 315663 packets received 4901 packets to unknown port received. 0 packet receive errors 154341 packets sent TcpExt: 7 resets received for embryonic SYN_RECV sockets ArpFilter: 0 37618 TCP sockets finished time wait in fast timer 2 packets rejects in established connections because of timestamp 12809 delayed acks sent 2 delayed acks further delayed because of locked socket Quick ack mode was activated 1930 times 144921 packets directly queued to recvmsg prequeue. 7524 packets directly received from backlog 40929271 packets directly received from prequeue 47328 packets header predicted 135097 packets header predicted and directly queued to user TCPPureAcks: 5602771 TCPHPAcks: 2027416 TCPRenoRecovery: 47 TCPSackRecovery: 19 TCPSACKReneging: 0 TCPFACKReorder: 0 TCPSACKReorder: 0 TCPRenoReorder: 0 TCPTSReorder: 0 TCPFullUndo: 0 TCPPartialUndo: 0 TCPDSACKUndo: 0 TCPLossUndo: 39 TCPLoss: 55 TCPLostRetransmit: 0 TCPRenoFailures: 2 TCPSackFailures: 1 TCPLossFailures: 1 TCPFastRetrans: 166 TCPForwardRetrans: 8 TCPSlowStartRetrans: 35 TCPTimeouts: 151 TCPRenoRecoveryFail: 9 TCPSackRecoveryFail: 1 TCPSchedulerFailed: 0 TCPRcvCollapsed: 0 TCPDSACKOldSent: 1 TCPDSACKOfoSent: 0 TCPDSACKRecv: 0 TCPDSACKOfoRecv: 0 TCPAbortOnSyn: 0 TCPAbortOnData: 948 TCPAbortOnClose: 14 TCPAbortOnMemory: 0 TCPAbortOnTimeout: 4 TCPAbortOnLinger: 0 TCPAbortFailed: 0 TCPMemoryPressures: 0 @@ @@data#741|1154534133.480925|192.168.224.202||dunn.hmgc.mcw.edu|ifstat data dunn,hmgc,mcw,edu.ifstat linux eth0 Link encap:Ethernet HWaddr 00:09:3D:13:DC:AB inet addr:192.168.224.105 Bcast:192.168.224.255 Mask:255.255.255.0 inet6 addr: fe80::209:3dff:fe13:dcab/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39290006 errors:0 dropped:0 overruns:0 frame:0 TX packets:15275236 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2864046246 (2.6 GiB) TX bytes:21735816115 (20.2 GiB) Interrupt:185 eth0:0 Link encap:Ethernet HWaddr 00:09:3D:13:DC:AB inet addr:192.168.224.107 Bcast:192.168.224.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:185 eth0:1 Link encap:Ethernet HWaddr 00:09:3D:13:DC:AB inet addr:192.168.224.160 Bcast:192.168.224.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:185 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:36728 errors:0 dropped:0 overruns:0 frame:0 TX packets:36728 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5951488 (5.6 MiB) TX bytes:5951488 (5.6 MiB) @@

5 6

[hobbit] Availability report
by henrik＠hswn.dk 03 Aug '06

03 Aug '06

On Mon, Jul 31, 2006 at 09:50:37AM -0500, Rich Smrcina wrote: > What is the difference between the types of availability reports > (critical, non-green, all)? When I run each report, they appear to > generate the same data. The difference shows up in the detailed view of the status in the report (the "Event log" display). "Critical" includes only red alerts. "non-green" includes all status changes to some color other than red. "all" includes also the status changes to green. See e.g the difference between this "critical" report: http://www.hswn.dk/hobbit-cgi/bb-replog.sh?HOST=www.sslug.dk&SERVICE=disk&C… this "non-green" report: http://www.hswn.dk/hobbit-cgi/bb-replog.sh?HOST=www.sslug.dk&SERVICE=disk&C… and this "all" report: http://www.hswn.dk/hobbit-cgi/bb-replog.sh?HOST=www.sslug.dk&SERVICE=disk&C… Regards, Henrik

3 2

[hobbit] Hobbit newbie from BB: differences and what may Ilose from migrating?
by brodie＠mcw.edu 03 Aug '06

03 Aug '06

Basically, you lose NOTHING when you change a BB server to a Hobbit server. At first, it'll look very similar. Life will be good. The BB clients can run untouched. However- once you start setting up a few *Hobbit* clients, you'll quickly see what Hobbit DOES-- and what a typical BB client does NOT do. That's the moment when you'll race to wipe BB completely. Took me about a week. :-) -----Original Message----- From: Jordan Mendler [mailto:jmendler at ucla.edu] Sent: Tuesday, August 01, 2006 8:43 PM To: hobbit at hswn.dk Subject: RE: [hobbit] Hobbit newbie from BB: differences and what may Ilose from migrating? Cool. I guess I'll add a second display to bb-hosts and give hobbit a run. I'll just use Shmux to deploy bb-hosts to all the clients (figured I'd mention that great application while I'm at it :-) Once again, thanks for all the help everyone, hopefully my next message here will be as a convert. Jordan

7 13

[hobbit] client info
by massimo.morsiani＠gilbarco.com 03 Aug '06

03 Aug '06

Hi Etienne, do you plan to introduce that centralized mode in BBWin just like hobbit client? Do you plan to add a GUI interface to BBWin just like BigBrother official client? Thank you. Regards. Massimo Morsiani Information Technology Dep. ------ Gilbarco S.p.a. via de' Cattani, 220/G 50145 Firenze tel: +39-055-30941 fax: +39-055-318603 email: massimo.morsiani at gilbarco.com web: http://www.gilbarco.it PS. Your BBWin was the kick-off to switch from BigBrother to HobbitMon. Thanks again! -----Original Message----- From: Etienne Grignon [mailto:etienne.grignon at gmail.com] Sent: mercoledì 2 agosto 2006 14.35 To: hobbit at hswn.dk Subject: Re: [hobbit] client info Hello Kolbjørn , 2006/8/2, Kolbjørn Barmen <kolbjorn.barmen at uninett.no>: > Is it possible to add more information to the "info" page? > > One thing I miss on that page is "Client version:" (especially now as > I upgrade BBWin client). > This is not possible for the moment. BBWin does not include the centralized mode for the moment so the hobbit server doesn't know anything about the client version used on the Windows hosts. Regards, -- Etienne GRIGNON To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

2 1

[hobbit] setting up multiple servers
by ralphmitchell＠gmail.com 03 Aug '06

03 Aug '06

On 7/21/06, Henrik Stoerner <henrik at hswn.dk> wrote: > On Fri, Jul 21, 2006 at 10:40:06AM +0200, Stephane Caminade wrote: > > > > And on the replicated servers, I guess that I have to modify both > > server/etc/hobbitserver.cfg and client/etc/hobbitclient.cfg with those > > same settings ? > > Correct. Especially, make sure your clients are configured to send data > to both servers. So, it's up to the clients to send to multiple servers, and the servers wouldn't forward anything except whatever reports they generate about themselves?? I *may* have a problem with that in 4.2-RC-20060712. I have some Big Brother scripts that are running in a Big Brother environment, reporting to two Hobbit servers - 4.1.2p1 & 4.2-RC. Almost all of the results get through to the RC server, but some don't. I'm still trying to refine it to a simple test case, but at the moment it looks like a report with "status+LIFETIME" isn't displayed on the RC server. If I remove the +LIFETIME value, the report *is* displayed. I figure I must have something wrong, because there have to be other people using that feature... :) Ralph Mitchell

1 0

[hobbit] Host Notes
by henrik＠hswn.dk 03 Aug '06

03 Aug '06

On Mon, Jul 31, 2006 at 02:51:01PM -0700, Charles Jones wrote: > Forgive me, as I am not thinking clearly today (it is Monday afterall). > You give a patch for bb-webpage.c, but I am unclear as to whether I am > supposed to replace the orig bb-webpage with this new one. Yes. When you patch bb-webpage with the patch I attached, you'll get a new bb-webpage - just copy that one over to your ~hobbit/server/bin/ directory. The current version is buggy. > and craft a "hostnotes.sh" to go in the cgi directory that calls it? Exactly. I've attached the one I used for testing. Regards, Henrik

2 2

[hobbit] Disk monitoring via free blocks
by henrik＠hswn.dk 03 Aug '06

03 Aug '06

On Fri, Jul 28, 2006 at 07:39:16AM -0400, James B Horwath wrote: > I have very large file systems I need to monitor, and the standard > hobbit/bb client monitors won't allow monitoring by bytes left, which is > what I need. The deadcat site has been down for the past 2 days, and I > didn't see anything but wish requests for byte free monitoring. I need > this for AIX, does anyone have the bb disk client for bytes free they can > send me, or give any quick pointers on how to do this natively in hobbit. > My hobbit server is 4.1.2p1. At this point it appears I will have to roll > my own byte free monitor. I would appreciate any tips or code anyone > could supply. I guess it doesn't help you right now, but the 4.2 release of Hobbit supports absolute-values monitoring of disks. Regards, Henrik

1 0

[hobbit] core in hobbitd_alert, clientupdate
by henrik＠hswn.dk 03 Aug '06

03 Aug '06

On Mon, Jul 24, 2006 at 01:29:36PM +0000, David Gore wrote: > Backtrace on the core, this is the latest snapshot. I do not have the > patience to fully test clientupdate, so I will assume it is broken > otherwise and that it may be fixed in the final version. Regardless > this is for hobbitd_alert: > > [hobbit at hobbit server]$ gdb bin/hobbitd_alert tmp/core.29742 > #6 0x00553282 in fprintf () from /lib/libc.so.6 > #7 0x08049dd7 in save_checkpoint (filename=0x9878098 > "/home/hobbit/server/tmp/alert.chk") > at hobbitd_alert.c:242 This should be fixed in the current snapshot. Regards, Henrik

1 0

[hobbit] hobbitd_rrdtool core
by henrik＠hswn.dk 03 Aug '06

03 Aug '06

On Fri, Jul 21, 2006 at 04:29:58PM -0500, Erich Zigler wrote: > Greetings, > I have migrated from bigbrother to hobbit-4.2-beta-20060605. I have > followed the documentation and hobbitd_rrdtool is the only thing that is > not working properly. It keeps generating core files. The output is > attached to this message. Any help would be greatly appreciated. This patch will solve this issue; against the current 4.2 RC. Regards, Henrik

1 0

[hobbit] Oratns
by Vernon.Everett＠dpi.wa.gov.au 03 Aug '06

03 Aug '06

Hi Henrik Yes, it is my experience that you only have one listener per server, and it can handle multiple databases. However, here, and in my previous company, they have 2 separate listener instances when running Oracle Financials. The database has a listener, and the applications also have a listener. Two separate instances on two separate ports. In the case of the one server, they have no less than 6 listener instances running, on 6 different ports. Configuring separate listener tests as below may be the only way to go at this point. Sadly, this may all be a waste of time. I am growing weary of fighting all the politics to get Hobbit in as a monitoring system, and am on the verge of giving up the fight. Regards Vernon -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Wednesday, 2 August 2006 3:26 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Oratns On Wed, Aug 02, 2006 at 09:36:28AM +0800, Everett, Vernon wrote: > How do I make it check for more than one Oracle listener? > For reasons unknown to me, we are running multiple listeners on > separate ports on a server. I'm surprised - I thought you could not have more than one tns listener per system. Oh well - I don't know one bit about Oracle DB; I've only worked with their J2EE application server. The problem with it is that even though you can put multiple "oratns" tests into the bb-hosts file, each of them will cause a separate status message. So what you'll see on the Hobbit display is the result of only one of the tests. My best suggestion is to copy the [oratns] section in bb-services so you have [oratns], [oratns1], [oratns2] and so up to the number of listeners you have on a single host. Then you can define them with their respective port numbers in the bb-hosts file, like 1.2.3.4 name.domain.com # oratns1:1545 oratns2:1546 Then there will be separate status columns for each of the listeners. Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0