Re: Monitoring at container level

Small plug for snap (https://github.com/intelsdi-x/snap). It's a telemetry framework with a lot of useful plugins for collecting, processing and publishing metrics. There's a go API (and soon more langs) for writing your own plugins. Plugin catalog:

[VOTE] Release Apache Mesos 1.0.0 (rc2)

Hi all, Please vote on releasing the following candidate as Apache Mesos 1.0.0. 1.0.0 includes the following: * Scheduler and Executor v1 HTTP APIs are now considered stable. * [MESOS-4791] -

Re: Monitoring at container level

Have you ever tried prometheus + Grafana? Please take a look at https://prometheus.io/docs/visualization/grafana/ to see if it helps. On Fri, Jul 8, 2016 at 5:51 AM, David Kesler wrote: > We use a combination of new relic for application level monitoring and a > custom python

Re: Setting up SSL for mesos

Inlining the environment variable fixed it! I had to use sudo to run mesos, so I either needed to inline it or use -E. *Facepalm* On the note of building mesos, is there any chance in the future that mesosphere would create a prebuilt mesos package with ssl included? It would be nice to avoid

Re: Setting up SSL for mesos

If you only set *SSL_ENABLED=true, *mesos would not start and throw error that certificate and key variables are not exported. So I assume mesos does not see SSL_ENABLED env variable in your case. Do you run mesos from the same shell as you do the variables export ? 2016-07-07 20:53 GMT+02:00

RE: Monitoring at container level

We use a combination of new relic for application level monitoring and a custom python script that scrapes a bunch of stats from the docker socket file and throws them into elastic so we can use kibana to make graphs. From: Gregory Durham [mailto:gregory.dur...@gmail.com] Sent: Thursday, July

Re: Monitoring at container level

I have been using datadog to monitor my infrastructure. The integration into service discovery has been really helpful for these environments. On Thu, Jul 7, 2016 at 1:37 PM, Steven Schlansker wrote: > We use Graphite and ran into similar problems with huge metric

Re: Monitoring at container level

We use Graphite and ran into similar problems with huge metric namespaces. We use the Singularity framework which provides both the task "request id" (name) and "instance number" (0..N) to the task. So we set our Graphite namespace to be "request-number" e.g. "myservice-3" This has the downside

Re: Monitoring at container level

I have had a good experience so far with bosun and scollector with cadvisor. Check it out at bosun.org. On Friday 8 July 2016, Pradeep Chhetri wrote: > Hi Michal, > > Do have a look at sysdig (http://www.sysdig.org). It is basically an > open-source tool which

Re: Setting up SSL for mesos

Probably not relevant. (I ran ldd on CentOS 7.) Which Ubuntu are you running? And what shell? Also, try running `make check` up until you see the libprocess tests. There are a couple of SSL tests there. (i.e. SSLTest.SSLSocket) If, for some inexplicable reason, your build is linking but not

Re: Monitoring at container level

Hi Michal, Do have a look at sysdig (http://www.sysdig.org). It is basically an open-source tool which provides container insights. Maybe your will find something helpful over there. To tackle the case of new metrics for new containers, maybe you should tag metrics by service-name instead of

Monitoring at container level

Hi, Before introducing Mesos we're using mainly Graphite / Grafana. Ideally we would like to have metrics per container as an easy way to detect if problem touches only single, subset of containers or it's global. Unfortunately using Graphite for that is far from being perfect. Having container

Re: Setting up SSL for mesos

ldd src/.libs/mesos-master | grep ssl returns: libevent_openssl-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent_openssl-2.0.so.5 libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 So I am missing the libssl3.so line. Is that another package I need to install as a prerequisite? In case it's

Re: Setting up SSL for mesos

Can you double-check if your master is linking to openssl? >From your build folder, you should get something like: ldd src/.libs/mesos-master | grep ssl libevent_openssl-2.0.so.5 => /lib64/libevent_openssl-2.0.so.5 libssl.so.10 => /lib64/libssl.so.10 libssl3.so => /lib64/libssl3.so

Re: Setting up SSL for mesos

I rebuilt from scratch with SSL support and got no errors. I only set *export SSL_ENABLED=true* and then I ran the mesos-master. No errors were thrown and I can see the web UI via HTTP. I double checked that I was running the .sh from the build folder I created. Is mesos not connecting with the

Re: Fetcher cache: caching even more while an executor is alive

Just a random thought, have you tried something like bittorrent based deployments. They are really efficient when you have to distribute big artifacts across cluster of machines. Following two projects might be helpful in achieving that: 1. http://erdgeist.org/arts/software/opentracker/ 2.

Re: Fetcher cache: caching even more while an executor is alive

I'd try the Docker image approach. We've done this in the past and used our CM tool to 'seed' all slaves by running 'docker pull foo:v1' across them all in advance, saved a lot of startup time (although we were only dealing with a Gb or so of dependencies). On 5 July 2016 at 11:23, Kota UENISHI

Support for shared resources

Hi This is a followup/update to the work that has been going on for the support for shared resources. For reference, the epic is MESOS-3421 (https://issues.apache.org/jira/browse/MESOS-3421 ). Support for shared resources involves the