Fix Wazuh GCP Pub/Sub Ingestion

Troubleshoot Authentication Problems

Authentication issues are among the most common reasons Wazuh fails to ingest Google Cloud Pub/Sub events.

Even when the Pub/Sub infrastructure is configured correctly, invalid credentials or insufficient permissions can prevent Wazuh from establishing a connection.

Work through the following checks to isolate authentication-related problems before investigating other parts of the ingestion pipeline.

Verify Service Account JSON Keys

The service account JSON key is the primary credential Wazuh uses to authenticate with Google Cloud.

Verify that:

• The file exists at the configured location.
• The file is valid JSON.
• The project ID matches the intended Google Cloud project.
• The private key has not been modified.
• The service account email is correct.
• The file has not been accidentally truncated or corrupted.

If multiple Google Cloud projects are managed from the same server, ensure Wazuh is using the correct credential file for the appropriate project.

For security reasons, store the credential file with restrictive permissions so that only the Wazuh service account can read it.

Check Key Expiration or Revocation

Although service account keys do not expire automatically, organizations often rotate or revoke them as part of their security policies.

Authentication failures can occur if:

• The key has been deleted.
• The key was revoked.
• A newer key replaced the old one.
• Organization policies disabled older credentials.
• The service account itself was removed.

Google Cloud audit logs can help determine whether a credential has recently been revoked or replaced.

If credential rotation is part of your security program, verify that Wazuh has been updated with the latest key immediately after rotation.

Confirm IAM Role Assignments

Successful authentication does not necessarily mean Wazuh has sufficient permissions to read Pub/Sub messages.

Review the service account’s effective IAM permissions and confirm it retains the necessary roles for your deployment.

Depending on your environment, the account may require permissions for:

• Pub/Sub subscriptions
• Cloud Logging exports
• IAM authentication
• Project-level resource access

Recent IAM policy changes are a frequent cause of previously working integrations suddenly failing.

Google recommends periodically auditing service account permissions to ensure they continue to align with operational requirements while maintaining least privilege.

Test Authentication Outside Wazuh

If authentication appears to fail, determine whether the problem lies with Google Cloud or with Wazuh itself.

Testing the service account independently can help isolate the issue.

For example, you can:

• Authenticate using the Google Cloud CLI with the same credential file.
• Attempt to access the Pub/Sub subscription.
• Retrieve project information.
• List available topics or subscriptions.

If authentication succeeds outside Wazuh but fails within Wazuh, the issue is more likely related to the Wazuh configuration rather than the credentials themselves.

Regenerate Credentials When Necessary

If all other authentication checks fail, creating a new service account key is often the fastest way to eliminate credential corruption or configuration problems.

After generating a replacement key:

1. Store it securely.
2. Update the credential path in the Wazuh configuration.
3. Remove any obsolete credential files.
4. Restart the appropriate Wazuh services.
5. Verify that Pub/Sub messages begin flowing again.

After replacing credentials, monitor Wazuh logs for successful authentication before assuming the issue has been resolved.

Fix Pub/Sub Subscription Issues

A healthy Pub/Sub subscription is essential for reliable log ingestion.

Even when logs are successfully published to a topic, configuration problems within the subscription can prevent Wazuh from receiving or processing messages correctly.

Verify Subscription Acknowledgements

Pub/Sub relies on message acknowledgements (ACKs) to determine whether a subscriber has successfully processed a message.

If acknowledgements are not being sent:

• Messages remain unacknowledged.
• Pub/Sub repeatedly redelivers events.
• Duplicate alerts may appear.
• Subscription backlog continues growing.

Review subscription metrics to confirm that acknowledgements are occurring at a steady rate and that the number of outstanding messages remains stable.

Repeated message redelivery is often a sign that Wazuh is retrieving messages but failing to complete processing.

Inspect Dead Letter Topics

Many production environments configure dead letter topics to capture messages that repeatedly fail delivery.

Inspect the dead letter topic for:

• Authentication failures
• Malformed messages
• Processing errors
• Retry exhaustion
• Unexpected message formats

Finding messages in the dead letter queue indicates that Pub/Sub is functioning, but message processing is failing somewhere in the pipeline.

Google recommends dead letter topics as a best practice for improving reliability and simplifying troubleshooting of failed message deliveries.

Check Message Retention Settings

Pub/Sub retains messages only for the configured retention period.

If retention is too short:

• Temporary outages may result in permanent data loss.
• Older security events may expire before Wazuh retrieves them.
• Recovery after maintenance becomes more difficult.

Verify that the retention period aligns with your operational requirements and expected recovery objectives.

Longer retention periods provide greater resilience during planned maintenance or unexpected service interruptions.

Review Subscription Filters

Subscription filters determine which messages are delivered to subscribers.

An overly restrictive filter can unintentionally exclude important security events.

Review filters for:

• Incorrect resource names
• Invalid log types
• Typographical errors
• Unexpected exclusions
• Outdated filtering logic

If only specific Google Cloud services are missing from Wazuh, subscription filters should be one of the first areas investigated.

Remove Stuck Messages

Occasionally, one or more problematic messages may repeatedly fail processing, preventing the subscription from progressing efficiently.

Symptoms include:

• Constant message retries
• Subscription backlog remaining unchanged
• Processing delays
• Duplicate deliveries

After identifying the problematic messages, consider:

• Correcting malformed events.
• Fixing the underlying parsing issue.
• Removing obsolete subscriptions if appropriate.
• Recreating the subscription when corruption is suspected.

Before deleting subscriptions or messages, verify that doing so will not result in the loss of security-relevant data.

Examine Wazuh Logs for Errors

Wazuh logs are often the fastest way to identify why Pub/Sub ingestion has stopped.

Most authentication failures, configuration errors, parsing problems, and communication issues generate detailed log entries that point directly to the underlying cause.

Review the following log sources in a systematic order.

Manager Logs

The Wazuh manager log is the primary source for diagnosing ingestion problems.

Look for entries related to:

• Authentication failures
• Pub/Sub connection attempts
• Cloud integration startup
• XML configuration errors
• Permission denied messages
• Module initialization failures
• Event processing errors

Pay close attention to the timestamp when ingestion stopped, as it often corresponds with configuration changes or infrastructure updates.

If the manager fails to load after configuration changes, see How to Fix ossec.conf Syntax Errors in Wazuh Agents.

Module Debug Logs

If the manager logs do not clearly identify the problem, review module-specific debug output.

Debug logging may reveal:

• API requests
• Authentication token generation
• Subscription polling
• Message retrieval
• JSON parsing
• Retry attempts
• Internal processing failures

These logs are particularly useful when Wazuh appears to connect successfully but fails while processing incoming Pub/Sub messages.

API Logs

Google Cloud integration relies heavily on API communication.

Review API-related log entries for errors such as:

• HTTP 401 Unauthorized
• HTTP 403 Forbidden
• HTTP 404 Resource Not Found
• HTTP 429 Rate Limited
• HTTP 500 Internal Server Error

Each status code typically points toward a different class of problem, making them valuable starting points during troubleshooting.

If authentication-related API errors occur elsewhere in your deployment, Wazuh API Authentication Failed? Causes and Solutions provides additional troubleshooting techniques that may also apply here.

Identify Common Error Messages

Certain log messages appear frequently during Pub/Sub ingestion failures.

Common examples include:

• Permission denied
• Authentication failed
• Subscription not found
• Invalid credentials
• Failed to acknowledge message
• Unable to retrieve access token
• Resource does not exist
• Connection timeout
• TLS handshake failed

Rather than treating these messages individually, look for recurring patterns that indicate failures within the same stage of the ingestion pipeline.

Maintaining a timeline of recurring errors can help determine whether the issue is intermittent or consistently reproducible.

Increase Logging Verbosity for Troubleshooting

If existing logs do not provide enough information, temporarily increase Wazuh’s logging verbosity.

Additional debug logging can expose:

• API request details
• Module execution flow
• Authentication exchanges
• Message processing stages
• Retry behavior
• Internal exceptions

Enable verbose logging only while troubleshooting, as excessive logging can increase disk usage and slightly impact performance in busy environments.

After resolving the issue, restore the normal logging level to reduce unnecessary log volume.

If you later encounter unusually large Wazuh log files after extended debugging sessions, Troubleshooting Broken Wazuh Log Rotations: Permission Denied Fixes can help ensure log rotation continues functioning correctly.

Validate Incoming Events

After correcting configuration or authentication issues, the final step is verifying that Google Cloud events successfully travel through the entire ingestion pipeline.

Simply confirming that Wazuh connects to Pub/Sub is not enough, you should validate every stage from message publication to searchable alerts in the dashboard.

A complete validation helps ensure there are no hidden issues with parsing, rule matching, or indexing.

Publish Test Messages

Begin by generating one or more known events in your Google Cloud environment.

Common test activities include:

• Creating a new Compute Engine instance
• Updating an IAM policy
• Uploading a file to a Cloud Storage bucket
• Modifying a firewall rule
• Creating or deleting a test resource
• Performing an authenticated API action

These actions should generate entries in Cloud Audit Logs or other configured log sources.

Alternatively, if appropriate for your environment, you can publish a test message directly to the Pub/Sub topic to verify that Wazuh successfully retrieves and processes it.

Using predictable test events makes it easier to confirm that the ingestion pipeline is functioning correctly.

Confirm Message Processing

After generating test events, verify that Wazuh is actually consuming messages from the subscription.

Indicators of successful processing include:

• Subscription backlog decreases.
• Messages are acknowledged.
• No authentication or permission errors appear.
• Processing logs show successful retrieval.
• No repeated retries occur.

If messages remain in the subscription indefinitely, Wazuh may still be failing during processing or acknowledgement.

Comparing Pub/Sub metrics before and after publishing a test event is often an effective way to verify successful consumption.

Verify Decoder Operation

Receiving a message does not necessarily mean Wazuh understands its contents.

Inspect the processed events to confirm that:

• JSON payloads are parsed correctly.
• Fields are extracted properly.
• Timestamps are accurate.
• Resource names appear correctly.
• Event types are identified.
• Cloud metadata is preserved.

If raw events appear but important fields are missing, decoder configuration may require adjustment.

When working with custom log formats or additional integrations, Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive provides detailed guidance on troubleshooting decoder behavior.

Check Alert Generation

After successful decoding, verify that Wazuh rules evaluate incoming events as expected.

Confirm that:

• Detection rules execute successfully.
• Expected alerts are generated.
• Alert severity levels are appropriate.
• Rule IDs match the intended detections.
• False positives remain minimal.

Not every cloud event should generate an alert, but security-relevant activities, such as IAM policy changes or administrative actions, should trigger the appropriate rules when configured correctly.

If expected detections are missing, review your custom rules or see How to Test Wazuh Rules and How to Create Custom Detection Rules in Wazuh (With Examples) .

Validate Indexed Events

Finally, confirm that processed events are successfully indexed and searchable within the Wazuh Dashboard.

Verify that:

• Events appear in Discover.
• Searches return expected results.
• Dashboards display current cloud activity.
• Timestamps are correct.
• Indexed fields contain expected values.
• No indexing errors are reported.

If events are processed but never appear in searches, the issue may exist within the indexing layer rather than the Pub/Sub integration.

For index-related problems, refer to Fixing Rejected Index Templates and Invalid Mapping Types in Wazuh and How to Fix a Yellow Cluster Status in Wazuh Indexer.

Resolve Performance and Scalability Problems

Large Google Cloud environments can generate thousands, or even millions, of log events every day.

As log volume increases, the ingestion pipeline must scale accordingly to maintain timely processing without introducing delays or losing visibility.

Addressing performance bottlenecks early helps prevent subscription backlogs and ensures that security events remain available for near real-time analysis.

Reduce Subscription Backlogs

Growing Pub/Sub subscription backlogs indicate that messages are arriving faster than Wazuh can process them.

Common causes include:

• Insufficient CPU resources
• Slow disk I/O
• Limited memory
• Network latency
• Parsing bottlenecks
• Inefficient indexing

Monitor backlog metrics regularly and investigate sustained growth before it begins affecting detection timelines.

Temporary spikes during high-activity periods are normal, but continuously increasing backlogs typically indicate an underlying capacity issue.

Optimize Polling Configuration

Polling behavior influences how efficiently Wazuh retrieves messages from Pub/Sub.

When reviewing your configuration, consider:

• Polling frequency
• Batch sizes
• Processing intervals
• Retry timing
• Acknowledgement behavior

Polling too frequently may increase API usage without improving throughput, while polling too infrequently can increase event latency.

Adjust these settings carefully and validate performance after each change rather than modifying multiple parameters simultaneously.

Monitor Resource Consumption

Continuous resource monitoring helps identify bottlenecks before they affect ingestion performance.

Track key metrics such as:

• CPU utilization
• Memory usage
• Disk I/O
• Network throughput
• Indexing latency
• Queue lengths
• Storage capacity

Resource utilization should be evaluated across every component involved in the ingestion pipeline, not just the Wazuh manager.

If resource usage continues increasing over time, investigate whether additional cloud services or log sources have recently been added.

Scale Wazuh Components

As ingestion volume grows, scaling individual Wazuh components may become necessary.

Depending on the workload, you may need to increase capacity for:

• Wazuh Manager
• Wazuh Indexer
• Dashboard infrastructure
• Storage systems
• Compute resources

Rather than focusing on a single component, evaluate the end-to-end ingestion pipeline to identify the actual bottleneck.

Organizations with larger deployments often benefit from distributed architectures that separate management, indexing, and visualization workloads.

If you’re expanding your deployment, How to Build a Wazuh Indexer Cluster provides guidance for scaling the indexing layer.

Improve Processing Throughput

Improving throughput often involves optimizing several smaller areas instead of relying on a single configuration change.

Potential improvements include:

• Reducing unnecessary log collection
• Optimizing Cloud Logging export filters
• Removing duplicate data sources
• Improving decoder efficiency
• Optimizing detection rules
• Increasing indexing performance
• Eliminating resource contention

Google’s Site Reliability Engineering (SRE) guidance emphasizes measuring end-to-end system performance and removing bottlenecks incrementally rather than optimizing isolated components.

Performance tuning should always be validated using measurable metrics such as ingestion latency, subscription backlog size, and processing throughput.

Prevent Future Wazuh GCP Pub/Sub Ingestion Issues

Once the integration is functioning correctly, implementing proactive operational practices can significantly reduce the likelihood of future outages.

Most production ingestion failures result from configuration drift, expired credentials, permission changes, or insufficient monitoring, issues that can often be prevented with routine maintenance.

Use Least-Privilege IAM Roles

Grant the Wazuh service account only the permissions required for log ingestion.

Avoid assigning broad administrative roles when narrower permissions are sufficient.

Benefits include:

• Reduced attack surface
• Easier security audits
• Lower risk of accidental privilege misuse
• Improved compliance with security best practices

Review role assignments whenever new Google Cloud services are integrated into the environment.

Monitor Subscription Health

Subscription metrics provide early warning signs of ingestion problems.

Regularly monitor:

• Subscription backlog
• Unacknowledged messages
• Delivery failures
• Retry counts
• Message age
• Throughput

Alerting on these metrics allows administrators to respond before delayed or missing logs impact security monitoring.

Google recommends using Cloud Monitoring to observe Pub/Sub health and detect abnormal processing behavior.

Rotate Service Account Keys Securely

Credential rotation is an important security practice, but it should be performed carefully to avoid service interruptions.

When rotating keys:

1. Generate the replacement credential.
2. Update Wazuh to use the new key.
3. Verify successful authentication.
4. Remove the old credential.
5. Confirm continued event ingestion.

Documenting this process helps minimize downtime during future rotations.

Enable Alerting for Failed Ingestion

Monitoring should include alerts that notify administrators when ingestion begins to fail.

Useful alert conditions include:

• Authentication failures
• Subscription backlog growth
• Missing cloud events
• Repeated processing errors
• High ingestion latency
• Module failures

Early detection significantly reduces the time required to restore complete security visibility.

Keep Wazuh Updated

Software updates often include:

• Bug fixes
• Performance improvements
• Security patches
• API compatibility updates
• Cloud integration enhancements

Maintaining supported Wazuh versions reduces the likelihood of encountering issues related to deprecated Google Cloud APIs or integration bugs.

Before upgrading production systems, validate compatibility in a staging environment whenever possible.

Regularly Test Log Collection

Do not assume the ingestion pipeline remains healthy simply because no alerts have been generated.

Instead, schedule periodic validation by:

• Generating known cloud events.
• Confirming Pub/Sub delivery.
• Verifying decoder output.
• Ensuring alerts trigger correctly.
• Checking indexed events in the dashboard.

Routine testing helps identify silent failures before they become operational incidents.

Document Configuration Changes

Maintain documentation for:

• IAM role assignments
• Service accounts
• Pub/Sub topics
• Subscription names
• Log Router sink filters
• Wazuh configuration files
• Credential rotation procedures

Good documentation makes troubleshooting significantly easier after personnel changes, infrastructure migrations, or future upgrades.

Store configuration changes in version control whenever practical to maintain a clear audit trail.

Audit Permissions Periodically

Cloud environments evolve continuously, and IAM permissions often change over time.

Perform periodic audits to verify that:

• Required roles remain assigned.
• Unused permissions have been removed.
• Service accounts are still active.
• Pub/Sub resources remain accessible.
• Organization policies have not introduced unexpected restrictions.

Regular permission reviews help maintain both security and operational reliability, reducing the likelihood of unexpected ingestion failures caused by configuration drift.

Best Practices for Managing Wazuh GCP Pub/Sub Integrations

A properly configured Wazuh GCP Pub/Sub integration should operate reliably with minimal maintenance.

However, cloud environments constantly change, and small configuration changes can introduce ingestion failures.

Following operational best practices helps maintain visibility, reduce troubleshooting time, and prevent unexpected security monitoring gaps.

Separate Production and Testing Topics

Avoid using the same Pub/Sub topics and subscriptions for both testing and production workloads.

Separating environments provides several benefits:

• Prevents test data from contaminating production monitoring.
• Reduces accidental configuration changes affecting live systems.
• Makes troubleshooting easier.
• Allows testing new configurations safely.
• Simplifies access control management.

A recommended approach is maintaining dedicated resources:

• Production Pub/Sub topics.
• Testing Pub/Sub topics.
• Separate subscriptions.
• Separate service accounts.

This allows administrators to validate configuration changes without risking production log ingestion.

Use Dedicated Service Accounts

Create a dedicated Google Cloud service account specifically for Wazuh ingestion rather than using shared administrative accounts.

Dedicated service accounts provide:

• Clear ownership of permissions.
• Easier auditing.
• Reduced security risk.
• Simplified credential rotation.
• Better compliance visibility.

Avoid attaching broad roles such as project owner or editor unless absolutely necessary. Instead, assign only the permissions required for Pub/Sub consumption and related logging access.

Separating service accounts by environment also makes it easier to identify which systems are accessing cloud resources.

Monitor Pub/Sub Metrics

Pub/Sub metrics provide valuable insight into the health of your Wazuh ingestion pipeline.

Important metrics to monitor include:

• Unacknowledged message count.
• Subscription backlog size.
• Oldest unacknowledged message age.
• Delivery latency.
• Acknowledgement failures.
• Message throughput.

A healthy integration should show consistent message consumption with minimal backlog growth.

Unexpected changes in these metrics can indicate:

• Wazuh service failures.
• Authentication issues.
• Resource exhaustion.
• Network problems.
• Configuration changes.

Enable Dead Letter Queues

Dead letter topics provide a safety mechanism for messages that cannot be processed successfully.

They help identify:

• Malformed log messages.
• Processing failures.
• Invalid payloads.
• Repeated delivery failures.

Using dead letter queues prevents problematic messages from continuously blocking normal processing.

Review dead letter messages periodically to identify recurring problems and improve ingestion reliability.

Protect Credential Files

Service account credential files contain sensitive authentication information and should be protected accordingly.

Recommended practices include:

• Restricting file permissions.
• Limiting access to the Wazuh service account.
• Avoiding storage in public repositories.
• Encrypting backups.
• Removing unused credential files.
• Rotating credentials periodically.

A compromised service account key could provide unauthorized access to Google Cloud resources, making credential security a critical part of the overall integration design.

Automate Configuration Backups

Regular backups protect against accidental configuration changes and simplify disaster recovery.

Backup important components such as:

• Wazuh configuration files.
• GCP service account settings.
• Pub/Sub topic configurations.
• Subscription settings.
• Log Router sink configurations.
• IAM role assignments.

Automation ensures backups occur consistently rather than relying on manual processes.

Version-controlled configuration management can also help identify when and why ingestion settings changed.

Review Google Cloud Audit Logs

Google Cloud Audit Logs provide visibility into administrative actions that may affect the Wazuh integration.

Regularly review events involving:

• Service account modifications.
• IAM policy changes.
• Pub/Sub configuration updates.
• API enablement changes.
• Log Router modifications.

Audit logs are especially useful when ingestion stops unexpectedly after a cloud administrator changes permissions or resources.

Periodically Validate End-to-End Log Flow

A healthy-looking Pub/Sub subscription does not guarantee that security events are reaching analysts.

Perform regular end-to-end validation:

1. Generate a controlled Google Cloud event.
2. Confirm the event appears in Cloud Logging.
3. Verify delivery to Pub/Sub.
4. Confirm Wazuh retrieves the message.
5. Validate decoding.
6. Confirm indexing.
7. Verify dashboard visibility.

Scheduled testing helps detect silent failures before they create security blind spots.

Frequently Asked Questions (FAQ)

Question: Why is Wazuh not receiving logs from GCP Pub/Sub?

Wazuh may stop receiving Google Cloud logs because of authentication problems, missing IAM permissions, incorrect Pub/Sub configuration, disabled APIs, network restrictions, or incorrect Wazuh integration settings.

The fastest troubleshooting approach is to verify the complete pipeline:

1. Confirm Cloud Logging is generating events.
2. Verify Log Router sinks are exporting logs.
3. Check Pub/Sub topics and subscriptions.
4. Validate service account permissions.
5. Review Wazuh logs for ingestion errors.

Question: Which IAM roles are required for Wazuh GCP Pub/Sub ingestion?

The exact permissions depend on your architecture, but the Wazuh service account generally requires permissions that allow it to consume messages from the Pub/Sub subscription.

Common permissions include:

• Pub/Sub subscriber access.
• Permission to authenticate with Google Cloud.
• Access required for the selected logging workflow.

Avoid granting excessive permissions and review effective IAM permissions regularly.

Question: How do I verify that Pub/Sub messages are being delivered?

You can verify message delivery by checking:

• Pub/Sub subscription backlog metrics.
• Acknowledged message counts.
• Delivery attempts.
• Message age.
• Manual message pulls.

A healthy subscription should show messages being consumed and acknowledged without continuous backlog growth.

Question: Can Wazuh ingest multiple Pub/Sub subscriptions?

Yes, Wazuh deployments can be configured to consume multiple Google Cloud data sources depending on the integration design.

Multiple subscriptions may be used for:

• Different projects.
• Separate environments.
• Different log categories.
• Organizational separation.

When scaling multiple subscriptions, monitor resource usage carefully to ensure the Wazuh manager can process the additional event volume.

Question: Why are Pub/Sub messages piling up in my subscription?

A growing Pub/Sub backlog usually means messages are being published faster than Wazuh can process them.

Common causes include:

• Wazuh service failures.
• Insufficient system resources.
• Authentication failures.
• Network connectivity issues.
• Processing bottlenecks.
• Large increases in cloud log volume.

Review both Pub/Sub metrics and Wazuh logs to determine where processing is stopping.

Question: How do I enable debug logging for the Wazuh GCP module?

Debug logging can be enabled by increasing Wazuh logging verbosity and restarting the relevant services.

Higher verbosity levels provide additional details about:

• Authentication attempts.
• API communication.
• Subscription polling.
• Message processing.
• Parsing failures.

Only enable detailed debugging temporarily because verbose logs can increase storage usage.

Question: Does Wazuh support all Google Cloud log types?

Wazuh can ingest many Google Cloud log sources through Pub/Sub, including:

• Cloud Audit Logs.
• VPC Flow Logs.
• Cloud DNS logs.
• Cloud Storage logs.
• Security Command Center findings.
• Other Cloud Logging sources.

However, availability depends on how logs are exported through Cloud Logging and how events are processed by Wazuh decoders and rules.

Question: How can I test my GCP Pub/Sub integration without generating production logs?

The safest approach is to create a controlled testing environment.

Options include:

• Creating a separate Google Cloud project.
• Using dedicated testing Pub/Sub topics.
• Creating temporary test resources.
• Publishing test messages manually.
• Using non-production log sources.

Testing in isolation prevents unnecessary alerts and avoids introducing artificial events into production monitoring.

Conclusion

Wazuh GCP Pub/Sub ingestion provides organizations with centralized visibility into Google Cloud security events, but maintaining a reliable pipeline requires careful configuration and ongoing monitoring.

The most common ingestion failures typically involve:

• Incorrect service account permissions.
• Invalid or expired credentials.
• Misconfigured Pub/Sub subscriptions.
• Incorrect Wazuh integration settings.
• Disabled Google Cloud APIs.
• Network connectivity restrictions.
• Resource limitations.

Successful troubleshooting requires validating both sides of the integration.

Google Cloud configuration must be verified by checking topics, subscriptions, IAM permissions, APIs, and Log Router sinks.

At the same time, Wazuh must be inspected for configuration errors, authentication problems, processing failures, and indexing issues.

A reliable GCP logging pipeline should not rely only on reactive troubleshooting.

Organizations should implement proactive practices such as monitoring Pub/Sub metrics, rotating credentials securely, testing log collection regularly, auditing permissions, and maintaining configuration backups.

By combining proper Google Cloud configuration with disciplined Wazuh maintenance, security teams can ensure that cloud telemetry remains available, timely, and actionable for threat detection and incident response.