Skip to main content

IBM Cloud Object Storage

IBM Cloud Long-Term Storage

Synopsis

Creates a target that writes log messages to IBM Cloud Object Storage buckets with support for various file formats and authentication methods. The target handles large file uploads efficiently with configurable rotation based on size or event count.

Schema

- name: <string>
description: <string>
type: ibmcos
pipelines: <pipeline[]>
status: <boolean>
properties:
key: <string>
secret: <string>
session: <string>
region: <string>
endpoint: <string>
part_size: <numeric>
bucket: <string>
buckets:
- bucket: <string>
name: <string>
format: <string>
compression: <string>
extension: <string>
schema: <string>
name: <string>
format: <string>
compression: <string>
extension: <string>
schema: <string>
max_size: <numeric>
batch_size: <numeric>
timeout: <numeric>
field_format: <string>
debug:
status: <boolean>
dont_send_logs: <boolean>

Configuration

The following fields are used to define the target:

FieldRequiredDefaultDescription
nameYTarget name
descriptionN-Optional description
typeYMust be ibmcos
pipelinesN-Optional post-processor pipelines
statusNtrueEnable/disable the target

IBM Cloud Object Storage Credentials

FieldRequiredDefaultDescription
keyY-IBM Cloud Object Storage HMAC access key ID
secretY-IBM Cloud Object Storage HMAC secret access key
sessionN-Session token for temporary HMAC credentials (rarely used with IBM COS)
regionY-IBM Cloud region (e.g., us-south, eu-gb, jp-tok)
endpointY-IBM COS endpoint URL (e.g., https://s3.us-south.cloud-object-storage.appdomain.cloud)

Connection

FieldRequiredDefaultDescription
part_sizeN5Multipart upload part size in megabytes (minimum 5MB)
timeoutN30Connection timeout in seconds
field_formatN-Data normalization format. See applicable Normalization section

Files

FieldRequiredDefaultDescription
bucketN*-Default IBM COS bucket name (used if buckets not specified)
bucketsN*-Array of bucket configurations for file distribution
buckets.bucketY-IBM COS bucket name
buckets.nameY-File name template
buckets.formatN"json"Output format: json, multijson, avro, parquet
buckets.compressionN-Compression algorithm (see file format documentation for supported values)
buckets.extensionNMatches formatFile extension override
buckets.schemaN*-Schema reference (required for Avro and Parquet formats)
nameN"vmetric.{{.Timestamp}}.{{.Extension}}"Default file name template when buckets not used
formatN"json"Default output format when buckets not used
compressionNzstdDefault compression when buckets not used
extensionNMatches formatDefault file extension when buckets not used
schemaN-Default schema reference when buckets not used
max_sizeN33554432Maximum file size in bytes before rotation (32 MB). An explicit 0 is replaced by that default, so it does not mean unlimited
batch_sizeN100000Maximum number of messages per file

* = Either bucket or buckets must be specified. When using buckets, schema is conditionally required for Avro and Parquet formats.

note

When max_size is reached, the current file is uploaded to IBM COS and a new file is created. Setting max_size to 0 does not disable rotation — an explicit 0 is replaced by the 32 MB default (MustInt64), so there is no unlimited setting. Raise the value instead.

Scheduling

See Scheduling and Pool Behavior for interval and cron fields shared by all targets.

Debug Options

FieldRequiredDefaultDescription
debug.statusNfalseEnable debug logging
debug.dont_send_logsNfalseProcess logs but don't send to target (testing)

Details

The IBM Cloud Object Storage target uploads each rotated file to the bucket it is routed to, in any of the supported file formats. IBM COS offers high durability (99.999999999%), security features, and flexible storage classes for cost optimization.

Authentication

Requires IBM Cloud Object Storage HMAC credentials. HMAC credentials can be created through the IBM Cloud console and provide programmatic access to COS buckets.

Endpoint Configuration

IBM Cloud Object Storage uses region-specific endpoints. The endpoint format is typically https://s3.<region>.cloud-object-storage.appdomain.cloud where <region> corresponds to your chosen IBM Cloud region.

Available Regions

IBM Cloud Object Storage is available in multiple regions worldwide:

Region CodeLocation
us-southDallas, USA
us-eastWashington DC, USA
eu-gbLondon, UK
eu-deFrankfurt, Germany
jp-tokTokyo, Japan
au-sydSydney, Australia

File Formats

FormatDescription
jsonEach log entry is written as a separate JSON line (JSONL format)
multijsonAll log entries are written as a single JSON array
avroApache Avro format with schema
parquetApache Parquet columnar format with schema

Compression

Some formats support built-in compression to reduce storage costs and transfer times. When supported, compression is applied at the file/block level before upload.

FormatDefaultCompression Codecs
JSON-Not supported
MultiJSON-Not supported
Avrozstddeflate, snappy, zstd
Parquetzstdgzip, snappy, zstd, brotli, lz4

File Management

Files are rotated based on size (max_size parameter) or event count (batch_size parameter), whichever limit is reached first. Template variables in file names enable dynamic file naming for time-based partitioning.

Bucket Routing

The target supports flexible bucket routing through pipeline configuration or explicit bucket settings:

Configuration-based routing: Define multiple buckets in the target configuration, each with its own format, compression, and schema settings. Logs are routed to specific buckets based on configuration.

Pipeline-based routing: Use the bucket field in pipeline processors to dynamically route logs to different buckets at runtime. This enables conditional routing based on log content, source, or other attributes.

Catch-all routing: When a log doesn't match any specific bucket configuration or when no bucket field is set in the pipeline, logs are routed to the catch-all bucket (configured via the bucket field in target properties).

Routing priority:

  1. Pipeline bucket field (highest priority)
  2. Configured buckets in buckets array (if bucket name matches)
  3. Default bucket field (catch-all, lowest priority)

This multi-level routing enables flexible data distribution strategies, such as routing different log types to different buckets based on content analysis, source system, severity level, or any other runtime decision.

Templates

The following template variables can be used in file names:

VariableDescriptionExample
{{.Year}}Current year2024
{{.Month}}Current month01
{{.Day}}Current day15
{{.Timestamp}}Current timestamp in nanoseconds1703688533123456789
{{.Format}}File formatjson
{{.Extension}}File extensionjson
{{.Compression}}Compression typezstd
{{.TargetName}}Target namemy_logs
{{.TargetType}}Target typeibmcos
{{.Table}}Bucket namelogs
{{.Thread}}Writer thread index. The sender also appends this automatically when two threads would otherwise produce the same path, so an explicit token is only needed to control WHERE it lands3
{{.ServiceRoot}}The service root directory/opt/vmetric

Multipart Upload

Large files automatically use multipart upload protocol with configurable part size (part_size parameter). Default 5MB part size balances upload efficiency and memory usage.

Multiple Buckets

Single target can write to multiple IBM COS buckets with different configurations, enabling data distribution strategies (e.g., raw data to one bucket, processed data to another).

Schema Requirements

Avro and Parquet formats require a schema. The schema value can be a Library schema name, a built-in schema name, or an inline JSON definition. Parquet also accepts a schema file deployed under the schemas directory. Avro has no file lookup, so an Avro schema must be a name or inline JSON. See Avro and Parquet for the JSON definition format.

Storage Classes

IBM Cloud Object Storage supports multiple storage classes for cost optimization. Choose the appropriate class based on data access patterns and retention requirements.

Examples

Basic Configuration

The minimum configuration for a JSON IBM COS target:

targets:
- name: basic_ibm_cos
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "us-south"
endpoint: "https://s3.us-south.cloud-object-storage.appdomain.cloud"
bucket: "datastream-logs"

Multiple Buckets

Configuration for distributing data across multiple IBM COS buckets with different formats:

targets:
- name: multi_bucket_export
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "eu-gb"
endpoint: "https://s3.eu-gb.cloud-object-storage.appdomain.cloud"
buckets:
- bucket: "raw-data-archive"
name: "raw-{{.Year}}-{{.Month}}-{{.Day}}-{{.Timestamp}}.json"
format: "multijson"
compression: "gzip"
- bucket: "analytics-data"
name: "analytics-{{.Year}}/{{.Month}}/{{.Day}}/data_{{.Timestamp}}.parquet"
format: "parquet"
schema: "<schema definition>"
compression: "snappy"

Multiple Buckets with Catch-All

Configuration for routing different log types to specific buckets with a catch-all for unmatched logs:

targets:
- name: multi_bucket_routing
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "us-south"
endpoint: "https://s3.us-south.cloud-object-storage.appdomain.cloud"
buckets:
- bucket: "security-logs"
name: "security-{{.Year}}-{{.Month}}-{{.Day}}-{{.Timestamp}}.json"
format: "json"
- bucket: "application-logs"
name: "app-{{.Year}}-{{.Month}}-{{.Day}}-{{.Timestamp}}.json"
format: "json"
bucket: "general-logs"
name: "general-{{.Timestamp}}.json"
format: "json"

Parquet Format

Configuration for daily partitioned Parquet files:

targets:
- name: parquet_analytics
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "jp-tok"
endpoint: "https://s3.jp-tok.cloud-object-storage.appdomain.cloud"
bucket: "analytics-lake"
name: "events/year={{.Year}}/month={{.Month}}/day={{.Day}}/part-{{.Timestamp}}.parquet"
format: "parquet"
schema: "<schema definition>"
compression: "snappy"
max_size: 536870912

High Reliability

Configuration with enhanced settings:

targets:
- name: reliable_ibm_cos
type: ibmcos
pipelines:
- checkpoint
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "us-east"
endpoint: "https://s3.us-east.cloud-object-storage.appdomain.cloud"
bucket: "critical-logs"
name: "logs-{{.Timestamp}}.json"
format: "json"
timeout: 60
part_size: 10

With Field Normalization

Using field normalization for standard format:

targets:
- name: normalized_ibm_cos
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "eu-de"
endpoint: "https://s3.eu-de.cloud-object-storage.appdomain.cloud"
bucket: "normalized-logs"
name: "logs-{{.Timestamp}}.json"
format: "json"
field_format: "cim"

Debug Configuration

Configuration with debugging enabled:

targets:
- name: debug_ibm_cos
type: ibmcos
properties:
key: "0123456789abcdef0123456789abcdef"
secret: "fedcba9876543210fedcba9876543210fedcba98"
region: "au-syd"
endpoint: "https://s3.au-syd.cloud-object-storage.appdomain.cloud"
bucket: "test-logs"
name: "test-{{.Timestamp}}.json"
format: "json"
debug:
status: true
dont_send_logs: true

Troubleshooting

The ibmcos target behaves the same way as the Amazon S3 target and reports the same errors for the same causes: refused credentials, a bucket that does not exist, region and endpoint mistakes, upload timeouts, throttling, and buckets that stay empty. Use the Troubleshooting section of Amazon S3 for the full list of errors, causes, and fixes. See Target Delivery Errors for how Director logs and retries target failures.

Log lines and the connection status carry this target's name, so match on the cause text, which is the part after Reason: or after the last colon, rather than on the target name shown in the examples there.

What differs for IBM Cloud Object Storage

  • Startup probes the account, not one bucket. Before anything is sent, the target makes one list-buckets call, so the credentials need an account-wide list permission. A service credential whose access is limited to a single bucket typically fails that probe, even though the same credential can write objects into that bucket. You get api error AccessDenied after ListBuckets, and nothing is sent until the credential can list the buckets of the instance.

  • key and secret must both be set. Use the HMAC access key ID and secret access key from a service credential created with HMAC enabled. A credential without them leaves the two fields empty, and they are used only when both resolve to a non-empty value. There is no instance-role or ambient credential fallback that can work here, so an empty value leaves the target with no credentials at all and it reports no EC2 IMDS role found instead. A ${VAR} or $secret{...} reference that resolves to an empty string fails the same way while the configuration still looks complete.

  • region and endpoint must both be set, and they must agree. Use the region code, such as us-south or eu-gb, not the location name shown in the console. Set endpoint to the full URL, https://s3.<region>.cloud-object-storage.appdomain.cloud, with the scheme included. Requests are signed with region, so an endpoint that serves another region typically answers with SignatureDoesNotMatch even though both values look correct on their own.

  • Name resolution and certificates cause most connection failures. Read the entry on the primary page that covers no such host, connection refused, and certificate signed by unknown authority. This target reads no TLS options, so a certificate issued by a private certificate authority, such as the one an inspecting proxy presents, has to be installed in the Director host's own trust store. Leave use_path_style unset so the custom endpoint keeps path-style addressing.

note

No bucket name is checked at startup. The probe only confirms that the credentials can list the account, so a misspelled name under bucket or buckets passes startup and fails on the first upload routed to it.

tip

If a bucket holds only the last batch, check that every name template contains {{.Timestamp}}. A name built only from {{.Year}}, {{.Month}}, and {{.Day}} produces the same object key on every flush, and each upload replaces the one before it.

Nothing is lost while any of these lasts. Incoming data stays queued and the target retries until you fix the cause.