About chris

Author Archive | chris

About chris

Find more about me on:

Here are my most recent posts

Welcoming the Parse community

Last week, Parse announced that it was winding down its service, and it will be fully retired on January 28, 2017.  

Parse provided a great mobile backend platform for developers who don’t want to wrangle with the complexities of server-side infrastructure. By encapsulating both the database and the app server into a single cloud service, mobile app developers were able to leverage Parse to rapidly build rich mobile applications with much less effort than would be required if they had to build the server component themselves.

The good news is that even though the Parse service is shutting down, it has open sourced its underlying software so that Parse customers can still experience the power of their platform. The missing component is now the hosting, and the Parse team has done a good job of giving its customers alternatives on how to host each of the components of the Parse platform, along with tools to help customers migrate their apps.

To run a Parse app in the cloud using the open-source software there are two components that need hosting:

  1. The Parse Server, written in Node.js
  2. The database that underlies Parse, which is MongoDB

We have been working with the Parse team for some months to help ensure that Parse customers have a great option for where they host the database component of their app following the closure of the Parse service, and we welcome Parse customers to the MongoLab MongoDB-as-a-Service platform.

Using MongoLab to host the database component of your Parse app will free you from having to run and manage MongoDB yourself. We handle all of the automation around database provisioning and scaling, ensure timely backups of your database are taken each day, and provide a suite of great tools to help you manage your data. Our multi-node MongoDB clusters also offer High Availability and failover so that your app stays running even in the face of infrastructure failure, and is available whether you host your Parse app on Amazon, Azure, or Google.

In the past week, we have seen a good number of Parse customers migrating to our service. We feel we are starting have a good handle on the process and the types of speed bumps customers may face while migrating. Over the next few weeks we will be releasing a FAQ that encapsulates these learnings in order to help customers navigate the process smoothly.

In the meantime, if you have any questions or need migration help we invite you to email us at support@mongolab.com. We look forward to helping you build the future.

Help save Robomongo with your donation

We recently learned that the team behind Robomongo, a free and open source MongoDB admin GUI, are in need of funds to keep the project going. The project, which has over 3,622 stargazers on GitHub, is a valuable free tool for the MongoDB community. We know that many of you, our customers, use and love Robomongo, so let’s try and help them!

The Robomongo team is currently fundraising on Indiegogo. To help support them, we’re announcing that MongoLab will match all donations starting now for a total of up to $15,000. Donate now and help save Robomongo!

New Telemetry features – metric descriptions and alert incidents

If you are running MongoDB in production, you should have a robust uptime and historical monitoring solution for every database deployment. Uptime monitoring ensures that your application runs smoothly by tracking database stability and alerts you to take action if necessary. Historical monitoring helps you analyze and compare database and operating system metrics over time so that you can make informed decisions when tuning and scaling your database.

Telemetry, our real-time and historical monitoring tool, provides a customizable dashboard and alerting system that allows you to track key MongoDB metrics, analyze specific points in time, and configure custom alert thresholds. We’ve now made Telemetry even easier to work with by adding metric descriptions for each graph along with a list of alert incidents.

Metric descriptions in UI

Telemetry CPU graph

You may have noticed the new “?” icon located on every Telemetry chart. If you click on the icon, you can view the descriptions for each metric. For example, the CPU metric descriptions are the following:

Telemetry metrics help text

We hope these descriptions help you better understand each metric and serve as a quick reference when you are reading the charts or configuring alerts.

Telemetry alert incidents

Telemetry also allows you to create custom alerts. For example, you may want to configure an alert whenever the CPU User metric exceeds 75%. You can visit our Telemetry documentation for more information on how to configure Telemetry alerts and set up different notification channels.

If you have multiple alerts configured and your database is under duress, it is likely that there are multiple alerts are triggered at once. To help you keep track of alert incidents we have now added a new tab in Telemetry called “Alert Incidents”. You can toggle between “open” and “closed” status, where “open” events are active issues and the “closed” events are past events.

Questions or feedback?

For questions about Telemetry metrics or feedback on what you would like to see in Telemetry, please contact MongoLab support. We look forward to hearing from you!

Shared Cluster plans in AWS Oregon (us-west-2)

We are now offering Shared Cluster plans in the AWS Oregon region. You can visit the MongoLab create page if you would like to provision the plan.

Shared Cluster plans are configured with two data-bearing nodes and an arbiter. These plans are hosted on shared multi-tenanted resources but are also suitable for “production use“. If you have questions about our different plans, we have helpful documentation on each plan type. For additional help, you can also email us at support@mongolab.com.

 

MongoDB version 3.0 now GA on MongoLab

We’re excited to announce that MongoDB 3.0 is now available on all MongoLab plans. Since the release of version 3.0 was announced in March, we’ve done extensive testing to ensure that it is production-ready for MongoLab users. For those looking to upgrade or create a new MongoDB 3.0 plan, you can do so through our self-service UI. Version 3.0 offers several valuable improvements, including collection-level locking; a new, more secure user authentication mechanism (SCRAM-SHA-1); and the WiredTiger storage engine. Each of these three improvements is described in detail below.

There are two important items to note, as you consider upgrading to version 3.0:

1) A driver upgrade may be required when upgrading your database to 3.0. You can find a matrix of 3.0 compatible drivers in the MongoDB 3.0 release notes.

2) Our release of support for version 3.0 comes with the default MMAPv1 storage engine. Support for the new WiredTiger storage engine will come later, most likely with the release of MongoDB 3.2, where it is expected to become the default storage engine for MongoDB. For more information about our support for storage engines, please read the section entitled “WiredTiger storage engine” below.

Collection-level locking

The default storage engine in MongoDB 3.0 is MMAPv1, which experienced MongoDB users may recognize as the same storage engine underlying previous versions of MongoDB. Although the name has stayed the same, MongoDB now offers collection-level locking; in prior versions of MongoDB, the database-level lock was the finest-grain lock.

How will this impact you?  In versions of MongoDB prior to 3.0, database-level locking would lock the entire database any time an operation that required the write lock (e.g. insert, update, delete) was issued. With collection-level locking, a write operation on one collection will not block the database from servicing reads and writes on other collections.

The effects of collection-level locks on your database deployment will vary depending on your data model, but generally you should see performance improvements, particularly in write-heavy workloads that target more than one collection.

SCRAM-SHA-1 authentication

In MongoDB 3.0, SCRAM-SHA-1 has now replaced MONGODB-CR as the default authentication mechanism. For the security buffs, MongoDB has written an interesting blog post that speaks to the advantages of SCRAM (short for “Salted Challenge Response Authentication Mechanism”). Two notable benefits include improved security against “malicious servers,” and heightened resistance to “replay attacks.”

Depending on your driver version, you may need to upgrade your driver to a 3.0- (or SCRAM-) compatible version. If you’re unsure if your current driver version supports SCRAM, be sure to check out MongoDB’s release notes. Again, make sure you double-check your driver version before you upgrade, or your driver will start throwing errors and you will experience downtime!

WiredTiger storage engine

MongoDB 3.0 ships with two storage engines: the default MMAPv1 engine (with collection-level locking), and the new WiredTiger storage engine (with document-level locking). We’re very excited about WiredTiger and have already begun testing internally. We look forward to supporting WiredTiger for MongoLab production plans when it is expected to become the default storage engine in version 3.2.

Questions?

As you will discover, there are numerous changes and enhancements to 3.0. We recommend that you explore the full list of changes and improvements in the MongoDB 3.0 release notes. If you have any questions along the way, drop us a line at support@mongolab.com and we’d be happy to help!  For example, if your MongoLab deployment experiences high write loads, and you would like to discuss how best to leverage collection-level locking to enhance your performance, please drop us a line!

MongoLab Telemetry supports custom MongoDB metric alerts

We’re excited to announce that you can now use MongoLab Telemetry to configure per-metric alerts for your MongoLab deployments! These custom alerts allow you to stay updated on your database’s performance even when you’re not actively working with the database.

For each metric in your Telemetry dashboard you may define custom threshold values and alerting methods (email, PagerDuty, etc.).

For a Quick-start Guide and full docs, visit our documentation on Telemetry Alerts.

SSL now in public beta on MongoLab

Our team at MongoLab is excited to announce the public beta of SSL-enabled* (Secure Sockets Layer) MongoDB connections on Dedicated deployments**. This feature adds an extra level of security by encrypting the communication between the application and database. It also allows clients to authenticate the identity of their database servers in order to mitigate spoofing attacks.

SSL on production-ready MongoDB

MongoLab has partnered with DigiCert, one of the most respected certificate issuers in the industry, to automate the certificate management process.

What’s unique about this solution is that we allow you to control the scope of your SSL certificates. You can issue unique certificates for each deployment or choose to share a single certificate amongst all of the SSL-enabled deployments in your account.

SSL domain scopes

We are currently offering two domain scopes: account and deployment. The narrower deployment scope maximizes security at increased cost, whereas the broader account scope balances security with cost. You can visit our documentation for more information on available domain scopes.

SSL configuration for clients (drivers)

For instructions on how to connect your driver to a SSL-enabled MongoDB deployment, you can visit the MongoLab documentation.

Pricing and availability

SSL support is currently in beta on MongoLab. For more details on pricing and the beta status you can visit our SSL documentation. If you’re interested in trying out SSL on MongoLab, you can create a new Dedicated deployment or upgrade an existing Dedicated deployment.

*Currently, all deployments with SSL enabled use the preferSSL net.ssl.mode

**We are only offering SSL on MongoDB 2.6

 

{ "comments": 2 }

Introducing Telemetry – monitoring for MongoLab deployments

Today we are announcing the alpha release of Telemetry, our real-time and historical monitoring tool for MongoLab deployments. Telemetry is a customizable dashboard GUI that displays important MongoDB metrics and helps you effectively monitor and tune database performance.

Telemetry Dashboard

Telemetry dashboard overview

Metrics in Telemetry

The alpha version of Telemetry displays real-time and historical MongoDB serverStatus data.

Specifically, there are historical graphs for:

  • Opcounters (queries, inserts, updates, deletes, getmores, cmds)
  • Memory
  • Effective Lock
  • Page Faults
  • Index Access (accesses, hits, misses)
  • Connections
  • Network (in, out, requests)
  • Queues (readers, writers)
  • Journal (stats, commits in write lock)
  • Cursors
  • Background Flush
  • Record Stats
  • Replication Stats (oplog window, lag)

Feature highlights

Telemetry has many features to help you quickly assess the health of your deployment.

Customizable dashboard

By default, Telemetry displays all of your historical MongoDB serverStatus data in a grid layout. You can also choose to view graphs in a row layout, which allows each graph to span the width of your screen. If there are specific graphs that you want to view, you can further customize the dashboard by adding, removing, or dragging individual graphs to specific locations.

Preset and dynamic zooms

Preset and dynamic zoom

Leverage preset and dynamic zooms

 

Our Zoom feature allows you to specify the timeframe for database metrics that you’d like to view. For example, if there’s an incident that occurred within the past hour, you can use the “1 HR” zoom option to filter out irrelevant information.

For further granularity, you can also highlight over a section of interest on any chart.

Highlight over the section of interest

 

This action provides a custom zoom that allows you to closely examine metric values.

Time lock

Frozen point-in-time

Lock a point-in-time for all metrics

 

Once you have your desired zoom set, you can lock your cursor by double-clicking on any point on a graph. This locked point in time will propagate to all the charts, making it easy to compare metrics at the same point in time.

Real-time stats

Sometimes you want to view real-time performance metrics. You can access your real-time dashboard in Telemetry by clicking on “View real-time stats” in the upper right-hand corner.

Accessing Telemetry

Once you log in to the MongoLab management portal, you can access Telemetry two different ways:

  • From your account’s Home page, locate the deployment whose stats you want to view and click on the graph icon at the end of the row. You can choose to view metrics for any member in your deployment.
  • From the deployment’s Home page, click on the “Monitoring” tab, locate the server whose stats you want to view and click on the “open historical” link at the end of the row.

Happy monitoring!

We hope Telemetry helps you become even more productive with MongoDB. If you’re new to MongoLab, you can get started with Telemetry by provisioning any for-pay plan. Please keep in mind that Telemetry is in alpha, which means it may be subject to occasional downtime and clearing of historical data.

We greatly value your feedback during the alpha period so please feel free to email support@mongolab.com with bug reports or general comments.

 

{ "comments": 3 }