From sign-up to first searchable log: the new Logs onboarding

Getting a Logs stack ready means finding your own log in search, not just starting a shipper. Here is the route from sign-up to that first searchable event, with a Filebeat example, checks for common problems and clear labels for dashboard improvements that are rolling out.

The short answer

Logs onboarding follows Category → Option → Install → Waiting → Launch, and Waiting unlocks Launch only when new searchable logs arrive. A successful connection or an open viewer does not complete that check. The dashboard flow is described below, along with which refinements are still rolling out.

What changed since unified onboarding

Our 8 October onboarding post introduced the shared five-step shell and featured OpenTelemetry first on Logs stacks. That shell remains the same: choose a source, use setup instructions for your stack, wait for data and open the viewer.

This update puts the Logs task first. The logs-first dashboard ordering is rolling out, bringing Linux and Windows server logs forward and making Filebeat the starting suggestion for Linux file collection. OpenTelemetry remains available. If your team already uses it, there is no reason to replace a working collection route simply to follow the first card.

Sign up and open Getting Started

Start a free trial or create a new Logs stack in your existing account, then open Getting Started for that stack. If you are helping a teammate, agree which source and stack you are connecting before copying commands. A valid configuration aimed at another stack can leave your intended destination empty.

Choose one source for the first pass: a server with readable logs or an application you can make produce a fresh message. Decide what you expect to find before installing anything. That gives you a specific verification target and makes troubleshooting much easier than connecting several sources at once.

The Logs Getting Started guide walks through sending a sample log to your stack, which proves the endpoint and API key work before you install a shipper. The managed log management overview explains the service behind it. For planning beyond the trial, Logs pricing starts from $25 per month with annual billing.

Category: the order today, and what is rolling out

On a Logs stack the category screen lists, in order, OpenTelemetry as the featured first card, then Quick start (no install), Linux servers & log files, Applications & code, Containers & Kubernetes, Cloud, Network, SaaS, Windows servers and All integrations. Pick the environment where the event originates, rather than the tool you eventually want to use for searching.

Rolling out: the logs-first category order is:

1. Linux servers
2. Windows servers
3. Quick start
4. Applications and code
5. Containers and Kubernetes
6. Cloud
7. Network
8. SaaS
9. OpenTelemetry, available without featured placement
10. All integrations

Rolling out: Linux servers gets a Filebeat "Start here" card, plus a pointer to the OpenTelemetry server option. Search from the first screen and Browse all provide alternatives. The picked source is persisted so you can return to that choice.

Rolling out: an idle prompt offers booking a call after 120 seconds. The category screen also offers "I'll do this later", shortened to "Later" where space is limited. These refinements help you choose or postpone setup without treating postponement as successful ingestion.

Option and Install: Filebeat

Choose Filebeat in Option, then select the platform tab matching the machine that will read the files. Copy the install commands and configuration shown for your stack. Platform tabs matter because package installation, configuration locations and service commands differ between operating systems.

Use "Open full docs" when you need context beyond the panel. Keep the Filebeat integration reference and Filebeat getting started guide nearby. The integration catalogue covers sources needing another collector or input.

After applying the configuration and starting collection, select "I've sent data, continue". An input-based setup may instead say "I've added the input, continue". These buttons advance to verification; they do not establish that a document has become searchable.

Worked example: Filebeat and a test log

For Filebeat 8.x or 9.x installed as a Linux service, this minimal configuration reads ordinary text logs with filestream and sends them to Logstash over SSL. Replace both destination placeholders with the values from your stack. Save it as /etc/filebeat/filebeat.yml, preserving any additional settings your environment requires.

filebeat.inputs:
  - type: filestream
    id: logit-linux-server-files
    enabled: true
    paths:
      - /var/log/*.log
      - /var/log/syslog
    fields:
      type: logfile

output.logstash:
  hosts: ["YOUR_LOGSTASH_HOST:YOUR_BEATS_SSL_PORT"]
  ssl.enabled: true

Give each filestream input a unique, stable id. Adjust the paths to files that actually exist and that Filebeat can read. The fields.type value labels these events as logfile. Keep only the intended output enabled; leaving another output active can invalidate the configuration.

sudo filebeat test config -c /etc/filebeat/filebeat.yml
sudo filebeat test output -c /etc/filebeat/filebeat.yml
sudo systemctl start filebeat
sudo systemctl status filebeat --no-pager

If Filebeat is already running, restart it after changing its configuration. Configuration validation checks the file; output testing checks the destination connection. Neither proves that a selected file has produced an indexed event. Generate fresh application activity that writes to a selected path, then look for its message.

For a separate ingestion check, the documented sample-log API uses the following request. Replace the endpoint and API key placeholders with your stack's values. This Linux or macOS shell example sends one JSON event without using Filebeat.

curl -i \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "LogType: json" \
  https://YOUR_API_ENDPOINT/v2 \
  -d '{"message":"Sample message from my computer"}'

Expect 202 ACCEPTED. That response acknowledges receipt, so continue to the searchable-data check. The API test proves a different route from Filebeat: it does not validate the Beats port, local file permissions or your filestream paths.

Waiting for searchable logs

Waiting automatically checks for new searchable logs. Existing documents are not a substitute for a fresh arrival. Keep the onboarding tab open and active while the source sends data; checking pauses if you leave the tab.

You can open the viewer early, but opening OpenSearch Dashboards does not confirm arrival or complete Waiting. Similarly, a pipeline receiving traffic is an intermediate signal. The onboarding check still waits until logs can be searched.

A test log alone can unlock Launch once it becomes searchable. If that is your only event, return to Install to connect the real source. Finding the sample is useful evidence that the API route works, but a server or application still needs an ongoing collection path.

Use a recognisable message for each route and note when you generated it. If you send the API sample and start Filebeat together, distinguish their events in search. Otherwise, the first successful route can hide a problem with the second.

Launch and verify in OpenSearch Dashboards

Once verification succeeds, choose "Launch logs" to open OpenSearch Dashboards. "Go to dashboard" returns you to the Logit.io dashboard. Treat these as different destinations: one is for searching events, the other for managing your stacks.

In Discover, select the logstash-* index pattern and use @timestamp as the time field. Set a time range covering your test, refresh the results and search for the message you sent. Expand a result to inspect its fields rather than relying only on a matching row count.

For Filebeat, check the message and identifying fields, including fields.type where retained by your pipeline. On default stacks, string fields have a .keyword subfield for exact-value filtering and aggregations. Confirm the actual field name in your document before building a filter. A recognisable new event from the intended source is the useful completion check.

For a teammate handover, record the source, collection method and search that found the event. Those details let the next person repeat the check without reopening every installation step or guessing which sample demonstrated success.

Skip, resume and finish Logs setup

If you need to return later, choose "Skip for now, go to dashboard", or "Skip for now" on mobile. Skipping lets you continue working in the account; it does not certify that collection is complete.

Resume through the "Finish Logs setup" or "Finish setup" banner, "Continue setup" on the stack card, or Getting Started in stack settings. Check that you have reopened the intended stack before using its commands.

Rolling out: the category-stage postponement wording is "I'll do this later", with a shorter "Later" label where needed. If your dashboard still shows the existing skip wording, use that route to leave and the setup entry points above to return.

Rolling out: smarter timeout help

Rolling out: Waiting gains more focused help under "Still nothing? Let's fix it." If your dashboard shows the earlier "Still quiet?" prompt, the checks below still apply. The rolling-out panel brings connection checks and next actions together.

Rolling out: its checklist starts with your real Logstash host and the SSL port for the input you selected: Beats, TCP or Syslog. Match the protocol as well as the port. From the source machine, a basic reachability check looks like this:

# Linux or macOS
nc -vz YOUR_LOGSTASH_HOST YOUR_SSL_PORT

# Windows PowerShell
Test-NetConnection -ComputerName YOUR_LOGSTASH_HOST -Port YOUR_SSL_PORT

A successful TCP connection is only one check. It does not validate authentication, the expected input protocol or searchability. A failed connection gives you a concrete place to investigate: hostname resolution, outbound access or the destination port.

Rolling out: timeout help offers up to three alternative shippers, prioritising log collection, alongside "Check again", "Get help in chat" and "Book a call". Filebeat checks for Docker and Kubernetes also address container log collection. Check that the collector can see the host log paths through its mounts and has permission to read them.

Failure modes worth checking first

• Unreachable destination: test from the source host using the actual Logstash hostname and matching input port. Testing from your laptop checks a different network path.
• Incomplete configuration or credentials: replace every placeholder and recheck the chosen stack. HTTP API credentials and a Beats destination belong to different setup routes.
• No new lines: confirm that the application is writing to a configured file. An idle service or an incorrect path can leave a healthy collector with nothing useful to send.
• Test-log-only confusion: finding the curl sample confirms that sample's route. Verify a separate event from Filebeat before calling the server connected.
• Paused checking: return to the onboarding tab if you left it. A paused browser check is different from a stopped collector.
• Pipeline traffic without searchable logs: inspect processing and indexing errors. Receiving bytes does not guarantee a searchable document.
• Wrong search scope: check logstash-*, the time range and @timestamp. Custom index routing requires the corresponding pattern.
• Configuration OK but no shipping: inspect service status and Filebeat logs for read permissions, output retries or TLS errors. Restart after edits and confirm the service uses the configuration you tested.

The trade-offs

Waiting for searchable data can take longer than showing a green "connected" indicator. It is a more honest finish line: you can answer a question with the event that arrived. Connection checks remain useful for diagnosis, but they measure an earlier part of the journey.

Filebeat suits straightforward file collection. OpenTelemetry suits teams already using a Collector or instrumenting applications through that ecosystem. Choose the route you can operate consistently, then prove it with a real message. You do not need to migrate collectors just to complete onboarding.

Skip and resume accommodate setup that depends on another teammate or a maintenance window. The managed stack removes the need to babysit the search cluster, while your team still controls source configuration and verifies that the intended logs arrive.

Frequently asked questions

Can existing logs complete Waiting?

No. Waiting checks for new searchable arrivals. Send a fresh event after configuring the source, then verify that event in Discover. An older document proves historical ingestion, not that today's setup is working.

Does 202 ACCEPTED mean the log is searchable?

It means the API accepted the request. Processing and indexing still need to complete. Keep Waiting open and search for the sample message once it arrives; do not use the HTTP response alone as completion evidence.

Must I use Filebeat?

No. Pick an integration matching your source and existing collection tools. Filebeat is a practical file-tail example here. Windows Event Logs, container output and application telemetry may need different instructions, even when they share the same destination stack.

Why did Launch unlock without my server logs?

A searchable API test log can satisfy the arrival check. Return to Install, complete the server collection setup and find a message written by that server. This separates a successful sample request from ongoing ingestion.

What should I check after skipping and returning?

Reopen setup for the correct stack, confirm the selected source and check whether your collector is running. Generate fresh activity before waiting again. Avoid repeatedly installing a service when the missing step is applying configuration or producing a log.

What should I share when requesting help?

Describe the source, operating system, input protocol and checks you ran. Include sanitised error messages and say whether the API sample or real source is searchable. Remove credentials from configuration excerpts so support can focus on the failing stage.

Get your first useful log into search

Open Getting Started, connect one source and find a fresh event in Discover before adding more. If you are comparing managed search options, explore Hosted OpenSearch. For a new Logs stack, review Logs pricing and choose a plan around the collection you need.