Re: Status of mail list ...

On Sun, 15 Mar 1998, Scott C. Lemon wrote:

> Yes ... I do know that it is quite different from yours. They have left most of
> the host operating system objects to other MIBs ...

There are several reasons for having this info into the caching mib:

1) same agent, port, access controls thus easy to install, no need to
install another agent, worry about configuration or even availability.

2) providing info that relates to the caching process only, such as
resource consumption, memory usage etc, without having to refer to
HR-MIB's tables or risking that this information is not available.

> There are a couple of points/questions that I was going to ask about in the current
> Squid MIB.
>
> 1. In the config group : table of peers you have an object to represent the
> cachePeerType. There are two issues that I have run across.
>
> First, you probably do not want to have "none (4)" as a type. If it was of type
> none then I would think it shouldn't be in the table. Also, it is not good to
> leave none as the last value. There might be more types that you want to add and
> none would seem out of place at number 4.
> Second, I have already found in my work that I want to know who the children are.
> So you're probably going to want to add a type child. This would be information on
> any node that pings you using ICP. I found that I need this to be able to traverse
> cache hierarchies in both directions ... upstream and downstream.

Thanks, that'll be done for the next version. We haven't gone thus far to
develop "cache discovery" yet ;-)

> 2. Do you maybe want to couple the table mentioned above, with the cache peer stats
> table? These stats would just be additional columns in the same table. This would
> consolidate some of the information.

Hmm, I'm aware of this problem, but I could not decide whether this
belongs to cacheConfig or cachePerf. What do you think?

> 3. I have found that another useful stat on peers is the number of objects, and
> total Kbytes transferred to or from a peer. This helps to give detail on the
> actual flow of objects in the hierarchy.

That's too in the "todo" list :)

> 4. Do you keep stats on active connections? Both client and server? I didn't see
> anything in the MIB related to connections, active, or persistant.

Yes, this information is available through "cacheFdTable", but should be
moved to cacheNetwork I guess.
 
> Cool stuff ... I've seen mrtg in the past ... these are some nice graphs. How
> heavily used is tirana? It looks fairly quiet ...

It's actually the box we use for beta testing so we've probably
dissapointed several tirana users with frequent coredumps and
careless overloading ;-) It's not a big machine either.

Regards,
-Kostas
Received on Mon Mar 16 1998 - 20:14:42 MST