Monitorizando las conexiones de Squid con InfluxDB y Grafana

Muchas son las herramientas que se utilizan para el análisis de los registros del servidor proxy Squid, aquí en sysadminsdecuba podrán encontrar artículos referentes a esta tarea. Otra de las formas de monitorizar a squid es utilizando su protocolo de administración cache_object:// donde se puede acceder directamente a información interna del servidor. Existe una aplicación SqStat que es un ejemplo de monitorización a través de un sitio web, de la utilización del cache_object://localhost/active_requests para visualizar una amplia información acerca de todas las conexiones activas de Squid, pudiendo observar información por cada conexión a cada URL, ordenadas por usuario o por IP, obteniendo cuántos datos a transferido, a que delay_pool pertenece, etc.

Ahora vamos a utilizar otra manera de hacerlo, les comentaré de cómo enviar esos datos desde el Squid para el servidor InfluxDB, para que de ahí poder realizar cualquier tipo de consultas y poder crear un buen dashboard con Grafana.

Manos a la obra

Lo primero es configurar nuestro Squid, que los que utilizan actualmente SqStat pueden omitir ya que lo tienen configurado, para que habilite el acceso a su protocolo de administración (desde la misma pc por seguridad), ponemos en el fichero de configuración, generalmente en /etc/squid/squid.conf

# Permitimos al propio servidor acceder al manager
http_access allow localhost manager               

# Cualquier otro intento de acceso es denegado                                                                                                                                                                                            
http_access deny manager

Luego recargamos Squid

# Recarga sin reiniciar el proxy
squid -k reconfigure

# Recarga reiniciando el servicio
systemctl restart squid

Ahora podemos probar que Squid tiene habilitado el manager:

# Si no ponemos -h por defecto es ::1 IPv6
$ squidclient -h 127.0.0.1 mgr:info

...
Squid Object Cache: Version 3.5.23
Build Info: Debian linux
Service Name: squid
Start Time:     Wed, 07 Mar 2018 12:47:01 GMT
Current Time:   Sat, 10 Mar 2018 06:20:55 GMT
Connection information for squid:
        Number of clients accessing cache:      58
        Number of HTTP requests received:       1700623
        Number of ICP messages received:        0
        Number of ICP messages sent:    0
        Number of queued ICP replies:   0
...

Ahora debemos configurar InfluxDB con la base de datos que albergará toda la información generada. En InfluxDB existen políticas de retención, que no es más que una forma de decirle por cuánto tiempo y cómo se almacenarán las métricas, por defecto es infinito y guarda íntegramente todos los datos. En nuestro caso, como toda la información de Squid también va a los registros, entonces no necesitas de por vida todos estos datos en InfluxDB, por lo que especifico una política de retención de 7 días, esto se configura en el Chronograf:

Luego de que Squid está configurado procedemos a descargarnos el programa que hará las consultas a Squid y lo enviará a InfluxDB, lo programé en Ruby y con dependencia del paquete de InfluxDB para Ruby por lo que deberían tenerlo instalado:

apt install ruby ruby-influxdb

Nos descargamos la versión más actualizada y el fichero app.rb lo podemos poner preferiblemente en /usr/bin o /usr/local/bin . Después de descargarlo y como todavía no tiene un fichero de configuración, debemos abrirlo y reemplazar ciertas líneas (como el script es corto, lo publico directamente, por si alguien no tiene acceso a internet), específicamente la 6 y 45:

require 'net/http'
require 'influxdb'
require 'date'

#En esta línea cambiamos por nuestro servidor de InfluxDB y BD
influxdb = InfluxDB::Client.new host: '192.168.0.9', database: 'squid'

Net::HTTP.start('127.0.0.1', 3128) do |http|
  while true

    request = Net::HTTP::Get.new 'cache_object://localhost/active_requests'

    response = http.request request # Net::HTTPResponse object

    case response
    when Net::HTTPOK then
      matches = response.body.scan /Connection: 0x([a-f0-9]+)\n\s+.+\s+.+\s+.+\s+remote: ([0-9\.]+).+\s+.+\s+.+\nuri (.+)\n.+\n.+out.size (\d+)\n.+\n.+\n.+\(([\d\.]+) seconds ago\)\nusername (.+)\ndelay_pool (\d+)/

      date = DateTime.parse(response['Date'])
      date = date.new_offset(DateTime.now.offset)

      matches.each do |match|

        match_url = match[2].match(/:\/\/([^\/]+).*/)
        match_url = match_url[1] unless match_url.nil?
        match_url = match[2].match(/[^:\/]*/)[0] if match_url.nil?

        data = {
            values: {
                data_down: match[3].to_i,
                duration: match[4].to_i,
                delay_pool: match[6].to_i
            },
            tags: {
                connection: match[0],
                ip: match[1],
                username: match[5],
                uri: match_url
            },
            timestamp: date.to_time.to_i
        }

        begin
          # En este caso decimos en que política de retención lo tendremos
          influxdb.write_point 'realtime', data, 's', 'realtime'
        rescue
          # ignored
        end
      end
    else
    end
    sleep 1

  end

end

Ya con esto enviamos los datos, pero faltaría establecerlo como un servicio así no tendríamos que iniciarlo cada vez que reinicia el servidor. Para este menester les comento como realizarlo con SystemD (soy de los que lo apoya):

# Creamos un usuario y grupo de servicio para evitar ejecutar como root
useradd -r ruby_realtime
groupadd -r ruby_realtime

# Creamos el servicio
nano /lib/systemd/system/proxy_realtime.service

# Le agregamos la definición

# INICIO

[Unit]
Description=Extract realtime information from SQUID proxy and send to InfluxDB

[Service]
User=ruby_realtime
Group=ruby_realtime
WorkingDirectory=/tmp
Restart=always
RestartSec=5
ExecStart=/usr/bin/ruby /usr/bin/app.rb

[Install]
WantedBy=multi-user.target

#FIN

# Recargamos los servicios de systemd
systemctl daemon-reload

# Habilitamos el inicio de proxy_realtime
systemctl enable proxy_realtime

# Lo iniciamos
systemctl start proxy_realtime

Ahora quedaría solo montar las gráficas en Grafana

¿De cuánta utilidad te ha parecido este contenido?

Luis Felipe Domínguez Vega

Administrador de Sistemas y Programador entusiasta de tecnologías libres.

Compartir
Publicado por
Luis Felipe Domínguez Vega

Entradas recientes

Alta disponibilidad de sus base de datos con Percona XtraDB Cluster en Kubernetes

Uno de los grandes retos al que nos podemos enfrentar cuando una aplicación crece, es…

8 meses hace

Home automation (Parte 3) – ESPHome

Qué es lo que deseo hacer en este capítulo? Básicamente un sonoff, quiero encender/apagar las…

1 año hace

Home automation (Parte 2) – Home Assistant

Hace algunos meses estoy escuchando hablar del proyecto Home Assistant (HA). En palabras literales del…

1 año hace

Home automation (Parte 1)

Desde hace varios meses vengo con la idea de automatizar la casa donde vivo. Poco…

1 año hace

Cocinando una imagen personalizada de OpenWRT

El artículo describe el uso para un caso particular de OpenWRT y la creación de…

1 año hace