When your platform coordinates patient transportation, home care, and DME delivery for hospitals and health systems, downtime isn't an option. At VectorCare, we rely on real-time monitoring across every integration and service layer to keep our patient logistics workflows running without interruption. That's why Elastic Observability documentation matters to teams like ours, and likely to yours, too, if you're responsible for keeping critical healthcare systems performant and reliable.

Elastic Observability unifies logs, metrics, and application traces into a single stack, giving engineering and operations teams the visibility they need to catch issues before they reach end users. But getting it set up correctly, from ingesting your first data sources to building meaningful dashboards, requires more than a quick skim of a README. You need to know where to find the right references and how to apply them to your specific infrastructure.

This guide walks you through the core Elastic Observability documentation, covering initial setup, key configuration steps, and the reference materials you'll want bookmarked. Whether you're instrumenting a new service or troubleshooting an existing deployment, the goal here is straightforward: get you to the right resource faster so you can spend less time searching and more time building observable systems that hold up under pressure.

Map the Elastic Observability docs you need

Before you run a single command, knowing where the documentation lives and how it's organized saves significant time. The official Elastic Observability documentation is split across several distinct areas, each serving a different stage of your setup. Mapping those areas upfront means you pull the right reference at the right moment rather than bouncing between unrelated pages.

The main documentation hubs

Elastic organizes its observability content across three primary locations you'll return to repeatedly. Understanding what lives where prevents confusion when a setup step references a concept documented in a completely separate guide.

The Fleet and Elastic Agent documentation is entirely separate from the main Observability guide, so bookmark both before you start any configuration work.

How the docs are versioned

Every page in the elastic observability documentation carries a version selector at the top of the screen. If your cluster runs Elastic Stack 8.13, lock that selector to 8.13 before copying any configuration snippet. Mismatched versions are the most common source of broken setup steps, particularly for Elastic Agent policies and integration settings where field names and defaults change between releases.

Your deployment version also controls which features appear in Kibana. For example, SLO management became generally available in version 8.12, so any earlier stack simply will not show those options under Observability. Confirm your current stack version in Kibana under Stack Management before opening any setup guide, and you'll avoid chasing configuration options that don't exist yet in your environment.

Step 1. Pick your deployment and feature tier

Your deployment model determines which setup path you follow in the elastic observability documentation, so confirm this before reading any further. Elastic offers two primary options: Elastic Cloud (fully managed) and self-managed on your own infrastructure. Each option has a different starting point in the docs, and mixing up references between them leads to configuration steps that simply do not apply to your environment.

If you run on Elastic Cloud, skip the installation guides entirely and start directly with the Fleet setup and integration configuration pages.

Deployment options and their feature tiers

Elastic Cloud gives you access to features based on your subscription tier: Standard, Gold, Platinum, or Enterprise. Self-managed deployments require you to apply a license manually through the Kibana License Management page under Stack Management before any paid features activate.

Confirm your current tier in Kibana under Stack Management > License Management before opening any feature-specific guide. Attempting to configure a feature your tier does not include produces misleading error messages and wastes time better spent on actual instrumentation work.

Step 2. Ingest logs and infrastructure metrics

With your deployment confirmed and your tier locked in, the next task is getting data flowing into your stack. The elastic observability documentation separates this work into two distinct parts: deploying the collection agent and then configuring the integrations that tell it exactly what to collect and where to forward it.

Install and enroll Elastic Agent

Elastic Agent is the single binary that handles log collection, metric gathering, and integration management across your hosts. Install it on each host you want to monitor using the command that matches your operating system. For a Linux host, the setup looks like this:

curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.13.0-linux-x86_64.tar.gz
tar xzvf elastic-agent-8.13.0-linux-x86_64.tar.gz
cd elastic-agent-8.13.0-linux-x86_64
sudo ./elastic-agent install --url=<fleet-server-url> --enrollment-token=<your-token>

Copy your enrollment token from Fleet > Enrollment Tokens in Kibana before running this command, not after.

Add infrastructure integrations

Kibana's Integrations catalog under Fleet lists every supported data source, including system metrics, Kubernetes, AWS, and Docker. Select an integration, configure the dataset paths or credentials, and assign it to an agent policy to begin collecting data immediately without restarting the agent. Your enrolled hosts pick up the new policy automatically within seconds of saving your changes.

Step 3. Add application tracing and synthetics

With your infrastructure metrics flowing, the next layer to add is application-level visibility. The elastic observability documentation covers two tools for this: APM agents that instrument your code directly, and synthetic monitors that simulate user journeys to catch availability issues before real users do.

Instrument your application with APM agents

Elastic APM agents slot into your application code and send trace data to the APM Server. For a Node.js service, the setup takes three lines added before any other imports in your entry file:

const apm = require('elastic-apm-node').start({
  serviceName: 'your-service-name',
  serverUrl: 'https://<your-apm-server-url>',
  secretToken: '<your-secret-token>'
});

Confirm your APM Server URL and secret token in Kibana under Observability > Add data > APM before modifying any application code.

Elastic supports agents for Java, Python, Ruby, Go, .NET, and PHP in addition to Node.js, and each agent's dedicated guide lives under the APM section of the official docs.

Set up synthetic monitors

Synthetic monitoring lets you run scripted browser checks on a schedule directly from Kibana under Observability > Synthetics. Configure a lightweight HTTP monitor by specifying your endpoint URL, check interval, and alert threshold, and Kibana begins reporting uptime and response time data within one minute.

Step 4. Explore data, dashboards, alerts, and SLOs

With logs, metrics, and traces landing in your stack, you can now use Kibana's Observability section to make that data useful. This is where the elastic observability documentation pays off most visibly: every UI workflow has a corresponding reference page that explains the exact fields, thresholds, and syntax options available to you.

Build dashboards and set alert rules

Navigate to Observability > Overview in Kibana to see a pre-built summary of your services, hosts, and uptime monitors. From there, open Analytics > Dashboards to clone any built-in template and customize it for your environment. To create an alert, go to Observability > Alerts > Manage Rules, click Create rule, and set a threshold condition:

Metric: system.cpu.total.norm.pct
Threshold: > 0.85
Check every: 1 minute
Notify: Slack or email action connector

Save your alert rule before adding notification connectors, since Kibana discards unsaved rule configurations on connector setup screens.

Configure SLOs

Go to Observability > SLOs > Create SLO and define your indicator, time window, and target. Select APM Latency or Availability as your indicator type, then set a rolling 30-day window with a 99.5% target. Kibana calculates your error budget automatically and surfaces it directly on the SLO detail page.

Next steps to keep your stack healthy

You now have the core setup complete, but maintaining a healthy Elastic stack requires consistent attention after the initial rollout. Revisit the elastic observability documentation each time you upgrade your stack version, since integration schemas, agent policies, and alerting syntax all shift between releases. Set a reminder to review your alert rules and SLO targets every quarter to confirm they still reflect your actual service performance expectations.

Run a review of your agent enrollment monthly to catch any hosts that dropped from Fleet silently. Stale or disconnected agents stop forwarding data without generating visible errors in Kibana, which means blind spots develop gradually until someone notices a gap in a dashboard.

Beyond the stack itself, your broader patient logistics operations require the same level of coordination discipline. If you want to see how purpose-built logistics automation reduces operational overhead across care delivery, explore what VectorCare's patient logistics platform makes possible for healthcare organizations.