Skip to content
Notifications
Clear all

Guide: Integrating Quantum Log Exporter with a homemade SIEM (Grafana/Loki setup).

4 Posts
4 Users
0 Reactions
1 Views
(@budget_buyer_99)
Reputable Member
Joined: 1 month ago
Posts: 148
Topic starter   [#17735]

Trying to get logs from Quantum into my own Grafana/Loki stack. The official docs are a maze of enterprise features I don't need.

I have the Log Exporter service running. Need the simplest way to point it at my Loki instance. What's the bare minimum config? I don't want SmartEvent or any other paid module. Just logs. Anyone done this without all the extra bloat?



   
Quote
(@budget_minded_buyer)
Estimable Member
Joined: 3 months ago
Posts: 94
 

Yeah, the docs make it look like you need a license for every checkbox. You don't.

The bare config is just an HTTP exporter pointing at your Loki `/loki/api/v1/push` endpoint. Set the format to JSON. The real catch is the log volume.

It'll start spamming you with connection events and system logs by default, which might blow through your Loki storage budget. You'll need to filter aggressively in the Quantum config, which of course requires another paid "log filtering" SKU. Classic.


always ask for a multi-year discount


   
ReplyQuote
(@backend_latency_queen)
Reputable Member
Joined: 2 months ago
Posts: 159
 

You can get around the filtering SKU by dropping unwanted logs at the Loki end. Set up a Promtail config before the push with a `pipeline_stages` drop rule for those noisy connection events. It's less efficient than filtering at the source, but it's free.

The minimal exporter config is essentially what user95 said, but make sure you match Loki's expected label structure. Something like:

```json
{
"exporters": [{
"type": "http",
"endpoint": "http://your-loki:3100/loki/api/v1/push",
"format": "json",
"labels": {
"job": "quantum",
"instance": "firewall-a"
}
}]
}
```

The volume can still be a problem if you're indexing everything. Consider setting up a separate retention policy for high-volume, low-value logs in Loki.


sub-100ms or bust


   
ReplyQuote
(@finops_auditor_ray)
Estimable Member
Joined: 4 months ago
Posts: 115
 

That config snippet's missing the authentication. Loki's endpoint usually needs a token or basic auth, unless you're running it open on an internal network (which I'd never recommend). Add `headers` with your auth key.

Also, "less efficient but free" is a cost trap. Processing and storing gigabytes of unwanted logs in Loki still costs you compute and storage. The SKU cost might be less than your Loki bill spike if you're on a cloud managed service.

Can you share actual volume numbers? How many logs per second are you seeing after the drop rules? Without that, any advice on retention policies is guesswork.


show me the bill


   
ReplyQuote