February 2008 - Xymon - Xymon mailman web

Error making latest snapshot
by lars.ebeling＠leopg9.no-ip.org 04 Feb '08

04 Feb '08

gcc -g -O -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHPUX -I. -I /home/hobbit/snapshot/include -I/usr/local/include -I. -I../include -DSTANDALONE -o loadhosts loadhosts.c loadhosts.c: In function `bbh_find_item': loadhosts.c:216: warning: return discards qualifiers from pointer target type loadhosts.c: In function `bbh_item_id': loadhosts.c:593: warning: return discards qualifiers from pointer target type /usr/ccs/bin/ld: Unsatisfied symbols: addtobuffer (code) nlencode (code) rbtFind (code) rbtNew (code) sanitize_input (code) get_fqdn (code) rbtKeyValue (code) dbgprintf (code) stackfclist (code) stackfclose (code) gettreeitem (code) xgetenv (code) rbtDelete (code) rbtInsert (code) xfreenullstr (data) clearstrbuffer (code) rbtEnd (code) stackfgets (code) freestrbuffer (code) stackfopen (code) errprintf (code) stackfmodified (code) name_compare (code) newstrbuffer (code) collect2: ld returned 1 exit status make[1]: *** [loadhosts] Error 1 make[1]: Leaving directory `/home/hobbit/snapshot/lib' make: *** [lib-build] Error 2 $ -- Regards Lars Ebeling http://leopg9.no-ip.org Hobbithobbyist "It is better to keep your mouth shut and appear stupid than to open it and remove all doubt." -- Mark Twain

2 2

.deb packet of Hobbit 4.2.0 with alle patches
by klj＠Beredskabsstyrelsen.dk 04 Feb '08

04 Feb '08

Hey all, I an looking at the new bbwin 0.10 because it can run in centralised mode. But to be able to do that I need to patch my hobbit, at least with the bbwin_4.2.patch but I will also like to have all the others patches. Now to the question is there a .deb version with all the patches installed or do I have to compile the sources from stratch on my ubuntu server? Best regards, Kim Johansen

1 0

Hobbit - extracting svcs data ?
by Keller_Liora＠emc.com 04 Feb '08

04 Feb '08

Hi, I am wondering, is there a way to extract the data, which services are running on a host, using a unix "grep" command? Where are the "svcs" logs are located to extract the information? Thanks, Liora

3 2

[hobbit] ext scripts & the Hobbit methodology for implementation.
by scott＠PacketPushers.com 03 Feb '08

03 Feb '08

Stece, Could you perhaps create a hobbit hostname for each application you'd like to monitor? So in the hobbit server, you'd see APP1 and APP2 with APP1.apache, APP1.http, and APP2.db monitors. Then on the client have the various data collecting scripts to change the hobbit hostname. This would also have the added benefit if you move applications around, the monitors/collectors move with. Aggregating load balanced application data metrics is another nightmare, so I could only propose APP1-instance1.metric. -Scott On Jan 24, 2008 6:34 PM, s_aiello at comcast.net <s_aiello at comcast.net> wrote: > On Thursday 24 January 2008, Henrik Stoerner wrote: > > On Thu, Jan 24, 2008 at 10:24:24AM -0500, s_aiello at comcast.net wrote: > > > What I mean by BB legacy ext scripts, are client based ext scripts > that > > > send reports in via the bb status command. The Hobbit method is more > > > server centric. In that clients report raw data to the server and the > > > server processes that data, applying thresholds, formating reports, > and > > > possibly trending. Now to send raw data from the client there are two > > > choices, data or client. Now in the past, I believe I saw a thread > where > > > Henrik mentioned that data was the preferred method for ext scripts & > > > that client was more for the internal use between hobbit clients & > > > server. But the lure of the client command is to great to ignore. > > > Especially with the ability to access that raw data via the clientlog > > > command. > > > > I think this is the real "killer" difference between the client- and the > > data-message types. If the client-data wasn't directly available, you > > could just as well use a data-message. > > > > > So that brings me to my first problem when sending data via the client > > > command the data needs to be structure in a very particular format. > Where > > > OSTYPE has to match a predefined Hobbit OSTYPE and a minimum set of > > > SECTIONNAME need to be filled for the Hobbit server to accept the > data. > > > If they are missing the data just ends up in /dev/null. > > > > Eh - not quite, you can still get at it with the clientlog command. It > > just doesn't generate any cpu/disk/memory... statuses because > > hobbitd_client - the only program that normally listens in on the Hobbit > > "client" channel - doesn't know how to interpret the data. > > > > The only requirement for a client-message really is that the hostname > > must be listed in bb-hosts. The operating-system type (and the optional > > client "class") is used to pick out an entry from the client-local.cfg > > file which is returned to the client system, but there is no requirement > > that these must be pre-defined anywhere in Hobbit. > > > > Ah you are right... My tests earlier this morning were failing for other > reasons. > > > So I was curious if in the upcoming 4.3 (or newer version), that the > > > client command could be opened up for more general usage ? > > > > I think what you really want to be able to do is to combine client-side > > data from multiple sources - e.g. you have the Hobbit client running and > > feeding the normal client data into Hobbit, and then you have a number > > of custom add-ons that generate data, and you want this data to be > > available in Hobbit as if it had been part of the "normal" client data. > > Like > > Hobbit client sends data (uptime, vmstat, ps-listing etc.) > > Add-on script A sends additional data (eg. JVM performance metrics) > > Add-on script B sends additional data (eg. custom application data) > > User views the "clientlog" info on Hobbit and sees all three > > > Well that would be nice too, but actually where I am headed is multiple > devices reporting from a single server. Lets say serverA runs 5 apache > instances (not 5 vhosts). I would like to have in Hobbit 6 total devices; > serverA, web1, web2, web3, web4, web5. So not sure if having all the > clientlog data contained under serverA would be such a good idea. That > clientlog could get to be rather large (I have some web servers that run > 20+ > apaches). So I was more thinking that each device in Hobbit would have > it's > own clientlog data. So clientlog data seperate or combined.. not sure.. > you > would be better to decide that. > > I was also going to do this for my App servers. We run multiple JVMs or > Apps > on a given server. So base server stats are good, but it would be great to > have other device entries in Hobbit that are completely focused for each > JVM > (just reports focused on that one JVM instance). Presently I have reports > that I term Monolithic. They give reports on every JVM or apache in one > report. There are some people that have issue with such large / multi app > reports. When there is an alert, unclear what is the cause or when a new > issue occurs it is lost due to a previous alert state from a differen JVM. > By > spliting the monotlithic reports into many reports for each instance, the > page would then be more of a dashboard. JVM-A has a red on CPU or the > DBPool > for JVM-C is yellow. Then the user can drill down into the report to find > out > the details. Another benefit would be that I could then create Application > Specific pages. On these App specific pages the application's entire tech > stack; Web, App, DB, etc. could be displayed without any data from a > different App. The Application teams would then have a clean page and see > the > health of their app at a glance. > > And then if I needed semi-Monolithic, i.e. rollup the application's load > balanced webservers, I can just use bbcombotest to combine the 4 web > server > device reports. > > > It isn't difficult to implement, most of the pieces are already there. > > Some things that will need to be done in the Hobbit daemon: > > - store client-ext-FOO data separately from client-ext-BAR (to know what > > to overwrite when an update arrives). > > - should there be a new protocol command for extensions? I think that > > might be necessary. > > - Should there be a "client-local.cfg"-like file for extensions? It > > could be useful. > > - for performance reasons, it would probably make sense to have some way > > of splitting extension data off from the normal client data, and then > > run a "client" channel worker handling each of the extension scripts. > > That way we dont need to send all of the client data through all of > > the add-on handlers who will just throw it away. > > > > > Now secondly after the data is actually accepted by the Server, the > > > ability to do something with it is needed. Now that shouldn't be a > > > problem with being able to attatch a script to a Hobbit channel or by > > > scheduling a command to run clientlog every X minutes and process the > > > data. But how does the script apply thresholds ? Now I am working > under > > > the assumption that for my custom data I would be able to add custom > > > definitions to the hobbit-clients.cfg file. But how does my script > access > > > those thresholds ? Since Hobbit already has all the internals to acess > > > this file, I would think that a Hobbit utility would fit the need. > Maybe > > > even a new BB command ? i.e. "bin/bb > > > 1.2.3.4 "threshold server", where there could be an optional > > > parameter "stats=" which could be CPU, PROCS, DISK, etc. By storing > the > > > custom ext thresholds in the hobbit-clients.cfg file, this allows the > cgi > > > hobbit-confreport.sh to report on the custom thresholds along with the > > > built-in client thresholds. > > > > It's hard for me to see how difficult this would be to implement. I know > > the client configuration handling is a bit tricky in how it's > > implemented, I don't know what it takes to provide a generic interface > > to this for custom client-modules. > > > > A "BB" command to fetch the configuration? No, don't like that idea. The > > hobbitd daemon should not have to bother with configuration files it > > doesn't need for itself. > > > > Another complication is that the program using the configuration info is > > "long-lived", so it will have to reload the configuration when it > > changes. And that has some performance implications - the first attempt > > at the current client-configuration performed very poorly because the > > way it scanned all of the client configuration rules was extremely slow, > > simply because of all the pattern-matching of hostnames, testnames, > > colors, time-specifications etc. hobbitd_client now caches the list of > > relevant configuration rules for each host once it has determined what > > they are, and this gave quite a performance boost. Having 5-10 add-on > > handlers making the same mistake would kill your server. > > > > I'll have to think about this. > > > > Yeah, I can only imagine the headache of trying to solve implementing > powerful > features and good performance. I have barely poked around with my fledging > C > experience. So I hope I do not come off asking for feature X, Y, Z and not > appreciating the complexity. Or not jumping into the code, and trying to > solve/implement myself. I was just thinking in my head of what features > would > make sense and how they might be implemented in the 'Hobbit way'. > > > > Sorry for the long winded email, I am just trying to move my ext > scripts > > > to the Hobbit methodology. It just makes more sense.. and offers many > > > more options & power. And this was just my take on it. Thoughts ? > > > > It's a good idea, and if it can be done right then it would fit in > > really well with the Hobbit philosophy of providing good basic > > monitoring, but also enabling you to add whatever extras you need. > > So I like it, but it does require some thought to get right. > > > > I don't think I explained why I wanted to access the clientlog data, so I > will > try to explain. I had hoped to send more information to hobbit than just > alerting stats. More like configuration & runtime information. Since I > would > then be monitoring most of the application stack (web, app, db) I could > wrap > a script around all that data, to query and provide up to the minute > information on applications. For example what IPs are presently being used > and for what. What http urls are which teams role to support (determined > by > what server the apache instance is running, etc). This would make support > of > my environment almost a breeze. Especially since I had planned to write > the > ext scripts in such a way that when a tech added web6 to serverA, the data > would then be collected automatically and the device entry for web6 would > be > added to Hobbit automatically (deletes removals would be manual). So this > extra data doesn't need to be seen in alerting reports, but it would be > rather nice to query for it and know that the hobbit-clients/scripts where > gathering and feeding Hobbit with the latest info. > > Again, sorry for the very verbose email. > ~Steve > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0

More Granular data than 300 second samples, duh!
by scott＠PacketPushers.com 03 Feb '08

03 Feb '08

One of the most common requests to the trending of data is "How do I make the charts graph data samples which are smaller than 300 seconds?" And the answer has been, you have the source, have fun. The original design decision that Henrik inherited was larrd should only be for capacity planning and NOT real-time performance analysis. Do one thing and do it well. I had a thought the other day, and I think we could possibly get the "best of both worlds." Instead of $ vmstat 300 2 (resulting in one 300 second sample) why not $ vmstat 5 61 (resulting in sixty 5 second samples) The data would still only be transported every five minutes, but contain more granular samples. This could not be done for all metrics, but many. This would also require the RRAs of the all the RRDs be re-made (export, re-create, import). But I've that's been on my mind anyway cause the original RRA structure was based on screen sizes for 800x600, instead of business requirements. Henrik, do you follow my thinking? It's kinda hard for me to believe it's taken me over five years to think of this! My biggest concern is not the technical details of the collectors and RRD/RRA restructuring, but inflicting resource usage on servers measuring themselves. $ vmstat 1 301 would definitely be a bad idea. Scott Walters -PacketPusher

3 4

hobbitfetch still crashes w/ latest snapshot
by jonescr＠cisco.com 02 Feb '08

02 Feb '08

I upgraded to the newest snapshot, and hobbitfetch started crashing on me. Overwriting it with a 4.2 binary from another machine fixed it. I have reported this problem before: http://www.hswn.dk/hobbiton/2007/06/msg00142.html Just notifying that it is still an issue. Here's a dump from one of the core files: Core was generated by `/home/monitor/server/bin/hobbitfetch --server=x.x.x.x --no-daemon --pidf'. Program terminated with signal 6, Aborted. #0 0x00736402 in __kernel_vsyscall () (gdb) bt #0 0x00736402 in __kernel_vsyscall () #1 0x4b0e3c00 in ?? () #2 0x4b1f3ff4 in ?? () #3 0xb7fd86c0 in ?? () #4 0xbf93ecd8 in ?? () #5 0x4b0e5451 in ?? () #6 0x00000006 in ?? () #7 0xbf93ec4c in ?? () #8 0x00000000 in ?? () -Charles

1 0

[hobbit] Admin Scripts download
by hobbit＠alexkeller.de 02 Feb '08

02 Feb '08

I uploaded the latest version that I found. Hobbit Admintools version 0.3.0b: http://hobbit.he-webpack.de/hobbit_admintools_0.3.0b.tar.gz Regards, Alexander > >Does anyone have the tarball of the Admin Scripts that were once found here: >http://www.fh-augsburg.de/~henk/hobbit/ > >I can't seem to find my archive of them =( > >-- >Josh Luthman >Office: 937-552-2340 >Direct: 937-552-2343 >1100 Wayne St >Suite 1337 >Troy, OH 45373 > >Those who don't understand UNIX are condemned to reinvent it, poorly. >--- Henry Spencer

1 0

"Cannot open configuration files"
by jonescr＠cisco.com 02 Feb '08

02 Feb '08

I'm seeing this error in rrd-status.log, snapshot build 4.3.0-0.20080103 2008-02-01 16:43:18 Peer not up, flushing message queue 2008-02-01 16:43:18 Cannot open configuration files (null) -Charles

3 2

does anyone know this error?
by HS3082＠att.com 01 Feb '08

01 Feb '08

2008-02-01 13:15:50 Failed to get a message, terminating Thank you, Howard Snyder hs3082 at att.com SR Network Control Engineer Network Services 404-531-5325 This email, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Cingular Wireless and its Affiliates. If you are not the intended recipient of this email, you are hereby notified that any dissemination, distribution or copying of this email, any attachments thereto, and any use of the information contained is strictly prohibited. If you have received this email in error, please notify me at 404.531.5325 and permanently delete the original and any copy thereof. For login requests and password resets, you will need to open a request on the "My Logins" website: https://nslogins.edc.cingular.net/login.cfm?CFID=13246&CFTOKEN=41726264 For OSS problems: DL-MNOC-OSS Adjunct DL-MNOC-OSS Siemens DL-MNOC-OSS Nortel DL-MNOC-OSS Nokia DL-MNOC-OSS Lucent DL-MNOC-OSS Ericsson

2 1

[hobbit] Future of Hobbit
by jonescr＠cisco.com 01 Feb '08

01 Feb '08

Josh Luthman wrote: > I love VIM myself, though I have to admit sometimes it's easier to use > notepad. > > If you're familiar with MS Edit then you should have no problems with > nano or pico. I've been noticing these two are being phased out, but > you should still be able to get one or the other. > Would it be nice if you could edit the configs via the web interface (a simple text editor)? -Charles

3 2