Kibana MCP Server: Connect an AI Assistant to Log Investigations

A Kibana MCP server lets an AI assistant search log data, query Elasticsearch indexes behind Kibana, and retrieve metric summaries — all within a conversation. Instead of writing and re-running queries manually, you describe what you are looking for and the assistant proposes and runs the search. Tools like fenbs keep the sanitized investigation conclusions and follow-up tasks in a shared record, so the next person or assistant who investigates the same service starts from what was already learned.

Kibana and the Elastic Stack have been building AI integration capabilities into their platform. Check the Elastic documentation for the current AI assistant and MCP integration options before relying on a community server. Either way, the principles for scoping access and handling sensitive log data apply regardless of implementation.

Set read-only scope before connecting

Create a dedicated Kibana user or API key for the MCP connection with read-only access to the index patterns you need. Do not use an admin account. In Kibana, this means granting read privilege on specific index patterns and read access to the relevant data views. The assistant should be able to search and retrieve; it should not be able to modify dashboards, delete indexes, or change alerts.

Be precise about which index patterns the connection can access. Production logs for the service under investigation are appropriate. Logs for unrelated services, security audit logs, or indexes with personal data are not.

What a Kibana MCP server can do

With read access, an assistant can search log messages, filter by time range and log level, aggregate counts and rates, and identify patterns across a set of log events. Typical investigation tasks include finding the first occurrence of an error, counting its frequency over a time window, identifying which services were affected, and correlating error spikes with deployment timestamps.

• Search log messages by keyword, error code, or pattern.
• Filter by time range to narrow investigation to a specific incident window.
• Count error occurrences and rate over time to assess severity.
• Identify the first occurrence of an error to help pinpoint the root cause.
• Correlate log events across services using trace IDs or request identifiers.

Connect the Kibana MCP server

A Kibana MCP server typically needs the Kibana URL, an API key or username and password for the read-only user, and the index patterns it is allowed to search. Pass credentials as environment variables, not as values in the configuration file. If you use the Elastic Cloud, the API key endpoint is at the Cloud console; for self-hosted Kibana, generate a key under Stack Management and restrict it to the minimum necessary privileges.

Test the connection by asking the assistant to count documents in a low-traffic index before running any investigation. Confirm the result is plausible and that the server returns an error rather than crashing when the assistant queries an index it does not have access to. A predictable error response is important: a crash or a timeout is harder to diagnose than a clear permission error.

Handle sensitive log data carefully

Production logs often contain personally identifiable information (PII), customer data, or security-sensitive content. Before asking an assistant to analyze a log, confirm what the log entries contain. Do not paste raw log lines with customer names, email addresses, IP addresses used for identification, or authentication tokens into any shared or stored context. If the assistant needs to summarize a log pattern, have it describe the pattern without reproducing the sensitive values.

When recording investigation findings outside Kibana — in fenbs or any shared note — write sanitized summaries that describe the error type and root cause without including raw log content. "A null pointer exception in the payment service affected roughly 200 requests between 14:00 and 14:15 UTC" is a useful conclusion. Repeating the full stack traces with customer IDs is not.

Record findings and lessons where the next investigation starts

Every incident investigation produces knowledge: what the error means, what caused it, how it was resolved, and what to check first next time. Without a record, the next engineer investigating the same service in three months starts from scratch. fenbs keeps sanitized conclusions as context notes and Lessons learned, so the next assistant or person has the investigation history before they write a single query.

How to manage Kibana investigations with fenbs

Record investigation outcomes in fenbs at the end of each session. A brief note takes two minutes and can save hours the next time.

1. Create a free account and start a project for the service you investigate. Describe the service, its log sources, and the index patterns used.
2. Write Decisions and rules for investigation scope: which index patterns the assistant may search, what data must be kept out of notes, and what requires escalation.
3. After each incident, add a sanitized context note: the error type, root cause, affected time window, and resolution. No raw log lines.
4. Add a Lesson learned for anything the investigation revealed that should change how future investigations are handled.
5. Connect your assistant via Integrations so it reads the investigation history before starting a new query session.