Older blog entries for eknuth (starting at number 2)

27 Jul 2000 »

Didn't walk last night. My poor dog.

Digging deep into cricket and rrdtool. They can be superfly tnt. Our current configuration is just scratching the surface. My brain is tired. I am going shopping.

4:35pm
Had movement in fifth floor bathroom. Everything came out ok.

26 Jul 2000 »

Last night over dinner with cdent and squiggy, we discussed the whole network monitoring situation. We decided that the problem seems to be project definition. In this entry I am going to try and clarify what my department needs as far as this project goes.

statistics gathering

outage notification

threshold notification

report generation

We, as a company are already using cricket/rrd and mrtg to gather statistics. We are using mon to notify us of outages. Mon also keeps a history of outages which pretty much covers the report generation. Cricket can send traps when thresholds are crossed which could probably be messaged into a pretty good threshold notification system. So, sounds like we have this almost covered. We just need to take advantage of the tools we have. My boss seems to want to do something, though.

Racked up our dslam today. The thing is a beast.

Does anybody else wonder if anyone ever does any advogato based industrial espionage?

Even after bumming around the Crazy Horse until 10pm, I still managed to get my 1hr evening walk in. At lunch I just did the 30minute one. Which is probably for the best. Doing the hour long walk kind of makes my lunch hour stretch a little too long.

I need to keep the door to my office locked and my lights off.

26 Jul 2000 »

This morning I went over our needs for a network monitoring system. We've looked at a bunch of different commercial setups, but they seem either pricey or not what we want, but usually both. We've tenatively decided to roll our own. Which may or may not be a good thing.

Our needs:
We need to monitor a variety of network devices including upses, routers, switches, cmtses, dslams, terminal servers, ds3 muxes, csus and other things like that. We need to be able to look at cpu usuage, temperature, modems in use, blah, blah, blah. Then we need to monitor thresholds and be notified when certain things happen. For example when a ds1 circuit zeros out or saturates.
My analysis:
Cricket/rrdtool could collect the data. We don't like rrd's pruning techniques. We could pull the relevant data out of the rrd data files and use it before it gets pruned.
Prior Art:
We've looked at netcool, nocol, and a couple others. I really like netsaint which I found in the project section. I've installed and I am playing. With some tweaking it could do what I want it to do. I also need to hook up with noc guys over at IU to see what they are doing. They've tweaked the hell out of mrtg. We'll see. Netsaint, rules, though.

We all need to think about burstable t1s. Monitoring and billing.

In other news, I've decided to more fully develop the linux side of my notebook. It has become my central workstation. I've needed to run windows because 3com's total control manager and cable modem manager run in windows (although wine seems to work more or less). Recent events have changed my needs. I've rewritten the cable modem manager in perl as a cgi, and we are mainly using as5300's rather than total controls. And I am going to be doing more developing. I've gotten used to securecrt and it keeping track of all the places I need to telnet or ssh too.

Personal:
I think every 8 months I get antsy. For more than 10 years I have either moved, changed schools, changed social groups or changed jobs every 8 to 9 months. Now I am supposedly all grown up. I am just passed 8 months in current job and I need to buckle down. I think I am over the antsiness, at least. Plus as my pal cdent says, I need to get in touch with my inner geek. That stalwart lad that hiked through the snow to the computer lab with dozens of disks to install linux way back when. We'll see.