Optimize Your Logs with Ollama and the ELK Stack

techhadoop ai, ELK, llm

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.

Leave a Reply