Log Management Playbooks

Use these playbooks to operate Cloudaware Log Management (Conflux) consistently across cloud, host, SaaS, identity, and custom log sources.

Each procedure assumes Conflux is used with Cloudaware CMDB context so logs can be correlated with owners, applications, environments, accounts, regions, and related configuration items.

Validate Log Coverage

Use this playbook after onboarding a new cloud account, subscription, project, application, or environment.

1. Review expected sources in Requirements and Log Sources.
2. Confirm that the related resources exist in Cloudaware CMDB, including accounts, buckets, log groups, hosts, applications, and tags.
3. For cloud sources, verify that the provider-specific logging service is enabled:
   • AWS: CloudTrail, VPC Flow Logs, CloudWatch Logs, S3 access logs, ALB/ELB logs, CloudFront logs, RDS logs, or other relevant sources.
   • Microsoft Azure: Activity logs, diagnostic settings, flow logs, and storage destinations.
   • Google Cloud: Cloud Logging audit logs and configured export or access patterns.
4. Confirm that Cloudaware has the required permissions for the selected source. See Log Management Requirements.
5. In Conflux, open dashboards or saved searches and confirm that events arrive for the expected accounts, regions, resources, and time window.
6. Compare observed sources against the expected CMDB inventory. Record any missing source, owner, environment, and required remediation.

Triage Missing or Delayed Logs

Use this playbook when dashboards show ingestion gaps, delayed events, or an expected log source is absent.

1. Scope the issue:
   • Identify the source type, log index, account or project, region, resource, and time range.
   • Check whether the gap affects one source, one provider, or multiple sources.
2. Check source-side configuration:
   • For cloud logs, confirm that the service is still writing to the expected CloudWatch group, S3 bucket, Azure Storage account, Google Cloud Logging destination, or equivalent export target.
   • For host logs, confirm that Breeze and the relevant Beat agent are installed and that outbound connectivity to the Conflux endpoint is allowed.
   • For syslog, confirm the destination hostname, port, and protocol provided by Cloudaware.
3. Check permissions:
   • AWS S3 and CloudWatch sources require read/list permissions for the destination.
   • Encrypted AWS S3 buckets require decrypt access. See Custom Policy for S3 Decryption.
   • Azure flow logs require access to Storage Account keys. See Storage Account Keys and VM Extensions.
4. Check discovery metadata:
   • Confirm source tags such as log-source:apigateway, log-source:guardduty, or the relevant bucket labels where tag-based discovery is used.
   • Confirm that CMDB relationships and ownership metadata are present.
5. If the source is correctly configured but data is still missing, contact Cloudaware Support support@cloudaware.com with the source, index, account/subscription/project, region, time range, and sample resource identifiers.

Investigate a Security Event

Use this playbook when an alert, finding, or analyst report requires log investigation.

1. Start from the alert, finding, or affected CI in CMDB.
2. Pivot into Conflux through the Cloudaware Control Hub (Launcher).
3. Search the relevant log index for the incident window. Include identifiers such as:
   • user, role, or identity provider account
   • instance ID, bucket, database, load balancer, or application
   • source IP, destination IP, region, account, project, or subscription
   • request ID, event name, status code, or error code
4. Expand the time window before and after the first suspicious event to identify setup actions, repeated attempts, lateral movement, or cleanup activity.
5. Use CMDB context to determine owner, application, environment, business criticality, and related resources.
6. Save the search or dashboard view if the pattern should be reused.
7. Escalate through the appropriate incident process and include:
   • event timeline
   • affected resources
   • actor identities
   • CMDB owner/application context
   • recommended containment or follow-up actions

Investigate an Ingestion Spike

Use this playbook when Conflux shows unexpected volume growth or when storage and retention costs need review.

1. Identify the index, source type, account/project/subscription, host, or application responsible for the volume change.
2. Compare current volume with the normal baseline for the same source and time window.
3. Filter by fields such as service, event type, severity, host, application, source IP, and log group.
4. Determine whether the spike is expected:
   • new application or account onboarded
   • debug or verbose logging enabled
   • repeated authentication, network, or application errors
   • security incident or scanning activity
5. If the spike is expected, update retention, dashboard baselines, and owner documentation.
6. If the spike is unexpected, work with the source owner to reduce unnecessary debug logs, fix noisy errors, or route only required events.
7. Document the decision and expected new baseline.

Onboard a New Cloud Log Source

Use this playbook when adding a new AWS, Azure, or Google Cloud source to Conflux.

1. Confirm the provider account, subscription, or project is already connected to Cloudaware.
2. Enable the source-side logging service and destination.
3. Grant Cloudaware the required permissions.
4. Apply tags or labels required for discovery where applicable.
5. Confirm that the source appears in CMDB.
6. Confirm that events appear in Conflux under the expected index.
7. Create or update dashboards and saved searches for the source owner.
8. Record the owner, purpose, retention expectation, and escalation path.

See also:

• Integrations
• Log Management Requirements

Onboard a Custom or Syslog Source

Use this playbook when a team needs to send application, appliance, or custom logs to Conflux.

1. Identify the source owner, log format, expected volume, environment, and retention need.
2. Choose the ingestion pattern:
   • syslog for network and security appliances
   • HTTPS/API or webhook for SaaS or application events
   • host-based collection for files or operating system telemetry
3. Request the Conflux destination hostname, port, protocol, and authentication details from Cloudaware.
4. Configure the source to send events to the provided destination.
5. Add CMDB ownership and application context for the source.
6. Validate that events appear in Conflux and that timestamps, severity, source, application, and environment fields are usable for search.
7. Save a basic dashboard or saved search for the source owner.

Prepare Audit or Incident Evidence

Use this playbook when logs are needed for an audit, investigation, or post-incident review.

1. Define the scope:
   • time range
   • account, subscription, project, or environment
   • affected CI, application, owner, or user
   • relevant event types and indexes
2. Run a Conflux search for the scoped data.
3. Validate that the result set contains the required fields and CMDB context.
4. Save the search or export the result according to your organization’s evidence handling process.
5. Record:
   • query or filter criteria
   • export timestamp
   • requester and approver
   • retention or legal hold requirements
6. Store the evidence in the approved system of record and link it from the incident, change, or audit ticket.

Maintain Playbooks

Review these playbooks after major onboarding work, incidents, audits, or changes in provider logging. Keep links to dashboards, saved searches, CMDB views, and ownership records current.

For broader operational processes, see Log Management Operations.