Use Elastic Cloud with Sazabi: ship logs and search Elasticsearch

Last verified on Nov 8, 2026.

Elastic Cloud usually holds the logs a team has kept for years in Elasticsearch indices. Sazabi, the AI-native observability and security platform, can take those logs in as a stream, and it can search the same indices live through Elastic's own MCP server. The two paths are independent: connecting one does not enable the other.

What each source sends

Log source. There are two routes out of Elastic. Elastic Agent 8.13 or later runs in otel mode, which Elastic describes as an embedded OTel Collector that reads the standard Collector configuration format. You point an otlphttp/sazabi exporter at your intake URL and keep a filelog receiver on the files you care about. The other route is a self-managed Logstash pipeline. Its elasticsearch input polls logs-* on a schedule, wraps each document into an OTLP log record body, and an http output posts it to /v1/logs on your intake. Logstash has to run outside Elastic Cloud, because Kibana Pipelines does not execute pipelines.

MCP connector. Elastic Cloud hosts an MCP server inside Kibana at /api/agent_builder/mcp. Sazabi builds that URL from your Kibana base URL and sends your Elastic API key as the Authorization header. The agent can search indices with Query DSL, list indices and read field mappings, fetch a document by ID, call custom Agent Builder tools you defined in Kibana, and analyze logs, metrics and traces stored in Elasticsearch.

Questions it answers

• Which Elasticsearch index holds the logs for this service, and what are its mappings?
• Did the same error show up in the logs Elastic Agent forwarded and in the indices Kibana already shows?
• What does the document with this ID contain, field by field?
• Can a custom Agent Builder tool our team wrote answer this in one call?
• Is the gap in Sazabi a collector problem, or did the Logstash poll stop?

A worked example: finding the right index before you query it

Your team keeps checkout logs in Elasticsearch, and an incident thread needs numbers from them. Elastic's built-in tool reference lists platform.core.list_indices, platform.core.get_index_mapping, platform.core.search and platform.core.get_document_by_id. The Sazabi agent can walk that same ladder when you ask:

Which indices on our Elastic Cloud deployment hold checkout logs?
Show me the mapping for the one that matches, then find the five most
recent error documents and open the first one by ID.

A typical sequence is list_indices to find candidates, get_index_mapping to see which fields exist, search for recent errors, and get_document_by_id for the full record. Elastic documents platform.core.search as accepting natural language and choosing between Query DSL and ES|QL itself, so you do not need to write either.

If the agent finds nothing, check the API key first. The key needs read and view_index_metadata on the indices in question, and an index outside that grant is invisible to the agent. If your Kibana uses a custom space, remember Elastic serves the endpoint at /s/{SPACE_ID}/api/agent_builder/mcp, so the space name matters. Once you know the index, the log-source path can carry its newest documents into Sazabi for continuous search.

How it fits with other integrations

Elastic Agent's otel mode shares its exporter shape with OpenTelemetry, so a Collector you already run can send to Sazabi the same way. If you ship logs from Kubernetes nodes, Fluent Bit forwards container and host logs the same way. Elasticsearch sits alongside Datadog and others in the observability tools category, and the integrations index lists every method.