Monitoring Mysql 5.0 Open Source

[Valeriano Manassero]

Una volta tanto, devo richiedere informazioni (spero di essermelo meritato ).

Ho un problema di difficile risoluzione e le documentazioni in merito latitano. Potrei reperirle andandomi a girare a mano i sorgenti di MySQL ma è un lavoro osceno in quanto a tempo (che non ho), inoltre, non essendo tra i miei database preferiti, non ne ho conoscenza così approfondita.

Fondamentalmente devo monitorare il numero di query effettuate in un determinato lasso di tempo suddivise per database (o utente).

La versione di MySQL è quella Open Source e non posso ricompilarla patchandola con i sorgenti Google (che aggiungono questa feature) poichè già mi ritrovo con una versione modificata che segue un suo percorso di sviluppo ed aggiornamento.

I sistemi di monitoring Enterprise hanno questa possibilità, ma non la Open Source.

La via della lettura dei log è impraticabile; i log binari contengono solo le update queries, un log di debug genera un'impatto sulle performance impossibile da reggere visto che poi me lo devo anche parsare a colpi di awk.

L'utilizzo delle variabili reperibili per STATUS sarebbero perfette, ma non sono suddivise per database.

Ho pensato di lavorare sul parametro MAX_QUERIES_PER_HOUR, ma non ho trovato modo per farmi dire dal motore quante query mancano per raggiungere il limite, di fatto posso solo limitare senza sapere quante query sono già nel counter.

Trovo assurdo che nel 2010, un motore DB così diffuso sia anche così limitato, anche per quanto riguarda la documentazione in merito che è inesistente.

Visto che non lavoro su MySQL da qualche anno, magari sto prendendo un abbaglio abominevole e qualcuno di voi ha già sperimentato una cosa simile e l'ha risolta.

Ringrazio anticipatamente chi avrà voglia di darmi una mano.

EDIT:
Dimenticavo, ho scartato anche mysql-proxy perchè il pool di macchine che devo monitorare è estremamente variabile e non posso aggiungere un ulteriore path di aggiornamento che renderebbe la manutenzione generale snella come una vacca.

[guest]

Sai che ti dico?
Dubito sia possibile farlo.
Molti contatori non sono accessibili in lettura ma solo impostabili in scrittura.

[Antonio]

Dimenticavo, ho scartato anche mysql-proxy perchè il pool di macchine che devo monitorare è estremamente variabile e non posso aggiungere un ulteriore path di aggiornamento che renderebbe la manutenzione generale snella come una vacca.

Stavo per postare poi ho letto l'edit... quindi alzo le mani .

[2busy]

Sulla falsa riga di questo dovresti riuscire a tirar fuori qualcosa monitoring + MySQL - SWiK

Edit: bugia, non per db o utente...

[Uno]

EDIT:
Dimenticavo, ho scartato anche mysql-proxy perchè il pool di macchine che devo monitorare è estremamente variabile e non posso aggiungere un ulteriore path di aggiornamento che renderebbe la manutenzione generale snella come una vacca.

Una via di mezzo sporca potrebbe essere comunque scrivere due righe di parser intermedio che prende tutto quello che passa sulla 3306 lo logga a modo tuo, ma prima nel frattempo (in modo da non imbottigliare il tutto) lo gira su un'altra porta su cui avrai messo in ascolto mysql.

[guest]

Che è appunto un proxy, che vorrebbe evitare.

[Valeriano Manassero]

Sai che ti dico?
Dubito sia possibile farlo.
Molti contatori non sono accessibili in lettura ma solo impostabili in scrittura.

Per l'appunto. Queste limitazioni mi danno molto l'idea di cose volute proprio per spingere l'Enterprise. I contatori sono già in essere (la patch Google non fa altro che cambiare dei flag), ma la giocano sul fatto che difficilmente si esce da un prodotto pacchettizzato dalla distribuzione per questioni di comodità.

Una via di mezzo sporca potrebbe essere comunque scrivere due righe di parser intermedio che prende tutto quello che passa sulla 3306 lo logga a modo tuo, ma prima nel frattempo (in modo da non imbottigliare il tutto) lo gira su un'altra porta su cui avrai messo in ascolto mysql.

A sto punto mi do a mysql-proxy se proprio devo, il problema è che devo interagire in un modo completamente differente rispetto all'analisi iniziale e prevedere un ulteriore variabile nell'update di tutti i nodi che saranno monitorati in questo modo, il che cambierà i costi di sviluppo (e manutenzione), zio cane, vedrò cosa dice il cliente (che tanto legge questo forum e lo saprà prima che io riesca a beccarlo online e verrà a tirarmi le orecchie ).

Grazie a tutti per i suggerimenti, torno in letargo

[guest]

Per l'appunto. Queste limitazioni mi danno molto l'idea di cose volute proprio per spingere l'Enterprise. I contatori sono già in essere (la patch Google non fa altro che cambiare dei flag), ma la giocano sul fatto che difficilmente si esce da un prodotto pacchettizzato dalla distribuzione per questioni di comodità.

Già... Concordo.

A sto punto mi do a mysql-proxy se proprio devo, il problema è che devo interagire in un modo completamente differente rispetto all'analisi iniziale e prevedere un ulteriore variabile nell'update di tutti i nodi che saranno monitorati in questo modo, il che cambierà i costi di sviluppo (e manutenzione), zio cane, vedrò cosa dice il cliente (che tanto legge questo forum e lo saprà prima che io riesca a beccarlo online e verrà a tirarmi le orecchie ).

Poi mi dirai come diavolo si configura mysql-proxy.
Non sono MAI (e dico MAI) riuscito a farlo funzionare e mi servirebbe per bilanciare due nodi in HA.

chi è il cliente che legge il forum? E sopratutto, come fai ad essere nipote di un cane?

[Valeriano Manassero]

Poi mi dirai come diavolo si configura mysql-proxy.
Non sono MAI (e dico MAI) riuscito a farlo funzionare e mi servirebbe per bilanciare due nodi in HA.

Pagando ti mando un bel doc

chi è il cliente che legge il forum?

Non posso dare questa info, NDA in corso, se vuole interverrà lui.

E sopratutto, come fai ad essere nipote di un cane?

Meglio che io sia nipote di un cane piuttosto che riportare letteralmente l'epiteto che sto usando da giorni, fidati

[Uno]

Che è appunto un proxy

Ma dai... io pensavo fosse un turboreattore

.

A sto punto mi do a mysql-proxy se proprio devo, il problema è che devo interagire in un modo completamente differente rispetto all'analisi iniziale e prevedere un ulteriore variabile nell'update di tutti i nodi che saranno monitorati in questo modo, il che cambierà i costi di sviluppo (e manutenzione), zio cane, vedrò cosa dice il cliente (che tanto legge questo forum e lo saprà prima che io riesca a beccarlo online e verrà a tirarmi le orecchie ).

Sopra dicevi che volevi evitare mysql-proxy per l'eterogeneità dei nodi etc.. inoltre mysql-proxy fa molte altre cose rispetto a quello che ti occorre ed è comunque un parser intermedio (se fosse stato direttamente dentro mysql forse, e dico forse, qualcosa poteva cambiare).

Altrimenti puoi solo abilitare i log lunghi, io non sono così sicuro che aumenti il carico più di un proxy, per non dire che non lo credo proprio... non c'è altra via di uscita.
In ogni caso se le esigenze sono quelle e non è per capriccio se serve occorre aggiungere risorse.

[Antonio]

Poi mi dirai come diavolo si configura mysql-proxy.
Non sono MAI (e dico MAI) riuscito a farlo funzionare e mi servirebbe per bilanciare due nodi in HA.

Ti ci sei impegnato molto per riuscire a non farlo andare eh?
Mi è capitato di usarlo un paio di volte (anche con un paio di script lua fatti da me per monitorare le query eseguite ed avere stats più approfondite) e faceva il suo dovere

Al più erano i mysql di backend che facevano venire i mal di pancia con la replica

[Valeriano Manassero]

Sopra dicevi che volevi evitare mysql-proxy per l'eterogeneità dei nodi etc.. inoltre mysql-proxy fa molte altre cose rispetto a quello che ti occorre ed è comunque un parser intermedio (se fosse stato direttamente dentro mysql forse, e dico forse, qualcosa poteva cambiare).

Altrimenti puoi solo abilitare i log lunghi, io non sono così sicuro che aumenti il carico più di un proxy, per non dire che non lo credo proprio... non c'è altra via di uscita.
In ogni caso se le esigenze sono quelle e non è per capriccio se serve occorre aggiungere risorse.

No, non ci siamo capiti. Abilitare i log di mysql (che non sono configurabili), mi crea file enormi in pochi minuti e poi devo parsare come un matto quando, di fatto io avrei bisogno di molte meno informazioni (database o user, timestamp della query, tipo di query).
Anche AWK, quando le formule di parsing sono complesse non scherza ad uso CPU, quindi andrei ad impattare CPU ed I/O in modo pesante. A sto punto mysql-proxy è un male minore perchè mi permette di loggare solo cosa mi serve e solo in una certa forma. Risparmio un bel po' di I/O e successivamente awk ci mette un attimo a tirare dentro i dati facendomi risparmiare CPU.

Il fatto che non volessi installarlo era per mantenere snelle le procedure di installazione e manutenzione, ma a questo punto non ho alternative.

[Uno]

No, non ci siamo capiti. Abilitare i log di mysql (che non sono configurabili), mi crea file enormi in pochi minuti e poi devo parsare come un matto quando, di fatto io avrei bisogno di molte meno informazioni (database o user, timestamp della query, tipo di query).

Scusa, cosa avresti in più con i log lunghi?
Solo le query vere e proprie se non sbaglio, tra l'altro il log è sequenziale riga per riga e marcato dai cancelletti
(esempio preso in rete)

# Time: 040301 18:38:28
  # User@Host: pippo[pippo] @ localhost []
  USE dbProva;
  UPDATE Download SET IDuser=149, Descrizione="Inserimento automatico dati ", Updated="04-2-20" WHERE IDDown=7;
  # Time: 040301 18:50:59
  # User@Host: root[root] @ localhost []
  ALTER TABLE Download ADD vrs CHAR(10);
  # Time: 040301 19:02:13
  # User@Host: pippo[pippo] @ localhost []
  UPDATE Download SET IDuser=149, Descrizione="Aggiornamento database", Updated="04-2-28", vrs="1.0.5" WHERE IDDown=8;
  # Time: 040301 19:02:43
  # User@Host: rt[rt] @ localhost []
  DELETE FROM Download WHERE IDDown=7;

Quindi anche le regex possono essere snelle e veloci, con un log rotate veloce ed un pò di spazio disco puoi far lavorare di più la gestione dei log in orari mosci, cosa che con il proxy non puoi fare.

Però se hai già la tua idea.....




allora che A@@O chiedi a fare?
(sto scherzando, fai come ti pare meglio)

[Valeriano Manassero]

Scusa, cosa avresti in più con i log lunghi?
Solo le query vere e proprie se non sbaglio, tra l'altro il log è sequenziale riga per riga e marcato dai cancelletti

Essendo che il log (come hai riportato) mi infila tutta la query ed essendo che, già di suo mysql è usato in maniera intensiva, in pochissimi minuti, avrei già dei log che supererebbero abbondantemente il centinaio di MB. Essendo che già di suo MySQL ha un uso I/O mica da ridere, quella sarebbe la mazzata definitiva, va bene il logrotate, ma non posso farlo intervenire ogni 2 minuti.

Quindi anche le regex possono essere snelle e veloci, con un log rotate veloce ed un pò di spazio disco puoi far lavorare di più la gestione dei log in orari mosci, cosa che con il proxy non puoi fare.

No anche qui, il processo di monitoring deve essere costante e "quasi" in realtime, in effetti mi ero scordato di scriverlo, non posso permettermi di frullare i log solo quando mi va.

allora che A@@O chiedi a fare?
(sto scherzando, fai come ti pare meglio)

In realtà, mi chiedevo se ci fosse un approccio che proprio non avevo valutato. Essendo che non c'è, si va per l'approccio "meno peggio". Non che la cosa mi faccia piacere, ma ci sono limiti evidenti su questo DB engine ed aggirarli non è uno sport che mi piace fare, ma se tra tutti qui, non abbiamo visto alternative, sono abbastanza certo che proprio non ci sono.

[Uno]

No anche qui, il processo di monitoring deve essere costante e "quasi" in realtime, in effetti mi ero scordato di scriverlo, non posso permettermi di frullare i log solo quando mi va.

Se lo dicevi prima.....