Cannot receive logs

[itnewgay]

I installed the Logtide logging server and it runs successfully, but I am unable to receive any logs. I don't know why.

[Polliog]

Sorry for the late reply, work has been keeping me busy.

To help properly I need a few details:

• LogTide version and how you installed it (docker compose, Helm chart, manual build)
• How you are sending logs (one of the SDKs, an OTel collector, Fluent Bit, plain curl)
• The full HTTP response of one ingest call (curl -i), and the backend container logs around that moment

In the meantime, here is the checklist that covers almost every "server is up but no logs" report.

1. Endpoint and auth

Batch ingestion is POST /api/v1/ingest, authenticated with the X-API-Key header. A quick end to end test:

curl -i -X POST http://localhost:8080/api/v1/ingest \
  -H "Content-Type: application/json" \
  -H "X-API-Key: lp_your_key_here" \
  -d '{"logs":[{"service":"test","level":"info","message":"hello"}]}'

Things that bite people here:

• API keys are project scoped and start with lp_. You create them in the project settings page, API Keys section, and the value is shown only once.
• A Bearer token (a session token) does not work for ingestion: you get 401 Project context missing, because only the API key path sets the project context.
• If the key has an origin/IP allowlist configured, you get 403 Request origin or IP not in API key allowlist.
• If you are testing by reading back with the same key and it is a write key, the read returns 403. That is expected and unrelated to ingestion.

2. If you use OTLP

The path is /v1/otlp/logs, not /v1/logs. A collector configured with a base endpoint that appends /v1/logs hits nothing. GET /v1/otlp/logs returns {"status":"ok"} and is a quick way to confirm you are pointing at the right host and port.

3. If you use the bundled Fluent Bit

It reads FLUENT_BIT_API_KEY from the environment. That variable is missing from the example env files (my fault, I will fix it). If it is unset, Fluent Bit sends an empty X-API-Key and every ingest gets a 401 while the whole stack looks healthy.

4. Ingest returns 200 but nothing shows in the UI

• Check the response body for a rejected[] array. PII masking is fail closed: records whose masking fails are rejected before storage, with reason: "pii_masking_failed".
• Records that fail schema validation are dropped from the batch silently (you only get a 400 if all of them fail). The most common cause is an empty message.
• Check the dashboard time range. It defaults to the last 24 hours and the selection is persisted in your browser, so an old custom range can hide new logs.
• Check the selected project matches the project the API key belongs to.
• Timestamps more than 24 hours in the past or more than 5 minutes in the future are stored but land outside the default window. The simplest test is to omit the time field entirely so the server timestamp is used. There is a skew banner on the project overview page when this happens.

5. Diagnostics

GET /api/v1/admin/stats/ingestion-health (also surfaced as the "Ingestion health (24h)" card in the admin page) shows 24 hour counters for PII rejections and timestamp skew, which usually tells you immediately whether the records are arriving at all.

Post the output of the curl above plus the backend logs and I will take it from there. I will also add a proper ingestion troubleshooting page to the docs, this comes up often enough.

[itnewgay]

I need to collect logs from Windows, Linux, and Cisco networks. How should I install them? I've tried both SDK and Fluent Bit, but neither has been able to receive the task logs. curl -i -X POST http://localhost:8080/api/v1/ingest
-H "Content-Type: application/json"
-H "X-API-Key: lp_your_key_here"
-d '{"logs":[{"service":"test","level":"info","message":"hello"}]}' has also been tried, but logs still cannot be collected.

[itnewgay]

Today , I installed again. I've received 1 log from curl -i -X POST http://localhost:8080/api/v1/ingest
-H "Content-Type: application/json"
-H "X-API-Key: lp_your_key_here"
-d '{"logs":[{"service":"test","level":"info","message":"hello"}]}'.

How to receive log from Cisco network ,H3C network ?

I used this way to installed LogTide . version is 1.2

[itnewgay]

Network device setting

[Polliog]

Good progress: the curl test working means the core ingestion path (API key, endpoint, storage) is fine. What is missing for Cisco/H3C is the syslog listener.

Network devices speak syslog, not HTTP. LogTide receives syslog through the bundled Fluent Bit container, which listens on port 514 (UDP and TCP, RFC 3164) and forwards to the API. That container is behind the logging compose profile, and install.sh starts the stack without any profile, so Fluent Bit is not running in a default installation. That is why nothing arrives from the devices.

Here is the full setup:

1. Set the API key for Fluent Bit

In docker/.env, add a project-scoped write key (create one in the UI under Project > Settings > API Keys; the network logs will land in that project):

FLUENT_BIT_API_KEY=lp_your_key_here

If your syslog devices send local time instead of UTC, also set the timezone offset in hours (RFC 3164 timestamps carry no timezone, so without this the logs can land outside the default 24h window in the UI):

SYSLOG_TZ_OFFSET=8

(8 for UTC+8; use your own offset.)

2. Start the stack with the logging profile

cd docker
docker compose --profile logging up -d

Then confirm the listener is up:

docker ps | grep fluent-bit        # logtide-fluent-bit should be running
docker logs logtide-fluent-bit     # no 401 errors from the http output

If you see 401s in the Fluent Bit logs, the FLUENT_BIT_API_KEY is missing or wrong (recreate the container after changing .env: docker compose --profile logging up -d --force-recreate fluent-bit).

3. Point the devices at it

Cisco IOS:

logging host <logtide-server-ip>
logging trap informational

H3C Comware:

info-center enable
info-center loghost <logtide-server-ip>

Both default to UDP 514, which matches the listener. Make sure the host firewall allows UDP 514 in.

4. Verify

Syslog severity is mapped to LogTide levels automatically (emergency/alert/critical -> critical, warning -> warn, and so on). The logs appear in the project the API key belongs to; check the Logs page with the time range on "last 24h". A quick end-to-end test from any Linux box on the same network:

logger -n <logtide-server-ip> -P 514 -d "test from linux"

For your other sources: Linux hosts can either use the same syslog path (rsyslog forwarding to port 514) or run Fluent Bit locally tailing files; Windows hosts are best served by a local Fluent Bit with the winlog/windows_exporter inputs posting to /api/v1/ingest/single with the X-API-Key header, same as the bundled config does.

I am also going to make this clearer in the docs, since the profile requirement is easy to miss.