Release

src/content/docs/docs/infrastructure/kubernetes/index.mdx

@@ -57,6 +57,7 @@ KloudMate provides visibility into all major Kubernetes components:
 - **Nodes:** infrastructure-level resource usage and node health
 - **Namespaces:** resource distribution across teams, applications, or environments
 - **Pods:** pod performance, restarts, and resource consumption
+- **Storage:** Persistent Volume Claims (PVCs) across clusters — status, claim, storage class, and capacity
 - **Workloads:** health and availability of deployments, daemonsets, and statefulsets
 
 ## Validation Checklist

src/content/docs/docs/kloudmate-agent/custom-config-override.mdx

@@ -8,40 +8,44 @@ sidebar:
 
 import { LinkCard, CardGrid } from '@astrojs/starlight/components';
 
-The **custom config override** lets you add your own collector configuration on top of a managed agent, without giving up managed mode. Use it when the managed integrations cover almost everything you need and you want to add one processor, adjust an exporter, or wire in an extra pipeline.
+The **custom config override** lets you add your own collector configuration on top of a managed agent, without giving up managed mode. Use it when the managed integrations cover almost everything you need and you want to add a processor, send data to a second place, or turn off one metric.
 
-This is the lighter alternative to [manual mode](../advanced-configuration/). Manual mode hands you the whole collector YAML and turns the feature toggles off. The override keeps you in managed mode, keeps every toggle working, and applies only the small piece of YAML you add.
+This is the recommended alternative to [manual mode](../advanced-configuration/). Manual mode hands you the whole collector YAML and turns the feature toggles off. The override keeps you in managed mode, keeps every toggle working, and applies only the piece of YAML you add.
+
+Write plain collector YAML. You don't add a `kloudmate:` wrapper or know the rest of the config. The agent merges what you write into the live configuration on the host.
 
 ## Where the override sits
 
-Your override is the **final layer** of the agent's configuration. The agent merges it on top of everything else, in this order:
+Your override is the final layer of the agent's configuration. The agent applies it on top of everything else, in this order:
 
 1. The base configuration.
 2. Whatever your managed integrations generate.
 3. Every receiver and processor the agent adds automatically (eBPF, PHP, PM2, database monitoring, and so on).
-4. **Your override, last.**
+4. Your override, last.
 
-Because it merges last, the override wins any conflict. It is also kept when your integrations change, so you do not have to reapply it after toggling a feature.
+Because it applies last, the override wins any conflict. The agent also keeps it when your integrations change, so you don't reapply it after toggling a feature.
 
 ## Set an override
 
 1. Open the agent's **Configuration** page.
 2. Find the **Custom config override** section.
-3. Enter your collector YAML in the editor. It is validated as you type.
+3. Enter your collector YAML in the editor. It's validated as you type.
 4. Choose **Save override**.
 
 The agent picks up the change on its next check-in.
 
 ## How the merge works
 
-The override is deep-merged with the configuration underneath it:
+What happens depends on what you write:
+
+- **Pipeline lists add, they don't replace.** When you set a pipeline's `processors`, `receivers`, or `exporters`, the agent adds your entries to what's already there and keeps everything the managed config and automatic monitoring put in the pipeline. List only what you want to add. A new processor lands just before `batch`. Adding a component that's already present does nothing, so an override stays correct even as the agent adds more receivers over time.
+- **Everything else deep-merges.** Maps merge key by key, so you change one setting by writing only the path down to it. A scalar or a non-pipeline list that you set replaces what was there.
 
-- **Maps merge.** Adding a new processor under `processors:` leaves the existing processors untouched.
-- **Scalars and lists are replaced, not combined.** If your override sets a key that already has a value, or a list such as a pipeline's `receivers:`, your value replaces what was there. A list is never appended to, so include every element you want when you override one.
+Two things an override can't do: remove a component from a pipeline, or change where the agent sends data. You can add another destination, but the default one stays and can't be repointed. To stop collecting something, add a `filter` processor instead of removing one.
 
-## Example: stamp an attribute on all metrics
+## Add a processor to a pipeline
 
-This adds a `resource` processor and wires it into the metrics pipeline, so every metric carries a `team` attribute:
+Stamp a `team` attribute on every metric. List only `resource/team`; the agent adds it to the metrics pipeline before `batch` and leaves the other processors in place.
 
 ```yaml
 processors:
@@ -56,21 +60,180 @@ service:
       processors: [resource/team]
 ```
 
-Because a list is replaced rather than merged, the `processors:` list you set here becomes the metrics pipeline's processor list. Include the other processors that pipeline needs alongside `resource/team`.
+## Send data to a second destination
+
+Fan traces out to your own endpoint alongside KloudMate. Define the exporter, then add it to the pipeline. The default `otlphttp` exporter stays, so KloudMate keeps receiving the same traces.
+
+```yaml
+exporters:
+  otlphttp/backup:
+    endpoint: https://otel.example.com:4318
+    headers:
+      Authorization: <your-token>
+service:
+  pipelines:
+    traces:
+      exporters: [otlphttp/backup]
+```
 
-## Example: raise exporter verbosity while debugging
+## Turn off a single metric
 
-To make the debug exporter log full telemetry while you diagnose a pipeline:
+Disable one host metric without touching the rest. Maps merge, so you write only the path to the `enabled` flag. Every other scraper, metric, and setting stays as the managed config left it.
+
+```yaml
+receivers:
+  hostmetrics:
+    scrapers:
+      cpu:
+        metrics:
+          system.cpu.utilization:
+            enabled: false
+```
+
+## Drop telemetry that matches a condition
+
+To stop collecting something, add a `filter` processor rather than removing one. Conditions are [OTTL](https://opentelemetry.io/docs/collector/transforming-telemetry/) expressions, so you drop exactly what you don't want. This drops health-check spans and any span under an internal path:
+
+```yaml
+processors:
+  filter/drop_noise:
+    error_mode: ignore
+    traces:
+      span:
+        - 'span.attributes["http.route"] == "/healthz"'
+        - 'IsMatch(span.attributes["url.path"], "/internal/.*")'
+service:
+  pipelines:
+    traces:
+      processors: [filter/drop_noise]
+```
+
+The same processor drops a high-volume metric:
+
+```yaml
+processors:
+  filter/drop_metric:
+    error_mode: ignore
+    metrics:
+      metric:
+        - 'metric.name == "process.runtime.gc_count"'
+service:
+  pipelines:
+    metrics:
+      processors: [filter/drop_metric]
+```
+
+## Keep only the logs that matter
+
+To cut log volume without losing the signal, keep `WARN` and above and drop the rest. This is usually a bigger and safer saving than random log sampling, which drops errors along with the noise.
+
+```yaml
+processors:
+  filter/min_severity:
+    error_mode: ignore
+    logs:
+      log_record:
+        - 'log.severity_number < SEVERITY_NUMBER_WARN'
+service:
+  pipelines:
+    logs:
+      processors: [filter/min_severity]
+```
+
+Adjust the threshold: `SEVERITY_NUMBER_INFO` keeps info and above, `SEVERITY_NUMBER_ERROR` keeps only errors.
+
+## Sample a percentage of traces and logs
+
+Sampling cuts volume *uniformly*: it keeps a random fraction and drops the rest, **including errors in the same proportion**. Use it for high-volume but uniform telemetry (a firehose of successful requests), and pair it with the filters above so the records you care about still survive.
+
+The `probabilistic_sampler` keeps a deterministic percentage of traces by trace ID, so every span of a kept trace stays together:
+
+```yaml
+processors:
+  probabilistic_sampler:
+    sampling_percentage: 10
+service:
+  pipelines:
+    traces:
+      processors: [probabilistic_sampler]
+```
+
+For logs, `attribute_source: record` samples every log. The default, `traceID`, only samples logs that carry a trace ID, so unlinked logs pass through untouched:
+
+```yaml
+processors:
+  probabilistic_sampler/logs:
+    sampling_percentage: 10
+    attribute_source: record
+service:
+  pipelines:
+    logs:
+      processors: [probabilistic_sampler/logs]
+```
+
+## Keep error and slow traces, sample the rest
+
+Tail sampling decides after a trace finishes, so you can keep every error and slow trace whole and sample only the successful, fast ones. Add the `tail_sampling` processor to the traces pipeline:
+
+```yaml
+processors:
+  tail_sampling:
+    decision_wait: 5s
+    policies:
+      - name: keep-errors
+        type: status_code
+        status_code:
+          status_codes: [ERROR]
+      - name: keep-slow
+        type: latency
+        latency:
+          threshold_ms: 1000
+      - name: sample-the-rest
+        type: probabilistic
+        probabilistic:
+          sampling_percentage: 10
+```
+
+```yaml
+service:
+  pipelines:
+    traces:
+      processors: [tail_sampling]
+```
+
+Set `decision_wait` comfortably longer than your slowest trace, since the collector buffers a trace's spans in memory until then. Tail sampling also needs every span of a trace to reach the same collector, which holds on a VM or Docker host. On Kubernetes spans are spread across per-node agents, so tail sampling belongs on a single gateway collector, not the node agents.
+
+## Change a component setting
+
+Adjust an existing component by setting only the field you want. This makes the debug exporter log full telemetry while you diagnose a pipeline.
 
 ```yaml
 exporters:
   debug:
     verbosity: detailed
 ```
 
+## On Kubernetes
+
+A Kubernetes agent runs two collectors, so the override is split into two sections. Put node-level changes under `daemonset_config` and cluster-level changes under `deployment_config`. Each section is plain collector YAML and merges the same way.
+
+```yaml
+deployment_config:
+  processors:
+    resource/env:
+      attributes:
+        - key: deployment.environment
+          value: production
+          action: upsert
+  service:
+    pipelines:
+      metrics/otlp:
+        processors: [resource/env]
+```
+
 ## Safety
 
-Before it applies a new configuration, the agent validates it. If your override makes the configuration invalid (most often from a wrong top-level key), the agent **rejects it and keeps the last working configuration** instead of restarting the collector into a broken state. The reason is reported back to your workspace, so you can see why an override was not applied without logging in to the host.
+Before it applies a new configuration, the agent validates it. If your override makes the configuration invalid, most often from a wrong top-level key, the agent rejects it and keeps the last working configuration instead of restarting the collector into a broken state. The reason is reported back to your workspace, so you can see why an override wasn't applied without logging in to the host.
 
 ## Related
 

src/content/docs/docs/platform/settings/index.mdx

@@ -9,6 +9,7 @@ The Settings area is where you manage workspaces, users, security, billing, and
 
 ## In This Section
 
+- [Organization](./organization/)
 - [Workspaces](./workspaces/)
 - [API Keys](./api-keys/)
 - [Users & Permissions](./users-permissions/)

src/content/docs/docs/platform/settings/organization.mdx

@@ -0,0 +1,45 @@
+---
+title: "Organization"
+description: "Manage your organization's display name, default timezone, overage policy, and your own membership."
+sidebar:
+  label: "Organization"
+  order: 1.5
+---
+
+Organization settings apply org-wide: the display name, default timezone, and overage policy.
+
+Open **Settings → Organization** to view or edit these settings.
+
+:::note
+Only an organization owner can edit these settings. Other members see the page in read-only mode.
+:::
+
+![Organization profile page, showing the General, Overage policy, and Danger Zone cards](./images/organization-profile.png)
+
+## General
+
+Set the organization's display name and default timezone. The timezone is the org-wide default for shared artifacts like alert schedules and reports; individual users can override it for themselves in their own [Profile & Security](../profile-security/) settings.
+
+## Overage Policy
+
+Controls what happens when usage exceeds your plan's allowance:
+
+- **Off (default):** overage is billed at the per-unit overage rate.
+- **On:** KloudMate suspends ingest the moment usage crosses the threshold, protecting against runaway bills.
+
+Toggle **Allow unlimited overage** to switch between the two.
+
+## Leave an Organization
+
+Instead of asking an owner to remove you, you can leave an organization yourself — useful cleanup if you've accumulated memberships in organizations or workspaces you no longer use.
+
+- **Non-owners** can leave at any time.
+- **Owners** must transfer ownership to another member first. An organization always needs at least one owner, so the leave action stays unavailable until ownership is transferred.
+
+Use **Leave organization** in the **Danger Zone**. Leaving removes your access to the organization and every workspace and data set associated with it.
+
+## Related
+
+- [Workspaces](../workspaces/)
+- [Users & Permissions](../users-permissions/)
+- [Profile & Security](../profile-security/)

src/content/docs/docs/platform/settings/users-permissions.mdx

@@ -17,8 +17,6 @@ User management is available to organization owners. Use this page to invite use
 
 Open **Settings -> Users** and click **Invite User** or **Add User**.
 
-![image](./images/users-_-permissions-1.png)
-
 Enter the user's email address and assign the required permissions.
 
 ![image](./images/users-_-permissions-2.png)

src/content/docs/docs/visualize-data/dashboards/dashboard-details.mdx

@@ -27,7 +27,7 @@ The toolbar at the top provides the following controls:
 ![image](./images/dashboard-details-3.jpeg)
 
 - **Export:** Exports the dashboard.
-- **Share:** Opens the Share Dashboard dialog to generate a public link.
+- **Share:** Opens the Share Dashboard dialog, with options for a public link or a copy of the dashboard's JSON.
 - **Fullscreen:** Expands the dashboard to fullscreen view.
 - **Edit:** Enters edit mode to modify the dashboard and its panels.
 
@@ -42,24 +42,24 @@ KloudMate integrates alerts directly into your dashboard visualizations, providi
 
 ## Sharing a Dashboard
 
-Click the **Share** button to open the Share Dashboard dialog. Sharing generates a public link that anyone can use to view the dashboard without logging in to KloudMate.
+Click **Share** — from the dashboard list's more options (⋯) icon, or from an individual dashboard's toolbar — to open the Share Dashboard dialog. Both entry points offer the same two options.
 
 ![image](./images/dashboard-details-2.png)
 
+### Public link
+
+Generates a link that anyone can use to view the dashboard without logging in to KloudMate.
+
 - **Enable public sharing:** Toggle this on to activate the public link.
 - **Allow time range selection:** Toggle this on to let viewers change the time range when viewing the shared dashboard.
 - **Time range:** Sets the default time range viewers will see when they open the shared link.
 
 Click **Save** to apply the settings. The shared link can be managed from the **Public Dashboards** page.
 
-## Sharing a Dashboard Across Workspaces
-
-You can replicate a dashboard in another workspace by exporting it as JSON. This saves time when the same dashboard layout is needed across multiple workspaces.
-
-To share:
+### Copy JSON
 
-1. Open the dashboard and click the more options icon, then select **Share**. This copies the dashboard JSON to your clipboard.
+Copies the dashboard's JSON definition to your clipboard. Use this to replicate a dashboard in another workspace: same layout, no manual rebuild.
 
 ![image](./images/dashboard-details-4.jpeg)
 
-2. Navigate to the Dashboards section in the target workspace, click **Import** , paste the copied JSON, and click **Submit**. The dashboard is recreated in the new workspace.
+To recreate it elsewhere, navigate to the Dashboards section in the target workspace, click **Import**, paste the copied JSON, and click **Submit**. The dashboard is recreated in the new workspace.

src/content/docs/docs/visualize-data/dashboards/index.mdx

@@ -13,7 +13,7 @@ Navigate to **Dashboards** from the left navigation menu to view all your existi
 
 The Dashboards screen lists all dashboards and folders by name and description. You can search for a specific dashboard using the search bar. Use the view toggle at the top-right to switch between list and grid view.
 
-From the more options (⋯) icon on any dashboard or folder, you can **edit** or **delete** it.
+From the more options (⋯) icon on any dashboard or folder, you can **edit**, **delete**, or **share** it. Sharing offers both a copyable public link and a copy of the dashboard's JSON — see [Sharing a Dashboard](./dashboard-details/#sharing-a-dashboard).
 
 ### User Permissions
 

src/content/docs/docs/visualize-data/explore/index.mdx

@@ -60,7 +60,7 @@ This walkthrough focuses on metrics.
 <Image src={exploreRanking} alt="Ranking" width={340} />
 
    - Use **Legend Format** to customize series labels.
-   - Switch to the **PromQL** tab if you prefer raw query expressions.
+   - Switch to the **PromQL** tab if you prefer raw query expressions. Its search bar is now easier to spot, so finding a keyword in a long query takes fewer clicks.
 
 5. **Add Queries and Expressions**
    Use **Add Query** to compare multiple metric series in one panel.