> ## 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. # Telemetry > Give Nexus the logs, metrics, traces, and dashboards your team relies on. Telemetry is the hard signal that explains what your system was actually doing: error spikes, latency changes, log lines, and the dashboards your team already trusts. Connect the observability tools your responders reach for during an incident, and Nexus can query them directly. Because it learns the shape of each source, including the queries in your own dashboards, it queries them the way an engineer who knows your systems would, not with generic guesses. Once connected, telemetry is used in two places: * **In Investigations**: an investigation queries your sources to confirm or rule out a hypothesis. It's the evidence that carries the most weight, and verifying against live system state is what gives an investigation the most [conviction](/investigations/how-investigations-work#building-conviction) in a finding. * **In the agent**: ask [the agent](/ai/at-incident) what your systems are doing, from Slack, the dashboard, or the mobile app, and it queries the same sources to answer, whether or not there's an incident open. ## What you can connect Connect a provider to bring several data sources at once, or connect a data source directly. **Providers** Loki, Prometheus, Tempo, and Pyroscope. Cloud Logging, Cloud Monitoring, and Cloud Trace. **Connect directly** Logs, metrics, traces, and error tracking. Logs, metrics, and APM traces. Logs from your index patterns. Logs from your index patterns. Traces and spans from your environments. Logs and metrics from your account. Logs, metrics, and traces. Metrics and dashboards from your account. Read-only SQL queries. Read-only SQL queries. To reach a system with no native integration, connect it as an [MCP server](/investigations/extensions/connectors) using Extensions. ## How telemetry is modeled Some tools host others. Connect **Grafana** once, and Nexus can discover the data sources behind it: Loki for logs, Prometheus for metrics, Tempo for traces, and more. The same pattern applies to **Google Cloud** (which exposes projects). You connect the provider once, then choose which of the discovered data sources to enable. Other tools (Honeycomb, Elasticsearch, your databases) are connected directly and stand on their own. ### Capabilities Each data source provides one or more capabilities, which is what Nexus actually uses it for: | Capability | What it answers | | ---------- | ------------------------------------------------------------ | | Logs | What was the system logging around the time of the incident? | | Metrics | Did error rates, latency, or saturation change? | | Traces | Where did a slow or failing request spend its time? | | SQL | What does the data in this database actually show? | | Dashboards | What do the views my team already built reveal? | ## Enabling data sources Each data source has an **enabled** toggle that controls whether Nexus can use it. When a provider is first connected, some data sources are enabled by default and others are left off so you stay in control: * Read-only and low-risk sources (such as traces) tend to be on by default. * Sources that allow broader querying (such as logs) tend to be off by default, so you opt in deliberately. Review the enabled data sources after connecting a provider and turn on the ones your team uses. ## Learning your stack Nexus doesn't query blindly. For each connected data source we continually learn how to query it well in your environment, discovering its real labels and fields, learning the query patterns in your own dashboards, and remembering what worked in past investigations. That's what lets a query filter on the attributes you actually use and reach for sensible defaults, instead of guessing against an unfamiliar stack. Routing a question to the right data source, translating it into the right query language, and the guidance and memory the system builds over time all sit behind this. See [How telemetry works](/nexus/telemetry/how-it-works) for the full picture. Connect the data sources and dashboards your team reaches for during real incidents. The more your setup reflects your real workflow, the better Nexus learns to query it. ## FAQs No. We connect to the observability tools you already run and query them on demand; there's no need to ship telemetry to us or keep a copy. The goal is to become an expert user of your existing stack, not to replace it. Yes. For a data source that isn't exposed to the public internet (a Loki, Prometheus, or VictoriaMetrics instance inside your VPC, for example), run a [proxy](/integrations/proxy) in your network and attach the data source to it. Queries travel over an outbound-only, encrypted tunnel, so you never open inbound ports. Connect it as an [MCP server](/investigations/extensions/connectors), then write a [skill](/investigations/extensions/plugins) that says how to use it. That's a good way to give Nexus visibility into a system (ArgoCD, say) ahead of native support, which we keep expanding. No. Nexus learns each source by exploring it and making test queries, so connecting the source is enough to get started. A well-built Catalog can improve results, but it isn't required. ## Related Routing, query planning, guidance, and memory. How telemetry queries become evidence in a finding. Why a data source's queries fail, and what to do about it.