1L0Gx

1L0Gx cuts through noisy security logs with AI, giving clear summaries, actions, and automated responses in real time. Powered by Groq + TiDB Serverless

Comment

Building 1L0Gx: My Hackathon Journey

Inspiration

The inspiration for 1L0Gx came from a recurring pain point in cybersecurity: drowning in logs and alerts. Security teams are constantly overwhelmed by raw event streams, intrusion detection system (IDS) warnings, firewall alerts, failed login attempts, and application errors.

I wanted to answer a simple question:

What if AI could cut through the noise, summarize the real threats, and even act on them automatically?

This idea became the foundation of 1L0Gx, a system that ingests logs in real time, analyzes them with large language models (LLMs), and triggers automated responses.

What I Learned

Working on this project taught me how to:

  1. Integrate databases at scale: I used TiDB Serverless, which is compatible with MySQL, to store both raw logs and structured incident data. It was eye-opening to see how TiDB can handle high-ingestion workloads while still supporting analytical queries.

  2. Leverage LLMs for cybersecurity: I learned how to design prompts that make AI act like a security analyst. For example, given a set of logs, the model had to:

  • Summarize the incident in plain language.
  • Assign a severity level: LOW, MEDIUM, HIGH, or CRITICAL.
  • Recommend specific actions like BLOCK_IP or CREATE_TICKET.

  1. Real-time systems with WebSockets: Instead of just storing data, I wanted live dashboards. WebSockets allowed me to stream logs, incidents, and actions directly to the frontend, so I could see things unfold in real time.

  2. Schema design for security data: I learned how to create tables that balance flexibility (storing embeddings for semantic search) with structure (indexing timestamps, severities, and relationships between incidents and actions).

How I Built It

The system has three major components:

  1. Log Ingestor (Go)
  • A Go service generates logs (simulating real sources like firewalls, auth servers, and web apps).
  • It inserts them into TiDB every few seconds.
  • Each log entry includes metadata and even a mock vector embedding for future semantic search.
  1. Incident Agent (Python)
  • A Python service polls TiDB for unprocessed CRITICAL or ALERT logs.
  • It groups related logs by IP and time window.
  • It sends the logs to an LLM (OpenAI or Groq), receives structured JSON back, and saves an incident into TiDB.
  • It also creates actions (e.g., BLOCK_IP, SLACK_ALERT) and simulates executing them.
  1. Frontend (HTML + JavaScript)
  • Uses WebSockets to subscribe to live updates.

  • Displays:

    • A log feed
    • An incident dashboard with summaries and recommendations
    • An action tracker showing what automated responses were taken

Challenges

Like any hackathon project, there were hurdles:

  1. Schema synchronization: At first, I ran into issues where tables didn’t exist in TiDB, or indexes clashed with old definitions. I had to carefully reset the schema and rebuild it.

  2. LLM responses: Sometimes the model returned lists instead of plain strings, which caused JSON parsing errors when saving to the database. I had to normalize outputs (e.g., joining recommendations into newline-delimited text).

  3. WebSocket integration: Moving from REST endpoints to WebSockets required rethinking how the backend pushes data instead of waiting for the frontend to pull it. It was a shift in mindset, but once working, it made the system feel alive.

  4. Model deprecation: During testing, the Groq model I used (llama3-8b-8192) was suddenly decommissioned. This forced me to swap to a newer supported model mid-build, which was a real lesson in depending on external APIs.

Reflection

This project showed me the power of combining:

  • Fast databases (TiDB)
  • AI reasoning (LLMs)
  • Real-time interfaces (WebSockets)

Together, they create a system that doesn’t just log security events but understands and responds to them.

At its heart, 1L0Gx turns chaotic log data into clear, actionable insights.

In mathematical terms, if we let:

$$ L = \text{raw logs}, \quad f = \text{LLM analysis}, \quad g = \text{automated response} $$

then the system pipeline is:

$$ \text{Incident Summary} = g(f(L)) $$

where $L$ may contain thousands of noisy events, but the composition $g \circ f$ produces only a handful of clear actions.

Share this project:

Updates