<div dir="ltr">Don't forget <a href="http://zipkin.io/">http://zipkin.io/</a> . It's awesome. :)<div><br></div><div>Cheers,</div><div>Ben</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 16 Nov 2017 at 08:46 Alex <<a href="mailto:alex@centromere.net">alex@centromere.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 15 Nov 2017 15:30:37 +0100<br>
MarLinn <<a href="mailto:monkleyon@gmail.com" target="_blank">monkleyon@gmail.com</a>> wrote:<br>
<br>
> Hi Alex,<br>
><br>
> sounds ambitious. But you might be able to reduce the scope massively<br>
> by relying on existing tools.<br>
><br>
<br>
Yes! I do not wish to reinvent the wheel.<br>
<br>
> Examples:<br>
><br>
>   *<br>
><br>
>     Let something like Nagios do the monitoring. I know there's tools<br>
> to control Nagios from Haskell. What I don't know is how up-to-date<br>
>     they are, and I haven't seen something that reports internal<br>
>     performance data of a Haskell app to Nagios, but that should be<br>
>     simple if necessary.<br>
><br>
<br>
I don't think Nagios is a good fit because I want to do more than<br>
monitor the performance of the interpreter. I want to rely on that<br>
performance data so that I can use resources more effectively. For<br>
example, I want to know what the load average of a particular node is,<br>
and then I want to rely on historical performance data of the DSL<br>
primitives to determine if the next instruction to be executed should<br>
be scheduled to run on that node or a different one.<br>
<br>
>   *<br>
><br>
>     Let something like Cassandra handle both the heaviest parts of<br>
>     messaging between your node controllers and the storage of their<br>
>     config data. If you base your WUI on top of the DB, you can<br>
> separate it from the controllers as well.<br>
><br>
>   *<br>
><br>
>     Coordination of resources is a variant of scheduling, which is a<br>
>     ""solved"" problem. So there should be libraries you can use.<br>
><br>
<br>
For cluster coordination/configuration I was thinking of using Consul.<br>
<br>
>   *<br>
><br>
>     Logging has been worked on by many a commercial Haskeller. My<br>
> guess is that filtering is just a matter of looking at one of the<br>
>     libraries from the right angle.<br>
><br>
<br>
I intend to leverage existing libraries where possible. I want to<br>
create an environment in which the commercial Haskeller never has to<br>
choose and wire in a logging library. The decision is already made by<br>
the framework. They just need to insert logging statements where<br>
appropriate.<br>
<br>
> Or just use Kubernetes. Whichever is easier. ;)<br>
><br>
<br>
Kubernetes is a great tool, but it doesn't do what I envision.<br>
<br>
--<br>
Alex<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>