* otel tutorial: fix the restore timeout, source the latency claim, close the coverage gaps
Review fixes for #2643, measured against a 1.17.1 Cloud cluster.
restore.py failed as written. recover_snapshot blocks until the restore
completes, which outlives the client's default timeout, so the reader got
a stack trace while the restore kept running server-side. Because the
collection_exists guard then no-ops on a re-run, it looked like the script
had never worked. timeout=600 on the client.
Step 7 asked the reader to correlate the slowest span with a cluster
signal, but ranked spans by client wall clock. On this collection the two
query shapes sit 1% apart at the client while the database does 26% more
work, so the slowest span is usually a network outlier on the cheaper
query and the correlation exercise had nothing to find. Added the measured
split (2.71 ms inside Qdrant against a 312.6 ms client median, read from
rest_responses_duration_seconds over 20 requests per shape) and pointed
readers at the histogram for ranking.
Also closes four gaps against the observability docs audit: the layer
boundary between database metrics and application tracing, the self-hosted
scrape path, the Grafana dashboard import with its envoy_* panel trap, and
the separation of scrape targets from alerting. Marked the vendor endpoint
table unverified, noted that per_collection=true works before its
documented 1.18, and added what the page was tested against.
* verified-against: drop the claim about a Kubernetes path, the page has none
* otel tutorial: run the collector in Kubernetes
Compose on a laptop is the only deployment path the page had, but the
accounts asking for this run their monitoring inside Kubernetes, and that
is where the setup stalls. Three sections, ordered by what they assume.
Plain manifests build the config map from the otelcol-config.yaml written
in Step 2 rather than restating the scrape jobs, so there is one copy of
the configuration on the page. Namespace, secret, deployment, service,
then the log check and the two-scrape output that says both endpoints are
working. Verified from a pod in kind v1.35.0 against a live 1.17.1 Cloud
cluster, bearer auth from the mounted secret, no scrape errors.
The operator section carries the OpenTelemetryCollector skeleton with the
config block pointing back at Step 2 instead of repeating it, plus the
apiVersion trap: v1beta1 takes config as a structured field and v1alpha1
takes it as a string. The CR wrapper itself is untested here and the
verified-against block says so.
The Prometheus section sends anyone running kube-prometheus-stack to the
existing managed-cloud-prometheus page, since that path needs no collector
at all. It also records the trap that a single ScrapeConfig against
/sys_metrics drops collection_running_optimizations, which is the first
signal to check when queries slow down.
Verified-against now names what is tested and what is not: the kind run is
tested, the self-hosted scrape, the operator resource and the vendor
endpoint rows are not.
* next: drop the external repo link, the other tutorials link only qdrant repos
---------
Co-authored-by: meinsta <9779373+meinsta@users.noreply.github.com>
