Database Monitoring — Required Attributes

Coralogix Database Monitoring (UI: APM → Database Catalog) gives visibility into every database that instrumented services interact with — query times, query failures, failure rates, and per-database / per-operation drilldowns. It is built from spans whose attributes follow the OpenTelemetry database client semantic conventions.

Coralogix-supported target attributes

The Database Catalog currently needs all five of these Coralogix-supported target attributes on every database client span. If any one is missing, the corresponding row in the Databases Grid does not populate, and the Operations / Queries drilldowns go blank. In support answers, list these five target names first. Treat stable/newer OTel names such as db.system.name, db.namespace, db.operation.name, db.query.text, server.address, and network.peer.address as bridge inputs, not as replacements for the target set.

Source: Database Monitoring — Coralogix. For new instrumentation, do not create legacy-only spans. Emit the latest stable OpenTelemetry database attributes first, then mirror them into the Coralogix-supported target names above until Coralogix APM reads the stable names directly.

Current DB semconv compatibility bridge

Do not ask customers to downgrade their SDKs. Keep the stable OTel attributes as the primary source, but mirror them into the names Coralogix APM / Database Catalog reads today before Span Metrics consumes the spans. A complete answer must say the newer names are inputs to the bridge: the bridge still writes db.system, db.name, db.operation, db.statement, and net.peer.name for the current Coralogix Database Catalog path.

DB system value compatibility

Attribute names are not the only compatibility point. Some newer instrumentation emits newer DBMS values under db.system.name, for example microsoft.sql_server, while existing Coralogix UI grouping or icons may still expect older db.system values such as mssql.

When a database row is present but icon/grouping/filter behavior is wrong:

1. Compare both the attribute name and the value.
2. Preserve the stable source attribute for future compatibility.
3. Add a temporary product compatibility mapping only where the current Coralogix surface requires it.
4. Prefer product/backend support for both values over asking customers to downgrade or delete stable semconv attributes.

Minimal OTTL shape, to be adapted by the opentelemetry-ottl skill:

processors:
  transform/db_semconv_compat:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - set(attributes["db.system"], attributes["db.system.name"]) where attributes["db.system"] == nil and attributes["db.system.name"] != nil
          - set(attributes["db.name"], attributes["db.namespace"]) where attributes["db.name"] == nil and attributes["db.namespace"] != nil
          - set(attributes["db.operation"], attributes["db.operation.name"]) where attributes["db.operation"] == nil and attributes["db.operation.name"] != nil
          - set(attributes["db.statement"], attributes["db.query.text"]) where attributes["db.statement"] == nil and attributes["db.query.text"] != nil
          - set(attributes["net.peer.name"], attributes["server.address"]) where attributes["net.peer.name"] == nil and attributes["server.address"] != nil
          - set(attributes["net.peer.name"], attributes["network.peer.address"]) where attributes["net.peer.name"] == nil and attributes["network.peer.address"] != nil

Put this in the traces pipeline before Span Metrics / APM derive catalog metrics. This is current Coralogix compatibility, not broad legacy migration coverage.

Span shape — what the catalog reads

For each database client span:

1. Top-level span kind = CLIENT. Database calls instrumented with INTERNAL kind do not appear in dependency views. Do not set a span attribute named span.kind; use the SDK SpanKind.CLIENT / collector span kind field.
2. Stable OpenTelemetry DB attributes on the span for new instrumentation, plus the five Coralogix-supported mirror attributes above while Coralogix APM still requires them.
3. The standard service identity attributes on the resource — service.name, service.version, etc. (see apm-service-catalog.md).

What the catalog surfaces

• Databases Grid — aggregates by database name (db.name). Filter by any tag or process tag on the calling service.
• Database Overview — performance over time per database, per calling-operation, per query.
• Database Operations — query metrics grouped by db.operation and table.
• Database Queries — per-db.statement rows with span detail and trace links.

Common reasons the catalog stays empty

SpanMetrics dimensions used downstream

The Span Metrics connector emits these as label dimensions on the generated metrics so the Database Catalog can aggregate them: db_namespace, db_operation_name, db_collection_name, db_system. See spanmetrics.md.

References

• Coralogix: Database Monitoring
• OpenTelemetry: Database client spans
• OTel attribute registry — db.* namespace
• apm-service-catalog.md — the resource-level attributes also required for any APM feature
• spanmetrics.md — how db.* attributes become metric labels