Connecting your first log source

A log source is a named thing that sends events to Qorionix. It might be a cloud service we poll on your behalf, a network appliance shouting into a syslog port, or a script on one of your servers posting JSON over HTTPS. Whatever the shape, the platform needs three facts about it: which organisation the events belong to, what format they arrive in, and how to prove the sender is really you.

This article covers the concept, the decision of which source to connect first, and — most importantly — an honest account of which sources do what today. There is one limit you should know before you spend ten minutes on any of this, so it is at the top rather than buried in a section you might not reach.

The four moving parts

Four separate concepts get called a log source in casual conversation, and confusing them is the fastest way to spend an afternoon debugging the wrong thing.

The sender

The actual firewall, server, script or cloud tenancy producing the events. Nothing in Qorionix can fix a sender that is not configured to emit audit logs in the first place — a Windows machine with no audit policy has nothing to forward, and a Microsoft tenant with unified audit logging switched off has nothing to poll.

The receiver

The thing on our side that accepts or fetches the events. For push sources that is an HTTPS endpoint. For pull sources — Microsoft 365, CloudTrail, Google Workspace — it is a row of configuration that tells a background worker where to poll, how often, and with which credentials.

The ingest token

The credential a push sender presents. It is a string beginning zqi_, sent in an Authorization header. It identifies your organisation and selects a parser. See Ingest tokens.

The parser

The code that turns a raw line or JSON blob into named fields, and then into the common event model everything else reads. Picking the wrong one is the single most common cause of events that arrive but look empty. See How your logs are normalised.

Which source to connect first

Microsoft 365, including Entra ID. Three reasons, in order of how much they should weigh with you.

• It is where your incidents will actually start. For an organisation of this size, the overwhelming majority of real security events are identity events: a password reused and phished, a mailbox rule quietly forwarding to an external address, an OAuth application granted more than anyone intended. Those live in the Microsoft audit feeds and nowhere else.
• There is no software to install. No agent, no forwarder, no firewall rule, no VM to keep patched. It is an application registration and a set of read permissions, which is the cheapest onboarding of any source in the product.
• You have probably already done the adjacent work. If you connected Microsoft 365 for the posture assessment, you already know how consent works in your tenant and who can grant it.

If you are not a Microsoft shop, or you want something working in the next ten minutes without involving your tenant administrator, connect the HTTP Event Collector instead. It is the only source you can set up entirely by yourself, start to finish, with no help from us.

What connected actually means

There is no single switch that reads connected. For a push source there are three states, and it is worth knowing which one you are in.

1. 1

   A token exists

   Someone with the siem:sources.write permission issued one, and the plaintext was captured. This proves nothing about your data — it is the equivalent of having a key cut.

2. 2

   The sender is authenticated

   Your collector posts and receives 202 Accepted rather than 401. This proves the credential works and the endpoint is reachable. It does not prove anything was stored — although on the HTTP Event Collector, unlike on OTLP, a storage failure is reported as 503 rather than swallowed.

3. 3

   Events are queryable

   You can find your own events in search, with fields populated rather than a wall of raw text. This is the only state worth calling connected, because it is the only one that proves the parser matched as well as the transport.

For a pull source the equivalent milestones are: the receiver configuration is valid enough to be scheduled, the first poll authenticated successfully against the provider, and events from that provider appear in search.

How to prove events are arriving

Three checks, cheapest first. Do them in this order; each one rules out a different class of problem.

One — read the response. A successful post to the HTTP Event Collector answers with a count. If the count is not the number of records you sent, your payload was split differently than you expected, and the parser is reading something other than what you think.

HTTP/1.1 202 Accepted
Content-Type: application/json

{"accepted":3,"text":"Success"}

Two — read the token's own counters. Every accepted request bumps the token's usage figures. Listing your tokens shows last_used_at, last_used_ip, events_ingested and bytes_ingested, so you can confirm the platform saw traffic from the address you expected without searching anything.

GET /api/v1/organizations/{orgID}/siem/ingest-tokens

[
  {"id":"sit-9f2c41ab77e0","name":"branch-firewall",
   "parser_kind":"syslog","last_used_at":"2026-09-01T09:14:22Z",
   "last_used_ip":"203.0.113.44","events_ingested":1841,
   "bytes_ingested":492118}
]

One caveat that will otherwise waste your time: OTLP traffic is not counted. The OTLP endpoint does not record token usage, so a token used only for OTLP will show events_ingested of zero however much you send. Use search rather than counters to verify an OTLP collector.

Three — search for your own events. This is the check that matters, because it is the only one that proves normalisation worked. Search on the source name and the last few minutes, and look at whether the fields you care about — the user, the source address, the action — carry values or are empty. See Searching your logs.

What works end to end today

This table is the least flattering thing in this article and the most useful. Collects means events reach storage and search. Alerts means the detection library evaluates them — which, as stated at the top, is currently nothing.

What to do next

1. Issue an ingest token — including what to do when one leaks, because it is a bearer credential with no expiry.
2. Send events with the HTTP Event Collector — the exact endpoint, header and payload, with a request you can copy.
3. Collect Microsoft 365 and Entra logs — the highest-value single source, and what it needs from you.
4. Why some rules stay quiet — worth reading before you draw conclusions from an absence of alerts.