Monitoramento / Metricas

49 views
Skip to first unread message

Isaias Barroso

unread,
Aug 17, 2015, 11:51:42 AM8/17/15
to scala-br
Olá Pessoal,

O que vocês estão utilizando para monitorar suas aplicações e capturar métricas?
Vou começar instrumentar minha aplicação para obter algumas métricas bem específicar e utilizar alguma ferramenta para ter uma visão geral, até o momento estou pensando em utilizar o http://kamon.io, alguém já usou o Kamon, alguma sugestão? O Stack da minha aplicação é Play 2.3 e Akka.

[]'s


Rodolfo Ferreira

unread,
Aug 17, 2015, 12:41:11 PM8/17/15
to scal...@googlegroups.com
Olá Isaias

Aqui na SoundCloud usamos uma solução própria porém open-source: http://prometheus.io/

Dá uma olhada, vem junto com uma aplicação visual para criar um dashboard: http://prometheus.io/docs/visualization/promdash/

Além disso, como ele também é um histórico de timeseries, você pode fazer consultas mais complexas com uma DSL para agregar dados e estudar tendências, peak time, correlacionar eventos, etc. Vem também com client libraries para algumas outras linguagens: http://prometheus.io/docs/instrumenting/clientlibs/

Porém o Kamon também é interessante, depois conte o que você achou!

[]s


Rodolfo Ferreira
Backend Engineer

--

---
Você recebeu essa mensagem porque está inscrito no grupo "scala-br" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para scala-br+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

Isaias Barroso

unread,
Aug 17, 2015, 3:15:26 PM8/17/15
to scala-br
Olá Rodrigo,

Muito legal o Prometheus, vou avaliar com certeza. Achei muito interessante a parte dos alertas.
Aproveitando, dei uma passada rápida (desculpa se não percebi algo) nas melhores práticas para ver se encontrava algo em relação a instrumentar códigos que executam em threads diferentes:

// Codigo Ludico
def processaAlgo = {
  for {
     res1 <- processaAlgoNoBanco // Thread Diferente
     res2 <- processaAlgoEmUmWSExterno // Thread Diferente
  } yield (res1, res2)
  ...
}

Eu poderia instrumentar o processaAlgo para obter o tempo total e se executou corretamente para monitoramento no Prometheus e ainda instrumentar o processaAlgoNoBanco e processaAlgoEmUmWSExterno, você saberia se tem algum recurso no Prometheus para que eu posso relacionar a execução do processaAlgoNoBanco e processaAlgoEmUmWSExterno com o processaAlgo? O Kamon utiliza o conceito de TraceContext http://kamon.io/core/tracing/threading-model-considerations/ ou atualmente para vocês não há essa necessidade de conhecer o fluxo completo de forma atômica?

A minha ideia com essa rastreabilidade seria usar os  Alertas (gostei demais) de forma onde eu pudesse colocar o caminho completo do evento. Por exemplo:

processaAlgoNoBanco demorou mais de 100ms para executar quando chamado a partir da função X, mas quando chamada a partir da função Y o comportamento demora apenas 10ms a partir dai consigo identificar alguns padrões.

Não sei se ficou muito claro, qualquer coisa tento explicar melhor.

[]'s

Isaias Barroso

unread,
Aug 18, 2015, 5:08:30 AM8/18/15
to scala-br
Olá Rodolfo, desculpe o nome errado no email anterior.

[]'s

Rodrigo Côrtes

unread,
Aug 18, 2015, 10:41:43 AM8/18/15
to scal...@googlegroups.com
Estou experimentando o New Relic: http://newrelic.com/

Em 18 de agosto de 2015 06:08, Isaias Barroso <isaias....@gmail.com> escreveu:
Olá Rodolfo,  desculpe o nome errado no email anterior.

[]'s

--

---
Você está recebendo esta mensagem porque se inscreveu no grupo "scala-br" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para scala-br+u...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/d/optout.

Natanael Pantoja

unread,
Aug 18, 2015, 10:47:28 AM8/18/15
to scal...@googlegroups.com
Temos ainda 



Atenciosamente,

--

---
Você recebeu essa mensagem porque está inscrito no grupo "scala-br" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para scala-br+u...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

Isaias Barroso

unread,
Aug 18, 2015, 1:05:51 PM8/18/15
to scala-br
Olá Rodrigo e Natanael,

Cheguei a utilizar NewRelic para monitorar algumas aplicações, caso eu venha a utilizar o Kamon, um dos backends suportados é o NewRelic.

No caso do Librato, uma possibilidade que estou avaliando seria utilizar o http://metrics.dropwizard.io. Estou mais inclinado a utilizar algo que me dê mais flexibilidade na escolha da ferramenta de visualização, ou no caso do Prometheus que é open source e posso adequar as minhas necessidades.

[]'s

Rodolfo Ferreira

unread,
Aug 18, 2015, 4:56:08 PM8/18/15
to scal...@googlegroups.com
Olá Isaias

O uso que você está descrevendo é mais próximo de event logging, sai um pouco do foco do Prometheus, que foca em monitoramento. Se você precisa fazer de benchmark mais profundo, talvez para você investigar a fundo você gostaria também de saber outras coisas como o resultado da operação, qual foi o input para processaAlgo, etc.

No caso do Prometheus, o ideal seria exportar métricas para execução das três funções (processaAlgo e as outras duas) e daí você consegue criar gráficos a partir do histograma por percentiles (ex: 0.99, 0.90, 0.5) e, caso necessário, disparar uma alerta caso nos últimos 10 segundos houve um aumento significante na duração da maioria das execuções (com rate() e delta() você já pode ir longe, com sum() ou avg() mais ainda para várias instâncias). Aqui fazemos isso para evitar sejamos alertados caso uma só operação demorou mais que X, pois não há realmente nada que possamos fazer.

Outro detalhe é que você precisaria de uma maneira para identificar essas execuções (um ID único) e precisará também correlacionar uma demora na execução com outra demora em outro recurso (seja um serviço ou banco de dados), pois sem isso você não conseguiria reproduzir o que causa essa demora. Daí começa a ficar mais complexo e recomendaria o Zipkin, escrito pelo pessoal do Twitter: https://blog.twitter.com/2012/distributed-systems-tracing-with-zipkin

Mas conte se conseguir fazer isso com o Kamon!

Abraço




Rodolfo Ferreira
Backend Engineer

Rodolfo Ferreira

unread,
Aug 18, 2015, 5:02:03 PM8/18/15
to scal...@googlegroups.com
Para esclarecer, o que eu disse no caso de precisar ID único e correlacionar a demora nos outros recursos estava me referindo ao caso de uso que você descreveu, não o que eu faria com o Prometheus.


Rodolfo Ferreira
Backend Engineer

Isaias Barroso

unread,
Aug 19, 2015, 6:08:34 AM8/19/15
to scala-br
Olá Rodolfo,

Isso mesmo, nesse caso precisaria de um ID para correlacionar e você tem razão, no caso do Kamon ele acaba tendo dois focos métricas e trace (TraceContext) no caso do TraceContext tem o conceito do TokenTrace que seria onde eu poderia incluir o ID que seria incluído nos logs e posteriormente analisar via Logstash/Elasticsearch, ou seja o Kamon ajudaria na propagação do ID entre diferentes contextos de execução sendo por exemplo uma aplicação Play que acaba chamando um Akka/Actor, pelo que vi ele faz a propagação automatica por todo o caminho. Vou verificar o que tem no Zipkin. Obrigado pelas dicas para não "alarmar" por apenas um único ponto fora da curva dentre várias medições.

Acredito que devo demorar mais um tempo para concluir as análise, assim que a fizer conto o resultado.

[]'s
Reply all
Reply to author
Forward
0 new messages