Schema explorer
Overview
Schema Explorer helps you unify and control the structure of your logs in Coralogix. Since logs often come from many sources with different naming conventions, inconsistencies can quickly make analysis harder.
The Schema Explorer automatically detects, highlights, and reports on these differences so you can:
- Prevent duplicate fields.
- Reduce query errors caused by inconsistent keys.
- Discover and resolve duplicate or conflicting fields.
- Provide feedback to developers when fields are misaligned.
How it works
- Ingestion – Coralogix ingests all log fields, regardless of structure or naming convention.
- Detection – Schema Management identifies duplicate or similar keys.
- Analysis – You can explore how each field is used, how often it appears, and its unique values.
- Unification – Align conflicting keys into a single schema, ensuring consistency across teams and services.
Select a dataspace and dataset
Schema Explorer scopes every report to a single dataset. Two selectors at the top of the report control what you're viewing:
- Dataspace — the data tier. Options appear in a fixed order:
default, thenfrequentsearch(when your account sends Frequent Search data), then any others, withsystemlast. - Dataset — the data type within that dataspace, such as
logsorspans.
Select a dataspace, then a dataset, to load its report. Switching either selector loads the matching schema.
View your Frequent Search logs schema
The logs dataset in the default dataspace covers all your logs. If your account sends high-priority Frequent Search logs, the frequentsearch dataspace appears as its own entry, letting you inspect the hot-tier logs schema on its own — the same field-level report you get for every other dataset.
To view it:
- Go to Data Flow → Schema Manager and select the Schema explorer tab.
- Select frequentsearch as the dataspace.
- Select logs as the dataset.
The report shows the fields, mapping status, popularity, and cardinality for your Frequent Search logs only. The default logs report is unchanged and continues to cover all logs, so you can switch between the two to compare the hot-tier schema against your full log schema.
The frequentsearch dataspace appears only if your account has Frequent Search data. This split applies to logs, not spans.
Key features
Schema Explorer provides a complete view of the fields ingested across your logs. For each field, you can see:
- Path — The field name and location.
- Description — A short, AI-generated explanation of what the field represents. See Field descriptions for details.
- Mapping status — Indexing status for the selected time range:
- Mapped — Indexed.
- Unmapped — Not indexed.
- Partially mapped — Indexed for part of the time range.
- Mapping exceptions — The count of mapping exceptions, which occur when multiple applications send the same field with different data types.
- Type — Data type (string, numeric, object, and so on).
- Popularity over time — How frequently the field appears.
- Cardinality — Number of unique values and how it changes over time.
- First seen / Last seen — When the field was ingested.
This helps you identify fields that may be redundant, inconsistent, or unexpectedly missing.
Report frequency and retention
Schema Explorer captures schema reports on a recurring schedule so you can track how your fields change over time. Use the report frequency selector to choose how often Coralogix generates a report:
| Frequency | Retention |
|---|---|
| Daily | 30 days |
| Weekly | 12 weeks |
| Monthly | 24 months |
Daily and weekly reports are best for catching recent mapping exceptions and naming drift. Monthly reports give you a longer-term view of schema growth for governance and capacity planning.
Field descriptions
The Description column on the Schema explorer tab shows a short, AI-generated description for each field, scoped per dataset (for example, the logs or spans dataset in the default dataspace). Descriptions are generated by Olly and give you context for what a field represents without leaving Schema Explorer.
Descriptions are stored separately from schema snapshots and update instantly when edited — they do not depend on data volume or re-ingestion.
View a field description
- Go to Data Flow → Schema Manager and select the Schema explorer tab.
- Find the field in the grid and read its description in the Description column.
- If the description is truncated, hover over or select the field to view the full text.
Edit a field description
You can correct or replace AI-generated descriptions for user-defined fields. OpenTelemetry (OTEL) and system-defined fields are read-only — their descriptions are canonical and cannot be edited.
To edit a description:
- In the Description column, select the description for a user-defined field. The Edit description modal opens.
- Update the text.
- Select Save.
Your edit persists across sessions and is reflected in Olly's subsequent analysis of the field. Olly does not overwrite user-edited descriptions.
OTEL and system fields
Fields defined by OpenTelemetry conventions or reserved by the system show a lock indicator in the Description column and open in read-only view when selected. This ensures well-known standard fields stay consistent across teams.
User-defined fields — any field your applications send that is not part of the OTEL or system set — are editable.
Example scenario
You have three services sending user data:
- Service A uses
surname - Service B uses
familyname - Service C uses
family-name
Without Schema Management, your queries might miss data because the fields don’t match. With Schema Management, you can detect these variations and map them to a unified key such as last_name.
Explore fields in Schema Explorer
- Go to Data Flow → Schema Manager and select the Schema explorer tab.
- Use the search bar to find specific fields.
- Review each field's description, popularity, type, mapping status, and cardinality to identify duplicates or inconsistencies.
- Select a description in the Description column to view or edit field descriptions.
- Use Mapping Exceptions to align similar fields into a single schema.
Best practices
- Regularly check for new fields ingested to catch inconsistent naming early.
- Standardize field names with your development teams to reduce mapping exceptions.
- Reserve fields for critical identifiers that must remain consistent across services.
To take schema governance a step further, Coralogix provides Reserved Fields which are a way to explicitly define the fields that matter most for your queries, alerts, and dashboards. While Schema Explorer helps you discover and analyze fields, Reserved Fields let you lock in critical ones, ensuring they are always indexed with the correct type and available for use.
Next steps
Explicitly define fields of importance for querying and monitoring with Reserved fields.
