How to archive legacy job trace files

Legacy job traces, which were created before GitLab 10.5, were not archived regularly.
It's the same state with the "2: overwriting" in the above Data flow.
To archive those legacy job traces, please follow the instruction below.

Execute the following command

gitlab-rake gitlab:traces:archive

After you executed this task, GitLab instance queues up Sidekiq jobs (asynchronous processes)
for migrating job trace files from local storage to object storage.
It could take time to complete the all migration jobs. You can check the progress by the following command

New live trace architecture

NOTE: Note:
This feature is off by default. Check below how to enable/disable it.

By combining the process with object storage settings, we can completely bypass
the local file storage. This is a useful option if GitLab is installed as
cloud-native, for example on Kubernetes.

The data flow is the same as described in the data flow section
with one change: the stored path of the first two phases is different. This new live
trace architecture stores chunks of traces in Redis and a persistent store (object storage or database) instead of
file storage. Redis is used as first-class storage, and it stores up-to 128KB
of data. Once the full chunk is sent, it is flushed a persistent store, either object storage(temporary directory) or database.
After a while, the data in Redis and a persitent store will be archived to object storage.

The data are stored in the following Redis namespace: Gitlab::Redis::SharedState.

Here is the detailed data flow:

GitLab Runner picks a job from GitLab

GitLab Runner sends a piece of trace to GitLab

GitLab appends the data to Redis

Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database).

The above steps are repeated until the job is finished.

Once the job is finished, GitLab schedules a Sidekiq worker to archive the trace.

The Sidekiq worker archives the trace to object storage and cleans up the trace
in Redis and a persistent store (object storage or the database).

NOTE: Note:
The transition period will be handled gracefully. Upcoming traces will be
generated with the new architecture, and on-going live traces will stay with the
legacy architecture, which means that on-going live traces won't be forcibly
re-generated with the new architecture.

To disable live trace:

Feature.disable('ci_enable_live_trace')

NOTE: Note:
The transition period will be handled gracefully. Upcoming traces will be generated
with the legacy architecture, and on-going live traces will stay with the new
architecture, which means that on-going live traces won't be forcibly re-generated
with the legacy architecture.

Potential implications

In some cases, having data stored on Redis could incur data loss:

Case 1: When all data in Redis are accidentally flushed

On going live traces could be recovered by re-sending traces (this is
supported by all versions of the GitLab Runner).

Finished jobs which have not archived live traces will lose the last part
(~128KB) of trace data.

Case 2: When Sidekiq workers fail to archive (e.g., there was a bug that
prevents archiving process, Sidekiq inconsistency, etc.)

Currently all trace data in Redis will be deleted after one week. If the
Sidekiq workers can't finish by the expiry date, the part of trace data will be lost.

Another issue that might arise is that it could consume all memory on the Redis
instance. If the number of jobs is 1000, 128MB (128KB * 1000) is consumed.

Also, it could pressure the database replication lag. INSERTs are generated to
indicate that we have trace chunk. UPDATEs with 128KB of data is issued once we
receive multiple chunks.