DataMasque Portal

In-Flight Server Configuration and Logs

This document explains how to configure the DataMasque in-flight server, view logs, and adjust settings for different deployment scenarios. You'll learn how to modify environment variables, handle common configuration scenarios, and understand the available configuration options.

In-Flight Server Logs

The logs for in-flight server requests can be downloaded from the DataMasque dashboard. Refer to the guide on viewing container logs.

There are two log files available:

  • masque_in_flight_server.log: Downloadable by selecting In-flight application logs from the Application Logs menu. This contains general messages for the in-flight server, including any unhandled errors or exceptions.
  • masque_in_flight_server_requests.log: Downloadable by selecting In-flight request logs from the Application Logs menu. This file contains the source IP, user, HTTP method, path and response code for all in-flight requests, for auditing purposes. Refer to common status codes for an explanation of what the status codes mean.

Example request log lines are shown below:

2024-12-10 22:49:30 UTC - 192.168.86.118 (Unknown User) - "POST /ifm/ruleset_plans/" 401
2024-12-10 22:49:35 UTC - 192.168.86.119 (alice) - "GET /ifm/ruleset_plans/" 200

Changing In-Flight Settings

The DataMasque in-flight server is configurable either by using environment variables (for Docker/Podman), or with Helm chart settings (for EKS). The method for updating these variables depends on your deployment type:

  • Docker/Podman: Settings are stored in a .env file.
  • EKS: Settings are defined in the values.yaml file for the Helm Chart.
  • AWS/Azure Marketplace: Follow Docker instructions (these are Docker-based deployments).

The following sections explain how to update settings for each deployment type.

Updating Environment Variables for Docker/Podman

First, locate the .env file. It is inside the DataMasque installation directory, which is /usr/local/etc/datamasque/ by default.

During DataMasque installation, the installation directory can be set to a different path. If your DataMasque install directory has been customised, you will find the .env file in this path instead. The directory will also contain a docker-compose.yml file.

Edit the .env file and change the necessary variable.

For example, to change the worker count from 4 to 8, change the line:

IN_FLIGHT_WORKERS=4

to

IN_FLIGHT_WORKERS=6

then save the file.

Next, restart your container platform.

Important: Restarting Docker or Podman will cause any masking jobs in progress to end. Please make sure no jobs are running before restarting.

Restarting Docker

Restart Docker with systemctl:

$ sudo systemctl restart docker

Restarting Podman

Restart the DataMasque Podman service with systemctl:

$   sudo systemctl restart datamasque_podman.service

Updating Settings for EKS

These settings are available in the Helm chart's values.yaml file, but use different names than their environment variable counterparts:

Environment Variable Helm Chart Setting
IN_FLIGHT_MASKING_RATE_LIMIT_ENABLED ifmRateLimitEnabled
IN_FLIGHT_MASKING_RATE_LIMIT_MINUTE ifmRateLimitMinute
IN_FLIGHT_MASKING_RATE_LIMIT_SECOND ifmRateLimitSecond
IN_FLIGHT_WORKERS ifmWorkers

Note: This document uses environment variable names in section headers, with the corresponding Helm chart setting name listed within each section.

These settings are defined under an ifm section in the values.yaml file. For example:

# The rest of the values.yaml has been omitted for brevity
ifm:
  ifmWorkers: 4
  ifmRateLimitEnabled: true
  ifmRateLimitMinute: "6000/minute"
  ifmRateLimitSecond: "150/second"

After editing them, use helm upgrade to update the cluster with the new variables.

$ helm upgrade datamasque ./datamasque-helmchart -f values.yaml

Note that while helm upgrade normally does not cause downtime, it should be executed while other masking jobs are not running, as any configuration errors could cause them to stop.

Common Scenarios

These are some common reasons for editing settings.

Handling More Requests

Edit IN_FLIGHT_WORKERS and specify a larger value (defaults to 4) to dedicate more worker processes to service in-flight requests.

As a general guideline, configure no more than 2 in-flight workers per CPU core available to DataMasque. Remember that both in-flight and static masking tasks use workers from this total pool. For example, if you have 4 CPU cores, you should have no more than 8 workers total across all tasks.

For detailed guidance on selecting worker count and balancing workers between in-flight and static masking tasks, see the Performance Guide.

Disabling In-Flight

To disable the in-flight server, set IN_FLIGHT_WORKERS to 0. Note that the in-flight-server container will still be active, but will not run any processes.

Rate Limiting

Server-side rate limiting of worker processes is controlled by the IN_FLIGHT_MASKING_RATE_LIMIT_MINUTE and IN_FLIGHT_MASKING_RATE_LIMIT_SECOND environment variables. Using both allows you to limit requests per second, (to prevent traffic spikes), and limit per minute (to limit sustained request traffic). Exceeding either rate limit means response will be returned with a 429 status code (i.e. only one limit needs to be exceeded to be rate-limited).

Rate limits are applied per worker process.

For example, with 4 workers and a limit of 150 requests/second per worker:

  • Individual worker capacity: 150 requests/second
  • Total system capacity: 150/second * 4 workers = 600 requests/second

In general this behavior is OK, as having more workers means more requests can be serviced.

The format of limits is in <num_requests>/<unit>. For example, 6000/minute or 150/second.

Environment Variables Reference

IN_FLIGHT_MASKING_RATE_LIMIT_ENABLED

Default: true Helm Chart Name: ifmRateLimitEnabled

Set to false to disable rate limiting. It is not recommended to disable rate limiting.

IN_FLIGHT_MASKING_RATE_LIMIT_MINUTE

Default: 6000/minute Helm Chart Name: ifmRateLimitMinute

Controls the maximum number of requests allowed per minute. Any requests beyond this limit will receive a response with a 429 status code.

IN_FLIGHT_MASKING_RATE_LIMIT_SECOND

Default: 150/second Helm Chart Name: ifmRateLimitSecond

Controls the maximum number of requests allowed per second. Any requests beyond this limit will receive a response with a 429 status code.

IN_FLIGHT_WORKERS

Default: 4 Helm Chart Name: ifmWorkers

Controls the number of in-flight worker processes to start. More workers allows more requests to be processed in parallel, at the expense of higher memory usage.