Ricercare problemi non è una cosa semplice, indipendentemente dall’ambiente in cui ci si trova. Oggi i programmatori accorti si sono resi conto che è necessario scrivere dei file di log per poter manifestare lo stato di errore, ma dal file a capirci qualcosa di acqua sotto i ponti ce ne passa. Specie se poi i file di log sono un ammasso di informazioni “accodate” e “relazionate” tra loro, ma che in un semplice file di testo diventano incomprensibili.

IIS7 , fortunatamente ha rivisitato un pochino questo sua parte, e in aggiunta al tradizionale file di log (il cosiddetto RAW Log) ha affiancato un elegante sistema di estrapolazione da questo file, che alla fine della storia niente altro che genera un file xml un po’ più ordinato, al quale, affiancando un file .xsl (XML Stylesheet Transformation file) generato in automatico dal server, si riesce a leggere in maniera decisamente più semplice il file.

Ma come fare per abilitare questo sistema di troubleshooting? Bisogna utilizzare il Failed Requests Tracing Setting – meglio conosciuto come FREB (perché prima il servizio si chiamava Failed Requests Event Buffering). Per la sua abilitazione ci sono diversi passaggi da dover eseguire. Iniziamo da principio.

Passo 1

Assicurarsi che il servizio di Tracing di IIS7 sia attivo (lo trovate sotto Control Panel, Program and Features, Turn Windows feature on, World Wide Web Services - Health and Diagnostics – Tracing)

Passo 2

Entrare nel pannello di amministrazione di IIS7 (La management console), quindi selezionare il sito web per il quale si vuole abilitare questa funzione, e sull’immediata destra fare click sulla voce “Failed Request Tracing”. Alla finestra di popup che si presenta, cliccare in alto sulla voce Enable. Il resto delle impostazioni si possono lasciare così come sono.

Questa parte serve in sostanza per comunicare al nostro server web che deve generare i log, cioè quel file di testo dove IIS scrive tutte le pagine richieste, l’IP del richiedente, lo stato di errore (200 pagina ok, 404 pagina non trovata, 500 errore, …). Questo è lo stesso file che viene utilizzato dai software di statistica per mostrare chi si connette al nostro sito.

C'è una cosa che mi sfugge. Il perchè abbiano chiamato questa feature come Failed Request Tracing, quando in realtà analizzando il file di log, lo stesso contiene come ho già detto, tutte quante le richieste avanzate al web server, con tutti i codici.

Passo 3

Configurare le eccezioni d’errore delle quali IIS deve tener traccia. Questo lo si può fare cliccando su Failed Request Tracing Rules e seguendo il wizard che compare facendo doppio click. La prima schermata consente di selezionare il contenuto che si vuole analizzare (in base alla sua estenzione). La seconda schermata richiede quale sia l’errore che di cui si vuole tenere traccia. Si deve necessariamente specificare un errore (almeno sul mio sistema non c’è stato verso di dire li voglio tutti).

Infine, terzo e ultimo passaggio, si configura il provider (cioè chi controllare) e la tipologia di errori (verbosity) da restituire. Se tutto è ok , potrete premere ok e ritrovarvi una nuova entry dentro alla lista.

Da questo momento in poi – limitatamente all’errore 500 (perché questo è stato richiesto) – all’interno della cartella %systemdrive%\inetpub\logs\FailedReqLogFiles\ (supponendo che stiamo parlando del default web server), sarà possibile trovare una serie di cartelle denominate W3SVC? Dove al posto del ? ci sarà un numero che altro non è che l’ID assegnato dal sistema quando si è creato un sito web. L’id del default web site è 1. All’interno di questa cartella si troveranno tanti file per ogni errore generato. Essendo dei file xml, doppio cliccandoci sopra, verrà aperto Internet Explorer e, in base al file freb.xsl contenuto nella cartella (e aggiunto in automatico dal sistema qualora questo non esista) si potrà leggere un file di analisi sufficientemente dettagliato.

In merito alla leggibilità c’è poi la possibilità di scaricare un nuovo template rilasciato direttamente dal Program Manager di IIS e disponibile qui.

Per applicare il file, basta semplicemente sostituire il file freb.xsl presente nella cartella sopra menzionata con quello presente nello zip.

Per ripristinare il file originale, invece, basta cancellare il file presente nella directory. Al successivo log, se mancante, il file verrà nuovamente rigenerato dal sistema.

N.B. I passi 2 e 3 lavorano assieme. Non è possibile far generare il file xml senza abilitare i raw logs.

 La Sitemap è un semplice file xml che elenca tutte le pagine di un sito Web con lo scopo di semplificare notevolmente l’attività di scansione e indicizzazione da parte dei crawler dei motori di ricerca.
Introdotta da Google con il servizio Google Sitemaps, e poi utilizzata anche da Yahoo!, Ask.com, Microsoft Live Search permette ai webmaster di enumerare all’interno di un file XML tutti gli URI delle pagine di un determinato sito web. In questo modo anche i siti dinamici possono fornire URI corretti permettendo una indicizzazione più intelligente. Il protocollo è regolamentato dalla Attribution-ShareAlike Creative Commons License che ne ha reso possibile l’uso anche ad altri motori di ricerca. Per maggiori dettagli potete consultare la traduzione italiana delle specifiche del formato Sitemaps 0.90.

Uno dei principali problemi che esisteva ancora sulle sitemaps era la necessità della segnalazione manuale in appositi pannelli di controllo messi a disposizione dai singoli motori di ricerca. La segnalazione manuale era ovviamente un processo che sottraeva del tempo prezioso. Finalmente da ieri, 11 aprile 2007, è stata attuata la modalità di autodiscovery del file Sitemap.xml del proprio sito.
Ebbene da ieri, Ask.com, Google, Microsoft Live Search e Yahoo! hanno comunicato, nei loro rispettivi blog, il supporto per l’autodiscovery delle Sitemaps, ovvero la possibilità, da parte dei webmaster di specificare il percorso per la Sitemap del sito all’interno del file robots.txt.

Quindi, per segnalare a tutti e quattro i motori la presenza della sitemap, sarà sufficente inserire questa riga nel proprio file robots.txt:

Sitemap: http://www.miosito.com/sitemap.xml

Sul sito sitemaps.org è specificato anche un’altro metodo alternativo per la segnalazione, ovvero attraverso una richiesta HTTP del tipo

/ping?sitemap=http://www.miosito.com/sitemap.xml

che può essere lanciata sia attraverso un browser (classico link) ma anche usando degli script.

Ovviamente per tutti i motori rimane attiva la possibilità di segnalare manualmente il percorso del Sitemap, ma perché precludersi questa comoda possibilità?

Quello dei cosidetti link morti è un altro degli errori spesso sottovalutati. Se si scrivono le pagine a mano, piuttosto che si fanno delle piccole correzioni senza un editor che selezioni automaticamente e scriva la risorsa, è molto facile commettere errore di battitura e di conseguenza creare link morti.

Finanto che i link morti sono riferiti ad immagini, il problema è “quasi” trascurabile; ma quando si parla di collegamenti morti verso pagine interne o esterne al sito, inutile che vi dica quanto fastidio queste possano portare.

Al motore di ricerca fastidio certo non ne dà, ma immaginatevi una macchina a 200 km orari cui di fronte gli compare un bel muro. Risultato? Schianto totale, che tradotto per il nostro motore di ricerca, significa “fine della corsa”.
In altre parole, il motore di ricerca, non potendo più proseguire con la sua azione di crawling, si trova costretto a passare al sito o a comunque al link successivo, che - per inciso - potrebbe anche non essere il vostro.
Questo significa anche che l’indicizzazione viene interrotta prematuramente, prima ancora che tutte le pagine siano state recepite dal motore.

Un consiglio caloroso è quindi quello di controllare tutte le vostre pagine e assicurarvi che non vi siano collegamenti morti. Un buono strumento on line, lo potete trovare a questo indirizzo. Ogni tanto produce falsi positivi, ma nel complesso aiuta moltissimo.