LogScale Troubleshooting Guide

When LogScale data is missing, repository errors appear, or event times look wrong, I start at the source and prove every hand-off before I change anything. This guide gives you that investigation order. It is deliberately a living runbook: I can add new, verified cases over time without turning it into a collection of guesses.

Scope: I use deliberately generic examples below. Replace repository names, hostnames and tokens with your own values, and never put credentials or sensitive event data into a ticket or shared query.

Contents

• Fast triage order
• No ingest
• Repository errors
• Incorrect timestamps
• Evidence before escalating
• Add the next verified case

My fast triage order

Before I touch a parser, I answer five questions in this order:

1. Is the source producing an event now?
2. Can the forwarder or collector reach its LogScale endpoint?
3. Does the request or listener accept the event?
4. Does the intended repository receive it, perhaps outside the current time range?
5. Does parsing preserve the fields and timestamp I expect?

I send one sanitised test event with a harmless, unique marker such as troubleshoot-test-01. I search for that marker before and after every change. This keeps a broad “no ingest” report from turning into a guessing exercise.

No ingest: find the broken hand-off

1. I prove the source and forwarder first

I check the source application's local logs or the collector's own status before I look at LogScale. I confirm that the input is enabled, the destination URL or listener port is correct, and the token can ingest into the intended repository.

Next, I send one sanitised test event through the same path. I do not begin with a parser rewrite: if no request leaves the forwarder, the parser cannot be the cause.

For HTTP-based shippers, I inspect the response status and retry queue. Authentication failures, a wrong repository target, proxy failures, and rate or payload errors normally show up there. For TCP or UDP listeners, I also validate DNS, firewall rules, and the listener's bound address and port.

LogScale ingest listeners bind a TCP or UDP port to a repository and parse data before insertion.[1] With raw TCP/UDP sockets, LogScale cannot return ingest errors to the forwarder, so a sender-side success signal is not proof that the event was accepted.[1] Where I need reliable feedback, I prefer a collector that exposes delivery errors and buffering.

2. I search the right repository and time range

I open the repository configured at the ingestion point, search for the unique marker, and then widen the time selector substantially. An apparently missing event is often present outside the current window because its event timestamp is old, future-dated, or parsed incorrectly.

I use two views of the same sample:

"troubleshoot-test-01"
| table([@timestamp, @ingesttimestamp, host, source])

If the marker appears only after I widen the time range, I move straight to the timestamp checks. If it never appears, I return to the forwarder and endpoint evidence instead of tuning the query.

3. I confirm parsing and fields

If raw events arrive but expected fields do not, I inspect the parser assigned to the ingestion path. I test it with a copy of one sanitised raw event and check that:

• the parser succeeds for the current log format, not only an older sample;
• field names used by saved searches match the parsed output exactly;
• conditional parser branches cover the affected source;
• the timestamp parser handles the source's timezone and precision; and
• parser errors are not silently dropping or altering the affected data.

I keep a minimal before-and-after sample with the parser change. It makes a later regression reproducible.

Repository errors: collect platform evidence

When the symptom points to the cluster rather than one shipper, I use the LogScale internal logging package and system repositories. CrowdStrike documents an internal logging package for analysing logs in the humio- system repositories.[2]

My repository-error check is simple:

1. I note the repository, listener or feed name, approximate time, and affected host.
2. I search the relevant system-repository data for that interval and identifier.
3. I correlate errors with configuration changes, node health, storage pressure, or network failures.
4. I compare the symptom with another repository using the same ingestion method.
5. I preserve the exact error text and timestamps before I restart components or change configuration.

The humio-fleet schema includes repository-related error information, so it can provide a starting point when fleet-managed components report failures.[3] I treat an error field as evidence to investigate, not as a diagnosis: I correlate it with the original collector log and the repository where data should have landed.

Timestamp is not correct

For timestamps, I separate two questions:

• When was the event created? I check @timestamp.
• When did LogScale receive it? I check @ingesttimestamp.

LogScale documents external-ingest-delay as the delay between event creation (@timestamp) and ingestion (@ingesttimestamp).[4] Comparing both values tells me whether the delay happened before LogScale or whether the source timestamp itself is wrong.

I use this checklist:

1. I search for one unique marker across a wide time range.
2. I display @timestamp and @ingesttimestamp for the matching event.
3. I compare the source clock, timezone, timestamp format, and precision with the parser configuration.
4. I check whether the source sends a timezone offset. A timestamp without one can be interpreted differently than expected.
5. I check for milliseconds versus seconds, epoch versus formatted time, and daylight-saving transitions.
6. I correct the source or parser and ingest a new test event rather than editing old evidence.

If @timestamp is correct but @ingesttimestamp is much later, I investigate queueing, connectivity, collector retries, or upstream buffering. If @timestamp is wrong while @ingesttimestamp is current, I focus on the source clock and timestamp extraction rule.

Evidence I collect before escalating

I keep the following evidence together so that the next investigation starts with facts rather than assumptions:

• repository and ingest method;
• affected source and collector version;
• time range, including timezone;
• one sanitised sample and unique marker;
• @timestamp and @ingesttimestamp values;
• exact forwarder response, retry, or error message;
• parser version and recent configuration changes; and
• relevant system-repository error text for self-hosted clusters.

I do not include API tokens, customer data, or full unredacted production payloads.

Add the next verified case

When I resolve a new issue, I will add a short section with the symptom, scope, evidence, root cause, fix, and a verification query. That keeps this guide useful as a stable starting point while making every added case repeatable.

Sources

[1] https://library.humio.com/falcon-logscale-self-hosted/ingesting-data-listeners.html — Ingest Listeners | LogScale Documentation [2] https://library.humio.com/falcon-logscale-self-hosted/admin-internal-logging.html — LogScale Internal Logging | LogScale Documentation [3] https://library.humio.com/logscale-repo-schema/logscale-repo-schema-humio-fleet.html — humio-fleet Repository | LogScale System Repository Schema [4] https://library.humio.com/logscale-repo-schema/logscale-repo-schema-humio-metrics-object-level-external-ingest-delay-externalingestdelay.html — external-ingest-delay Metric | LogScale Documentation