Collect
OpenTelemetry
Structured logs and correlated IDs
Log shippers
Vector · Fluent Bit · Logstash
Kafka
Buffer high-volume event paths
All use cases
One retained signal path for incident evidence
Build a logs-first observability foundation
Collect operational events through the tools you already use, retain changing context and investigate with search and SQL from one data foundation.
All sources / last 1 hour
Unified event stream
ALL SOURCESAPPLICATIONKUBERNETESSECURITY
TIMESOURCELEVELMESSAGE
10:42:18.904checkout-apiERRORpayment upstream timeout · trace=8fa2
10:42:18.887k8s / podWARNreadiness probe failed · checkout-7c4
10:42:17.512doris-feINFOquery finished · latency=184ms
Error spike began 3 min after the checkout deploymentInvestigate →
Your dashboards show that something changed, but the evidence needed to explain it is split between short-lived logs, service metadata and separate operational stores.
Observability improves when the signal and the evidence behind it remain connected.
The pain
A signal is visible; its context is somewhere else
01
Collectors and schemas vary from team to team.
02
High-volume evidence is discarded before the next investigation.
03
Trace and service identifiers are present but difficult to correlate.
04
Search, aggregation and historical analysis follow different paths.
UNIFYLOGS / OBSERVABILITY DATA PATH
The whole signal path, not another isolated search box.
Unifylogs is strongest as a logs-first observability foundation: keep high-volume operational evidence together, preserve context and move from fast retrieval to analytical SQL without exporting the incident.
Ingest
Source templates
App · Kubernetes · security
Routine Load
Continuous Kafka consumption
Stream Load
HTTP push from services
Store & index
Inverted indexes
Structured and full-text retrieval
VARIANT
Evolving nested attributes
Time lifecycle
Partitioned retention by workload
Investigate
Log Explorer
Timeline · search · filters
SQL Studio
Join, group and correlate
Shared context
Service · host · pod · trace ID
Act
Dashboards
Operational views and trends
AI assistance
Evidence-backed investigation
Team workflows
Export or connect downstream
Logs-first by design. Trace IDs and metric-like aggregates can enrich an investigation without implying a full APM or tracing replacement.
BUILD PLAN / LOGS-FIRST OBSERVABILITY
Connect the incident path before expanding the signal set
Begin with the evidence behind one recurring alert. Preserve correlation fields, retention and source context, then prove that the same incident can move from search to SQL without a manual export.
01Collectors · OTel
02Kafka · HTTP
03Doris event tables
04Explorer · SQL · export
- Partition events by time and set retention per signal workload.
- Index message and high-value identity fields; keep changing attributes in VARIANT.
- Carry service, host, pod and trace identifiers as typed correlation columns.
- Materialize only repeated operational aggregations after measuring their query pattern.
- Use source templates to standardize the first application and infrastructure feeds.
- Validate the generated collector configuration and table design before deployment.
- Investigate the same retained event set in Log Explorer and SQL Studio.
- Share bounded query results with existing dashboard and response workflows.
BEFORE CUTOVER
Acceptance gates
- 1Alert window is reproducible
- 2Correlation IDs survive ingestion
- 3Retention matches incident needs
- 4No manual export is needed for the test question
What changes
The operating pattern changes—not only the tool.
- One durable starting point for operational investigations
- Shared service and infrastructure context across teams
- Search and analytical questions on the same retained data
- A logs-first foundation that complements metrics and tracing tools
CONTACT / HUBSPOT
Bring one workload. Leave with a measured decision.
We’ll map the current cost and investigation path, then define success criteria before you replace anything.