[squid-users] Squid - mrtg problem

Hi Squid experts,

I have a squid-mrtg question. I got a script from
http://www.psychofx.com/chris/unix/mrtg/. Snmp is correctly (I believe)
communicating with squid. A snmpwalk request returns something.
Mrtg won't get the data with the sample script (modified following the
instructions). Unfortunately I don't know snmp so it'd be nice if someone
could lend me a hand on this. I will post here some parts of configs/logs.

        Target[proxy-hit]:
cacheHttpHits&cacheProtoClientHttpRequests:public@localhost:3401
        Title[proxy-hit]: HTTP Hits
        PageTop[proxy-hit]: <H2>proxy Cache Statistics: HTTP Hits /
Requests</H2>
        Suppress[proxy-hit]: y
        LegendI[proxy-hit]: HTTP hits
        LegendO[proxy-hit]: HTTP requests
        Legend1[proxy-hit]: HTTP hits
        Legend2[proxy-hit]: HTTP requests
        YLegend[proxy-hit]: perminute
        ShortLegend[proxy-hit]: req/min
        Options[proxy-hit]: nopercent, perminute, dorelpercent

This seems to work somehow. In mrtg directory there are lots of pngs and
.log files, some of them have the current date/time after running mrtg. I
don't get any .html generated, is this normal? I got an index.html from the
same website. This sample I provided is from the mrtg share/doc directory.

mrtg version is 2.10.15 as I recall, squid is 2.5stable5 running on fedora
core 2.

The following config, part of the config from Chris' website, won't work:

Target[cacheServerRequests]:
cacheServerRequests&cacheServerRequests:public@localhost:3401
MaxBytes[cacheServerRequests]: 10000000
Title[cacheServerRequests]: Server Requests @ thor
Options[cacheServerRequests]: growright, nopercent
PageTop[cacheServerRequests]: <h2>Server Requests @ thor</h2>
YLegend[cacheServerRequests]: requests/sec
ShortLegend[cacheServerRequests]: req/s
LegendI[cacheServerRequests]: Requests&nbsp;
LegendO[cacheServerRequests]:
Legend1[cacheServerRequests]: Requests
Legend2[cacheServerRequests]:

This gives me the following error:

[root@thor mrtg]# env LANG=C /usr/bin/mrtg test.cfg
Rateup ERROR: Can't cope with %Y-%m-%d %H:%M, sorry!
ERROR: Skipping webupdates because rateup did not return anything sensible
WARNING: rateup died from Signal 0
 with Exit Value 1 when doing router 'cacheserverrequests'
 Signal was 0, Returncode was 1
[root@thor mrtg]#

I know I'm a total n00b in this whole thing, first time I see snmp and
mrtg, but can someone please look into this and help me with some advices?
I'd be really grateful. I am deploying some squids (upgrading one,
implementing 1 or perhaps 2 new ones) in our company and I would be very
happy sto see some real data on how squid works, how loaded is it, to see
if a hardware (memory? cpu? disk?) upgrade is needed and so on, as the
number of users are increasing.

Also I can see in squid's cache.log - using the 'buggy' .cfg:

2004/09/10 12:28:17| snmpHandleUdp: Called.
2004/09/10 12:28:17| snmpHandleUdp: FD 15: received 113 bytes from
127.0.0.1.
2004/09/10 12:28:17| snmpDecodePacket: Called.
2004/09/10 12:28:17| snmpAgentParse: reqid=[583033999]
2004/09/10 12:28:17| snmpConstructReponse: Called.
2004/09/10 12:28:17| snmpAgentResponse: Called.
2004/09/10 12:28:17| snmpTreeGet: Called
2004/09/10 12:28:17| snmpTreeGet: Current :
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.3.2.1.10
2004/09/10 12:28:17| snmpTreeGet: return
2004/09/10 12:28:17| snmp_prfProtoFn: Processing request with magic 2!
2004/09/10 12:28:17| snmpTreeGet: Called
2004/09/10 12:28:17| snmpTreeGet: Current :
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.3.2.1.10
2004/09/10 12:28:17| snmpTreeGet: return
2004/09/10 12:28:17| snmp_prfProtoFn: Processing request with magic 2!
2004/09/10 12:28:17| snmpTreeGet: Called
2004/09/10 12:28:17| snmpTreeGet: Current :
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.1.3
2004/09/10 12:28:17| snmpTreeGet: return
2004/09/10 12:28:17| snmp_sysFn: Processing request:
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.1.3
2004/09/10 12:28:17| snmpTreeGet: Called
2004/09/10 12:28:17| snmpTreeGet: Current :
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.2.2
2004/09/10 12:28:17| snmpTreeGet: return
2004/09/10 12:28:17| snmp_confFn: Processing request with magic 2!
2004/09/10 12:28:17| snmpTreeGet: Called
2004/09/10 12:28:17| snmpTreeGet: Current :
2004/09/10 12:28:17| oid = .1.3.6.1.4.1.3495.1.2.3
2004/09/10 12:28:17| snmpTreeGet: return
2004/09/10 12:28:17| snmp_confFn: Processing request with magic 2!
2004/09/10 12:28:17| Buffer=0xa69c2a8 BufLenP=0xa69b37c, buflen=4096
2004/09/10 12:28:17| snmp_msg_Encode: Encoding community (public) (6)
2004/09/10 12:28:17| snmp_msg_Encode:Encoding PDU Header at 0x0xa69c2b7
(fake len 4081) (4081 bytes so far)
2004/09/10 12:28:17| LIBSNMP: snmp_build(): Packet len 152 (requid
583033999)

So I cannot do anything just assume that request are made and correctly
returned, but mrtg perhaps can't parse some data? :(

I can provide you any other relevant data you might need.

PS: I'm done with the squid acl part, that shouldn't be a problem.

Thank you,
Endre.

Greetings,
Endre Szekely-Bencedi
GE GDC Security Leader
_____________________________________
TATA Consultancy Services - Hungary
Science Park B, 1st floor
Irinyi Jozsef utca 4-20 Budapest 1117
Tel: +36 1 886 TATA | +36 1 886 8022
Fax: +36 1 886 8001
Email: Endre.Szekely-Bencedi@hu-tcs.com
_____________________________________

"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information. If the
reader of this message is not the intended recipient, you are notified that
any dissemination, distribution or copy of this communication is strictly
prohibited. If you have received this message by error, please notify us
immediately, return the original mail to the sender and delete the message
from your system."

"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information. If the
reader of this message is not the intended recipient, you are notified that
any dissemination, distribution or copy of this communication is strictly
prohibited. If you have received this message by error, please notify us
immediately, return the original mail to the sender and delete the message
from your system."
Received on Fri Sep 10 2004 - 04:30:49 MDT