I’m asking in a context of using clojure to write a web application. Coming from Ruby/Rails background, I normally monitor web-request response time using tools like New Relic. But for a clojure app, it doesn’t seem enough as clojure app might spawn lots of threads which consume cpus and slow down overall system.
What’s your approach tracking those?
Do you write a custom thread management system with monitoring to control how your app spawning threads?
You can use New Relic to instrument a JVM (hence Clojure code), but there probably won’t be any defaults for measuring HTTP response times.
If you’re using Ring or something similar, you could add a middleware that measures HTTP response times and send them to a destination e.g AWS Cloudwatch. You can also use a MemoryMXBean to monitor memory usage. Finally, if you want thread management to be monitored, you can use Thread Pools such as provided by Dirigiste.
HTH!
Why should it spawn a lot of threads? the container will use a thread pool. If you spawn threads, you can use a bounded thread pool as well.
In Java land, I’d risk saying that the gold standard is Metrics https://metrics.dropwizard.io/4.0.0/ so I’d go for https://github.com/metrics-clojure/metrics-clojure
We use New Relic at World Singles Networks and it can measure HTTP request/response times, as well as time spent in the database (including what type of query/update/insert), and time spent calling external systems.
We use the embedded Jetty server (via the Ring adapter) because New Relic supports Jetty. We have worked with New Relic on getting support for http-kit but haven’t made much progress so far (we got as far as annotating web transactions and measuring response times but we weren’t really satisfied with the results).
If you have the budget, I can heartily recommend New Relic. It provides a huge amount of insight into your infrastructure as well as your back end and front end applications (we have a React.js SPA and NR is able to tell us all sorts of things about it that have really helped us tune things).
We’ve started the project by not using bounded thread pool but we are moving to this direction.
Thanks for all the answers. I’ll dig more into resources you shared.
We use a combination of Docker monitoring and Statsd+CollectD+Google’s Stackdriver.
All of our HTTP endpoints and RabbitMQ consumers are instrumented and send metrics via our own Stature component.
And as other posts mentioned: using bounded threadpools pays off in the end.
If you’re in the mood to run your own monitoring infrastructure, I can strongly recommend Riemann as a central piece. It’s like a monitoring switchboard which is configured in Clojure, so you can make arbitrarily powerful aggregation and alarm logic before forwarding events to other systems for persistence and side-effects. We use it with Grafana and InfluxDB for dashboards, and plug it into Slack and OpsGenie for alerting.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.