StatsN é um cliente Stastd de desempenho moderno para dotnet core. StatsN oferece suporte a TCP e UDP, embora o UDP seja recomendado. Em grande parte inspirado no cliente statsd-csharp e no cliente statsd.net. Ambos os projetos são incríveis na minha opinião, mas não são exatamente o que eu estava procurando.
Eu escrevi este cliente porque achei a estática de teste de unidade menos divertida e cansei de esperar que os recursos fossem publicados. Ou suporte para recursos que o statsd na verdade não suporta.
Este cliente tenta ajudar na testabilidade usando interfaces, na observabilidade, permitindo que você registre funções para escutar exceções e registros que ocorrem dentro do cliente, e na escalabilidade, fazendo com que o código tenha um bom desempenho.
Install-Package StatsN
Resumindo, a API é fácil. Você pode obter um novo IStatsd de algumas maneiras diferentes e, em seguida, registrar métricas com uma implementação do IStatsd. Aqui estão alguns exemplos.
Observe que você desejará armazenar seu IStatsd como um singleton (provavelmente dentro de um contêiner DI). Este tipo persiste em uma conexão TCP ou UDP. As funções do cliente são thread-safe.
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 ) ;
Como a maioria dos clientes statsd, este cliente evita lançar exceções a todo custo . Quaisquer erros/exceções criados serão registrados como mensagens Systems.Diagnostics.Trace.
Você pode passar lambda para a classe StatsdOptions
para receber exceções e mensagens de log, em vez de obtê-las por meio do sistema Trace.
var opt = new StatsdOptions
{
OnExceptionGenerated = ( exception ) => { /* handle exception */ } ,
OnLogEventGenerated = ( log ) => { /* handle log msg */ }
} ;
var stats = Statsd . New ( opt ) ;
ou
var stats = Statsd . New ( a => a . OnExceptionGenerated = ( exception ) => { /* handle exception */ } ) ;
Ao definir a propriedade BufferMetrics
no objeto de opções como true, as métricas serão armazenadas em buffer, enviando menos pacotes. O tamanho do buffer é padronizado como 512, que é documentado pelo statsd. Você pode alterar seu tamanho usando a propriedade BufferSize de StastdOptions
. Isso usa uma fila simultânea para enfileirar as métricas e um BackgroundWorker
para extrair as métricas da fila e enviá-las agregadas.
var opt = new StatsdOptions ( ) {
BufferMetrics = true ,
BufferSize = 512
} ;
Por padrão, as diversas funções métricas de registro em log retornam Tarefas. Você não precisa esperar por eles. Se você esperar por eles e tiver as métricas armazenadas em buffer desativadas, você retornará depois que os bytes forem adicionados ao fluxo da rede. Se você aguardar e as métricas em buffer estiverem ativadas, sua espera retornará quando sua métrica for adicionada à fila de métricas a serem enviadas.
Embora este projeto tenha como alvo o dotnet 4.0, os testes de unidade não são executados no 4.0. O suporte é limitado (novos recursos podem não chegar ao dotnet 4.S), mas os bugs serão corrigidos.
Se você planeja brincar com o código, baixe e instale o .NET Core SDK.