Self-hosted Meteor APM with MUP

deployment
1

TL/DR: Get a stable, fully functional, HTTPS enabled Meteor APM server running in less than 30 minutes using lmachens/meteor-apm-server.

After leaving Galaxy hosting for AWS, I went through every forum post trying to find the minimum-pain method of getting APM back up and running.

I tried the NodeChef service, and it was acceptable but did not feature any alerts, and the service pricing wasn’t attractive: (as of 2/26/18) $10/month per host, no pro-rating, only 4 days of data retention.

I tried the various compose and docker setups with partial success. While they would spin up a server, they only supported HTTP, which was unacceptable. Attempting to modify or fix these solutions was a painful time sink.

I finally found lmachens/meteor-apm-server which combined all the various APM server components into one Meteor project. After fixing a few issues with proxy config, missing mongo indexes, and excessive docker logs, I finally have a stable, self-hosted APM server running an AWS t2.micro instance for under ~$10/month.

The default setup throws everything (mongo, apm-server, apm-ui, nginx proxy) on a single server and it just works. For devs with small applications, this is all that is needed, and it should not take a lot of time to get this up and running. From there it is trivial to scale out to hosted mongo if you need it, but I expect this setup will work for many.

8 Likes
2

Did you use MUP, or the Docker image?

If you did use Docker, how did you setup SSL?

3

Please also share what you did to fix the Proxy issues etc. :slight_smile:

4

I used MUP, you can see detailed instructions here.

5

Let’s talk more about this… What’s your overall process for this setup, rolling out new releases, horizontal scaling, etc? Are you using Passenger?

6

I put together a detailed post about the process of switching.

To give you a quick summary:

  • Typically I push new releases when the site isn’t being heavily used, as there is a very brief (~30 second) downtime for each server as I update (one at a time). If I need to do a zero-downtime push, I need to manually remove a server from the load balancer while being updated, but I typically don’t need to bother.

  • I’m getting great sustained and even better burst performance on AWS. I no longer need horizontal scaling, as I can handle almost 10x the amount of burst users for the same cost as on Galaxy.

  • I’m not using Passenger.

1 Like
7

Very cool. I haven’t checked in on MUP in a long time since using Galaxy once it came out. Nice to see there’s a nice community around it. I’m spending so much on Galaxy because I’ve been having to handle a lot of users by brute-force while I optimize my app and integrate redis-oplog. In addition to those optimizations I want to get off Galaxy all together eventually. It’s so overpriced.

Did you not check into https://github.com/zodern/mup-aws-beanstalk? It says it handles load balancing, rolling updates, etc. A lot of the pain points you mention when migrating to AWS from Galaxy.

Do you also host your own DB in AWS too? Or do you use a vendor?

Also, how do you subscribe to your blog? I saw no way of doing this.

8

That repo was released after I completed my AWS setup, so I haven’t tried it yet. I used mlab for Mongo, they are awesome.

I used github pages / jekyll to host my blog, it’s all static. I don’t have any subscription service set up for it though, lol.

1 Like