Until now, setting up a new source on Logit.io meant two browser tabs: a docs page with a config full of placeholders, and your stack settings. You copied hostnames, ports and keys from one to the other, and that's where most failed first attempts come from. A Beats port goes where the TCP port should, or an API key picks up a trailing space.
The new onboarding in the Logit.io dashboard removes the copying. You pick a source, and the setup steps on screen already contain your stack's endpoint, port, username and password. You paste, run, and the page waits for your first data before it lets you move on. Here's what's in it and how it behaves.
Contents
Five steps, and the last one waits for your data
Onboarding is the same shell on Logs, OpenSearch, APM and Metrics stacks. The page is titled after the product you're setting up and has a five-step bar across the top:
- Category: what kind of source you have, such as servers, applications, Kubernetes or a cloud service.
- Option: the specific shipper or integration inside that category.
- Install: the commands and config for that option, already filled in for this stack.
- Waiting: the page checks for your first data.
- Launch: open the stack's visualiser once the data is there.
The step that matters most is the one between Install and Launch. On a Logs stack, Launch only unlocks when your first logs are searchable. A shipper reporting that it connected isn't enough, and neither is a pipeline that has seen traffic. The check is that real documents can be found in your stack.
That doesn't lock you out. While the page is waiting, it says your stack is ready and gives you the same Launch buttons as the final step, so you can open OpenSearch Dashboards straight away and watch the data arrive yourself. If nothing turns up after a minute and a half or so, the page offers a troubleshooting hint for the option you picked.
APM stacks wait for a first trace and Metrics stacks for a first data point. OpenSearch stacks have nothing to install, so their check is a connection test against your cluster.
OpenTelemetry is the featured first option
OpenTelemetry is the featured first option in the new onboarding flow on a Logs stack, ahead of Quick start, Linux servers & log files, Applications & code, Containers & Kubernetes, Cloud, Network, SaaS and Windows servers. It uses your Logs stack's Hosted OpenTelemetry endpoint, https://your-stack-id-otel.logit.io, which takes logs, traces and metrics over OTLP/HTTP and is included on every plan. Inside the category there are six options:
- Servers & log files, marked Recommended, installs the OpenTelemetry Collector and tails system logs.
- Applications gives you the SDK or official zero-code agent setup for your language, with a dropdown that runs from .NET through Python, Node.js, Java and Go to Rust and Swift.
- Kubernetes is one Helm command that runs the Collector on every node.
- Host metrics scrapes CPU, memory, disk, filesystem, network and load from a server.
- Send a test signal needs no install: three curl commands send one log, one trace and one metric.
- I already run a Collector gives you the extension and exporter to merge into a Collector you already operate.
Every one of these shows the same credentials block: Endpoint, Username, API key and a ready-made Header value, each with a Copy button. If your stack's endpoint is still being set up, the panel says so. Setup takes a few minutes, and then the connection details appear.
The older categories haven't gone anywhere. Filebeat, Winlogbeat, rsyslog, Fluent Bit and the HTTPS API are all still there, and the categories that have an OpenTelemetry equivalent show an OpenTelemetry card alongside their own options.
Every integration is selectable
The old flow offered a short, hand-picked list of sources. Now every integration that's relevant to the stack type can be chosen without leaving the page. There are three ways in:
- A search box on every category, so you can type Fortigate, Okta or Filebeat straight away.
- The Cloud, Network and SaaS categories list all of their integrations, followed by the rest of the catalogue.
- An All integrations category at the end with the full list.
For integrations that don't have their own guided panel yet, onboarding opens the docs steps inside the flow. Where the docs describe a Filebeat setup, the install, config, start and check steps are built from that docs page, using the log paths, modules and syslog listeners it documents, rather than a guessed /var/log/ path.
What "ready to paste" means in practice
Options with a full config are marked Ready-made config. In those, the config blocks are rendered with your stack's own values. A Telegraf, Prometheus, vmagent or OpenTelemetry Collector block for metrics has your host, username and password in it. The APM samples have your endpoint and credentials. The .NET appsettings.json and the Java otel.properties carry the Header value, so the file works as pasted. You're no longer asked to export a set of $LOGIT_* variables first and hope they reach the process that needs them.
A few details we cared about while building it:
- Install, config and restart each get their own code block with a Copy button, and long blocks expand with "Show all lines".
- Beats setups such as Auditbeat, Packetbeat, Metricbeat and Heartbeat keep the Beat's own modules and only swap the output to your stack. Running the output step a second time doesn't add a second output.
- Heartbeat setup writes one HTTP monitor against a URL you choose, so data arrives as soon as it starts rather than after you've written your first monitor.
Unlock complete visibility with hosted ELK, Grafana, and Prometheus-backed Observability
Linux and Windows tabs where the commands differ
Servers & log files and Host metrics have a Linux tab and a Windows tab. Under Linux there's a second switch for Debian/Ubuntu and RHEL/Amazon Linux. Each tab shows only that platform's install command, config path and restart command, so you never have to work out which half of a mixed snippet applies to you. On Windows, the server log option reads the Application, System and Security event logs instead of files.
Fluent Bit and Telegraf have Debian/Ubuntu and RHEL tabs, and the Filebeat-based docs steps include install commands for both families. If you want the full reference for a source, the getting started docs are still the place for it.
Copy AI prompt, without the secrets
Under each Install panel there's a row that starts "Using an AI assistant?" with a Copy AI prompt button and a Preview. The prompt carries this stack's endpoint and username, the known-working config for the option you picked, and a short check to confirm it worked. Paste it into Cursor, Claude or another coding agent and it has what it needs to make the change.
The prompt never contains your API key. It tells the assistant to read the key from an environment variable (LOGIT_API_KEY on a Logs stack) and to ask you to set it, so the key stays out of chat history and out of whatever the assistant writes to disk. For application languages, the prompt is specific to the language you chose in the dropdown, and if your app already sends OpenTelemetry data it asks for the endpoint, protocol and auth header to be changed rather than a second SDK installed.
Be careful with screenshots
Because the paste blocks are prefilled, the Install step shows live credentials for your stack. They're only shown to signed-in users who can access that stack, but it's worth treating the page like your stack settings: don't screenshot it into a ticket or share your screen on it in a public call. If a key does leak, you can rotate the Hosted OpenTelemetry credentials from the Hosted OpenTelemetry card on your stack's Endpoints page. Any Collector or app still using the old key will stop authenticating until you update it.
Where to find it
A stack that hasn't received data yet shows a Finish Logs setup button (or the Metrics and APM equivalent), which takes you into onboarding.
If you're new to this, our first logs on Logit.io walkthrough shows what to look for in OpenSearch Dashboards once data lands, and your first useful log alert is a good next step after that. For OpenTelemetry specifically, the OpenTelemetry getting started docs cover logs, traces and metrics in more depth.