DEV Community: Misbah Ulhaq

Teaching Your Spring Boot App to Think: LLM Tool Calling with Groq and Spring AI

Misbah Ulhaq — Mon, 08 Jun 2026 18:08:07 +0000

Large language models are powerful, but they become much more useful when they can work with real application data.

That is where tool calling comes in.

Tool calling allows an LLM to call backend functions, APIs, or services before producing its final answer. Instead of guessing about live data, the model can ask your application for the information it needs, receive the result, and then respond with better context.

In this tutorial, we will build a small Spring Boot application where a user can ask a question such as:

Should I go out today in Ashburn, VA?

The application will let the LLM call Java methods to fetch current weather and top news headlines, then combine both results into a practical answer.

Note: This article uses Spring AI 1.0.0-M1 with Groq through Spring AI's OpenAI-compatible configuration. Spring AI has continued evolving, so if you are using a newer Spring AI version, check the current Tools API documentation and adjust the .functions(...) usage accordingly.

What We Are Building

We are building a simple chat application with:

A Spring Boot backend
A vanilla HTML/JavaScript frontend
A Groq-hosted LLM
Two Java tools:
- get_weather
- get_news

The flow looks like this:

The user sends a message from the browser.
Spring Boot forwards the message to the LLM.
The LLM decides whether it needs weather or news data.
Spring AI invokes the matching Java function.
The tool result is sent back to the LLM.
The LLM generates the final answer for the user.

Here is the homepage:

Prerequisites

You will need:

Java 21
Maven 3.9 or later
A Groq API key
Basic Spring Boot knowledge

Groq provides an OpenAI-compatible API, which makes it possible to configure Spring AI's OpenAI integration to call Groq instead of OpenAI.

Project Structure

java-mcp-weather-news/
├── pom.xml
└── src/main/
    ├── java/com/mulhaq/mcp/
    │   ├── McpWeatherNewsApplication.java
    │   ├── config/
    │   │   └── GroqConfig.java
    │   ├── tools/
    │   │   ├── WeatherService.java
    │   │   └── NewsService.java
    │   └── controller/
    │       └── ChatController.java
    └── resources/
        ├── application.properties
        └── static/
            └── index.html

How Tool Registration Works

In this version of the project, the tools are registered as Spring beans using Java's Function<Request, Response> interface.

The basic pattern is:

Create a Java function that performs a useful backend action.
Register that function as a Spring @Bean.
Add a clear @Description.
Reference the tool by name when calling the ChatClient.

Example:

chatClient.prompt()
    .system(systemPrompt)
    .user(message)
    .functions("get_weather", "get_news")
    .call()
    .content();

Spring AI sends the tool definitions to the model. If the model decides that it needs live data, it returns a tool call. Spring AI then invokes the matching Java function, sends the tool result back to the model, and receives the final response.

The important idea is that the LLM does not directly call external services. Your backend controls which tools exist, what they can do, and what data they return.

WeatherService.java

The weather service fetches current weather from wttr.in. This keeps the demo simple because no separate weather API key is required.

package com.mulhaq.mcp.tools;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Service for fetching real-time weather data from wttr.in.
 * No API key is required.
 */
@Service
public class WeatherService {

    private static final Logger log = LoggerFactory.getLogger(WeatherService.class);
    private static final String WTTR_URL = "https://wttr.in/%s?format=j1";

    private final RestTemplate restTemplate;
    private final ObjectMapper objectMapper;

    public WeatherService(RestTemplate restTemplate, ObjectMapper objectMapper) {
        this.restTemplate = restTemplate;
        this.objectMapper = objectMapper;
    }

    public String getWeather(String city) {
        try {
            String url = String.format(WTTR_URL, city.replace(" ", "+"));
            String json = restTemplate.getForObject(url, String.class);

            JsonNode root = objectMapper.readTree(json);
            JsonNode current = root.path("current_condition").get(0);
            JsonNode area = root.path("nearest_area").get(0);

            String condition = current.path("weatherDesc").get(0).path("value").asText("Unknown");
            int tempC = current.path("temp_C").asInt(0);
            int tempF = current.path("temp_F").asInt(0);
            int windKph = current.path("windspeedKmph").asInt(0);
            int humidity = current.path("humidity").asInt(0);
            String areaName = area.path("areaName").get(0).path("value").asText(city);
            String country = area.path("country").get(0).path("value").asText("");

            return String.format(
                "Weather in %s%s: %s, %d°C (%d°F), Wind: %d km/h, Humidity: %d%%",
                areaName,
                country.isEmpty() ? "" : ", " + country,
                condition,
                tempC,
                tempF,
                windKph,
                humidity
            );
        } catch (Exception e) {
            log.error("Error fetching weather for {}: {}", city, e.getMessage());
            return "Unable to fetch weather for " + city + ": " + e.getMessage();
        }
    }
}

This service returns a short, human-readable summary. That format is intentional: the LLM does not need the full raw JSON response. It only needs the useful weather facts.

NewsService.java

The news service fetches the top five headlines from the BBC News RSS feed.

package com.mulhaq.mcp.tools;

import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.ByteArrayInputStream;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;

/**
 * Service for fetching top news headlines from the BBC News RSS feed.
 * Uses Java's DOM parser to handle RSS content reliably.
 */
@Service
public class NewsService {

    private static final Logger log = LoggerFactory.getLogger(NewsService.class);
    private static final String BBC_RSS = "https://feeds.bbci.co.uk/news/rss.xml";

    private final RestTemplate restTemplate;

    public NewsService(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    public String getTopNews() {
        try {
            String xml = restTemplate.getForObject(BBC_RSS, String.class);

            DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
            factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
            factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

            DocumentBuilder docBuilder = factory.newDocumentBuilder();
            Document doc = docBuilder.parse(
                new ByteArrayInputStream(xml.getBytes(StandardCharsets.UTF_8))
            );

            doc.getDocumentElement().normalize();

            NodeList items = doc.getElementsByTagName("item");
            int limit = Math.min(5, items.getLength());

            List<String> headlines = new ArrayList<>();
            for (int i = 0; i < limit; i++) {
                Element item = (Element) items.item(i);
                String title = getTagText(item, "title");
                String description = getTagText(item, "description");

                StringBuilder entry = new StringBuilder((i + 1) + ". " + title);

                if (description != null && !description.isBlank()) {
                    String clean = description.replaceAll("<[^>]*>", "").trim();
                    if (clean.length() > 120) {
                        clean = clean.substring(0, 120) + "...";
                    }
                    entry.append("\n   ").append(clean);
                }

                headlines.add(entry.toString());
            }

            log.info("Fetched {} news headlines", limit);
            return "Top News Headlines:\n" + String.join("\n", headlines);

        } catch (Exception e) {
            log.error("Error fetching news: {}", e.getMessage());
            return "Unable to fetch news: " + e.getMessage();
        }
    }

    private String getTagText(Element parent, String tagName) {
        NodeList nodes = parent.getElementsByTagName(tagName);
        return nodes.getLength() > 0 ? nodes.item(0).getTextContent().trim() : null;
    }
}

I used Java's built-in DOM parser here because RSS feeds can contain CDATA and HTML-like text. For this small use case, the DOM parser is simple and reliable.

One security detail is important: external XML entities are disabled. This helps reduce the risk of XML External Entity issues when parsing XML from an external source.

GroqConfig.java

This configuration class wires together the ChatClient, RestTemplate, and the two tool functions.

package com.mulhaq.mcp.config;

import com.mulhaq.mcp.tools.WeatherService;
import com.mulhaq.mcp.tools.NewsService;
import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.boot.web.client.RestTemplateBuilder;
import org.springframework.boot.web.client.RestClientCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Description;
import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;
import org.springframework.web.client.RestTemplate;
import java.time.Duration;
import java.util.function.Function;

@Configuration
public class GroqConfig {

    /**
     * Tolerant ObjectMapper that ignores unknown JSON fields.
     * This is useful when using OpenAI-compatible providers that may
     * return additional response fields.
     */
    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper()
                .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
    }

    /**
     * Injects the tolerant ObjectMapper into Spring AI's internal RestClient.
     */
    @Bean
    public RestClientCustomizer restClientCustomizer(ObjectMapper mapper) {
        return builder -> builder
                .messageConverters(converters -> {
                    converters.removeIf(c -> c instanceof MappingJackson2HttpMessageConverter);
                    converters.add(0, new MappingJackson2HttpMessageConverter(mapper));
                });
    }

    @Bean
    public ChatClient chatClient(ChatClient.Builder builder) {
        return builder.build();
    }

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder, ObjectMapper mapper) {
        return builder
                .setConnectTimeout(Duration.ofSeconds(10))
                .setReadTimeout(Duration.ofSeconds(10))
                .additionalMessageConverters(new MappingJackson2HttpMessageConverter(mapper))
                .build();
    }

    @Bean
    @Description("Get current weather for a city. Input: city name, for example 'Ashburn, VA'. Returns temperature, condition, wind speed, and humidity.")
    public Function<WeatherRequest, String> get_weather(WeatherService weatherService) {
        return request -> weatherService.getWeather(request.city());
    }

    @Bean
    @Description("Get the top 5 current news headlines from BBC News. No input is required.")
    public Function<NewsRequest, String> get_news(NewsService newsService) {
        return request -> newsService.getTopNews();
    }

    public record WeatherRequest(
        @com.fasterxml.jackson.annotation.JsonProperty(required = true, value = "city")
        String city
    ) {}

    public record NewsRequest() {}
}

The @Description text matters more than it may seem. It tells the model when and how to use the tool. A vague description can cause the model to skip the tool or call it with the wrong input.

ChatController.java

The controller exposes one endpoint: POST /api/chat.

package com.mulhaq.mcp.controller;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.web.bind.annotation.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.Map;

/**
 * POST /api/chat
 * Accepts a user message and returns an AI-generated response.
 */
@RestController
@RequestMapping("/api")
@CrossOrigin(origins = "*")
public class ChatController {

    private static final Logger log = LoggerFactory.getLogger(ChatController.class);
    private final ChatClient chatClient;

    public ChatController(ChatClient chatClient) {
        this.chatClient = chatClient;
    }

    @PostMapping("/chat")
    public Map<String, String> chat(@RequestBody Map<String, String> request) {
        String message = request.get("message");
        log.debug("Chat request: {}", message);

        try {
            String systemPrompt = """
                You are a helpful assistant with access to real-time weather and news data.
                When the user asks about weather, call the get_weather tool with the city name.
                When the user asks about news, call the get_news tool.
                When a combined decision is needed, such as "Should I go out today?",
                call both tools and reason over the results.
                Be concise, practical, and friendly.
                """;

            String response = chatClient.prompt()
                    .system(systemPrompt)
                    .user(message)
                    .functions("get_weather", "get_news")
                    .call()
                    .content();

            return Map.of("response", response);

        } catch (Exception e) {
            log.error("Error while processing chat request: {}", e.getMessage(), e);
            return Map.of("response", "Sorry, something went wrong: " + e.getMessage());
        }
    }
}

The key line is:

.functions("get_weather", "get_news")

Those names match the bean names from GroqConfig. Spring AI uses them to expose the functions as callable tools for the model.

For a production app, I would not keep @CrossOrigin(origins = "*"). It is acceptable for a local demo, but production systems should restrict allowed origins.

application.properties

spring.ai.openai.api-key=YOUR_GROQ_API_KEY_HERE
spring.ai.openai.base-url=https://api.groq.com/openai
spring.ai.openai.chat.options.model=llama-3.3-70b-versatile

server.port=8080

logging.level.root=INFO
logging.level.com.mulhaq.mcp=DEBUG

Do not commit your real API key. Use an environment variable or secret manager when deploying the application.

Also note the base URL:

spring.ai.openai.base-url=https://api.groq.com/openai

Spring AI appends the remaining OpenAI-compatible path internally. If you add /v1 here in this Spring AI setup, you may run into a 404 because the final URL can become incorrect.

Frontend

The frontend is intentionally simple. It lives in:

src/main/resources/static/index.html

It sends a request like this:

{
  "message": "Should I go out today in Ashburn, VA?"
}

to:

POST /api/chat

Spring Boot serves the page directly, so no React, Angular, or separate frontend build is needed.

You can find the full UI code in the repository:

https://github.com/mulhaq/blogs/tree/main/java-mcp-weather-news

Demo

Type your question:

The AI responds using real tool results:

Behind the scenes, this happens in one request:

The browser sends the user message to POST /api/chat.
Spring AI sends the message and tool definitions to Groq.
Groq returns tool calls such as get_weather("Ashburn, VA") and get_news().
Spring AI invokes the Java methods.
The tool results are sent back to Groq.
Groq generates the final answer.
The response is returned to the browser.

Problems I Hit While Building This

Problem 1: Groq Returned Extra Fields

I saw an error similar to this:

UnrecognizedPropertyException: Unrecognized field "queue_time"
(class org.springframework.ai.openai.api.OpenAiApi$Usage)

Groq may return response fields that are not declared in Spring AI's OpenAI response model for this version. Jackson rejects unknown fields unless configured otherwise.

The fix was to register a custom ObjectMapper with:

.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)

and apply it to the message converter used by Spring AI's internal client.

Problem 2: RSS Parsing Failed with XmlMapper

I also saw an RSS parsing issue similar to this:

Cannot construct instance of RssItem: no String-argument constructor

The simpler fix was to use Java's DOM parser instead of forcing the RSS feed into a strict Jackson XML object model.

For this demo, the DOM parser was enough because I only needed a few fields from the RSS feed.

Production Improvements

This demo is intentionally small, but the same pattern can be extended. Before using this in production, I would improve the following areas:

1. Replace demo APIs with reliable providers

wttr.in and public RSS feeds are good for demos. A production app should use reliable APIs with rate limits, uptime guarantees, and predictable response formats.

2. Validate tool inputs

The model may call a tool with missing or unclear input. Validate city names, limit input length, and return safe error messages.

3. Add timeouts and retries

The current code has timeouts, but production systems should also include retries, circuit breakers, and clear fallback behavior.

4. Restrict CORS

@CrossOrigin(origins = "*") should not be used in production. Restrict it to your frontend domain.

5. Add observability

Log tool calls, latency, failure rates, and model responses. This helps debug tool behavior and understand when the model is using tools correctly.

6. Upgrade carefully

Spring AI has been evolving quickly. If you move from this M1 version to a newer release, review the current Tools API and migration notes before copying this code directly.

Ideas to Extend This Project

You can add more tools, such as:

Stock price lookup
Calendar availability
Internal database search
Customer profile lookup
Order status lookup
CRM updates

The pattern stays the same: expose a controlled Java method as a tool, describe it clearly, and let the LLM decide when it needs to call it.

Conclusion

Tool calling is one of the most useful patterns for building real-world LLM applications.

In this project, we built a Spring Boot app where the model can call Java methods to fetch live weather and news data before answering the user. This makes the application more useful than a normal chatbot because the model can reason over current data.

The biggest lesson is that tool calling is not only an AI feature. It is also a backend architecture pattern. Your application must define safe tools, validate inputs, handle errors, and control what the model can access.

Full source code:

https://github.com/mulhaq/blogs/tree/main/java-mcp-weather-news

Run it locally:

git clone https://github.com/mulhaq/blogs.git
cd blogs/java-mcp-weather-news

# Edit application.properties and add your Groq API key
mvn spring-boot:run

Then open:

http://localhost:8080

Happy building.

Turning Server Logs into Incident Summaries with Java and Groq

Misbah Ulhaq — Wed, 06 May 2026 01:50:26 +0000

I built a small Java CLI that uses Groq’s LLM API to turn noisy server logs into structured incident summaries: root cause, severity, affected components, and suggested fixes.

Introduction

Server logs are useful, but during an incident they can also become overwhelming.

A single failure can produce hundreds or thousands of lines in a few minutes. You search for ERROR, skim stack traces, follow timestamps, jump between services, and slowly piece together what actually happened.

The problem is not that logs are useless. The problem is that logs are raw events, not explanations.

I built ai-log-analyzer to explore a simple idea:

Can a Java CLI turn noisy server logs into a short, structured incident summary using an LLM?

This is not meant to replace observability platforms, incident response workflows, or proper monitoring. It is a small developer tool that shows how LLMs can help summarize unstructured operational data.

The goal was simple:

Input: a plain-text log file
Processing: split the file into LLM-friendly chunks
Output: root cause, severity, affected components, fix suggestions, and summary
Constraint: keep the setup minimal and easy to run locally

The Problem: Logs Are Events, Not Intelligence

Here is a familiar debugging flow:

A service starts failing.
You open the logs.
You see a wall of timestamps, warnings, retries, and stack traces.
You grep for ERROR.
You still have to figure out which event actually matters.

Logs tell you what happened. They do not always tell you why it happened or what to do next.

That analysis still lands on the engineer.

This project tries to reduce that manual step. Instead of reading every line yourself, the tool sends chunks of logs to an LLM and asks for a structured analysis.

Architecture

The architecture is intentionally small.

The project has three main pieces:

LogChunker — reads the log file and breaks it into smaller chunks
GroqClient — sends each chunk to Groq’s API and parses the response
AnalysisResult — stores the structured result returned by the model

Why Groq?

Groq has a straightforward API, low-latency inference, and easy access to models like llama-3.3-70b-versatile. For this project, I wanted something simple enough to call from a Java CLI without adding unnecessary infrastructure.

Why Java 21 HttpClient?

Java 21’s built-in HttpClient is good enough for this use case. I did not want to add an external HTTP dependency just to make one API call.

Why Maven Shade?

The Maven Shade plugin produces a single executable JAR. That makes the tool easy to build and run without classpath issues.

Project Structure

java-ai-log-analyzer/
├── pom.xml
├── README.md
├── sample-logs/
│   └── app.log
└── src/main/java/com/mulhaq/loganalyzer/
    ├── LogAnalyzer.java      # main entry point and CLI handling
    ├── GroqClient.java       # Groq API calls
    ├── LogChunker.java       # reads and chunks log files
    └── AnalysisResult.java   # structured analysis result

Stack and Tooling

The project uses:

Java 21
Maven
Jackson for JSON parsing
Groq API
Maven Shade plugin for a runnable JAR

The build command is:

mvn clean package

The output is:

target/java-ai-log-analyzer-1.0-shaded.jar

Key Implementation Pieces

1. LogChunker: Splitting the Log File

LLMs have context limits, so the tool does not send the entire log file in one request. It splits the file into smaller chunks.

public class LogChunker {
    private static final int CHUNK_SIZE = 3000;

    public static List<String> chunkLogFile(String filePath) throws Exception {
        String content = Files.readString(Paths.get(filePath));
        List<String> chunks = new ArrayList<>();
        int length = content.length();

        for (int i = 0; i < length; i += CHUNK_SIZE) {
            int end = Math.min(i + CHUNK_SIZE, length);
            chunks.add(content.substring(i, end));
        }

        return chunks;
    }
}

The current version uses a simple character-based chunking strategy. It works for a prototype, but a production version should be smarter: chunk by timestamp ranges, request boundaries, stack traces, or service sections.

2. GroqClient: Calling the LLM API

The GroqClient sends each chunk to Groq and asks for a structured JSON response.

public class GroqClient {
    private static final String API_URL = "https://api.groq.com/openai/v1/chat/completions";
    private static final String MODEL = "llama-3.3-70b-versatile";

    private final String apiKey;
    private final HttpClient httpClient;
    private final ObjectMapper mapper;

    public AnalysisResult analyzeChunk(String logChunk) throws Exception {
        String prompt = "Analyze this server log chunk and provide: root cause, "
                + "affected components, severity (critical/high/medium/low), fix suggestions, "
                + "and a summary. Return as JSON with keys: rootCause, affectedComponents, "
                + "severity, fixSuggestions, summary.\n\nLog:\n" + logChunk;

        String requestBody = mapper.writeValueAsString(Map.of(
                "model", MODEL,
                "messages", List.of(Map.of("role", "user", "content", prompt)),
                "temperature", 0.3
        ));

        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(API_URL))
                .header("Authorization", "Bearer " + apiKey)
                .header("Content-Type", "application/json")
                .POST(HttpRequest.BodyPublishers.ofString(requestBody))
                .build();

        HttpResponse<String> response = httpClient.send(
                request,
                HttpResponse.BodyHandlers.ofString()
        );

        if (response.statusCode() != 200) {
            throw new RuntimeException("Groq API error: " + response.statusCode());
        }

        var responseJson = mapper.readTree(response.body());
        String content = responseJson.get("choices")
                .get(0)
                .get("message")
                .get("content")
                .asText();

        return mapper.readValue(content, AnalysisResult.class);
    }
}

One practical lesson from this build: model names can change.

I originally used llama3-8b-8192, but that model was later unavailable. I switched to llama-3.3-70b-versatile, and the output quality improved. In a real tool, I would make the model configurable instead of hardcoding it.

3. AnalysisResult: Structuring the Output

The model response is parsed into a simple Java object.

public class AnalysisResult {
    @JsonProperty("rootCause")
    public String rootCause;

    @JsonProperty("affectedComponents")
    public List<String> affectedComponents;

    @JsonProperty("severity")
    public String severity;

    @JsonProperty("fixSuggestions")
    public List<String> fixSuggestions;

    @JsonProperty("summary")
    public String summary;
}

This keeps the CLI output predictable and easier to consume later if I want to write results to JSON, Markdown, or another system.

4. LogAnalyzer: The CLI Entry Point

The main class reads the API key, chunks the log file, sends each chunk to Groq, and prints the analysis.

public class LogAnalyzer {
    public static void main(String[] args) throws Exception {
        if (args.length == 0) {
            System.err.println("Usage: java -jar java-ai-log-analyzer-1.0-shaded.jar <log-file>");
            System.exit(1);
        }

        String apiKey = System.getenv("GROQ_API_KEY");
        if (apiKey == null || apiKey.isEmpty()) {
            System.err.println("Error: GROQ_API_KEY environment variable not set.");
            System.exit(1);
        }

        List<String> chunks = LogChunker.chunkLogFile(args[0]);
        GroqClient client = new GroqClient(apiKey);

        System.out.println("=== AI-Powered Log Analyzer ===\n");
        System.out.println("Log file: " + args[0]);
        System.out.println("Total chunks: " + chunks.size() + "\n");

        for (int i = 0; i < chunks.size(); i++) {
            System.out.println("--- Chunk " + (i + 1) + " of " + chunks.size() + " ---");

            AnalysisResult result = client.analyzeChunk(chunks.get(i));

            System.out.println("Root Cause: " + result.rootCause);
            System.out.println("Severity: " + result.severity);
            System.out.println("Affected Components:");
            result.affectedComponents.forEach(c -> System.out.println(" - " + c));
            System.out.println("Fix Suggestions:");
            result.fixSuggestions.forEach(s -> System.out.println(" - " + s));
            System.out.println("Summary: " + result.summary + "\n");
        }

        System.out.println("=== Analysis Complete ===");
    }
}

Example Output

I ran it against a small sample log file included in the repo.

=== AI-Powered Log Analyzer ===
Log file: sample-logs/app.log
File size: 3.70 KB
Reading and chunking log file...
Total chunks: 2

--- Chunk 1 of 2 ---
Root Cause: Database connection pool exhaustion due to prolonged request processing
Severity: critical
Affected Components:
 - DatabasePool
 - AuthService
 - CacheManager
 - DataSyncService
 - ApiGateway
 - RequestHandler
Fix Suggestions:
 - Increase the database connection pool size
 - Optimize database queries to reduce connection usage
 - Implement connection timeout and retry mechanisms
 - Monitor and alert on connection pool utilization
 - Regularly check for and resolve data inconsistencies
Summary: The application experienced a critical outage due to database connection pool exhaustion. Requests were queued and timed out as new connections could not be established.

--- Chunk 2 of 2 ---
Root Cause: Unknown, but a repair was initiated
Severity: low
Affected Components:
 - Database
 - Connection Pool
 - Cache Cluster
 - Request Handler
 - Data Sync Service
Fix Suggestions:
 - Monitor system logs for similar issues
 - Verify database consistency regularly
 - Review connection pool and cache cluster configurations
Summary: The system experienced an issue requiring a database consistency repair. Repair was successful and all components are now fully operational.

=== Analysis Complete ===

That is the main value of this project: noisy logs become a short, structured incident summary.

It is not perfect, but it gives an engineer a faster starting point.

Privacy Note

Logs can contain sensitive information: tokens, emails, customer IDs, internal URLs, stack traces, headers, and infrastructure details.

Before sending logs to any external LLM API, scrub sensitive data.

For a production-grade version, I would add a redaction layer before the API call. That layer should remove or mask:

API keys
access tokens
emails
IP addresses where needed
customer identifiers
internal service URLs
request headers
personally identifiable information

This project should be treated as a local developer prototype unless proper redaction and security controls are added.

Limitations

This is not a replacement for a full observability pipeline.

A few limitations are worth calling out:

The analyzer depends on the quality of the model response.
It processes chunks independently, so cross-chunk reasoning is limited.
The current version does not deduplicate repeated errors.
It does not validate every model response against a strict schema before parsing.
Very large logs should be pre-filtered or split before analysis.
The chunking strategy is simple and may split related events across chunks.
Sensitive logs should be scrubbed before being sent to an external API.

For a production version, I would add structured validation, retries, redaction, aggregation across chunks, and better error handling.

How to Run It Yourself

Prerequisites

Java 21
Maven 3.8+
Groq API key from console.groq.com

Steps

# 1. Set your API key
export GROQ_API_KEY="your-api-key-here"

# 2. Clone the repo
git clone https://github.com/mulhaq/blogs
cd blogs/java-ai-log-analyzer

# 3. Build
mvn clean package

# 4. Run against the sample log
java -jar target/java-ai-log-analyzer-1.0-shaded.jar sample-logs/app.log

# 5. Optional: save output to a file
java -jar target/java-ai-log-analyzer-1.0-shaded.jar sample-logs/app.log > analysis.txt

Common Issues

GROQ_API_KEY not found

Make sure the variable is exported in your current shell session.

Connection timeout

You may be hitting rate limits or network issues. Wait and retry.

Out of memory on huge files

Pre-split large logs before analysis:

split -l 1000 app.log app-log-part-

Then analyze each batch separately.

What I Would Improve Next

There are several directions I would take this project next.

1. Smarter Chunking

Instead of splitting every 3000 characters, chunk logs by timestamp, request ID, trace ID, or stack trace boundary.

2. Aggregated Summary

Right now each chunk is analyzed separately. A better version would produce a final summary across all chunks.

3. Redaction Layer

Before calling the LLM API, detect and mask secrets, emails, tokens, and internal identifiers.

4. Schema Validation

The model is asked to return JSON, but production code should validate and repair malformed responses.

5. Streaming Mode

A future version could tail a live log file and analyze new chunks as they arrive.

6. Observability Integrations

The results could be sent to tools like Grafana Loki, Datadog, Slack, or PagerDuty.

7. Custom Severity Rules

Different teams define severity differently. A config file could let teams define what critical, high, or medium means in their environment.

Conclusion

Logs are one of the most valuable sources of operational truth, but they are not always easy to reason about during an incident.

This project is a small experiment in using LLMs as a debugging assistant. The LLM does not replace engineering judgment, but it can help summarize noisy logs, identify likely causes, and suggest starting points for investigation.

The broader pattern is useful:

Find a repetitive engineering task, wrap it in a small tool, and use an LLM to reduce the manual analysis step.

Logs are one example. The same pattern could apply to exception traces, failed CI logs, pull request diffs, incident notes, or deployment summaries.

For me, the value is not just the tool itself. It is the workflow: take a common engineering pain point, build a focused implementation, test it on a realistic input, document the tradeoffs, and keep improving it.

Full source code: https://github.com/mulhaq/blogs/tree/main/java-ai-log-analyzer

Tags: #java #ai #groq #devtools

A Review of Domain-Driven Design Distilled

Misbah Ulhaq — Tue, 09 Mar 2021 20:12:53 +0000

Recently, I thought of writing my experiences and share my point of view on various topics. I am interested in Domain-Driven Design and microservices for quite some time and have spent some effort understanding the essence of Domain-Driven Design. This blog is a small attempt to review the book "Domain-Driven Design Distilled" by Vaughn Vernon. This book is a condensed version of the book Implementing Domain-Driven Design written by the same author.

This book introduced you to the Domain-Driven Design narrative, explain usages and benefits along with the efforts required. The author has used examples and case studies to explain the concepts of Bounded Context, Ubiquitous Language, Aggregates, Entity, Core Domain, Scenario, and Sub-Domain.

This book highlights the Context Mapping types like Partnership, Shared Kernel, Customer-Supplier, Conformist, Anticruption Layer, Open Host Service, Published Language, Separate Ways, and Big Ball of Mudd. The aggregates publish domain events to be subscribed by other Bounded-Context (That can be the same Bounded Context).
The author emphasized using eventual consistency and not using the Anemic Domain Model. The Anemic Domain Model is a representation of the Object-Oriented Model (getter and setter).

The author expresses the use of Event Sourcing and provides a detailed guideline for Event Storming. Domain Expert involvement and how to perform sessions with the team to accelerate the development of the domain model are part of the Event Storming guideline.
The author has introduced some tools for managing estimation and collaboration with Agile.

Thoughts:

The domain-driven design is a journey for learning about your business and crafting the best possible software. This practice is a team effort as it requires domain experts to work side by side to develop Ubiquitous language that interprets the same for business and developers. This process includes learning, experimentation, modeling, and learning (cycle continues). Once started with Domain-Driven Design, you need to consider the time estimate and how much effort is enough? In the end, it will simplify your model, ease communication with the business and produce an exceptional software product.

Conclusion

Domain-Deliver Design Distilled is a very informative book covering almost all the aspects of DDD with the minimum detail possible. The book emphasizes business needs rather than a technical marvel. But It will not quench your thirst as one needs to dive deeper into some topics. Specially CQRS is not covered in this book, and many chapters are referring to IDDD for more detail. Finally, this book will enable you to think from the perspective of domain-driven design and help you grasp key concepts.
I recommend you to go through this book wheater you are quite adept in DDD or starting.

“Developers are too wrapped up with technology and trying to solve problems using technology rather than careful thought and design. This leads developers to constantly chase after new “shiny objects,” which are the latest fads in technology.”
― Vaughn Vernon, Domain-Driven Design Distilled