Skip to main content

Log Sources

This guide describes the log sources Conflux can collect and how those sources are discovered, classified, and mapped to the CMDB context across your environment.

Cloud Provider Sources​

Conflux typically collects:

  • AWS
    • API/audit logs such as CloudTrail.
    • Network logs such as VPC Flow Logs.
    • Access and delivery logs such as ALB/ELB, CloudFront, and S3 access logs.
  • Microsoft Azure
    • Network and security logs.
    • Activity and audit logs.
  • Google Cloud
    • Audit logs from Cloud Logging.

Cloudaware CMDB helps map accounts, buckets, log groups, and other log destinations to the applications, teams, and environments they support.

Host‑Level and OS Sources​

Conflux supports host-level and OS telemetry collected through agents such as:

  • Metricbeat for metrics and system events
  • Filebeat for file-based logs
  • Winlogbeat for Windows event logs
  • Packetbeat for network traffic

These agents are useful for operating system visibility, application logs on servers, and network telemetry, where cloud‑native logs are not sufficient.

Identity, SaaS, and Network Services​

Examples include:

  • Identity providers — Okta, OneLogin, and other IAM platforms, typically through API tokens.
  • SaaS applications — GitLab audit streaming, Cloudflare logs, and similar integrations.
  • Network and security appliances — firewalls, VPNs, proxies, and other devices through syslog or log exports.

These logs provide critical context for security investigations, access reviews, and compliance workflows.

CMDB‑Driven Discovery​

Rather than relying only on manually configured log pipelines, Conflux uses CMDB discovery to identify expected log sources and locate their destinations:

  • New resources, such as buckets, databases, and load balancers, appear in Cloudaware CMDB as they are created.
  • Conflux uses CMDB inventory to determine which accounts, resources, and destinations should be checked for supported log types.
  • Coverage can be checked by comparing expected log sources from CMDB with the sources that are actually ingested.

This reduces blind spots and makes it easier to maintain complete log coverage in large, dynamic environments.