> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.
# CrowdStrike Falcon LogScale
> Query your LogScale logs to see what your systems were doing during an incident.
CrowdStrike Falcon LogScale (formerly known as Humio) holds your log events, queried with LogScale's query language, LQL.
Nexus queries it to read what a service was logging around the time of an incident, and to graph how those logs changed.
You connect LogScale directly, with your deployment URL and an API token. One connection covers every repository and
view that token can read, and you choose which ones Nexus can query.
## What we support
LogScale is a log store, so connecting it gives Nexus one capability, plus your dashboards:
| Capability | What it queries |
| ---------- | ----------------------------------------------------------------------------------- |
| Logs | Log events from the repositories and views you enable, and trends over those events |
| Dashboards | The queries built into your own dashboards |
### Logs
Nexus queries your log events with LQL, scoped to one repository or view at a time, in two ways:
* **Log queries**: read the events themselves. What a service was logging when an incident started, whether the same errors were appearing elsewhere, whether a message started right after a deploy.
* **Trends over those logs**: LQL buckets events into a time series, so Nexus graphs an error rate climbing, latency moving, or one endpoint's volume falling away. You get a chart of what your logs were doing across the incident window even where you never set up a metric for it.
LogScale defines no schema beyond its own `@` fields and `#` tags, so every other field name is whatever your shipper chose to write. One view can carry several shippers that spell the same thing three ways (`severity`, `level`, and `log.level`), and a filter on the wrong one comes back empty rather than failing. Nexus learns which names each slice of your data actually uses, and the values those fields really hold, so an error search filters on a spelling and a value that exist.
### Dashboards
Your LogScale dashboards are discovered automatically once you connect, and read for the LQL behind their widgets. That's the only place your team's own queries exist in writing, so it teaches Nexus the fields, tags, and filters you really query on, and which slices of the data matter.
### Repositories and views
LogScale calls a repository or a view a search domain. Every one your token can read arrives as its own data source that you enable individually, so a token that reaches more than you want investigated doesn't put all of it in scope. A view is queried like any repository, including one that federates several.
## Connecting CrowdStrike Falcon LogScale
You connect LogScale directly. There's no provider in front of it.
**What you'll need:**
* Your **deployment**: LogScale Cloud in the EU (`https://cloud.humio.com`) or the US (`https://cloud.us.humio.com`), or the base URL of your self-hosted deployment, without a path.
* An **API token**, created in LogScale under **Settings → API tokens**, whose role has read access to the repositories and views you want searched. A Repository & View token reaches the single repository or view it was issued for; a broader token reaches every one its role can read, and we connect each of them. LogScale covers this in its [API token documentation](https://library.humio.com/data-analysis/api-tokens.html).
1. From the [Nexus telemetry settings](https://app.incident.io/~/nexus/telemetry), add a telemetry data source and choose **CrowdStrike Falcon LogScale**.
2. Choose your deployment, either a LogScale Cloud region or your own base URL, then enter the token and test the connection. We check that LogScale accepts the token and can read at least one repository or view.
3. Enable the repositories and views you want Nexus to query. Each one arrives switched off, so you opt in to each deliberately.
If your team issues a token per repository or view rather than one that covers them all, you can add those tokens after connecting, and each brings in everything it can read.
Your dashboards are discovered automatically once LogScale is connected — there's nothing extra to set up.
## Best practice
* Use a token whose role grants read access and nothing more, so Nexus can only do what a reader in LogScale could.
* Give that role read access to the repositories behind a view, not only to the view itself. Retention is configured on repositories, so a token that can't read every repository behind a view leaves Nexus without your retention window, and without knowing how far back it's worth searching. If you'd rather not widen the token, set the retention window yourself on the data source instead.
* Enable the repositories and views your responders actually open during an incident, rather than everything the token reaches. Each domain enabled is more data in scope, and more of it read on every query.
* Select the LogScale dashboards your responders reach for during incidents. Nexus learns your real query patterns from them, which makes the queries it writes more like the ones you'd write.
## Related
How data sources and capabilities fit together.
Routing, query planning, guidance, and memory.