> Does Prometheus only not work in a multi-process Rails web server? Does it > work for a single process multi-threaded web server? This is an interesting > roadblock given you'd expect this to affect lots of webserver across > multiple languages out there.
Any Rails app that has multiple processes needs currently to figure out how to deliver data to the HTTP endpoint. E.g. store it in a database or something, which is not the best approach. Absolutely, it lacks quite important feature right there. It stems from the design which is pull-based. > Yes, standard practice is to think about one container per pod (in a > Kubernetes environment). However, there are patterns for things like log > aggregation and monitoring such as doing a sidecar container that ensures > co-location. The part I don't entirely get with sidecars is if I scale the > pod to say 5, I get 5 web applications and 5 monitoring containers and that > seems odd. Which I why I think the tendency is towards models where your > single process/application is the end point for your metrics to be scrapped > by an outside agent or services. > > I agree you want the collector to be separate, but if your web application > is down what value would a monitoring endpoint being alive provide? The > application would be down, thus no metrics to serve up. The other exporters > such as the one exporting metrics about the underlying system would be > responsible for giving system metrics. In the Kube world, this is handled by > readiness and liveness probes for Kubenernetes to re-spin the container if > it stops responding. In container world, monitoring agents are running on hosts, not in containers themselves. And collector agents can be 1:1 or 1:N (e.g. for each container host). I am not sure I follow you here. Why you don't see added value again? Monitoring agent without any apps connected is as useful as ssh deamon waiting for connections. Let me put it this way - push approach seems to be more appropriate for multi process Ruby application than pull approach. That's what we are discussing here, unless there are better protocols/agents I am not aware of. Honestly, pull approach via simple HTTP REST API seems cleaner but it is just not good fit and also it creates other unnecessary responsibility on the app itself. You are working on containerizing Foreman, so it is also actually against this effort. Anyway, let me throw another integration. Collectd has an agent (or plugin) that opens a local socket which can be used to receive data from other applications. I wrote Ruby client library the other day (https://github.com/lzap/collectd-uxsock) but I believe this make no difference than statsd - you still need a local process to gather the data. -- Later, Lukas @lzap Zapletal -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
