Skip to content
LogScale Self-Hosted
Content was updated:May 27, 2025
This is an archived version of the documentation downloaded from LogScale Documentation Archives. Up to date documentation, and documentation for later versions, is available on LogScale Documentation

### S3 Archiving

supports archiving ingested logs to Amazon S3. The archived logs are then available for further processing in any external system that integrates with S3. The files written by in this format are not searchable by — this is an export meant for other systems to consume.

For information about using S3 as storage for segments in a format that can read, see Bucket Storage.

When S3 Archiving is enabled all the events in repository are backfilled into S3 and then it archives new events by running a periodic job inside all nodes, which looks for new, unarchived segment files. The segment files are read from disk, streamed to an S3 bucket, and marked as archived in .

An administrator must set up archiving per repository. After selecting a repository on , the configuration page is available under `Settings`.

### Note

For slow-moving datasources it can take some time before segment files are completed on disk and then made available for the archiving job. In the worst case, before a segment file is completed, it must contain a gigabyte of uncompressed data or 30 minutes must have passed. The exact thresholds are those configured as the limits on mini segments.

### Important

S3 archiving is not supported for S3 buckets where object locking is enabled.

For more information on segments files and datasources, see segment files and Datasources.

#### S3 Archive Storage Format and Layout

When uploading a segment file, creates the S3 object key based on the tags, start date, and repository name of the segment file. The resulting object key makes the archived data browsable through the S3 management console.

uses the following pattern:

shell

    REPOSITORY/TYPE/TAG_KEY_1/TAG_VALUE_1/../TAG_KEY_N/TAG_VALUE_N/YEAR/MONTH/DAY/START_TIME-SEGMENT_ID.gz

Where:

- `REPOSITORY`

  Name of the repository

- `type`

  Keyword (static) to identfy the format of the enclosed data.

- `TAG_KEY_1`

  Name of the tag key (typically the name of parser used to ingest the data, from the #type field)

- `TAG_VALUE`

  Value of the corresponding tag key.

- `YEAR`

  Year of the timestamp of the events

- `MONTH`

  Month of the timestamp of the events

- `DAY`

  Day of the timestamp of the events

- `START_TIME`

  The start time of the segment, in the format `HH-MM-SS`

- `SEGMENT_ID`

  The unique segment ID of the event data

An example of this layout can be seen in the file list below:

shell

    $ s3cmd ls -r s3://logscale2/accesslog/
    2023-06-07 08:03         1453  s3://logscale2/accesslog/type/kv/2023/05/02/14-35-52-gy60POKpoe0yYa0zKTAP0o6x.gz
    2023-06-07 08:03       373268  s3://logscale2/accesslog/type/kv/humioBackfill/0/2023/03/07/15-09-41-gJ0VFhx2CGlXSYYqSEuBmAx1.gz

Read more about Parsing Event Tags.

#### File Format

supports two formats for storage: native format and NDJSON.

- Native Format

  The native format is the raw data, i.e. the equivalent of the @rawstring of the ingested data:

  accesslog

      127.0.0.1 - - [07/Mar/2023:15:09:42 +0000] "GET /falcon-logscale/css-images/176f8f5bd5f02b3abfcf894955d7e919.woff2 HTTP/1.1" 200 15736 "http://localhost:81/falcon-logscale/theme.css" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
      127.0.0.1 - - [07/Mar/2023:15:09:43 +0000] "GET /falcon-logscale/css-images/alert-octagon.svg HTTP/1.1" 200 416 "http://localhost:81/falcon-logscale/theme.css" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36"
      127.0.0.1 - - [09/Mar/2023:14:16:56 +0000] "GET /theme-home.css HTTP/1.1" 200 70699 "http://localhost:81/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
      127.0.0.1 - - [09/Mar/2023:14:16:59 +0000] "GET /css-images/help-circle-white.svg HTTP/1.1" 200 358 "http://localhost:81/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
      127.0.0.1 - - [09/Mar/2023:14:16:59 +0000] "GET /css-images/logo-white.svg HTTP/1.1" 200 2275 "http://localhost:81/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"

- NDJSON Format

  The default archiving format is NDJSON When using NDJSON, the parsed fields will be available along with the raw log line. This incurs some extra storage cost compared to using raw log lines but gives the benefit of ease of use when processing the logs in an external system.

  json

      {"#type":"kv","#repo":"weblog","#humioBackfill":"0","@source":"/var/log/apache2/access_log","@timestamp.nanos":"0","@rawstring":"127.0.0.1 - - [07/Mar/2023:15:09:42 +0000] \"GET /falcon-logscale/css-images/176f8f5bd5f02b3abfcf894955d7e919.woff2 HTTP/1.1\" 200 15736 \"http://localhost:81/falcon-logscale/theme.css\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36\"","@id":"XPcjXSqXywOthZV25sOB1hqZ_0_1_1678201782","@timestamp":1678201782000,"@ingesttimestamp":"1691483483696","@host":"ML-C02FL14GMD6V","@timezone":"Z"}
      {"#type":"kv","#repo":"weblog","#humioBackfill":"0","@source":"/var/log/apache2/access_log","@timestamp.nanos":"0","@rawstring":"127.0.0.1 - - [07/Mar/2023:15:09:43 +0000] \"GET /falcon-logscale/css-images/alert-octagon.svg HTTP/1.1\" 200 416 \"http://localhost:81/falcon-logscale/theme.css\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36\"","@id":"XPcjXSqXywOthZV25sOB1hqZ_0_3_1678201783","@timestamp":1678201783000,"@ingesttimestamp":"1691483483696","@host":"ML-C02FL14GMD6V","@timezone":"Z"}
      {"#type":"kv","#repo":"weblog","#humioBackfill":"0","@source":"/var/log/apache2/access_log","@timestamp.nanos":"0","@rawstring":"127.0.0.1 - - [09/Mar/2023:14:16:56 +0000] \"GET /theme-home.css HTTP/1.1\" 200 70699 \"http://localhost:81/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36\"","@id":"XPcjXSqXywOthZV25sOB1hqZ_0_15_1678371416","@timestamp":1678371416000,"@ingesttimestamp":"1691483483696","@host":"ML-C02FL14GMD6V","@timezone":"Z"}
      {"#type":"kv","#repo":"weblog","#humioBackfill":"0","@source":"/var/log/apache2/access_log","@timestamp.nanos":"0","@rawstring":"127.0.0.1 - - [09/Mar/2023:14:16:59 +0000] \"GET /css-images/help-circle-white.svg HTTP/1.1\" 200 358 \"http://localhost:81/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36\"","@id":"XPcjXSqXywOthZV25sOB1hqZ_0_22_1678371419","@timestamp":1678371419000,"@ingesttimestamp":"1691483483696","@host":"ML-C02FL14GMD6V","@timezone":"Z"}
      {"#type":"kv","#repo":"weblog","#humioBackfill":"0","@source":"/var/log/apache2/access_log","@timestamp.nanos":"0","@rawstring":"127.0.0.1 - - [09/Mar/2023:14:16:59 +0000] \"GET /css-images/logo-white.svg HTTP/1.1\" 200 2275 \"http://localhost:81/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36\"","@id":"XPcjXSqXywOthZV25sOB1hqZ_0_23_1678371419","@timestamp":1678371419000,"@ingesttimestamp":"1691483483696","@host":"ML-C02FL14GMD6V","@timezone":"Z"}

  A single NDJSON line is just a JSON object, which formatted looks like this:

  json

      {
      "#humioBackfill" : "0",
      "#repo" : "weblog",
      "#type" : "kv",
      "@host" : "ML-C02FL14GMD6V",
      "@id" : "XPcjXSqXywOthZV25sOB1hqZ_0_1_1678201782",
      "@ingesttimestamp" : "1691483483696",
      "@rawstring" : "127.0.0.1 - - [07/Mar/2023:15:09:42 +0000] \"GET /falcon-logscale/css-images/176f8f5bd5f02b3abfcf894955d7e919.woff2 HTTP/1.1\" 200 15736 \"http://localhost:81/falcon-logscale/theme.css\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36\"",
      "@source" : "/var/log/apache2/access_log",
      "@timestamp" : 1678201782000,
      "@timestamp.nanos" : "0",
      "@timezone" : "Z"
      }

Each record includes the full detail for each event, including parsed fields, the original raw event string, and tagged field entries.

#### How Data is Uploaded to S3

Data is uploaded to S3 as soon as a segment file has been created during ingest (for more information, see Ingestion: Digest Phase).

Each segment file is sent as as multipart upload, so the upload of a single file may require multiple S3 requests. The exact number of requests will depend on rate of ingest, but expect a rate of one request for each 8MB of ingested data.

The size of each part of the upload is configured using the `S3_STORAGE_CHUNK_SIZE` configuration variable.

#### Set up S3 archiving

To archive data to S3, you must do the following steps in order.

1. S3 Storage Configuration

2. Setup S3 archiving with IAM role

##### S3 Storage Configuration

### Important

Until archiving has been configured at the cluster level, no archiving can be configured at the org level within the user interface.

For , you need an IAM user with write access to the buckets used for archiving. That user must have programmatic access to S3, so when adding a new user through the AWS console make sure programmatic access is checked:

Figure 2. Setup

Later in the process, you can retrieve the access key and secret key:

Figure 3. Setup Key

This is needed in in the following configuration:

ini

    S3_ARCHIVING_ACCESSKEY=$ACCESS_KEY
    S3_ARCHIVING_SECRETKEY=$SECRET_KEY

The keys are used for authenticating the user against the S3 service. For more guidance on how to retrieve S3 access keys, see AWS access keys. For more details on creating a new user, see creating a new user in IAM.

Once you have completed this configuration, choose whether to set up S3 archiving with an IAM role (recommended) or an IAM user.

#### Monitor S3 Archiving

To monitor the S3 archiving process, the following query can be executed in the humio:

logscale

    #kind=logs thread=/archiving-upload-latency/ class!=/TimerExecutor
    | JobAssignmentsImpl/

A monitoring task within checks this and reports if the latency is greater than 15 minutes. This adds an event entry to the humio repo using the phrase Archiving is lagging by ingest time for more than (ms).

#### Troubleshoot S3 archiving configuration

If you encounter an access denied error message when configuring S3 archiving, check your configuration settings for missing information or typos.

#### Tag Grouping in AWS S3

Prior to version 1.169, if tag grouping is defined for a repository, the segment files will be split by each unique combination of tags present in a file. This results in a file in S3 per each unique combination of tags. The same layout pattern is used as in the normal case. The reason for doing this is to make it easier for a human operator to determine whether a log file is relevant.

#### Other options

##### HTTP proxy

If is set up to use an `HTTP_PROXY_HOST`, it will be used for communicating with S3 by default. To disable it, set the following:

ini

    # Use the globally configured HTTP proxy for communicating with S3.
    # Default is true.
    S3_ARCHIVING_USE_HTTP_PROXY=false

##### Non-default endpoints

You can point to your own hosting endpoint for S3 to use for archiving if you host an S3-compatible service such as MinIO.

ini

    S3_ARCHIVING_ENDPOINT_BASE=http://my-own-s3:8080

###### Virtual host style (default)

will construct virtual host-style URLs like `https://my-bucket.my-own-s3:8080/path/inside/bucket/file.txt`.

For this style of access, you need to set your base URL, so it contains a placeholder for the bucket name.

ini

    S3_ARCHIVING_ENDPOINT_BASE=http://{bucket}.my-own-s3:8080

will replace the placeholder `{bucket}` with the relevant bucket name at runtime.

###### Path-style

Some services do not support virtual host style access, and require path-style access. Such URLs have the format `https://my-own-s3:8080/my-bucket/path/inside/bucket/file.txt`. If you are using such a service, your endpoint base URL should not contain a bucket placeholder.

ini

    S3_ARCHIVING_ENDPOINT_BASE=http://my-own-s3:8080

Additionally, you must set `S3_ARCHIVING_PATH_STYLE_ACCESS` to true.

##### IBM Cloud Storage compatibility

To use S3 Archiving with IBM Cloud Storage, set `S3_ARCHIVING_IBM_COMPAT` to true.

#### S3 archived log re-ingestion

You can re-ingest log data that has been written to an S3 bucket through S3 archiving by using and the native JSON parsing within .

This process has the following requirements:

- The files need to be downloaded from the S3 bucket to the machine running the . The S3 files cannot be accessed natively by the .

- The ingested events will be ingested into the repository that is created for the purpose of receiving the data.

To re-ingest logs:

1. Create a repo in where the ingested data will be stored. See Creating a Repository or View.

2. Create an ingest token, and choose the JSON parser. See Assigning Parsers to Ingest Tokens.

3. Install the to read from a file using the `.gz` extension as the file match. For example, using a configuration similar to this:

   yaml

       #dataDirectory is only required in the case of local configurations and must not be used for remote configurations files.
       dataDirectory: data
       sources:
       bucketdata:
         type: file
         # Glob patterns
         include:
         - /bucketdata/*.gz
         sink: my_humio_instance
         parser: json
         ...

   For more information, see Configuration Examples.

4. Copy the log file from the S3 bucket into the configured directory (`/bucketdata`) in the above example.

The reads the file that has been copied, sends it to , where the JSON event data will be parsed and recreated.

#### Enter search term