Environments

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.

How Environments Work

You can collect performance data and traces from different environments of your project with this feature. The 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.

Your 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, 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. Using the UI through "Settings" then "Configure Servers & Environments" or the REST-API allows you to create environments for a limited amount of time after which they get automatically de-activated. You can re-activate an environment through the settings screen inside Tideways or through the Environment REST API endpoint.

Each active non-production environment gets assigned up to 10% of the traces/minute quota, so for a basic project with 25 traces/minute an environment gets 2 traces assigned. The non-production environments only collect application monitoring data and no detailed transaction level percentile monitoring data. The detail of traces is not limited for non-production environments.

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.

Configuration

Environments are configured at the daemon level using a flag, that means applications and services reporting to the same daemon always have to be part of the same environment. This is a technical limitation that we might lift at some point.

By default each daemon assumes it is running for the production environment of the project.

You can pass the --env flag to start the daemon for a different environment, by creating or modifying the configuration file /etc/default/tideways-daemon to contain:

TIDEWAYS_DAEMON_EXTRA="--env=staging1"

Make sure to restart the daemon after doing this change. The log file /var/log/tideways/daemon.log should then contain a hint about the environment used:

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 127.0.0.1:8135

See the Daemon Reference Documentation for more information.

Environments are then automatically created inside Tideways as soon as a daemon collects data for them.

You can see a list of all environments, create new ones and toggle which ones are active from the "Project Settings" and then "Configure Servers & Environments" screen.

Rest Api

We provide a simple REST API to create and re-activate environments from automated environments. The endpoint works as follows:

POST https://app.tideways.io/api/environments
{
    "apiKey": "....",
    "name": "staging-1",
    "activeUntil": "+1 hour"
}

The "apiKey" and "name" are required arguments. The "activeUntil" property is passed to the PHP DateTime constructor and can be a relative or absolute date. It is always set to UTC.

Use-Case: 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.

Use-Case: Platform-as-a-Service with Review Apps

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

The idea is that you use the REST API during your build process to inform Tideways of a new environment and configure the Tideways daemon that is collecting data for this build that it is running a special environment, for example "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]