Logz.io

Logz.io stores and searches your logs on a hosted ELK stack, and stores your metrics on a Prometheus-compatible backend. Investigations query them to read what your services were doing around the time of an incident: the errors and warnings your services logged, and the metric that moved.

​

What we support

Connecting Logz.io gives investigations two capabilities, which you can enable independently:

​

Logs

Investigations query Logz.io with Elasticsearch Query DSL against your logs, in two ways:

• Log searches: pull back the actual log documents, whether that’s what a service logged at the time, whether errors appeared on an endpoint, or whether a message started showing up right after a deploy.
• Aggregations over logs: turn matching logs into a time series, so investigations can graph trends straight from your logs, such as an error count climbing, request volume dropping away, or how often a particular message appears across the incident window. You get a chart of what your logs were doing even where you never set up a dedicated metric.

Your main account’s logs — and any sub-account that’s searchable from it — are covered by the token you connect, with no extra tokens needed. A logs account that isn’t searchable from the main account can still be included by giving it its own token, the same way metrics accounts are connected.

​

Metrics

Investigations query your Logz.io metrics with PromQL and graph them for the incident’s time window, so a resource spike, a latency change, or a growing error count shows up against the period that matters. Logz.io keeps metrics in separate accounts, each with its own API token (distinct from your logs token), so metrics are opt-in: after connecting, you choose which metrics accounts to include and give each its own token. Connect as many as you use, and add, remove, or rotate them later from the data source’s settings.

​

Learning your data

Logz.io logs arrive as flattened fields, such as a service name, a log level, a trace ID, and whatever structured fields your applications emit, alongside the raw message. A query is only as good as knowing which of those fields exist and what they hold, so investigations sample your logs to learn the fields that are actually populated and the common values for the ones worth filtering on, like a status code, a service, or a level. They learn this across the full spread of your logs rather than only the most recent burst, so a field that shows up occasionally still gets picked up. Your metric names are learned the same way, so investigations know what’s there to query. This means investigations filter on the fields that matter in your logs, and reach for the metrics you actually have, without you describing your schema by hand. How that learning works is covered in How telemetry works.

​

When a search comes back empty

An empty result is ambiguous: it can mean nothing happened, or that a filter used a field or value that doesn’t exist in your logs. When a search returns nothing, an investigation re-checks the structural part of the query on its own to tell those apart, a genuine absence versus a filter that excluded everything, then adjusts and tries again rather than reporting nothing found.

​

Connecting Logz.io

Connect Logz.io directly with your main account’s API token and region, then choose any extra accounts to include. What you’ll need:

• Your main (owner) account’s API token, from Settings → Manage tokens → API tokens. It has to be an owner-account token — that’s what lists your accounts and searches your logs. We recommend one scoped to read-only search, since investigations only ever read from Logz.io.
• Your account region: one of US, EU, UK, AU, or CA. This is the region your Logz.io account lives in, shown in the URL you use to log in, for example app-eu.logz.io for EU.
• A token for each metrics account you want to include, and for any logs account that isn’t searchable from the main account — each Logz.io account has its own token.

To connect:

1. From the Nexus telemetry settings, add a telemetry data source and choose Logz.io.
2. Enter your main account’s API token and region, then test the connection.
3. Choose which accounts to connect: paste a token for each metrics account — and each non-searchable logs account — you want investigations to use. Your main account’s logs and its searchable sub-accounts are already covered, so you can skip this if you only need logs.
4. Turn on the search over your main account’s logs when you want investigations to use it. It’s created switched off, so it stays unqueried until you enable it. Every account you connected in step 3 is enabled straight away — naming one means you’ve supplied its token and want it used.

You can add, remove, or re-token accounts anytime from the data source’s settings. We check each token as you connect it, so a wrong one is caught here rather than turning up as an empty result mid-incident. The accounts whose tokens work are connected even if another fails, and each one we couldn’t connect is flagged with the reason, so a single mistyped token won’t fail the rest. We also catch tokens that are correct but pasted against the wrong account, rather than quietly returning another account’s data, which is easy to do when you have several. An account that’s already connected keeps its existing token if a replacement is refused, so trying a new one can’t cost you access you already have.

​

Best practice

• Connect with your main account’s owner token, scoped to read-only search — it’s what lists your accounts and searches your logs, and investigations only ever read from Logz.io.
• Pick the region that matches your account. Logz.io’s regions are separate, and a token from one won’t work against another.
• Add a metrics account (or a non-searchable logs account) only when you want investigations to use it — connecting one enables it, and you can remove it later.
• Leave your main account’s log search switched off until you want investigations reading your logs — it’s the one source that doesn’t turn itself on.

​

Related