StatsN

StatistikenN

StatsN ist ein moderner Performance-First-Stastd-Client für Dotnet Core. StatsN unterstützt sowohl TCP als auch UDP, obwohl UDP empfohlen wird. Weitgehend inspiriert vom statsd-csharp-client und dem statsd.net-Client. Beide Projekte sind meiner Meinung nach großartig, nur nicht genau das, was ich gesucht habe.

Ich habe diesen Client geschrieben, weil ich die Statik von Unit-Tests weniger unterhaltsam fand und es satt hatte, auf die Veröffentlichung von Features zu warten. Oder Unterstützung für Funktionen, die statsd eigentlich nicht unterstützt.

Dieser Client versucht, die Testbarkeit durch die Verwendung von Schnittstellen zu verbessern, die Beobachtbarkeit, indem er es Ihnen ermöglicht, Funktionen zu registrieren, um auf Ausnahmen zu warten, und die Protokollierung, die innerhalb des Clients erfolgt, und die Skalierbarkeit, indem er dafür sorgt, dass der Code wirklich gut funktioniert.

Erste Schritte

 Install-Package StatsN

Kurz gesagt, die API ist einfach. Sie können auf verschiedene Arten ein neues IStatsd erhalten und anschließend Metriken mit einer IStatsd-Implementierung protokollieren. Hier sind einige Beispiele.

Beachten Sie, dass Sie Ihr IStatsd als Singleton speichern möchten (höchstwahrscheinlich in einem DI-Container). Dieser Typ behält eine TCP- oder UDP-Verbindung bei. Die Funktionen des Clients sind Thread-sicher.

 IStatsd statsd = Statsd . New < Udp > ( a => a . HostOrIp = "10.22.2.1" , Port = 8125 , Prefix = "MyMicroserviceName" ) ;
IStatsd statsd = Statsd . New < Tcp > ( a => a . HostOrIp = "10.22.2.1" ) ; //use tcp
IStatsd statsd = Statsd . New < NullChannel > ( a => a . HostOrIp = "10.22.2.1" , Port = 8125 ) ; //pipes your metrics to nowhere...which can scale infinately btw
IStatsd statsd = Statsd . New ( a => a . HostOrIp = "10.22.2.1" ) ; //defaults to udp
IStatsd statsd = Statsd . New ( new StatsdOptions ( ) { HostOrIp = "127.0.0.1" } ) ; //defaults to udp
IStatsd statsd = new Stastd ( new StatsdOptions ( ) { HostOrIp = "127.0.0.1" } ) ;  //defaults to udp
IStatsd statsd = new Stastd ( new StatsdOptions ( ) { HostOrIp = "127.0.0.1" } , new Tcp ( ) ) ; //pass a new udp client. You could in theory make your own transport if you inherit from BaseCommunicationProvider


statsd . CountAsync ( "myapp.counterstat" ) ; //default to 1 aka increment
statsd . CountAsync ( "myapp.counterstat" , 6 ) ;
statsd . CountAsync ( "myapp.counterstat" , - 6 ) ;
statsd . TimerAsync ( "myapp.timeMyFunction" , ( ) => {
 //code to instrument
} ) ;
statsd . TimerAsync ( "myapp.timeData" , 400 ) ; //400ms
statsd . GaugeAsync ( "autotest.gaugeyo" , 422 ) ;
statsd . GaugeDeltaAsync ( "autotest.gaugeyo" , - 10 ) ;
statsd . SetAsync ( "autotest.setyo" , 888 ) ; 

Protokollierung

Wie die meisten Statsd-Clients vermeidet dieser Client um jeden Preis das Auslösen von Ausnahmen . Alle erstellten Fehler/Ausnahmen werden als Systems.Diagnostics.Trace-Meldungen protokolliert.

Sie können Lambda an die StatsdOptions -Klasse übergeben, um Ausnahmen und Protokollmeldungen weiterzugeben, anstatt sie über das Trace-System abzurufen.

            var opt = new StatsdOptions
            {
                OnExceptionGenerated = ( exception ) => { /* handle exception */ } ,
				OnLogEventGenerated = ( log ) => { /* handle log msg */ }
            } ;
			var stats = Statsd . New ( opt ) ;

oder

 var stats = Statsd . New ( a => a . OnExceptionGenerated = ( exception ) => { /* handle exception */ } ) ; 

Puffermetriken

Wenn Sie die BufferMetrics Eigenschaft im Optionsobjekt auf „true“ setzen, werden die Metriken gepuffert und somit weniger Pakete gesendet. Die Puffergröße beträgt standardmäßig 512, was von statsd dokumentiert wird. Sie können die Größe mithilfe der BufferSize-Eigenschaft von StastdOptions ändern. Dabei wird eine Concurrent Queue verwendet, um die Metriken in die Warteschlange zu stellen, und ein BackgroundWorker um Metriken aus der Warteschlange zu entfernen und sie aggregiert weiterzuleiten.

 var opt = new StatsdOptions ( ) {

    BufferMetrics = true ,
    BufferSize = 512
} ; 

Warten auf Messwerte

Standardmäßig geben die verschiedenen Protokollierungsmetrikfunktionen Aufgaben zurück. Sie müssen nicht auf diese warten. Wenn Sie auf diese warten und die gepufferten Metriken ausgeschaltet haben, kehren Sie zurück, nachdem die Bytes dem Netzwerkstream hinzugefügt wurden. Wenn Sie warten und gepufferte Metriken aktiviert sind, wird Ihr Warten zurückgegeben, sobald Ihre Metrik zur Warteschlange der zu sendenden Metriken hinzugefügt wurde.

Dotnet 4.0

Obwohl dieses Projekt auf Dotnet 4.0 abzielt, werden die Komponententests nicht in 4.0 ausgeführt. Die Unterstützung ist begrenzt (neue Funktionen werden möglicherweise nicht in Dotnet 4.S verfügbar sein), Fehler werden jedoch behoben.

Entwickler-Setup

Wenn Sie vorhaben, mit dem Code herumzuspielen, laden Sie unbedingt das .NET Core SDK herunter und installieren Sie es.