Azure Java Tomcat accedendo

Question

Sto progettando di migrare un creato in precedenza applicazioni Web Java per Azure. L'applicazione precedentemente utilizzata log4j per i registri a livello di applicazione che sono stati salvati in un file creato localmente. Il problema è che con il ruolo di Azure con più istanze devo raccogliere e aggregare questi registri e inoltre assicurarmi che siano archiviati in una memoria permanente invece del disco rigido delle macchine virtuali.

La registrazione è un componente fondamentale dell'applicazione, ma non deve rallentare il lavoro effettivo. Ho preso in considerazione più opzioni e sono curioso della best practice, la soluzione migliore considerando la sicurezza, la coerenza del registro e le prestazioni sia nello storage-time che nell'elaborazione successiva. Ecco un elenco delle opzioni:

• Utilizzo di log4j con un Appender personalizzato per memorizzare le informazioni in SQL di Azure.
• Utilizzando log4j con un costume Appender per memorizzare le informazioni in Azure tabelle di stoccaggio.
• Scrivendo un ulteriore strumento che trasferisce i dati dal disco rigido locale a uno dei depositi persistenti sopra.

C'è qualche altro metodo o ci sono soluzioni complete per questo problema per Java? Quale dei suddetti sarebbe meglio considerare i suddetti criteri?

Answer 1

Infine ho deciso di scrivere un Log4J Appender. Non avevo bisogno di raccogliere informazioni di diagnostica, il mio obiettivo principale era solo quello di raccogliere i file di registro in un modo facilmente intercambiabile. Il mio primo timore era che avrebbe rallentato l'applicazione, ma con la scrittura solo sulla memoria e solo periodicamente la scrittura dei dati di registro nelle tabelle di Azure funziona perfettamente senza fare troppe chiamate API.

Ecco i passaggi principali per la mia realizzazione:

Per prima cosa ho creato una classe di entità da memorizzare nelle tabelle Azure, chiamati LogEntity che si estende com.microsoft.windowsazure.services.table.client.TableServiceEntity.

Successivamente ho scritto l'appender che estende org.apache.log4j.AppenderSkeleton contenente uno java.util.List<LogEntity>.

Dal metodo sovrascritto protected void append(LoggingEvent event) ho solo aggiunto a questa raccolta e quindi creato un thread che svuota periodicamente questo elenco e scrive i dati nelle tabelle di Azure.

Infine ho aggiunto il nuovo Appender al file di configurazione log4j.

Answer 2

Al momento non esiste una soluzione pronta per l'uso, ma ... un appender personalizzato per Table Storage ha senso, in quanto è possibile interrogare i registri in modo simile alla diagnostica (contatori perf, ecc.) .

L'unica considerazione è se si scrivono istruzioni di registro in una quantità massiccia (come centinaia di volte al secondo). A quel ritmo, inizierai a notare i costi di transazione visualizzati sulla fattura mensile. A un centesimo per 10.000 e 100 al secondo, stai cercando circa $ 250 per istanza. Se hai più istanze, il costo sale da lì. Con SQL Azure, non avresti costi di transazione, ma avresti un costo di archiviazione più elevato.

Se si desidera adottare un approccio di trasferimento di memoria, è possibile impostare i test di diagnostica di Windows Azure per visualizzare una directory e caricare periodicamente i file sullo storage BLOB. L'unico inconveniente è che Java non ha un supporto diretto per la configurazione della diagnostica. Se stai creando il tuo progetto da Eclipse, hai solo un file di script che lancia tutto, quindi devi scrivere una piccola app .net, o usare qualcosa come AzureRunMe. Se stai creando un progetto di Visual Studio per avviare l'app Java, hai la possibilità di configurare la diagnostica senza un'app separata.

C'è un blog post da Persistent Systems che è appena stato pubblicato, per quanto riguarda l'installazione di Java e diagnostica. Aggiornerò questa risposta con un collegamento una volta che è attivo . Inoltre, dai un'occhiata a Cloud Ninja for Java, che implementa la registrazione di Tomcat (e l'analisi relativa) utilizzando un file .net esterno che imposta la diagnostica, come descritto nel post successivo.

Answer 3

Si prega di visitare il mio blog e scaricare il documento. In questo documento puoi cercare il capitolo "Tomcat Solution Diagnostics" per la soluzione di registrazione degli errori. Questo documento è stato scritto molto tempo fa, ma è possibile utilizzare questo metodo per generare qualsiasi tipo di registrazione basata su Java (log4j, sicuro) in Tomcat e visualizzare direttamente.

Capitolo 6: Tomcat Solution Diagnostics

• Registrazione degli errori
• Visualizza File di log

http://blogs.msdn.com/b/avkashchauhan/archive/2010/10/29/windows-azure-tomcat-solution-accelerator-full-solution-document.aspx

In qualsiasi scenario in cui v'è un'applicazione personalizzata cioè java.exe, php. exe, python ecc., suggerisco di creare il file di registro direttamente nella cartella "Archiviazione locale" e quindi inizializzare Diagnostica di Azure in Ruolo di lavoro (W orkerRole.cs) per esportare questi file di registro personalizzati direttamente da Azure VM nell'archivio BLOB di Azure.

Come creare log personalizzati sullo storage locale è descritto here.

Utilizzando Azure diagnostica e l'invio di log per Azure blob sarebbe più economico e robusto quindi qualsiasi altro metodo u hanno descritto.

Answer 4

Un'altra alternativa;

Non possiamo continuare a utilizzare log4j nel modo standard (come DailyRollingFileAppender), solo il file deve essere creato su un percorso UNC, su una VM (IaaS). Questa VM, avrà solo bisogno di un po 'di spazio su disco, ma non ha bisogno di avere una grande potenza di elaborazione. Quindi è possibile condividere una VM disponibile o creare una VM con la configurazione minima, preferibilmente nella stessa area e nel medesimo servizio cloud.

I file di registro accumulati si può accedere tramite RDP/FTP, ecc

In questo modo uno non incorrere in costi di transazione e costo di sviluppo di uno speciale Log4j appender ... potrebbe rivelarsi come alternativa più economica.

grazie Jeevan

PS: mi riferisco più verso, quelli di registrazione applicazione e non nei registri app-server (catalina/manager log o file .out di Weblogic)