Running a project usually involves a production deployment, multiple development setups, and, in a continuous pipeline setup, multiple staging, QA and review installations. Keeping all these different environments under monitoring without interfering with each other requires a tailored monitoring tool, such as Tideways, with built in multi-environment support — available on all plans.

Production and non-production environments operate differently.

Production environments collect more traces, store more event details, and retain data as per plan limits. Non-production environments, however, collect a reduced quantity of data. More details are available below.

How Environments Work

Environments allow you to collect performance data and traces from different "environments" of your project. For example, data is kept separate to avoid interference of testing data with production data. Comparing them is supported to find performance regressions before they get into production.

Each project has a limit on the number of active environments that can report performance and trace data to Tideways. If you create more environments than this limit, then only the most recently activated environments are marked as active and collect data.

The "production" environment is a special case, however, because it is always active and never gets de-activated when too many other environments are created.

When a non-production environment gets created during the ingestion of performance or tracing data, then it gets activated forever.

Temporary Environments

Using the UI through Settings  Configure Servers & Environments or the REST API allows you to create environments for a limited amount of time, after which they are automatically de-activated. You can re-activate an environment through the settings screen inside Tideways, or through the Environment REST API.

Traces Per Environment

The traces rules are as follows:

  • The production environment receives all traces/minute of the plan

  • Every other environment receives exactly 1 trace per minute

The following things can be configured for environment traces:

  • Each environment can be edited under "Application Settings" to add 5 more traces/minute, which are "taken" from the production environment

  • On a pro plan, you can create more than one "production" environment, which allows user to set even more than 5 traces/minute in settings screen

Servers running in an inactive environment discard all their data at the daemon level automatically.

Environments are available in Basic, Standard and Pro plans, lower plans only ship with the built-in "production" environment and a limited "development" environment to collect manually triggered traces.

Switching Between Environments

To switch between environments in the application’s Performance Overview dashboard, click the environment that you want to view data for in The Service and Environment Switcher. In the example below there are two environments to choose from: production and vagrant.

The service and environment selector in an application’s performance overview
Figure 1. The service and environment selector in an application’s Performance Overview dashboard

Managing Environments

Environments can be managed at the daemon level, using the --env flag, and by using the Tideways UI.

Managing Environments at the Daemon Level

Applications and services reporting to the same daemon always have to be part of the same environment. This is a technical limitation that might be lifted at some point in the future.

By default, each daemon assumes it is collecting data for a project’s production environment. You can pass the --env flag to start the daemon for a different environment, or by creating or modifying the configuration file /etc/default/tideways-daemon, similar to the example configuration below:

Configure the Tideways daemon environment using a configuration file
; Change "staging1" below, as desired.

See the Daemon Reference Documentation for more information.

Make sure to restart the daemon, if you make this change.

Managing Environments Using the Tideways UI

You can see a list of all environments, create new ones, and toggle which environments are active, from Settings  Servers & Environments  Environments.

Create an Environment

Create an environment in the Tideways UI

To create a new environment, click Create Environment in the top right-hand corner of the Environments section, which takes you to the "Create Environment" form.

When there, specify the name and active period (Active For) for the new environment, and click Create Environment. Environments can be active for forever, an hour, a day, or a week.

After that, you will be redirected back to the Environments list, where you will see the new environment in the list of available environments, already activate.

Deactivate an Environment

Deactivate an environment in the Tideways UI

To deactivate an active environment, click Deactivate on the far right-hand side of its row in the environment’s list. After doing so, you’ll see its status change to Inactive.

Edit an Environment

To edit an existing environment, click (Edit) in the Production column for that environment.

Pick an environment to edit in the Tideways UI

After doing so, you will be on the "Promote Environment development" form. From there, you can promote the environment to production, and assign 0, 5, 10, 25, and 50 extra traces per/minute to the environment.

Edit an application environment using the Tideways UI

After setting the respective values in the form, click Change Environment Settings to apply the changes, and you will be back at the Environments list.

View Environment Information Log Data

After updating the daemon configuration and restarting the daemon, the daemon’s log file (/var/log/tideways/daemon.log) should show that the environment is in use. The new environment will be created as soon as a daemon collects data for it.

In the following example, on line three, you can see that the environment in use is staging1.

2017/09/14 13:48:05 Starting up daemon (version 1.5.9)
2017/09/14 13:48:05 Sending to https://app.tideways.io
2017/09/14 13:48:05 Sending for Environment 'staging1'
2017/09/14 13:48:05 Collecting for demo.tideways.io
2017/09/14 13:48:05 Supported server stats: CPU [X]  Memory [X]  Load [X]  Disk [X]  Network [X]
2017/09/14 13:48:05 Listening for Unix Socket connections at /var/run/tideways/tidewaysd.sock.
2017/09/14 13:48:05 Listening for UDP connections

Use Cases

The Staging Environment

The most common use-case for the environment feature is a permanently running staging application that is running an unstable version of your project. You can run Tideways on this staging deployment and collect all data into a single environment.

Platform-as-a-Service with Review Apps

If you are using an existing PaaS (Product as a Service) or have built a review pipeline yourself (for example, with Jenkins and Docker), then, for example, you can use Tideways to create on-demand environments for every newly created build, that is based on a pull-request in GitHub.

The idea is that you use the TIDEWAYS_ENVIRONMENT to set the environment name to the review environment name, for example TIDEWAYS_ENVIRONMENT=pull-request-1234.

With the active environment limitation, Tideways selects the most recent environments to collect data for you so that you always get data for the most recently created builds.

You can then check for performance regressions by running automated load-tests against these environments and checking the results from Tideways.

Still need help? Email [email protected]