Dynatrace offre l'accesso gratuito alla sua piattaforma per far fronte all'emergenza

[Redazione di Hardware Upg]

Link alla notizia: https://edge9.hwupgrade.it/news/clou...nza_88094.html

I nuovi clienti potranno accedere gratuitamente alla piattaforma Dynatrace Software intelligence sino al 19 maggio e a Dynatrace Real User Monitoring for SaaS vendor experience sino al 19 settembre

Click sul link per visualizzare la notizia.

[Tasslehoff]

E di grazia per quale motivo uno dovrebbe farsi tanto male?
Per insozzarsi gli header http e restituire tante response 400 ai propri utenti?
Per pagare (una volta terminata la promozione) montagne di soldi per fare quello che banalmente Nagios e qualche altro strumento di monitoraggio fanno meglio e GRATIS?
O forse per "l'eccellente" flessibilità del monitoraggio che vendete ai vostri clienti, tanto eccellente che gli agenti possono essere scritto solo in python?
Ah no, forse sarà per la IA che tanto sbandierate con i vostri clienti, che fa tanto figo con i manager...

Ecco voi siete il perfetto esempio di quelli che un mio stimatissimo collega e amico definisce mercanti, quei mercanti che andrebbero cacciati dal tempio...

[cdimauro]

Originariamente inviato da Tasslehoff

O forse per "l'eccellente" flessibilità del monitoraggio che vendete ai vostri clienti, tanto eccellente che gli agenti possono essere scritto solo in python?

Qual sarebbe il problema con Python? Ormai da tempo viene usato anche dai sysadmin per rimpiazzare bash e perl (se esiste ancora qualcuno che lo usi ).

Mal che vada è sempre possibile eseguire facilmente comandi esterni (specialmente con le ultime versioni di Python 3), e il problema è risolto.

[Tasslehoff]

Originariamente inviato da cdimauro

Qual sarebbe il problema con Python? Ormai da tempo viene usato anche dai sysadmin per rimpiazzare bash e perl (se esiste ancora qualcuno che lo usi ).

Mal che vada è sempre possibile eseguire facilmente comandi esterni (specialmente con le ultime versioni di Python 3), e il problema è risolto.

Il problema non è python in se, ma il fatto che sia possibile usare solo quello, come scrivevo la scarsissima flessibilità di Dynatrace è uno dei motivi per cui è un pessimo prodotto per il monitoraggio e un prodotto mediocre per analisi di problem solving.

Io ho plugin di monitoraggio per Nagios fatti in qualsiasi modo, dal vbscript a java, da bash a python, addirittura ho plugin basati quasi totalmente su appositi agenti Lotuscript per monitorare specifici aspetti applicativi di database Lotus Domino.

A questo si sommano tante altre criticità di cui ho già accennato, ma tra queste la mancanza di flessibilità è una delle più grandi.
Il monitoraggio sono gli occhi e le orecchie di un sistemista, dev'essere la cosa più solida e affidabile, dev'essere KISS all'ennesima potenza.
Dynatrace è l'esatto opposto, è chiuso, proprietario, hostato da terzi (salta la connettività wan e non funziona più nulla), necessita di agenti anche per il monitoraggio di base, estremamente invasivo (vedi problematiche sugli header http), poco flessibile e, dulcis in fundo, "caro come il fuoco"

[cdimauro]

OK, chiaro e assolutamente comprensibile e condivisibile (anche se non faccio il sistemista, mi ci devo interfacciare alcune volte ).

Ma posto che un tuo cliente abbia Dynatrace e debba dargli supporto, non potresti risolvere con uno scriptino Python di qualche riga che richiami uno script esterno scritto in un altro linguaggio e lo rigiri a Dynatrace?

[Tasslehoff]

Originariamente inviato da cdimauro

OK, chiaro e assolutamente comprensibile e condivisibile (anche se non faccio il sistemista, mi ci devo interfacciare alcune volte ).

Ma posto che un tuo cliente abbia Dynatrace e debba dargli supporto, non potresti risolvere con uno scriptino Python di qualche riga che richiami uno script esterno scritto in un altro linguaggio e lo rigiri a Dynatrace?

Viceversa io non faccio lo sviluppatore (mi ci devo interfacciare alcune volte anch'io ) però solo guardando la documentazione la procedura per creare un plugin custom è a dir poco farraginosa, occorre scaricare l'sdk Dynatrace, configurare un servizio affinchè sia in ascolto in locale, sistemare json per i metadati, sviluppare il plugin, fare la build, uplodare, incrociare le dita e sperare vada.

Capisci bene che nulla di tutto questo è il "focus" di chi si occupa di monitoraggio, è una gargantuesca perdita di tempo, non si tratta di uplodare un script python e configurare un servizio di monitoraggio affinchè lo esegua, è molto più complicato.

Poi ripeto, questa è la ciliegina sulla torta, i problemi grossi sono altri imho, ma questo da l'idea di quanto sia inutilmente complicato il servizio.

Poi uno certamente si deve fare i suoi conti e valutare se tutta questa inutile complessità valga la pena e dia in cambio dei benefici.
Ebbene dalla mia esperienza i benefici sono zero, forse l'unica cosa che può apparire invitante di Dynatrace è il monitoraggio full stack che tiene traccia di tutte le dipendenze di una tale applicazione; non fa miracoli eh, non fa altro che tracciare le connessioni tcp fatte dal processo che fa girare l'applicazione (e quasi sempre genera ragnatele incomprensibili con relazioni inesistenti), a differenza delle supercazzole dei loro venditori che grondano di IA ad ogni slide non si tratta di scindere l'atomo, chiunque abbia un minimo di familiarità con find, grep e tcpdump (questi si essenziali per un sistemista) li può trovare in tempo zero.
Su altre cose sembra faccia miracoli, tipo sulle applicazioni che girano su jvm, in realtà basta attivare la jmx console e si può estrarre facilmente le stesse informazioni con tanto di grafici "sciccosi" da sbandierare ai manager.

Vabbè dai basta, credo si sarà capito che è un prodotto su cui ho leggermente "il dente avvelenato", del resto ci ha causato tanti di quei mal di testa e complicato la vita che quando è stato defenestrato abbiamo tutti stappato lo spumante

[cdimauro]

Ti capisco benissimo, perché è evidente che siamo di fronte a un accrocco.

Quando i sysadmin dell'azienda per cui lavoravo in Italia mi chiese di realizzare uno scriptino Python per controllare con nagios lo stato dei servizi che avevo sviluppato, con poche righe di codice me uscii, e il tutto funzionava benissimo (vabbé, parliamo veramente di stupidaggini: status/start/stop/restart si implementano in pochi minuti).

Se quest'altro servizio ti obbliga a usare Python, ma usando un SDK, soltanto per il monitoraggio... sarebbe come sparare a una mosca con un cannone. E non oso immagine in che modo andrebbe in produzione una roba così.