link fixes

Author: gingerwizard

docs/use-cases/observability/build-your-own/index.md

@@ -6,3 +6,13 @@ pagination_next: null
 description: 'Landing page building your own observability stack'
 ---
 
+This guide helps you build a custom observability stack using ClickHouse as the foundation. Learn how to design, implement, and optimize your observability solution for logs, metrics, and traces, with practical examples and best practices.
+
+| Page                                                        | Description                                                                                                                                                                   |
+|-------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| [Introduction](/use-cases/observability/introduction)            | This guide is designed for users looking to build their own observability solution using ClickHouse, focusing on logs and traces.                                             |
+| [Schema design](/use-cases/observability/schema-design)          | Learn why users are recommended to create their own schema for logs and traces, along with some best practices for doing so.                                                  |
+| [Managing data](/observability/managing-data)          | Deployments of ClickHouse for observability invariably involve large datasets, which need to be managed. ClickHouse offers features to assist with data management.           |
+| [Integrating OpenTelemetry](/observability/integrating-opentelemetry) | Collecting and exporting logs and traces using OpenTelemetry with ClickHouse.                                                           |
+| [Using Visualization Tools](/observability/grafana)    | Learn how to use observability visualization tools for ClickHouse, including HyperDX and Grafana.                                       |
+| [Demo Application](/observability/demo-application)    | Explore the OpenTelemetry demo application forked to work with ClickHouse for logs and traces.                                           |

docs/use-cases/observability/build-your-own/integrating-opentelemetry.md

@@ -537,7 +537,7 @@ A few important notes on this schema:
 - The table uses the classic [`MergeTree` engine](/engines/table-engines/mergetree-family/mergetree). This is recommended for logs and traces and should not need to be changed.
 - The table is ordered by `ORDER BY (ServiceName, SeverityText, toUnixTimestamp(Timestamp), TraceId)`. This means queries will be optimized for filters on `ServiceName`, `SeverityText`, `Timestamp` and `TraceId` - earlier columns in the list will filter faster than later ones e.g. filtering by `ServiceName` will be significantly faster than filtering by `TraceId`. Users should modify this ordering according to their expected access patterns - see [Choosing a primary key](/use-cases/observability/schema-design#choosing-a-primary-ordering-key).
 - The above schema applies `ZSTD(1)` to columns. This offers the best compression for logs. Users can increase the ZSTD compression level (above the default of 1) for better compression, although this is rarely beneficial.  Increasing this value will incur greater CPU overhead at insert time (during compression), although decompression (and thus queries) should remain comparable. See [here](https://clickhouse.com/blog/optimize-clickhouse-codecs-compression-schema) for further details. Additional [delta encoding](/sql-reference/statements/create/table#delta) is applied to the Timestamp with the aim of reducing its size on disk.
-- Note how [`ResourceAttributes`](https://opentelemetry.io/docs/specs/otel/resource/sdk/), [`LogAttributes`](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-attributes) and [`ScopeAttributes`](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-instrumentationscope) are maps. Users should familiarize themselves with the difference between these. For how to access these maps and optimize accessing keys within them, see [Using maps](/use-cases/observability/integrating-opentelemetry.md).
+- Note how [`ResourceAttributes`](https://opentelemetry.io/docs/specs/otel/resource/sdk/), [`LogAttributes`](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-attributes) and [`ScopeAttributes`](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-instrumentationscope) are maps. Users should familiarize themselves with the difference between these. For how to access these maps and optimize accessing keys within them, see [Using maps](/use-cases/observability/schema-design#using-maps).
 - Most other types here e.g. `ServiceName` as LowCardinality, are optimized.  Note the Body, although JSON in our example logs, is stored as a String.
 - Bloom filters are applied to map keys and values, as well as the Body column. These aim to improve query times on accessing these columns but are typically not required. See [Secondary/Data skipping indices](/use-cases/observability/schema-design#secondarydata-skipping-indices).
 

docs/use-cases/observability/clickstack/architecture.md

@@ -2,7 +2,7 @@
 slug: /use-cases/observability/clickstack/architecture
 pagination_prev: null
 pagination_next: null
-description: 'Architecture of ClickStack ClickHouse Observability Stack'
+description: 'Architecture of ClickStack - The ClickHouse Observability Stack'
 title: 'Architecture'
 ---
 

docs/use-cases/observability/clickstack/config.md

@@ -369,7 +369,7 @@ For details on configuring the wider OTel collector, including [`receivers`](htt
 
 ### Modifying configuration {#modifying-otel-collector-configuration}
 
-If you are managing your own OpenTelemetry Collector - such as when using the HyperDX only distribution - you are responsible for defining its configuration. We [recommend still using the official ClickStack distribution of the collector](/observability/clickstack/deployment/hyperdx-only#otel-collector) where possible, but if you choose to bring your own, ensure it includes the [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter).
+If you are managing your own OpenTelemetry Collector - such as when using the HyperDX only distribution - you are responsible for defining its configuration. We [recommend still using the official ClickStack distribution of the collector](/use-cases/observability/clickstack/deployment/hyperdx-only#otel-collector) where possible, but if you choose to bring your own, ensure it includes the [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter).
 
 If you’re using a ClickStack distribution that includes the OpenTelemetry Collector - such as the [All-in-One](/use-cases/observability/clickstack/deployment/all-in-one), [Docker Compose](/use-cases/observability/clickstack/deployment/docker-compose), or [Helm](/use-cases/observability/clickstack/deployment/helm) chart - you can override the default configuration in the following ways:
 

docs/use-cases/observability/clickstack/deployment/docker-compose.md

@@ -117,21 +117,19 @@ This distribution can be used with ClickHouse Cloud. Users should:
     otel-collector:
         image: ${OTEL_COLLECTOR_IMAGE_NAME}:${IMAGE_VERSION}
         environment:
-        CLICKHOUSE_ENDPOINT: '<CLICKHOUSE_SERVER_ENDPOINT>' # https endpoint here
-        CLICKHOUSE_USER: '<CLICKHOUSE_USER>'
-        CLICKHOUSE_PASSWORD: '<CLICKHOUSE_PASSWORD>'
-        HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
+          CLICKHOUSE_ENDPOINT: '<CLICKHOUSE_SERVER_ENDPOINT>' # https endpoint here
+          CLICKHOUSE_USER: '<CLICKHOUSE_USER>'
+          CLICKHOUSE_PASSWORD: '<CLICKHOUSE_PASSWORD>'
+          HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
         ports:
-        - '13133:13133' # health_check extension
-        - '24225:24225' # fluentd receiver
-        - '4317:4317' # OTLP gRPC receiver
-        - '4318:4318' # OTLP http receiver
-        - '8888:8888' # metrics extension
+          - '13133:13133' # health_check extension
+          - '24225:24225' # fluentd receiver
+          - '4317:4317' # OTLP gRPC receiver
+          - '4318:4318' # OTLP http receiver
+          - '8888:8888' # metrics extension
         restart: always
         networks:
-        - internal
-        depends_on:
-        - ch-server
+          - internal
     ```
 
     The `CLICKHOUSE_SERVER_ENDPOINT` should be the ClickHouse Cloud HTTPS endpoint, including the port `8443` e.g. `https://mxl4k3ul6a.us-east-2.aws.clickhouse.com:8443`

docs/use-cases/observability/clickstack/deployment/helm.md

@@ -9,7 +9,7 @@ description: 'Deploying ClickStack with Helm - The ClickHouse Observability Stac
 import Image from '@theme/IdealImage';
 import hyperdx_24 from '@site/static/images/use-cases/observability/hyperdx-24.png';
 
-The helm chart for HyperDX can be found [here](git@github.com:hyperdxio/helm-charts.git) and is the **recommended** method for production deployments.
+The helm chart for HyperDX can be found [here](https://github.com/hyperdxio/helm-charts) and is the **recommended** method for production deployments.
 
 By default, the Helm chart provisions all core components, including:
 
@@ -68,11 +68,7 @@ Verify the installation:
 kubectl get pods -l "app.kubernetes.io/name=hdx-oss-v2"
 ```
 
-When all pods are ready proceed. To debug failed installs:
-
-```bash
-helm install my-hyperdx hyperdx/hdx-oss-v2 --debug --dry-run
-```
+When all pods are ready proceed.
 
 ### Forward ports {#forward-ports}
 
@@ -191,6 +187,12 @@ hyperdx:
 
 ## Using ClickHouse Cloud {#using-clickhouse-cloud}
 
+If using ClickHouse Cloud users disable the ClickHouse instance deployed by the Helm chart:
+
+```bash
+helm install myrelease hyperdx-helm --set clickhouse.enabled=false --set clickhouse.persistence.enabled=false 
+```
+
 
 ## Production notes {#production-notes}
 

docs/use-cases/observability/clickstack/index.md

@@ -10,15 +10,14 @@ description: 'Landing page for the ClickHouse Observability Stack'
 
 | Section | Description |
 |---------|-------------|
-| [Overview](overview.md) | Introduction to ClickStack and its key features |
-| [Getting Started](getting-started.md) | Quick start guide and basic setup instructions |
-| [Architecture](architecture.md) | System architecture and components overview |
-| [Configuration](config.md) | Detailed configuration options and settings |
-| [Sending Data](sending-data.md) | Guidelines for sending data to ClickStack |
-| [Search](search.md) | How to search and query your observability data |
-| [Production](production.md) | Best practices for production deployment |
-| [SDKs](sdks/) | Software Development Kits for various languages |
-| [Example Datasets](example-datasets/) | Sample datasets and use cases |
-| [Deployment](deployment/) | Deployment guides and options |
-
+| [Overview](/use-cases/observability/clickstack/overview) | Introduction to ClickStack and its key features |
+| [Getting Started](/use-cases/observability/clickstack/getting-started) | Quick start guide and basic setup instructions |
+| [Example Datasets](/use-cases/observability/clickstack/sample-datasets) | Sample datasets and use cases |
+| [Architecture](/use-cases/observability/clickstack/architecture) | System architecture and components overview |
+| [Deployment](/use-cases/observability/clickstack/deployment) | Deployment guides and options |
+| [Configuration](/use-cases/observability/clickstack/config) | Detailed configuration options and settings |
+| [Ingesting Data](/use-cases/observability/clickstack/ingesting-data) | Guidelines for ingesting data to ClickStack |
+| [Search](/use-cases/observability/clickstack/search) | How to search and query your observability data |
+| [Production](/use-cases/observability/clickstack/production) | Best practices for production deployment |
+| [SDKs](/use-cases/observability/clickstack/sdks) | Software Development Kits for various languages |
 

…observability/clickstack/sending-data.md …servability/clickstack/ingesting-data.mddocs/use-cases/observability/clickstack/sending-data.md renamed to docs/use-cases/observability/clickstack/ingesting-data.md docs/use-cases/observability/clickstack/sending-data.md renamed to docs/use-cases/observability/clickstack/ingesting-data.md

@@ -1,10 +1,10 @@
 ---
-slug: /use-cases/observability/clickstack/sending-data
-title: 'Sending data'
-sidebar_label: 'Sending data'
+slug: /use-cases/observability/clickstack/ingesting-data
+title: 'Ingesting data'
+sidebar_label: 'Ingesting data'
 pagination_prev: null
 pagination_next: null
-description: 'Sending data to ClickStack'
+description: 'Ingesting data to ClickStack'
 ---
 
 All data is ingested into ClickStack via the **OpenTelemetry Collector**, which acts as the primary entry point for logs, metrics, traces, and session data.

docs/use-cases/observability/clickstack/overview.md

@@ -46,7 +46,7 @@ ClickStack consists of three core components:
 
 These components can be deployed independently or together. A browser-hosted version of the HyperDX UI is also available, allowing users to connect to existing ClickHouse deployments without additional infrastructure.
 
-To get started, visit the [Getting Started guide](/use-cases/observability/clickstack/getting-started). You can also explore documentation on [deployment](/use-cases/observability/clickstack/deployment), [scaling](/use-cases/observability/clickstack/scaling), and [production best practices](/use-cases/observability/clickstack/production).
+To get started, visit the [Getting Started guide](/use-cases/observability/clickstack/getting-started) before loading a [sample dataset](/use-cases/observability/clickstack/sample-datasets). You can also explore documentation on [deployment options](/use-cases/observability/clickstack/deployment) and [production best practices](/use-cases/observability/clickstack/production).
 
 ### Principles {#clickstack-principles}
 

docs/use-cases/observability/clickstack/sdks/index.md

@@ -0,0 +1,8 @@
+---
+slug: /use-cases/observability/clickstack/sdks
+pagination_prev: null
+pagination_next: null
+description: 'Language SDKs for ClickStack - The ClickHouse Observability Stack'
+title: 'SDKs'
+---
+