integrate Elasticsearch/ELK with Ollama like this:

Filebeat / Logstash
        ↓
Elasticsearch  ← Kibana dashboards
        ↓
Python log-analysis API
        ↓
Ollama local LLM
        ↓
AI summary / root cause / recommendation

1. Install Ollama model

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1
# or lighter:
ollama pull mistral

Test:

ollama run llama3.1

2. Python script to analyze Elasticsearch logs with Ollama

pip install elasticsearch requests

from elasticsearch import Elasticsearch
import requests
ES_URL = "http://localhost:9200"
OLLAMA_URL = "http://localhost:11434/api/generate"
INDEX = "filebeat-*"
es = Elasticsearch(ES_URL)
query = {
    "size": 50,
    "sort": [{"@timestamp": {"order": "desc"}}],
    "query": {
        "bool": {
            "must": [
                {"match": {"log.level": "error"}}
            ]
        }
    }
}
result = es.search(index=INDEX, body=query)
logs = []
for hit in result["hits"]["hits"]:
    src = hit["_source"]
    logs.append(str(src.get("message", src)))
log_text = "\n".join(logs)
prompt = f"""
You are a senior DevOps/SRE log analyst.
Analyze these logs and provide:
1. Summary
2. Possible root cause
3. Impact
4. Recommended fix
5. Exact next commands to troubleshoot
Logs:
{log_text}
"""
payload = {
    "model": "llama3.1",
    "prompt": prompt,
    "stream": False
}
response = requests.post(OLLAMA_URL, json=payload)
print(response.json()["response"])

Run:

python3 analyze_logs.py

3. Better Elasticsearch query examples

For Docker errors:

{
  "size": 100,
  "query": {
    "bool": {
      "must": [
        { "match": { "container.name": "kong" }},
        { "match": { "message": "error" }}
      ]
    }
  }
}

For last 15 minutes:

{
  "size": 100,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-15m"
      }
    }
  }
}

4. Best architecture for your ELK setup

For your Docker/syslog environment:

Linux servers
  ├── Filebeat syslog
  ├── Filebeat Docker logs
  ↓
Central Logstash
  ↓
Elasticsearch
  ↓
AI Analyzer Service
  ↓
Ollama
  ↓
Kibana / Email / Slack report

5. Example AI output you can generate

Incident Summary:
Kong is returning intermittent 500 errors.
Likely Root Cause:
Upstream service closed the connection before Kong received a valid response.
Evidence:
- upstream prematurely closed connection
- HTTP 500 from upstream
- repeated failures from same container
Recommended Actions:
1. Check upstream container logs
2. Verify health checks
3. Check Kong upstream timeout settings
4. Check DNS resolution from Kong container

For production, do not send all logs to Ollama. First filter in Elasticsearch, then send only relevant errors/warnings to the model.

Here are the two detailed ways to integrate Ollama with the ELK Stack based on your structural preference.

• Option 1: The Ingest Pipeline Method (Recommended) – Uses Elasticsearch’s Native Inference API to call Ollama directly whenever a log document is indexed.
• Option 2: The Logstash Method – Enriches logs mid-flight before they reach Elasticsearch.

Option 1: Using Elasticsearch’s Native Inference API (Modern Way)

Elasticsearch includes a built-in Inference API that natively treats Ollama as an OpenAI-compatible provider. This eliminates the need for middleman scripts.

[Raw Error Log] ──> [Elasticsearch Ingest Pipeline] ──> [Ollama Inference API] ──> [Enriched Log Document]

Step 1: Allow Elasticsearch to Communicate with Ollama

By default, Ollama only listens to localhost. If Elasticsearch is running on a different server or container, you must configure Ollama to accept external connections.

• Linux (systemd): Run systemctl edit ollama.service and add:Ini, TOML[Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Save and run systemctl daemon-reload && systemctl restart ollama.
• Windows: Set a system environment variable named OLLAMA_HOST to 0.0.0.0:11434 and restart Ollama.

Step 2: Download Your Analytics Model

Pull a technical model designed for reasoning or code analytics (like mistral or llama3.2):

Bash

ollama pull mistral

Step 3: Define the Inference Model in Elasticsearch

Run this command inside Kibana’s Dev Tools (Console) to register Ollama as an inference service. (Replace the URL if Elasticsearch is calling an external machine IP).

JSON

PUT _inference/text_completion/ollama_log_analyzer
{
  "service": "openai",
  "service_settings": {
    "api_key": "not-needed-for-local",
    "url": "http://localhost:11434/v1/chat/completions",
    "model": "mistral"
  }
}

Step 4: Create an Ingest Pipeline

This pipeline instructs Elasticsearch to intercept any incoming log file, run it through the inference model we defined above, and save the AI analysis to a new field called ai_summary.

JSON

PUT _ingest/pipeline/log_ai_enrichment_pipeline
{
  "description": "Analyzes error logs using local Ollama instance",
  "processors": [
    {
      "inference": {
        "model_id": "ollama_log_analyzer",
        "input_output": [
          {
            "input_field": "message",
            "output_field": "ai_summary"
          }
        ],
        "task_settings": {
          "user": "Explain this system log error concisely in one sentence and provide a brief fix recommendation."
        }
      }
    }
  ]
}

Step 5: Route Logs to the Pipeline

When configuring Filebeat, Logstash, or Elastic Agent, specify your new pipeline in the configuration.

For a quick test, manually index a document using the pipeline:

JSON

POST my-system-logs/_doc/1?pipeline=log_ai_enrichment_pipeline
{
  "message": "FATAL: connection back-off failure, system.db.Pool empty. Max capacity 50 reached."
}

When you view the document, it will contain a populated ai_summary field containing Ollama’s localized insight.

Option 2: Using the Logstash Mid-Flight Method

If you already use Logstash to process and transform your logs before shipping them to Elasticsearch, you can leverage Logstash’s http filter plugin to interact with Ollama dynamically.

Step 1: Configure logstash.conf

Open your logstash configuration file and place an conditional block in the filter section. You should isolate the AI triggers to error or critical logs so you do not flood your LLM with benign info logs.

Ruby

input {
  beats {
    port => 5044
  }
}
filter {
  # Only trigger Ollama on actual system faults
  if [log][level] == "error" or [log][level] == "critical" {
    
    http {
      url => "http://localhost:11434/api/generate"
      method => "post"
      
      # Structuring the payload contextually
      body => '{"model": "mistral", "prompt": "Analyze this system error. Provide a 1-sentence root cause explanation and a 1-sentence fix. Log: %{[message]}", "stream": false}'
      
      headers => {
        "Content-Type" => "application/json"
      }
      
      # Temporary target field for the raw response JSON
      target_body => "[@metadata][ollama_raw]"
    }
    # Extract the clean text out of the API response structure
    if [@metadata][ollama_raw] {
      json {
        source => "[@metadata][ollama_raw]"
        target => "[ollama_parsed]"
      }
      
      mutate {
        add_field => { "ai_analysis" => "%{[ollama_parsed][response]}" }
      }
    }
  }
}
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "production-logs-%{+YYYY.MM.dd}"
  }
}

Step 6: Mapping the Output in Kibana

No matter which architecture option you choose, the resulting fields flow natively into your indexes.

1. Head to Kibana -> Discover.
2. Refresh your index pattern or create a new data view matching my-system-logs-* or production-logs-*.
3. Add the fields message and ai_analysis (or ai_summary) directly to your active column view for real-time localized troubleshooting triage.

When presenting local AI log analysis to executives, skip the raw code, config files, and API endpoints. Executives care about three things: reducing system downtime, maximizing engineering efficiency, and keeping data secure and cost-effective.

Frame this initiative as a business efficiency upgrade rather than a cool engineering experiment.

1. The Core Pitch (The 30-Second Hook)

“Right now, when a critical system fails, our engineers spend valuable time digging through thousands of lines of cryptic error logs to find the root cause. By integrating a secure, local Large Language Model directly into our existing ELK monitoring stack, we can automatically translate complex raw errors into instant, plain-English root causes and action items. This slashes our Mean Time to Resolution (MTTR), protects our intellectual property, and incurs zero monthly cloud vendor fees.”

2. High-Level Architecture (The Strategic Flow)

Your executive slide deck should simplify the technical implementation down to its raw business value stream. Avoid technical deep-dives on Logstash filters.

[Raw System Logs] ──> [ELK Filtering Engine] ──> [Secure, Local AI (Ollama)] ──> [Kibana Dashboard]
                                                                                      │
                                                                                      ▼
                                                                           Instant Plain-English
                                                                           Root Cause & Fixes
                                                                           

3. Key Business Pillars to Highlight

Drop in MTTR (Mean Time to Resolution)

• The Problem: Junior engineers or on-call staff often struggle to decode advanced stack traces, escalating issues to senior architects and delaying fixes.
• The AI Solution: The ELK dashboard instantly populates a clear “AI Analysis” field alongside the error. On-call staff can patch the issue immediately without waking up tier-3 support teams.

Ironclad Data Privacy & Security

• The Problem: Sending proprietary application data, user metadata, or internal system logs to external APIs (like OpenAI or Anthropic) introduces massive compliance risks and potential data leaks.
• The AI Solution: Ollama runs entirely on-premise on our hardware. Our system logs never leave our secure network perimeter, ensuring full compliance with privacy regulations (GDPR, SOC 2, HIPAA).

Zero Scaling / Token Costs

• The Problem: Commercial LLM APIs charge per “token” (word fragment). Processing gigabytes of streaming infrastructure logs through a cloud API would generate an astronomical monthly bill.
• The AI Solution: By leveraging local hardware and open-weights models (like Mistral or Llama), our operational cost is flat-rate power and hardware amortization. No surprise subscription fees or variable usage spikes.

4. Before vs. After (The Visual Reality)

Show the executives exactly what an engineer sees in Kibana today versus what they will see after this implementation.

5. Proposed Next Steps (The Proof of Concept)

Conclude by asking for approval to run a low-risk, zero-budget trial.

• Phase 1 (2 Weeks): Spin up a local instance on an existing development machine. Route a non-production log stream (e.g., staging environment) into it.
• Phase 2 (1 Week): Measure accuracy and evaluate the quality of the AI’s troubleshooting suggestions with the engineering team.
• Phase 3: Report back on verified time-savings before asking for dedicated production hardware resources (GPUs).

Here is how to set up Ollama on your computer to run large language models locally.

1. Download and Install

• Mac: Download the zip file from the Ollama website, unzip it, and drag Ollama to your Applications folder.
• Windows: Download the Windows installer (OllamaSetup.exe) from the website and run it.
• Linux: Run the following command in your terminal:Bashcurl -fsSL https://ollama.com/install.sh | sh

2. Verify the Installation

Open your terminal (Mac/Linux) or Command Prompt/PowerShell (Windows) and type:

Bash

ollama --version

If it returns a version number, Ollama is running.

3. Run a Model

To download and start chatting with a model, use the ollama run command followed by the model name. For example, to run Llama 3:

Bash

ollama run llama3

The first time you run this, Ollama will download the model weights (usually a few gigabytes), so it might take a few minutes depending on your internet speed.

Once the download finishes, you will see a >>> prompt. You can now type your questions and chat with the model directly in your terminal.

4. Useful Commands

• /bye : Type this inside the chat prompt to exit the model.
• ollama list : Shows all the models you have downloaded on your machine.
• ollama rm <model_name> : Deletes a downloaded model to free up space.
• ollama pull <model_name> : Downloads or updates a model without opening the chat interface.

Popular Models to Try

• ollama run mistral (Great all-rounder)
• ollama run phi3 (Lightweight and fast for lower-spec machines)
• ollama run codegemma (Tuned for coding tasks)

Integrating Ollama with the ELK Stack (Elasticsearch, Logstash, Kibana) allows you to bring the power of localized Large Language Models directly to your log telemetry. Instead of manually writing complex regex or staring at lines of stack traces, you can use Ollama to explain cryptic error codes, detect anomalous behavior, and summarize massive log spikes.

There are two primary architectural patterns to achieve this:

• Pattern A (Reactive Pipeline): Passing logs through a Python script or Logstash webhook into Ollama before indexing them into Elasticsearch.
• Pattern B (Elastic Inference API): Using Elasticsearch’s native AI capabilities to query Ollama directly as an external inference service.

Below is the implementation guide for Pattern A, which is the most reliable, customizable, and widely used method for custom AI log processing.

The Architecture

1. Logstash / Filebeat collects the logs.
2. An Intermediate Processor (Logstash Webhook or a Python Worker) intercepts the logs, calls Ollama’s local HTTP API, and gets an AI summary or anomaly score.
3. The enriched log (Original data + AI Explanation) is indexed into Elasticsearch.
4. You visualize the AI-generated insights in Kibana.

Step 1: Prepare your Local Ollama Model

You want a model that is fast and skilled at code or technical troubleshooting. Mistral, Llama3, or Phi3 are highly recommended.

1. Start Ollama and pull your model:Bashollama pull mistral
2. Verify that Ollama’s local API is listening on port 11434 by querying it via curl:Bashcurl http://localhost:11434/api/generate -d '{ "model": "mistral", "prompt": "What does a 500 Internal Server Error mean?", "stream": false }'

Step 2: Set up the Ingestion and AI Enrichment

Because logs stream continuously and can overwhelm an LLM, you typically want to filter logs so only Errors or Warnings get sent to Ollama.

You can accomplish this using Logstash’s HTTP Filter plugin to dynamically call Ollama during ingestion.

Logstash Configuration (logstash.conf)

Ruby

input {
  # Your standard log input (e.g., Filebeat, Syslog, Beats)
  beats {
    port => 5044
  }
}
filter {
  # 1. Filter out info logs; only process actual errors through the LLM to save CPU/GPU cycles
  if [log][level] == "error" or [log][level] == "critical" {
    
    # 2. Use the HTTP filter to hit Ollama's local API
    http {
      url => "http://localhost:11434/api/generate"
      method => "post"
      
      # Craft a robust system prompt + your raw log message
      body => '{"model": "mistral", "prompt": "Analyze this system log. Provide a 1-sentence root cause explanation and a 1-sentence fix. Log: %{[message]}", "stream": false}'
      
      headers => {
        "Content-Type" => "application/json"
      }
      
      # Target field where Ollama's JSON response will land
      target_body => "[@metadata][ollama_response]"
    }
    # 3. Parse out the textual string from Ollama's JSON structure
    if [@metadata][ollama_response] {
      json {
        source => "[@metadata][ollama_response]"
        target => "[ollama]"
      }
      
      # Rename the output to a clean root-level field
      mutate {
        add_field => { "ai_analysis" => "%{[ollama][response]}" }
      }
    }
  }
}
output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "ollama-enriched-logs-%{+YYYY.MM.dd}"
    # user => "elastic"      # Uncomment if security is enabled
    # password => "changeme" # Uncomment if security is enabled
  }
}

Step 3: View the Results in Kibana

Once Logstash restarts with the updated configuration, look at your incoming indices.

1. Go to Kibana -> Management -> Data Views and create a view for ollama-enriched-logs-*.
2. Navigate to Discover.
3. Add the field message (your raw system error) alongside your brand new custom field: ai_analysis.

Example of what you’ll see in Kibana:

• message: [2026-07-08 14:02:11] FATAL: connection back-off failure, system.db.Pool empty. Max capacity 50 reached.
• ai_analysis: Root Cause: The application has exhausted its database connection pool because connections aren’t being closed properly. Fix: Increase the max_connections parameter in your database configuration or audit your code for connection leaks.

Advanced Architecture Strategy: Vector Search (RAG)

If you have massive logs and don’t want Logstash to trigger Ollama sequentially for every single error, you should shift to a RAG (Retrieval-Augmented Generation) workflow using Elasticsearch as a Vector Database.

1. You use an embedding model (like ollama pull nomic-embed-text) to convert error logs into vectors.
2. Store these vectors in Elasticsearch natively using the dense_vector field type.
3. When a new system anomaly breaks out, write a Python/LangChain script to fetch similar past errors from Elasticsearch, bundle them together, and feed them into Ollama. This lets Ollama explain the current issue using historical context unique to your company’s network stack.