OCI Log Retention Validation: Moving Load Balancer Logs to Object Storage with Connector Hub

A practical checklist for confirming logs are collected, routed, stored, and reviewable

Logs are useful only if they are available when the team needs them.

In OCI, it is possible to enable service logs, route them through Connector Hub, and store them in Object Storage for later review. Connector Hub is also referenced in some Oracle material as Service Connector Hub. The setup can look simple on the surface. But from a delivery point of view, the important question is not whether the connector was created.

The important question is:

Can we prove that the logs are being collected, routed, stored, retained, and reviewed when needed?

This article is written from a practical validation point of view. It uses a simple example: moving OCI Load Balancer logs from OCI Logging to Object Storage using Connector Hub.

Scope note: this is an independent review and validation exercise. It is not a client implementation, and no production environment, customer data, or confidential information is referenced. All names, prefixes, and identifiers below are placeholders. Console labels, defaults, and behaviour can change between releases and regions, so every value should be confirmed in your own tenancy and current Oracle documentation.

The goal is not to describe every possible logging design. The goal is to give a clear checklist that helps confirm the flow is working end to end.

Why log retention needs validation

Enabling a log is not the same as retaining a log.

A team may be able to show that logging was switched on. That does not automatically prove that the data still exists for the period being questioned, that it landed where it was supposed to land, or that someone can retrieve and read it when needed.

There is one detail worth stating early.

There are two retention clocks, not one.

These are independent. Data can age out of Logging while the archived copy remains in Object Storage. The reverse can also happen if bucket lifecycle rules delete or move objects earlier than expected.

So when someone asks, “How long are logs retained?”, the answer should not be assumed from the Logging setting alone. The team should confirm both clocks against the agreed requirement.

The flow

I prefer to view this as four validation checkpoints rather than only as a service-to-service diagram.

In this setup, OCI Load Balancer produces access or error logs, OCI Logging collects those logs in a log group, Connector Hub routes the selected records, and Object Storage retains the archived copy. Lifecycle rules on the bucket help govern how long that archived copy is kept.

Logging Analytics is optional. I would treat it as an analysis layer for search, parsing, dashboards, or investigations, not as a replacement for the Object Storage retention target.

This is a simple pattern, but each step needs to be validated. A missing policy, wrong compartment, inactive log, wrong bucket, or connector issue can break the flow, and some of those failures may not be obvious immediately.

Services involved

From a Project Manager point of view, the focus is not to configure each service personally. The focus is to confirm that each owner has completed their part and that evidence exists.

Prerequisites

Before starting, confirm the following are in place:

• A compartment for the resources: COMPARTMENT_NAME
• Permission to create and manage log groups, logs, connectors, and buckets in that compartment
• A Load Balancer that is receiving at least some traffic: LB_NAME
• An agreed retention expectation, stated in months or years
• A named owner for the flow after go-live
• A decision on whether Logging Analytics is in scope

The last three are easy to miss. They are also the ones that decide whether this remains reliable later.

Step 1: Object Storage bucket readiness

Before configuring the connector, the target bucket should be ready.

Worth confirming:

• The bucket exists: BUCKET_NAME
• The bucket is in the expected compartment
• Bucket name and namespace are confirmed
• Visibility is private
• Lifecycle rules are defined and match the agreed retention expectation
• The team knows who owns the bucket after go-live

A bucket can be created quickly. The bigger question is whether it is the right long-term location and whether lifecycle rules reflect a decision rather than a default. If no lifecycle rule is set, objects may be kept longer than required, which can become a cost and retention-control question.

Typical owner: Storage or OCI administrator

PM check: Confirm bucket name, compartment, owner, lifecycle rules, and retention expectation

Step 2: Log group and log source readiness

Next, confirm the source side.

Worth confirming:

• The log group exists: LOG_GROUP_NAME
• The compartment matches what will be used in the connector and policy
• Load Balancer logging is enabled
• Access and/or error logs are enabled as required
• Log retention on the individual log is set deliberately
• Logs are visible in OCI Logging before routing them anywhere

Connector Hub cannot move logs that are not being generated or collected. A common mistake is to start troubleshooting the connector when the real issue is that the source log was never enabled or no test traffic was generated.

Typical owner: OCI administrator or network owner

PM check: Confirm logs are visible in OCI Logging before moving to the connector step

Step 3: Load Balancer logging validation

For a Load Balancer, confirm what is actually enabled.

Worth confirming:

• Access logs are enabled where required
• Error logs are enabled where required
• The correct log group is selected
• Test traffic has been generated
• Log entries appear after that traffic

A load balancer can be working from an application point of view and still have incomplete logging. That is why validation should include a real traffic check.

Example validation:

1. Send a test request to LB_ENDPOINT_PLACEHOLDER
2. Allow a short interval for ingestion
3. Open OCI Logging
4. Confirm the expected records are visible

Typical owner: Network or OCI technical owner

PM check: Confirm there is evidence that logs appear after test traffic

Step 4: Connector Hub source and target configuration

Once logs are visible in OCI Logging, configure the connector.

Five points are worth understanding before validation.

Rollover settings control when objects appear. The connector writes on a batch interval or size threshold. An empty bucket shortly after activation does not always mean failure. Wait for at least one full rollover interval before investigating, and confirm the actual setting in the Console.

Confirm the source window. For a Logging source, validate with recent log records and make sure the source search window includes the test event. Oracle documents a limited source retention window for Connector Hub with Logging as the source, so a repaired connector may not move older records that have already fallen outside that window.

Objects are written compressed. Reviewers should expect compressed files rather than plain text. If the review process assumes a directly readable text file, it may stop at the first step. The decompression step should be part of the documented process.

A filter task can quietly remove what you need. Filters are useful, but they can also exclude expected records. If nothing arrives, test once with the filter removed or simplified.

Enable the connector’s own service log. This is one of the most useful validation items. It gives the team evidence when the connector succeeds, fails, or stops moving data.

The connector being created is not enough. The connector must be moving the right logs to the right place.

Typical owner: OCI administrator or observability owner

PM check: Confirm source selection, target bucket, connector state, and connector service log

Step 5: IAM and policy review

Permissions can block the flow even when the configuration looks correct.

Connector Hub evaluates the connector as the requesting principal for policy purposes. It does not simply inherit the permissions of the person who created it. In practice, the connector needs permission to read from the source and write to the target.

When a connector is created through the Console, default policies may be offered for the required authorization. Accepting them may be useful, but reviewing what they grant is better, because the default scope may be wider than intended.

Worth confirming:

• The user or group configuring the connector has the required permissions
• The connector has read access to the source logs
• The connector has write access to the target bucket
• The policy is applied at the correct compartment or tenancy scope
• Policy conditions are scoped appropriately where possible
• The team has documented who can update the connector later

Compartment values in the policy must match where the log group and bucket actually sit. A mismatch here can create a connector that looks configured but moves nothing.

From a PM point of view, this does not mean writing IAM policies personally. It means confirming that the dependency has been validated by the right owner.

Typical owner: IAM or OCI administrator

PM check: Confirm policy ownership and validation evidence

Step 6: End-to-end validation

Once the setup is complete, validate the full flow in order.

1. Generate traffic on the Load Balancer
2. Confirm logs appear in OCI Logging
3. Confirm the connector is active
4. Confirm the connector is moving data, using metrics or the connector service log
5. Confirm Object Storage receives objects under PREFIX, after at least one rollover interval
6. Download one object, decompress it, and open it
7. Confirm timestamp and content can be matched back to a known request
8. Confirm someone other than the person who built the flow can repeat the review

The important point is not only that something reached Object Storage. The stored object should be usable.

Step 8 is often the real operational test. If retrieval only works when the builder is available, it is not yet a control.

Validation evidence can include:

• Screenshot or export showing logs in OCI Logging
• Connector state and movement evidence over a known window
• Bucket listing showing newly created objects
• Confirmation that a sample object was decompressed and reviewed
• Named owner for ongoing review

Typical owner: OCI technical owner

PM check: Confirm evidence for each step

Expected result

At the end of validation, the team should be able to say:

• Load Balancer access and/or error logs are enabled as required
• Logs are visible in OCI Logging
• The connector is active and moving data
• Objects are reaching the expected bucket at an interval consistent with rollover settings
• A stored object has been retrieved, decompressed, and reviewed
• Retention is governed by lifecycle rules that match the agreed requirement
• The owner and escalation path are named

That statement is stronger than:

The connector was created.

A created connector is a configuration status. A validated log flow is operational evidence.

Troubleshooting

Work the flow in order: source, connector, target. That isolates the failure faster than checking everything at once.

Logs are not appearing in OCI Logging

Check:

• Is Load Balancer logging enabled?
• Is the correct log category enabled?
• Was test traffic generated?
• Is the correct compartment and log group being searched?
• Is the search time window wide enough?

Do not start with Object Storage if the logs are not visible at the source.

Connector is not active

Check:

• Connector lifecycle state
• Source and target configuration
• Required policy
• Connector service log, if enabled

One behaviour worth knowing: a connector that is not successfully moving data may be deactivated automatically by OCI. This can look like an unexplained stoppage after an earlier clean setup. It is also a strong reason to enable the connector service log and define a failure path. Current behaviour should be confirmed in the Oracle documentation.

Logs are not reaching Object Storage

Check:

• Has a full rollover interval elapsed?
• Is data volume below the batch size threshold?
• Is the correct bucket and compartment selected?
• Is write permission in place?
• Do the source logs actually exist for that window?
• Is the test event still within the Logging source window for Connector Hub?
• Are filters excluding the expected records?

Wrong bucket or compartment

Check:

• Bucket name and namespace
• Compartment and region
• Configured prefix or target path
• Bucket OCID where similar names exist across compartments

A connector can be working correctly and still deliver to a location nobody is checking.

Permission issue

Check:

• Were default policies declined at creation and never replaced?
• Are policy conditions too narrow, for example referencing the wrong connector or bucket?
• Was the policy created in the wrong compartment?
• Has enough time passed since the last policy change?

Permission problems should be owned clearly because they can sit between teams when ownership is undefined.

PM readiness checklist

This is the part I care about most from a delivery perspective.

The PM does not need to configure the connector. The PM needs to know who owns each step, what evidence confirms it, and what happens if the flow stops working later.

If several of items 11 to 14 are open, the control should be treated as partially implemented, regardless of how clean the configuration looks.

What I took from reviewing this pattern

OCI provides the services needed to collect and route logs without building a custom script-based process. The value comes from validation.

The real control is being able to prove the flow:

Collected → Routed → Stored → Retained → Reviewable

If any one of those is missing, the team may believe logging is ready when it is only partially configured. From a delivery point of view, that is the difference between a setup activity and an operational control.

The technical setup is only part of the control. The important question is whether the team can prove that logs are being collected, routed, retained, and reviewed when needed.

For log retention, I would not stop at “the connector is created.” I would ask:

• Can we prove the logs are being collected?
• Can we prove they are being routed?
• Can we prove they are stored in the expected bucket?
• Can we prove someone can retrieve and read them later?
• Can we prove someone owns the flow after go-live?

That is the evidence that supports operational readiness.

If you have used Connector Hub to route logs in OCI, I would be interested to know which validation check you consider most important before calling the setup complete.

References

Links and behaviour can change between releases. Confirm details against current documentation for your region and tenancy.

• Logging Overview
• Logging for Load Balancers
• Details for Load Balancer Logs
• Connector Hub Documentation Home
• Overview of Connector Hub
• Creating a Connector
• Creating a Connector with a Logging Source
• Scenario: Archiving Logs to Object Storage
• Managing Connectors
• Securing Connector Hub: IAM Policies
• Object Storage Overview
• Object Lifecycle Management
• Logging Analytics Documentation

Written as an independent review and validation exercise. No client environment, production system, or confidential information was used. All identifiers are placeholders. Feedback and corrections from the Oracle community are welcome.