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.
| Clock | What it controls | Where it is set |
|---|---|---|
| Logging retention | How long the log data stays inside OCI Logging | On the individual log |
| Object Storage lifecycle | How long the exported copy stays in the bucket | On the bucket, through lifecycle rules |
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.
| Stage | What needs to be proved | OCI area involved |
|---|---|---|
| Collect | Load Balancer logs are generated and visible | Load Balancer and OCI Logging |
| Route | Selected log records are moving through the connector | Connector Hub |
| Retain | Log objects land in the expected bucket and lifecycle rules match the retention requirement | Object Storage |
| Review | A sample object can be retrieved, decompressed, and read by someone other than the builder | Object Storage and operating owner |
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
| Service | Role in this flow |
|---|---|
| OCI Load Balancer | Produces access or error logs |
| OCI Logging | Collects and stores logs |
| Log Group | Logical container for logs within a compartment |
| Connector Hub | Moves logs from Logging to a target service |
| Object Storage | Destination where log objects are retained |
| Logging Analytics, optional | Useful when deeper parsing, search, dashboards, or analysis are required later |
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:
- Send a test request to
LB_ENDPOINT_PLACEHOLDER - Allow a short interval for ingestion
- Open OCI Logging
- 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.
| Setting | Value or placeholder |
|---|---|
| Connector name | CONNECTOR_NAME |
| Source service | Logging |
| Source compartment | COMPARTMENT_NAME |
| Log group | LOG_GROUP_NAME |
| Logs | Access log and/or error log, based on requirement |
| Task, optional | Log filter query |
| Target service | Object Storage |
| Target bucket | BUCKET_NAME |
| Object name prefix | PREFIX |
| Source review window | Confirm recent source logs exist for the validation window |
| Batch rollover size or time | Set deliberately |
| Connector service log | Enabled |
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.
- Generate traffic on the Load Balancer
- Confirm logs appear in OCI Logging
- Confirm the connector is active
- Confirm the connector is moving data, using metrics or the connector service log
- Confirm Object Storage receives objects under
PREFIX, after at least one rollover interval - Download one object, decompress it, and open it
- Confirm timestamp and content can be matched back to a known request
- 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.
| # | Item to confirm | Evidence | Typical owner |
|---|---|---|---|
| 1 | Load Balancer access and/or error logs enabled as required | Log configuration reviewed | Network / OCI owner |
| 2 | Logs visible in OCI Logging | Sample log entries | OCI administrator |
| 3 | Correct log group selected | Log group name and compartment | OCI administrator |
| 4 | Object Storage bucket ready | Bucket name, compartment, owner | Storage owner |
| 5 | Connector source and target configured | Configuration reviewed | OCI administrator |
| 6 | Connector service log enabled | Connector log visible | OCI administrator |
| 7 | IAM policy validated | Policy confirmed by IAM owner | IAM owner |
| 8 | Test traffic generated | Test request record | Technical owner |
| 9 | Objects delivered to the bucket | New objects visible under prefix | Storage / OCI owner |
| 10 | Sample object retrieved and reviewed | Decompressed sample, redacted if needed | Technical owner |
| 11 | Retention expectation documented | Requirement stated, lifecycle rules match | Service owner |
| 12 | Failure path defined | Alarm or scheduled check with a named recipient | Service owner |
| 13 | Retrieval repeatable by a second person | Confirmation from a second reviewer | PM / Service owner |
| 14 | Ongoing monitoring owner named | Named owner and escalation path | PM / Service owner |
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.
Top comments (0)