Supervisar el rendiment en Ubuntu implica analitzar i quantificar el consum de recursos de l’equip o servidor en viu. Aquesta pràctica resulta vital per diagnosticar la salut del sistema i anticipar-se a possibles situacions de saturació.
En executar l’aplicació, es visualitzen tots els processos actius en el sistema. Tal com vam practicar en entregues anteriors, aquest entorn gràfic ofereix una funcionalitat equivalent a la d’eines de terminal com htop, etop o btop.
Com s’observa a la interfície, tenim la possibilitat de finalitzar processos, tancar-los o ajustar paràmetres com l’afinitat de la CPU i la prioritat d’execució. Aquestes operacions ja s’han tractat detalladament en seccions prèvies.
Així mateix, tal com s’ha esmentat prèviament, disposem d’una visió global del rendiment de tots els recursos de la màquina. Els indicadors principals són:
CPU: Reflecteix el volum de treball que està processant la unitat central. Si el percentatge d’ús es manté constantment al màxim, el sistema perdrà fluïdesa en no poder gestionar totes les tasques de manera simultània.
Memòria RAM: Representa l’entorn on s’executen les aplicacions actives. En cas d’esgotar-se la memòria física, Ubuntu utilitzarà l’espai d’intercanvi (Swap) al disc dur; aquest recurs d’emergència provoca una caiguda dràstica en el rendiment general de l’equip.
Xarxa: Monitoritza el flux de dades (entrada i sortida) del dispositiu, a més de supervisar l’estat de les connexions vigents i els ports que romanen oberts.
Emmagatzematge (Disc): Supervisa tant l’ocupació de l’espai disponible com la taxa de transferència en les operacions de lectura i escriptura. Una activitat excessiva del disc pot generar colls d’ampolla que afectin la velocitat del sistema.
Per consultar l’historial d’esdeveniments, visualitzarem el contingut de l’arxiu syslog mitjançant la comanda cat, cosa que ens permetrà revisar tots els registres del sistema.
En aquest directori podem presonalitzar la rotació dels logs.
Tenim la possibilitat d’editar aquest fitxer per configurar i ajustar els paràmetres de rotació dels registres segons les nostres necessitats.
Aquest fitxer ens indica la ruta de la configuració per defecte dels registres; a continuació, ens hi desplaçarem per realitzar les modificacions oportunes.
En primer lloc, realitzarem un test per analitzar l’impacte d’una notificació de correu i identificar en quins fitxers de registre queda reflectida. Mitjançant una simulació, verificarem si l’enviament genera una entrada immediata al syslog i si, posteriorment, es registra a l’arxiu mail.log. Per fer-ho, utilitzarem dues terminals: una per enviar el missatge i l’altra per monitorar el syslog en temps real.
Realitzarem una segona prova modificant la configuració del servei de correu. L’objectiu és restringir el fitxer mail.log perquè només enregistri els missatges de nivell error, descartant tant els nivells inferiors com els superiors. Cal recordar que, si utilitzéssim el comodí *, el sistema tornaria a desar tots els registres sense distinció.
Quan el modifiquem, hem de fer un restart al servei.
En repetir la prova anterior, observem que el registre no s’emmagatzema al fitxer mail.log. Això es deu al fet que la notificació enviada té una prioritat de tipus notice, la qual queda exclosa pel filtre que hem configurat exclusivament per a nivells err.
Finalment, si substituïm la prioritat mail.notice per mail.err, comprovarem que el registre s’emmagatzema correctament a l’arxiu de logs, ja que ara sí que coincideix amb el filtre establert.
Procedirem a modificar novament el filtratge dels registres de correu, aquest cop eliminant el signe =. Amb aquest canvi, el sistema emmagatzemarà no només les entrades de tipus err, sinó també totes les que tinguin una prioritat superior.
Reiniciem el servei i seguim.
Per validar aquest funcionament, canviarem el nivell d’alerta a crit (criticitat superior) i comprovarem que el sistema el registra correctament al fitxer de logs.
És possible definir una ruta personalitzada per emmagatzemar els registres que considerem més rellevants. En aquest cas, configurarem el sistema per capturar totes les entrades de tipus crit, hi indicarem el directori de destinació desitjat i, finalment, reiniciarem el servei per aplicar els canvis.
En enviar una notificació de tipus cron.crit, observem que s’ha generat automàticament un nou fitxer anomenat mireia.log. Aquesta és la ruta específica que havíem definit en el pas de configuració anterior.
Amb aquesta comanda podem veure tots els logs de tipus crit.
Depenent dels paràmetres que hi afegim, podem filtrar les cerques per acotar els resultats. En aquest cas, ens centrarem a consultar els registres de tipus mail que hem generat anteriorment.
Per a aquesta pràctica, configurarem un entorn amb dues màquines Ubuntu: un client encarregat d’enviar els seus registres a la xarxa (mentre els conserva localment) i un servidor que actuarà com a receptor centralitzat de tota la informació.
En primer lloc, a la màquina servidor (l’encarregada de rebre i emmagatzemar els registres), procedirem a configurar la redirecció. Crearem un nou fitxer de configuració per desviar tots els logs remots cap a una carpeta específica, la qual generarem en aquest mateix pas.
Dins del fitxer de nova creació, hem d’afegir les línies següents per habilitar la recepció de registres mitjançant els protocols UDP i/o TCP.
Finalment, permitim el pas de tcp i udp al firewall.
Un cop completats aquests passos de configuració, hem de reiniciar el servei per tal que el sistema apliqui i activi els nous paràmetres.
Dins d’un nou fitxer anomenat 90-forward.conf, hi afegirem l’adreça IP del servidor per indicar cap a on s’han de reenviar els registres.
Fem un restart de rsyslog.
Un cop configurat el reenviaments, executarem un logger des del client per generar un missatge de prova i verificar que arriba correctament al servidor.
Podem comprovar que s’han generat diversos fitxers dins del directori remote. Entre ells, trobem la carpeta corresponent al ClientSP5, confirmant que el servidor ha organitzat correctament els registres rebuts per cada node.
Si accedim al directori que s’acaba de crear, podrem localitzar el fitxer de registre i, un cop el comprovem, visualitzarem el log de prova que hem enviat anteriorment des del client.
Implementar un servidor d’actualitzacions centralitzat en un entorn amb múltiples nodes Ubuntu és fonamental per garantir l’eficiència operativa:
Optimització de l’ample de banda: Les actualitzacions es descarreguen un sol cop des de la xarxa externa. Els 50 equips de la infraestructura les obtenen directament del servidor local, reduint dràsticament el trànsit d’Internet.
Gestió del cicle de vida i control de riscos: Permet establir un entorn de proves amb equips “pilot” per validar els pedaços abans del desplegament massiu, minimitzant l’impacte d’actualitzacions inestables.
Monitoratge centralitzat de la seguretat: Facilita la supervisió de l’estat de cada node, identificant quins equips requereixen accions urgents o reinicis pendents.
Suport per a entorns aïllats: És la solució indispensable per mantenir al dia servidors crítics que no disposen de sortida directa a Internet per motius de seguretat.
Instalem apache i apt-mirror al servidor.
Accedirem al fitxer mirror.list i comentarem totes les línies per defecte per evitar descarregues innecessàries. A continuació, hi afegirem exclusivament el repositori o el paquet específic que volem instal·lar i mantenir sincronitzat.
Un cop configurat el fitxer, executarem la comanda apt-mirror per començar a descarregar i sincronitzar el repositori del paquet que hem definit prèviament.
Un cop finalitzada la descàrrega, comprovarem que s’ha instal·lat correctament i enllaçarem el contingut a l’Apache per fer-lo accessible a través de la xarxa.
A la màquina client, accedirem al fitxer sources.list per afegir-hi el nou repositori. En lloc d’apuntar als servidors oficials d’Ubuntu, utilitzarem l’adreça de l’enllaç simbòlic que hem creat prèviament al servidor local.
Aquest pas és indispensable abans d’instal·lar el paquet, ja que primer cal signar-lo (o importar-ne la clau de signatura) perquè el sistema el reconegui com a font de confiança.
Ara, en executar un apt update al client, podrem observar com el sistema agafarà un dels repositoris directament de la màquina servidor en lloc de buscar-lo a Internet.
Un cop verificat el repositori, procedirem a instal·lar el paquet desitjat; podrem comprovar que la descàrrega es realitza directament des del nostre servidor local.
He triat l’aplicació AnyDesk perquè és una de les que consumeix menys recursos, la qual cosa en facilita una instal·lació ràpida. A continuació, procedirem a afegir el seu repositori al servidor.
Fem un apt-mirror i veem que descarrega ja el paquet.
Enviem el paquet a apache.
A la màquina client, accedirem al fitxer sources.list per afegir-hi el nou repositori. En lloc d’apuntar als servidors oficials, utilitzarem l’adreça de l’enllaç simbòlic que hem creat prèviament al servidor local.
Aquest pas és indispensable abans d’instal·lar el paquet, ja que primer cal signar el repositori (o importar-ne la clau de confiança) perquè el sistema en validi l’autenticitat.
Ara, en executar un apt update, veiem que el client s’ha connectat correctament al servidor local per agafar la llista de paquets del repositori que hem configurat.
Finalment, ja podem procedir a instal·lar el paquet i confirmar que el sistema el descarrega directament des del nostre servidor local.
Un cop finalitzada la instal·lació, l’aplicació ja està operativa i ja la podem fer servir amb total normalitat a la màquina client.