Mòdul
5
|
Serveis de xarxa amb GNU/Linux |
Exercici |
Monitorització
i manteniment
Introducció En aquest apartat descriurem les eines o recursos que utilitzarem per poder 'prendre el pols' a l'aplicació Squid: - Monitorització
via línia de comandes
Monitorització general via línia de comandes Per accedir a aquest nivell de monitorització cal tenir accés al teclat i pantalla del servidor o poder obrir una sessió telnet o ssh (secure shell, substitut encriptat del Telnet) contra ell.
És la més senzilla i la més potent a l'hora, doncs en cas de tenir problemes greus permet actuar directament sobre el fitxer de la configuració de l'Squid, reiniciar-lo, reconstruir els directoris de la cache, etc. Proposem una pauta de control: 1.- Verificació de l'estat del procés Squid Amb les ordres ps i top comprovarem l'estat del procés Squid, si està executant-se i quants recursos del sistema utilitza. Així executant, # ps -ef | grep squid podrem veure si el procés està en marxa i el seu identificador,
en aquest cas, el procés principal de l'Squid està en marxa amb l'identificador 607. O de forma estesa amb la mateixa ordre ps podem arribar a mesurar de forma puntual moltes més dades per saber fins a quin punt el procés Squid està utilitzant els recursos del nostre equip, # ps -aux | grep squid ens mostraria
tenint com a principals mesures la tercera columna amb %CPU utilitzada, la quarta amb %MEM física (pot ser més del 100 % si el sistema està paginant) i el flag d'estat del procés que aquí apareix com S indicant que el procés està adormit des de fa menys de 20 segons. Recordem que els altres flags
que poden aparèixer son:
Per fer una monitorització a intervals regulars podem utilitzar l'ordre top. Així executant: # top apareixen en pantalla els processos més actius i la informació del sistema. Sense cap paràmetre addicional la mesura es va actualitzant cada cinc segons:
Podeu aturar el monitor amb CRTL+C. Amb el màxim de clients treballant amb el proxy, el procés principal de l'Squid no hauria d'utilitzar més del 75 % de la memòria del sistema i tampoc sotmetre l'equip a mitjanes de càrrega (load average) superiors a 4. Hem de tenir en compte que aquest equip ha de poder realitzar altres tasques. La càrrega la podeu consultar amb l'ordre top o amb uptime i sempre apareix en tres mesures, la primera és la mitjana de càrrega registrada en l'últim minut, la segona en els últims cinc minuts i la tercera en els quinze últims. Podeu alliberar memòria
reduint el valor assignat al paràmetre
cache_mem, i si us
cal reduir càrrega haureu d'eliminar processos innecessaris que
estiguin executant-se en el sistema.
2.- Inspecció fitxer de registre cache.log Inspeccionant les últimes entrades del fitxer cache.log n'hi ha prou per saber si l'Squid treballa sense problemes, qualsevol incidència que afecti el funcionament del programa hi apareixerà reflexada. Quan hi ha una aturada del servei, és a dir, que amb les mesures del primer punt no aconseguim veure l'Squid en marxa, és el primer fitxer que cal observar. Anem a veure un exemple del que podem obtenir del fitxer cache.log. Hem volgut canviar el directori del magatzem cache, modificant la configuració. A l'hora de posar l'Squid en marxa ens adonem que no dóna servei. Per veure que pot estar passant, ens posicionem dins el directori /var/log/squid i executem l'ordre: # tail cache.log i veurem dins les últimes línies:
sembla que no hem inicialitzat el nou directori ( /magatzem), passem a fer-ho manualment: # squid -z i la resposta que obtenim és:
Ja hem detectat l'error, el procés Squid no té drets per poder crear la nova estructura del magatzem, resultava que el directori era de l'usuari root i tal com havíem comentat dins l'apartat de personalització, ha de ser propietat de l'usuari squid. Si volem mantenir en observació l'Squid podem volcar una traça del que es va registrant al fitxer en pantalla executant: # tail -f cache.log
3.- Inspecció fitxer de registre access.log Per acabar, quan hi ha problemes d'accés per part d'algunes de les nostres estacions de treball i d'altres funcionen correctament, o volem veure si fa peticions correctament als proxy de la jerarquia, o pel contrari accedeix directament, podem consultar el fitxer access.log. Per exemple, si volem saber si ha 'denegant' l'accés a algun dels nostres clients des de l'última rotació de registres, per intentar accedir al servidor Web de gestió, tal com veiem en la figura:
executarem: # more access.log | grep DENIED | grep gestio.delcentre.ct i podem observar entre d'altres entrades les que es refereixen a gestió:
On trobarem detallat: - l'adreça ip del
client, 192.168.0.10
Aquest fitxer conté
totes les peticions servides pel proxy als clients, per això és
molt útil per generar estadístiques del rendiment i ús
de l'Squid.
Monitorització via Web amb l'aplicació cachemgr.cgi La mateixa distribució de l'Squid inclou l'aplicació cgi cachemgr.cgi que permet consultar des de qualsevol navegador un conjunt molt complet de mesures sobre el funcionament del proxy. L'accés a aquesta aplicació es pot restringir des de la configuració de l'Squid. Amb la configuració recomanada ens demanarà una contrasenya i és accessible des de qualsevol estació del centre.
Copieu l'aplicació cachemgr.cgi, del directori /usr/lib/squid,
a l'espai d'execució de cgi-bin del servidor Web (Apache) /home/httpd/cgi-bin.
Per accedir-hi només cal un navegador i demanar la URL:
http://192.168.0.2/cgi-bin/cachemgr.cgi
o
http://www.intracentre/cgi-bin/cachemgr.cgi
i ens apareixerà el
següent menú:
que caldrà omplir
en cada opció:
Cache Host:
192.168.0.2 -> Nom o adreça
IP del host on hi ha l'Squid.
Cache Port:
8080 -> Port
pel que dóna servei el proxy cache.
Manager name:
admin -> Nom
de l'usuari que vol accedir (no es verifica).
Password: *****
-> Contrasenya
assignada dins al fitxer squid.conf.
Un cop al menú principal,
podem consultar qualsevol paràmetre dels mesurats dins les trenta
tres opcions.
En aquest cas la pauta proposada
és:
1.- General Runtime
Information
Ens dóna un recull
de dades que ens permet saber com està responent l'Squid, agrupat
en apartats:
- Informació sobre
les connexions.
Tenim al nostre abast de
forma senzilla gairebé tots els paràmetres necessaris per
saber si l'Squid està donant servei de forma correcta.
En la figura següent
podem observar la informació detallada sobre la cache,
tenint directament el percentatge d'encerts (HITS) i errors (MISS).
2.- Cache Client List
Podem veure un resum del
rendiment de la cache per cada connexió, identificades per
l'adreça IP de l'equip, i al peu de pàgina el resultat d'encerts
i errors del total.
En aquest llistat apareixeran
tots els equips que facin peticions a la cache, així podreu
verificar quins treballen i quins tenen malament la configuració.
També hi podreu veure
les connexions denegades per les llistes d'accés (acl), amb la
3.- Peer Cache Statistics
Aquesta opció ens
permetrà verificar l'enllaç amb la jerarquia, llistant un
resum de les peticions fetes pel nostre Squid als pares corresponents.
La configuració actual
amb un sol pare no mostra aquesta opció però cal anomenar-la,
doncs és molt necessària per verificar el funcionament de les relacions
en jerarquies complexes.
4.- Store Directory Stats
Ens ajudarà a verificar
l'estat del magatzem en disc, el percentatge d'ocupació, el nombre
d'objectes, etc.
Aquesta eina doncs es presenta
com una interfície molt útil per resoldre incidències
amb el nostre proxy, amb l'avantatge addicional de poder-la consultar des
de qualsevol navegador web connectat a Internet.
Generació
d'estadístiques d'ús i aprofitament de la cache amb
l'script Calamaris
Per completar aquest apartat
de manteniment i monitorització ens aniria molt bé poder
processar les dades de qualitat de funcionament de l'Squid que hi ha reflexades
dins el fitxer d'accessos.
Utilitzant l'aplicació
calamaris
generarem un fitxer HTML amb un recull estadístic força complet.
Seguim la pauta següent
per implementar la generació d'estadístiques diàries:
1.- Instal·lació de l'aplicació Calamaris
Aprofitarem la distribució
en format RPM de l'aplicació Calamaris per instal·lar fàcilment
l'script al sistema, encara que estigui dins un servidor FTP remot.
# rpm -i http://www.xtec.es/formacio/curstele/d70/d70m5/calamaris-2.27-2.i386.rpm
(tot va dins una sola línia)
Demanem el llistat de fitxers
que ha instal·lat:
i veiem que tenim l'script
principal amb el nom de calamaris, una mica de documentació
i la pàgina del manual per consultar les funcionalitats més
bàsiques.
Cal tenir en compte que els
exemples que hi ha a la documentació es refereixen a l'script principal
amb el nom de calamaris.pl i en aquest cas no porta l'extensió.
2.- Rotació de
logs diaris i generació del fitxer proxystats.html
Per evitar una acumulació
de fitxers de registre (logs) activarem una rotació diària
i un cop processats els logs pel Calamaris els eliminarem.
2.1.- Eliminem la rotació
de l'Squid que governa per defecte l'aplicació logrotate, desant-ho
al diretori /etc
per si ens cal recuperar-ho.
# mv /etc/logrotate.d/squid
/etc/squid.logrotate
2.2.- Modifiquem el control
del registre de logs per aconseguir una còpia que processarem amb
l'aplicació Calamaris.
Editem el fitxer squid.conf
deixant
l'opció:
logfile_rotate 1
Reiniciem el procés
squid per fer efectius els canvis:
# squid -k reconfigure
2.3.- Preparem un script
per executar la rotació, processar els logs i eliminar la còpia
dels registres per estalviar disc.
Una possible solució
pot ser:
fitxer process_log.sh
#
#
# Fí de l'script
Un cop editat l'script cal
donar-li drets d'execució
# chmod u+x process_log.sh
i ja podem provar d'executar-lo
manualment
# ./process_log.sh
Si tot va bé es generarà
el fitxer proxystats.html a l'arrel
del servidor Web i podreu consultar el resultat del treball del proxy.
2.4.- Programem mitjançant
l'eina cron l'execució de l'script que generarà les
estadístiques.
En l'exemple suposarem que
l'administrador vol crear una pàgina d'estadístiques diària,
que recollirà el treball del proxy del dia anterior.
Tenim dues opcions:
- Aprofitant l'organització
de tasques diàries que ofereix RedHat per defecte:
Copiem el fitxer process_log.sh
dins
els directori /etc/cron.daily
i s'executarà de forma
automàtica cada matinada a les 4:02 hores.
- Afegint una tasca perquè
el cron del sistema la executi a l'hora que l'administrador decideixi:
Suposem que el fitxer process_log.sh
l'hem
desat a /etc/squid.
Crearem una tasca, de l'usuari
root, al cron amb l'ordre:
# crontab -e
i quan s'obri la 'finestra
d'edició amb vi' escriurem:
30 8 * * * /etc/squid/process_log.sh
desant-ho amb la combinació
de tecles ESC
:wq! la nova
feina queda programada per executar-se cada dia a dos quars de nou del
matí.
2.5 - Accés via Web
a les estadístiques diàries
Podem visionar el recull
d'estadístiques generades a la URL:
http://www.intracentre/proxystats.html
on podrem avaluar
el treball diari del nostre proxy. |
|