Introduction
The Squid Proxy Server does not use the Linux typical Net-SNMP when installed. Instead, it uses a separate binary that runs as its own process. The binary is installed by default with Squid 3.x and later, but must be enabled when compiled into Squid 2.x and earlier and the SNMP binary compiled after. Once the SNMP binaries are available, they may be configured in the squid.conf file. The separate SNMP procces may then be queried by SNMP monitoring tools such as Zabbix.Configuring the Squid SNMP Process
The Squid Proxy web site provides a detailed HOW-TO page. Assigning ACLs and listener IP addresses for security is strongly recommended. For instance, create a host ACL for the Zabbix Server's IP address and limit access to that ACL and set the listener IP address for a single interface. For this article, we will not use a secure configuration because it is for demonstration purposes. Familiarity with Squid's ACLs is assumed for a live deployment.Minimum squid.conf Configuration
A minimal Squid SNMP configuration requires the following lines in the squid.conf file:snmp_port 3401These lines create the SNMP process listener port (3401 is a widely-referenced port) and listens on all interfaces (default), creates an SNMP_Community-type ACL and assigns a community name (public is a de facto, but inssecure, standard) and allows access over port 3401 to all hosts.
acl <acl_name> snmp_community <community_name>
snmp_access allow all
Squid Proxy Zabbix Template
The Zabbix Share web site hosts the Squid Proxy Server template. There are several customizations to query Squid Proxies.Two macros are included in the template:
{$SQUID_SNMP_COMMUNITY} > publicThese reflect the settings applied in the squid.conf file above. If the global configurations of Squid Proxies in the enterprise differ, adjust them accordingly.
{$SQUID_SNMP_PORT} > 3401
Each host must also be configured with an SNMP interface (Hosts > Interfaces > SNMP) that specifies the listening IP address / UDP port configured in the squid.conf file. This must also be the primary listening SNMP interface.
Example Squid Proxy Server Cache Monitoring
The following architecture is a test environment.
There are two Linux host bridges (br0 and br1) on different subnets. On br0, there is a Zabbix Server, a parent Squid Server (Squid01) and its child Squid Server (Squid02). On br1, there is another Squid01 child Squid Server, Squid03. The two child Squid Servers are configured as siblings. The Squid Servers begin with empty Disk Caches.
Squid01 -- the parent cache -- is configured to only disk cache files larger than 4096 bytes and smaller than 128 MB. Squid02 and Squid03 -- the sibling child caches -- have the default configuration of only caching files less than 4MB. There is an overlap of the caching size policies, but in general, large files will only be cached on the parent. Smaller files will be cached on the children.
The Internet connection (through which the Debian repositories are accessed during installation) is limited to 10 Mb/s (1.25MB/sec).
The Zabbix Server utilizes the Squid Proxy SNMP template. The custom screens below organize the three Squid Proxy Servers in columns. The three respective rows present graphs for HTTP Byte Hit Ratio (%), HTTP Rate (KB/s) and HTTP Request Hit Ratio.
The test consists of performing a Debian 8 (Jessie) desktop network installation (packages retrieved from repositories) with the Debian hosts configured to use different Squid Proxies. First, we perform the installation with empty caches; also, server Squid03 is off line because we only want to cache on Squid02 and the sibling configuration will distribute the load. As illustrated below, the installation requires approximately 20 minutes to download required packages from the repositories. Notice the HTTP Rate (KB/sec) is limited to approximately 1.25 MB/sec (1.25KKB/sec or the Internet connection bandwidth of 10 Mb/sec). Parent Proxy Squid01 (in the left column) returns generally low cache hit ratios and Child Proxy Squid02 returns higher hit ratios because it is passing requests to the parent.
 |
| Unpopulated Parent-Child Proxy Caches |
The second test installation mimics the first, but is now accessing Proxy Caches populated with files from the first test. Not only is the installation much faster (approximately five minutes compared to 20 in the first test), but the HTTP Rate is much higher -- 9 to 10 MB/sec (72 - 80 Mb/sec). Internet bandwidth for this test is not an issue because the files are all cached locally. Bandwidth is limited by the system Linux Bridge and Virtio NIC and Disk performance.
 |
| Populated Parent-Child Proxy Caches |
The third test installation moves the Debian machine to Linux KVM host bridge br0 and uses Squid03 as its proxy server. Here we see limitations of disk IO and peer caching because Sibling Proxies Squid02 and Squid03 are synchronizing and both accessing parent cache Squid01. While the installation is faster than fetching all the files from the Internet-hosted repository, the disk contention and peer cache synchronization slow the total time of installation to approximately 10 minutes (compared to 20 for fetching all files from the Internet and five minutes for the populated two-cache proxy arrangement).
 |
| As above with an Unpopulated Child-Sibling Proxy Cache |
The fourth test installation mimics the third but is now accessing Proxy Caches populated with files from the first three tests and the Sibling Proxies are also synchronized. The Parent Proxy and Squid03 Child Proxy are both actively providing files for the installation which completes in approximately five minutes. HTTP Rate bandwidth is also comparable to the tuned proxy performance in Test 2 -- 7MB/sec - 11 MB/sec. Squid02 -- the other Sibling Proxy depicted in the center column -- displays very little activity bceuase its disk cache contents are identical to Squid03 and no files are needed.
 |
| Populated Parent - Sibling Children Proxy Caches |
The above tests are not representative of an enterprise proxy server deployment. The caches are either unpopulated or fully populated with requested data, whereas in live deployments typically approximately 5% of requests are cached. There are performance limitations (particularly disk IO) in the Linux KVM test environment. The all-or-nothing caching depicted above does, however, demonstrate the increased HTTP and Cache Hit Rates associated with proxy caching.
The Zabbix Share web site hosts the Squid Proxy Server template.
