Conversation
- Separate Alert Sources, AI Analysis, and Automation sections - Reorganize integrations and notifications hierarchy - Move sinks from Integrations to Notifications & Routing - Add new metric providers documentation - Improve navigation and content clarity - Remove redundant and outdated content 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Separate Alert Sources, AI Analysis, and Automation sections - Reorganize integrations and notifications hierarchy - Move sinks from Integrations to Notifications & Routing - Add new metric providers documentation - Improve navigation and content clarity - Remove redundant and outdated content 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
WalkthroughConsolidates HolmesGPT docs (adds main-features/getting-started, removes many toolset pages), adds Metric Providers section, refactors Alertmanager integration to focus on alert delivery, splits API docs into multiple API pages, updates redirects and navigation, and reorganizes troubleshooting into phased guidance. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Client
participant API as Robusta API
participant Store as Alert Store
participant UI as Robusta UI
rect rgba(200,230,255,0.20)
note right of Client: Send Alerts API (POST /api/alerts)
Client->>API: POST /api/alerts (account_id, alerts[], Bearer token)
API->>Store: Validate & persist alerts
Store-->>API: 200 OK
API-->>Client: { "success": true }
API-->>UI: async notify new alerts
end
rect rgba(200,255,200,0.20)
note right of Client: Export & Stats APIs (GET /api/query/alerts, /api/query/report)
Client->>API: GET /api/query/alerts or /api/query/report (account_id, start_ts, end_ts[, filters])
API->>Store: Query/aggregate alerts
Store-->>API: Results
API-->>Client: JSON payload (list or aggregates)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: CodeRabbit UI 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (8)
docs/help.rst (4)
80-88: Use “macOS” and broaden certificate guidance.
- “Mac OS” → “macOS”
- Mention that Homebrew Python and system Python differ; the “Install Certificates.command” tip applies to python.org installations.
-.. details:: SSL certificate errors on Mac OS +.. details:: SSL certificate errors on macOS @@ - To fix it, run ``/Applications/Python 3.9/Install Certificates.command`` + If you installed Python from python.org, run ``/Applications/Python 3.x/Install Certificates.command`` (adjust the version). + For Homebrew Python, ensure ``certifi`` is up-to-date: ``/opt/homebrew/bin/python3 -m pip install -U certifi``
100-107: Typo and phrasing: “configue” → “configuration” and simplify guidance.- Verify ``sinksConfig`` is defined in your Robusta values file, with at least one sink like Slack, Teams or Robusta UI ("robusta_sink"). If it's your first time installing, the fastest solution is to start configue creation from scratch. + Verify ``sinksConfig`` is defined in your Robusta values file with at least one sink (e.g., Slack, Teams, or Robusta UI via ``robusta_sink``). If this is your first install, the fastest solution is to regenerate your configuration from scratch.
136-148: Kubernetes memory units: use “Mi” instead of “MiB” in YAML.The copy/paste example uses
512MiB, which is invalid for K8s resources. It should be512Mi.runner: resources: requests: - memory: 512MiB + memory: 512Mi limits: - memory: 512MiB + memory: 512Mi
293-301: Standardize to “Alertmanager” and replace placeholder text.
- Heading and body should use “Alertmanager”.
- “Receiver url has namespace TBD” is a placeholder and must be replaced with concrete guidance.
-Alert Manager is not working +Alertmanager is not working @@ -.. details:: Not getting alert manager alerts +.. details:: Not receiving Alertmanager alerts @@ - Receiver url has namespace TBD + 1. Verify the receiver webhook URL points to Robusta and includes the correct account/authorization. + 2. Confirm the matching route selects your alerts and either targets the Robusta receiver first or uses ``continue: true`` on earlier routes. + 3. Check Alertmanager logs for non-2xx webhook responses.If you share the exact expected Robusta webhook format, I can add a ready-to-copy receiver snippet here.
docs/configuration/alertmanager-integration/grafana-alert-manager.rst (1)
14-16: Replace legacy Prometheus metrics-integration reference with new Metric Providers docs.This keeps guidance consistent with the new structure introduced in this PR.
-For metrics integration with self-hosted Grafana, refer to :ref:`metrics-integration docs for Prometheus <Integrating with Prometheus>`. -For Grafana Cloud metrics integration, see :doc:`grafana-cloud-mimir`. +For self-hosted metrics integration, see: + +- :doc:`/configuration/metric-providers-in-cluster` +- :doc:`/configuration/metric-providers-external` + +For Grafana Cloud metrics integration, see :doc:`grafana-cloud-mimir`.docs/configuration/alertmanager-integration/google-managed-prometheus.rst (1)
62-66: Broken demo command: wrong code-block type and missing closing quote.The block is labeled as YAML but contains a shell command, and the URL string is unterminated.
Apply this diff:
-.. code-block:: yaml - - robusta demo-alert --alertmanager-url='http://alertmanager.gmp-system.svc.cluster.local:9093 +.. code-block:: bash + + robusta demo-alert --alertmanager-url='http://alertmanager.gmp-system.svc.cluster.local:9093'docs/configuration/alertmanager-integration/coralogix_managed_prometheus.rst (2)
25-31: Headers block: use JSON and remove comments (UI usually expects strict JSON).The current snippet is marked “yaml” and includes a trailing comment inside the object, which will break JSON parsers in the Coralogix UI.
Apply this diff:
-.. code-block:: yaml - - { - "Content-Type": "application/json", - "Authorization": "Bearer <TOKEN>" # where token is '<ACCOUNT_ID> <SIGNING_KEY>' - } +.. code-block:: json + + { + "Content-Type": "application/json", + "Authorization": "Bearer <ACCOUNT_ID> <SIGNING_KEY>" + }Add a short note below the block, if desired: “Replace ACCOUNT_ID and SIGNING_KEY with your values.”
34-59: Body block: switch to JSON and move guidance out of the payload (JSON doesn’t support comments).Inline comments and YAML label style may fail in the UI.
Apply this diff:
-.. code-block:: yaml - - { - "externalURL": "", - "groupKey": "{}/{}:{}", - "version": "1", - "status": "firing", - "receiver": "robusta receiver", - "alerts": [ - { - "description": "$ALERT_DESCRIPTION", - "status": "firing", - "endsAt": "$EVENT_TIMESTAMP_MS", - "startsAt": "$EVENT_TIMESTAMP_MS", - "generatorURL": "$ALERT_URL", - "annotations": {}, - "labels": { - "cluster_name": "MY_CLUSTER_NAME", # make sure to add your cluster name here for this webhook. Both "cluster" or "cluster_name" labels are also supported - "alertname": "$ALERT_NAME", - "alert_url": "$ALERT_URL" - # Add any additional alert specific fields here - # see here for more parameters https://coralogix.com/docs/alert-webhooks/#custom-alert-webhooks - } - } - ] - } +.. code-block:: json + + { + "externalURL": "", + "groupKey": "{}/{}:{}", + "version": "1", + "status": "firing", + "receiver": "robusta receiver", + "alerts": [ + { + "description": "$ALERT_DESCRIPTION", + "status": "firing", + "endsAt": "$EVENT_TIMESTAMP_MS", + "startsAt": "$EVENT_TIMESTAMP_MS", + "generatorURL": "$ALERT_URL", + "annotations": {}, + "labels": { + "cluster_name": "MY_CLUSTER_NAME", + "alertname": "$ALERT_NAME", + "alert_url": "$ALERT_URL" + } + } + ] + }Add textual notes under the block:
- Ensure you add your cluster label (cluster or cluster_name are supported).
- See Coralogix docs for additional fields.
🧹 Nitpick comments (89)
docs/configuration/alertmanager-integration/_testing_integration.rst (5)
59-60: Prefer Sphinx cross-references over hard-coded HTML paths for internal linksHard-coding an absolute HTML path may break in versioned docs or when the site root changes. Use a section label and a :ref: instead to keep links stable across builds.
Proposed change (assuming the target section has or can get a label like
alert-label-mapping):- `customize this mapping </setup-robusta/additional-settings.html#alert-label-mapping>`_ to fit your environment. + :ref:`customize this mapping <alert-label-mapping>` to fit your environment.If the label doesn’t exist yet in the target page, please add:
.. _alert-label-mapping:immediately above the “Alert label mapping” section header in
setup-robusta/additional-settings.rst.
37-38: Grammar nit: “setup” (noun) vs “set up” (verb)Use “set up” here since it’s a verb phrase.
-If everything is setup properly, this alert will reach Robusta. It will show up in the Robusta UI, Slack, and other configured sinks. +If everything is set up properly, this alert will reach Robusta. It will show up in the Robusta UI, Slack, and other configured sinks.
4-4: Consistent naming: “Alertmanager” (Prometheus upstream style)Prometheus uses “Alertmanager” (lowercase “m”). If the project style guide aligns with upstream, consider standardizing these instances. If you intentionally use “AlertManager,” ignore this.
Example edits:
-Send a dummy alert to AlertManager: +Send a dummy alert to Alertmanager: -3. Select **Alert Manager** under the "Send alert to" section. +3. Select **Alertmanager** under the "Send alert to" section. -... due to AlertManager's `group_wait` and `group_interval` settings. +... due to Alertmanager’s `group_wait` and `group_interval` settings.Also applies to: 18-18, 27-31, 41-41
41-41: Avoid Text Fragments (#:~:text=) in external linksThe “text fragment” part is brittle and not guaranteed to be stable across site updates. Link to the canonical section instead and mention the exact keys in the text.
Suggested rewrite:
- It might take a few minutes for the alert to arrive due to AlertManager's `group_wait` and `group_interval` settings. More info `here <https://prometheus.io/docs/alerting/latest/configuration/#:~:text=How%20long%20to%20wait%20before%20sending%20a%20notification%20about%20new%20alerts%20that%0A%23%20are%20added%20to%20a%20group%20of%20alerts%20for%20which%20an%20initial%20notification%20has%0A%23%20already%20been%20sent>`_. + It might take a few minutes for the alert to arrive due to Alertmanager’s `group_wait` and `group_interval` settings. See the Alertmanager configuration docs for details: https://prometheus.io/docs/alerting/latest/configuration/If you prefer deep-linking to anchors, use the canonical section anchor (without text fragments) once verified.
25-26: Minor copy edit for flowRemove trailing space after “Then” and combine with the next sentence for smoother reading.
-Then - -1. Check **Send alert with no resource**. +Then: +1. Check **Send alert with no resource**.docs/configuration/alertmanager-integration/outofcluster-prometheus.rst (1)
65-65: Nit: mention URL encoding and delimiter behavior for query stringsGiven this gets appended to the base Prometheus URL, call out that values should be URL-encoded and that Robusta will handle inserting '?' or '&' as appropriate (or document the expectation). Prevents user confusion with examples like cluster=prod 1.
Apply this diff to expand the inline comment:
- # Additional query string parameters to be appended to the Prometheus connection URL (optional) + # Additional query string parameters appended to the Prometheus URL (optional). + # Use URL-encoded values. Robusta will add '?' or '&' as needed.docs/configuration/alertmanager-integration/_prometheus_flags_check.rst (2)
3-3: Retain inline code formatting for boolean literalsRevert to using inline code for false/true to keep formatting consistent across docs and avoid ambiguity.
Apply this diff:
-You can disable the Prometheus flags API check by setting the following option to false. +You can disable the Prometheus flags API check by setting the following option to ``false``.
7-8: Replace placeholder “true/false” with concrete YAML samplesThe current snippet isn't valid YAML as-is. Give two explicit examples or add an explanatory comment to avoid copy/paste errors.
Apply this diff:
- globalConfig: - check_prometheus_flags: true/false + # Example 1: Default behavior (perform the flags API check) + globalConfig: + check_prometheus_flags: true + + # Example 2: Disable for providers that don't implement the flags API + globalConfig: + check_prometheus_flags: falsedocs/configuration/alertmanager-integration/alert-manager.rst (1)
1-1: Terminology: “Alertmanager” (lowercase m) is the standard spellingPrometheus uses “Alertmanager” consistently. Recommend aligning with upstream terminology across titles and body.
Apply this diff:
-In-cluster AlertManager Integration +In-cluster Alertmanager Integrationdocs/configuration/alertmanager-integration/_pull_integration.rst (2)
4-6: Clarify scope: metrics vs. alerts and confirm doc pathThis page is about configuring metric querying and silences. Consider explicitly stating that alert routing is configured separately and link to the alert integration page. Also confirm the doc path in :doc: is correct after reorg.
Apply this diff:
-To enable Robusta to pull metrics and create silences, you need to configure Prometheus and AlertManager URLs. +To enable Robusta to pull metrics and create silences, configure Prometheus and Alertmanager URLs. +Alert routing to Robusta is configured separately; see :doc:`/configuration/alertmanager-integration/alert-manager`.And verify:
-See :doc:`Prometheus and metrics configuration </configuration/metric-providers-in-cluster>` for detailed instructions. +See :doc:`Prometheus and metrics configuration </configuration/metric-providers-in-cluster>` for detailed instructions. <!-- keep if path is valid -->
8-10: Auto-detection caveats: add conditions when manual config is requiredAuto-discovery often fails in restricted clusters (NetworkPolicies, custom namespaces, non-default service names). Suggest adding common caveats to set expectations and reduce support load.
Proposed addition after the note:
.. note:: Robusta will attempt to auto-detect Prometheus and AlertManager URLs in your cluster. Manual configuration is only needed if auto-detection fails. + Auto-detection may not work if: + - Prometheus/Alertmanager run in non-standard namespaces or with custom Service names + - NetworkPolicies restrict access from the runner + - ServiceMonitors/Ingresses are used instead of ClusterIP Services + In these cases, follow the manual configuration in the provider docs.docs/configuration/metric-providers-aws.rst (7)
1-2: Consistent provider namingUse the official name “Amazon Managed Service for Prometheus (AMP)” on first mention and a consistent short form thereafter.
Apply this diff:
-AWS Managed Prometheus +Amazon Managed Service for Prometheus (AMP)And line 4:
-Configure Robusta to use Amazon Managed Prometheus (AMP). +Configure Robusta to use Amazon Managed Service for Prometheus (AMP).
54-55: Upgrade step: link explicitly to the upgrade docMake the “Update Robusta” step actionable with a link.
Apply this diff:
-4. :ref:`Update Robusta <Simple Upgrade>` +4. :ref:`Update Robusta <Simple Upgrade>` (see the upgrade guide for applying updated values)
70-73: Tighten wording and defaultsMinor clarity/nit improvements.
Apply this diff:
-- ``PROMETHEUS_SSL_ENABLED``: Always ``"true"`` for AMP +- ``PROMETHEUS_SSL_ENABLED``: Must be ``"true"`` for AMP - ``AWS_SERVICE_NAME``: Always ``"aps"`` for Amazon Prometheus Service - ``AWS_REGION``: The AWS region where your workspace is located
83-101: Scope IAM permissions to the specific workspace ARNLeast-privilege: avoid wildcarding all workspaces.
Apply this diff:
- "Resource": "arn:aws:aps:*:*:workspace/*" + "Resource": "arn:aws:aps:us-east-1:123456789012:workspace/ws-12345678"Also consider adding a second statement permitting the “metrics” endpoints if required by AWS (QueryMetrics covers it for read-only).
106-118: IRSA: include a pointer to AWS docs and namespace/serviceAccount caveatsAdd links and a note that the annotated ServiceAccount must match the runner’s ServiceAccount name/namespace.
Apply this diff:
-For EKS clusters, you can use IAM Roles for Service Accounts (IRSA): +For EKS clusters, you can use IAM Roles for Service Accounts (IRSA): +See AWS docs: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html @@ - runner: - serviceAccount: + runner: + serviceAccount: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/robusta-amp-role + # Ensure this ServiceAccount name/namespace matches the runner's deployment.
122-129: Clarify alerting note and add ingestion link
- AMP does provide Alertmanager, but Robusta alert routing is configured separately. Clarify to avoid implying that no alert setup is required for Robusta.
- Add an explicit link for remote_write ingestion to AMP.
Apply this diff:
-- AlertManager URL is not needed (AWS handles alerting separately) +- An AMP Alertmanager exists, but Robusta alert routing is configured separately. + To send alerts to Robusta, follow :doc:`/configuration/alertmanager-integration/alert-manager`. - Ensure your AWS credentials have permissions to query the AMP workspace - The workspace must be in the same region specified in AWS_REGION + - Set up Prometheus remote_write to AMP per AWS docs: + https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-set-up-ingest-metrics-Prometheus.html
131-136: Cross-links: make next steps concreteAdd a link for “ingestion from your cluster to AMP” and ensure the “metric-providers” overview path is correct.
Apply this diff:
-- Set up ingestion from your cluster to AMP +- Set up ingestion from your cluster to AMP (remote_write)docs/configuration/alertmanager-integration/_alertmanager-config.rst (1)
7-7: Standardize capitalization: “Alertmanager”, not “AlertManager”.Prometheus’ component is spelled “Alertmanager”. Please align these two occurrences for consistency and searchability.
- Add the following to your `AlertManager's config Secret <https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/alerting.md#managing-alertmanager-configuration>`_. + Add the following to your `Alertmanager's config Secret <https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/alerting.md#managing-alertmanager-configuration>`_.- Add the following to your AlertManager configuration, wherever it is defined. + Add the following to your Alertmanager configuration, wherever it is defined.Also applies to: 39-39
docs/configuration/exporting/send-alerts-api.rst (3)
61-65: Clarify allowed priority values and casing to match other docs.Here the allowed values are lowercase and include “error”, while in the export API example the output shows uppercase values like “HIGH”. Please specify whether the API is case-insensitive and what canonical casing is stored/returned. Consider documenting the exact enum your backend accepts and normalizes to.
- * - ``priority`` - - string (one of: ``critical``, ``high``, ``medium``, ``error``, ``warning``, ``info``, ``low``, ``debug``) - - The priority level of the alert. + * - ``priority`` + - string (enum; accepted case-insensitively; canonicalized to ``CRITICAL|HIGH|MEDIUM|WARNING|INFO|LOW|DEBUG``) + - The priority level of the alert. If a non-enum value is provided, the request is rejected.
7-7: Document over-limit behavior and payload constraints.You mention “up to 1000 alerts per request”. Please add what happens if this is exceeded (HTTP status, error_code), and any max body size. This prevents guesswork for integrators.
166-169: Tighten authentication and error semantics.
- Specify the exact permission scope required by the token (e.g., “Write Alerts”).
- List common error codes (401 invalid/expired token, 403 insufficient scope, 404 unknown account_id, 422 validation error with field errors, 429 rate limited), and show a sample validation error payload if applicable.
This improves client-side handling and retries.
Would you like me to draft the expanded “Errors” section once you confirm the exact status codes and permission names?
Also applies to: 185-199
docs/configuration/exporting/alert-export-api.rst (1)
72-76: Add pagination/limits and sort order.For large time ranges, clarify if results are paginated, any default/max page size, sort order (e.g., started_at asc/desc), and how to request subsequent pages. If not paginated, call out any max range or record cap.
docs/configuration/metric-providers-in-cluster.rst (2)
72-73: Use consistent “Alertmanager” capitalization and clarify Basic auth format.
- Standardize “Alertmanager” spelling.
- Clarify that Basic auth uses base64(user:password), and give a safe example to avoid confusion.
-For multi-tenant Prometheus or AlertManager, pass the organization ID to all queries: +For multi-tenant Prometheus or Alertmanager, pass the organization ID to all queries:- globalConfig: - prometheus_auth: Bearer <YOUR TOKEN> # Replace with your actual token - alertmanager_auth: Basic <USER:PASSWORD base64-encoded> # Replace with base64-encoded credentials + globalConfig: + prometheus_auth: Bearer <YOUR TOKEN> # Replace with your actual token + alertmanager_auth: Basic <BASE64(user:password)> # Example below + +.. code-block:: bash + + # Example: generate base64(user:password) safely (no trailing newline) + printf '%s' 'user:password' | base64Also applies to: 85-92
98-116: Add a security warning about disabled TLS verification by default.Highlighting the risk helps users avoid shipping insecure defaults to production.
-By default, Robusta does not verify the SSL certificate of the Prometheus server. +.. warning:: + By default, Robusta does not verify the SSL certificate of the Prometheus server. + For production clusters, enable verification and provide a trusted CA to prevent MITM risks. + +By default, Robusta does not verify the SSL certificate of the Prometheus server.docs/configuration/holmesgpt/main-features.rst (4)
4-4: Prefer canonical docs link over GitHub repo for product overviewSince most HolmesGPT docs were moved to holmesgpt.dev in this PR, consider linking the first mention to the product docs instead of the GitHub repo.
-Robusta integrates `HolmesGPT <https://github.com/robusta-dev/holmesgpt>`_ to provide AI-powered root cause analysis for Kubernetes alerts and issues. +Robusta integrates `HolmesGPT <https://holmesgpt.dev>`_ to provide AI-powered root cause analysis for Kubernetes alerts and issues.
37-43: Slack usage: briefly note prerequisite to install/authorize the Slack appUsers may not see “Ask HolmesGPT” unless the Slack app is installed and authorized on the workspace. Add a short prerequisite sentence and link to the relevant setup page.
-**Via @holmes in Slack** +**Via @holmes in Slack** + Ensure the Robusta Slack app is installed and authorized for your workspace.
76-78: Consistent “Next Steps” orderingConsider listing the internal doc first, then external references, to keep users within the docs flow before sending them out.
-* `HolmesGPT Documentation <https://holmesgpt.dev>`_ - Advanced configuration and customization -* `Available Data Sources <https://holmesgpt.dev/data-sources/builtin-toolsets/>`_ - See all supported integrations +* `HolmesGPT Documentation <https://holmesgpt.dev>`_ - Advanced configuration and customization +* `Available Data Sources <https://holmesgpt.dev/data-sources/builtin-toolsets/>`_ - See all supported integrations(If you prefer a different order, feel free to ignore.)
34-36: Accessibility: Add alt text to images in docs/configuration/holmesgpt/main-features.rstBoth referenced images exist under
docs/imagesand should include descriptive alt text for accessibility:• File: docs/configuration/holmesgpt/main-features.rst
– Lines 34–36 (ai-root-causeanalysis.png)
– Lines 49–51 (AI_Analysis_demo2.png)Proposed diff:
.. image:: /images/ai-root-causeanalysis.png :width: 600px + :alt: Root cause analysis view in Robusta UI .. image:: /images/AI_Analysis_demo2.png :width: 1000px + :alt: Example HolmesGPT investigation for a CrashLoopBackOff alertThese additions ensure each image conveys its purpose to assistive technologies.
docs/configuration/exporting/namespace-resources-api.rst (2)
66-71: Avoid placing API keys directly in shell history; prefer environment variablesUse an environment variable in the curl example to reduce accidental credential exposure and to align with security best practices. Also standardize placeholder casing.
- curl --location 'https://api.robusta.dev/api/namespaces/resources' \ - --header 'Authorization: Bearer API-KEY-HERE' \ + export ROBUSTA_API_KEY="YOUR_API_KEY" + curl --location 'https://api.robusta.dev/api/namespaces/resources' \ + --header "Authorization: Bearer ${ROBUSTA_API_KEY}" \ --header 'Content-Type: application/json' \ @@ - "namespace": "your-namespace", - "account_id": "your-account-id", - "cluster_name": "your-cluster-name", + "namespace": "YOUR_NAMESPACE", + "account_id": "YOUR_ACCOUNT_ID", + "cluster_name": "YOUR_CLUSTER_NAME", @@ -- ``API-KEY-HERE`` with your API Key from **Settings → API Keys → New API Key**. +- ``YOUR_API_KEY`` with your API Key from **Settings → API Keys → New API Key**. Make sure the key has **Clusters → Read** permissions to access namespace resource data. -- ``your-account-id`` with the ID found in ``generated_values.yaml`` -- ``your-cluster-name`` and ``your-namespace`` accordingly +- ``YOUR_ACCOUNT_ID`` with the ID found in ``generated_values.yaml`` +- ``YOUR_CLUSTER_NAME`` and ``YOUR_NAMESPACE`` accordinglyAlso applies to: 83-89
126-140: Error response section: add authentication/authorization statuses for clarityMany users will hit 401/403 first; listing them explicitly helps troubleshooting.
-- **Status Code**: Varies depending on the error (e.g., `400`, `403`, `500`) +- **Status Code**: Varies depending on the error (e.g., `400` Bad Request, `401` Unauthorized, `403` Forbidden, `500` Server Error)docs/configuration/alertmanager-integration/eks-managed-prometheus.rst (2)
4-8: Avoid URL shorteners in docsURL shorteners can break and are less transparent. Replace with a canonical Slack invite URL used elsewhere in the docs (or a docs-internal link).
- Please contact our team for support on Slack (https://bit.ly/robusta-slack) or by email (support@robusta.dev). + Please contact our team for support on Slack (link available on our website) or by email (support@robusta.dev).If you have a stable direct Slack invite URL used in other pages, link that instead.
4-8: Add “Last updated” date to the warningCommunicates freshness and reduces support pings if the page is current.
-.. warning:: +.. warning:: + Last updated: August 2025.docs/configuration/holmesgpt/getting-started.rst (5)
9-16: Replace raw HTML notice with a standard Sphinx admonition for theme/PDF compatibilityRaw HTML can render poorly outside HTML builds. Use an admonition.
-.. raw:: html - - <div style="margin: 20px 0; padding: 15px; background-color: #fff3e0; border-left: 4px solid #ff9800;"> - ✓ Robusta SaaS account (free or paid)<br> - ✓ Robusta UI sink enabled<br> - ✓ Robusta version 0.22.0 or higher - </div> +.. important:: + + ✓ Robusta SaaS account (free or paid) + + ✓ Robusta UI sink enabled + + ✓ Robusta version 0.22.0 or higher
36-37: Consider specifying namespace in helm commandMost users install Robusta into a dedicated namespace. Adding “-n robusta” reduces confusion.
- helm upgrade robusta robusta/robusta -f generated_values.yaml + helm upgrade robusta robusta/robusta -n robusta -f generated_values.yaml
66-85: Secrets creation examples: avoid plaintext in shell historyRecommend using environment variables (exported for the session) or reading from stdin/files to avoid leaking secrets in shell history.
OpenAI:
- kubectl create secret generic holmes-secrets \ - --from-literal=openAiKey='YOUR_API_KEY' + export OPENAI_API_KEY='YOUR_API_KEY' + kubectl create secret generic holmes-secrets \ + --from-literal=openAiKey="${OPENAI_API_KEY}"Azure:
- kubectl create secret generic holmes-secrets \ - --from-literal=azureOpenAiKey='YOUR_API_KEY' + export AZURE_OPENAI_API_KEY='YOUR_API_KEY' + kubectl create secret generic holmes-secrets \ + --from-literal=azureOpenAiKey="${AZURE_OPENAI_API_KEY}"AWS Bedrock:
- kubectl create secret generic holmes-secrets \ - --from-literal=awsAccessKeyId='YOUR_KEY_ID' \ - --from-literal=awsSecretAccessKey='YOUR_SECRET_KEY' + export AWS_ACCESS_KEY_ID='YOUR_KEY_ID' + export AWS_SECRET_ACCESS_KEY='YOUR_SECRET_KEY' + kubectl create secret generic holmes-secrets \ + --from-literal=awsAccessKeyId="${AWS_ACCESS_KEY_ID}" \ + --from-literal=awsSecretAccessKey="${AWS_SECRET_ACCESS_KEY}"Also applies to: 88-109, 114-140
110-111: Clarify “token limit 450K” wording for Azure; likely TPM (rate limit), not context window“Token limit” could be misread as context window. If you mean Tokens-Per-Minute (TPM) quota, please say so explicitly and consider adding a link to Azure quota settings. Otherwise, readers may set the wrong parameter.
-**Important**: In Azure Portal, increase your deployment's token limit to at least 450K. +**Important**: In Azure Portal, increase your deployment's Tokens-Per-Minute (TPM) quota to at least 450K.Also applies to: 165-166
49-58: Optional: Provide cleanup step for the crash podA quick cleanup command helps keep clusters tidy after testing.
- **Slack**: Click "Ask HolmesGPT" on the alert notification + +Cleanup: + +.. code-block:: bash + + kubectl delete -f https://raw.githubusercontent.com/robusta-dev/kubernetes-demos/main/crashpod/broken.yaml || truedocs/configuration/metric-providers-azure.rst (2)
92-99: Minor copy tweaks for clarityA couple of bullet points can be tightened.
- - The prometheus URL must include port ``:443`` + - The Prometheus URL must include port ``:443``. - - SSL is required and automatically enabled - - AlertManager URL is not needed (Azure handles alerting separately) + - SSL is required and automatically enabled. + - AlertManager URL is not needed (Azure handles alerting separately).
25-48: Optional: note RBAC scope on the workspaceWhen granting Monitoring Data Reader, specify the exact scope (workspace resource) to avoid users applying it at the subscription by mistake.
- 3. Grant your app access to the workspace (Monitoring Data Reader role) + 3. Grant your app access to the workspace (Monitoring Data Reader role on the workspace resource scope) @@ - 3. Grant the Managed Identity access to your workspace: + 3. Grant the Managed Identity access to your workspace (Monitoring Data Reader on the workspace resource):Also applies to: 68-82
docs/configuration/alertmanager-integration/troubleshooting-alertmanager.rst (2)
63-67: Add a concrete connectivity test command.Provide a quick example users can paste to test Alertmanager → Robusta webhook connectivity from the Alertmanager pod.
- Test connectivity to Robusta webhook endpoint + - From the Alertmanager pod: + + .. code-block:: bash + + kubectl exec -n <AM_NAMESPACE> deploy/alertmanager-<NAME> -- \ + /bin/sh -c "apk add --no-cache curl >/dev/null 2>&1 || true; \ + curl -sS -X POST -H 'Content-Type: application/json' \ + -d '{\"alerts\":[]}' https://api.robusta.dev/api/alerts | head -n1"
70-71: Path Confirmed—Consider Aligning Link Text or Adding a Section AnchorThe target file
docs/setup-robusta/additional-settings.rstexists, so the:doc:path is valid. However, there is no “Alert Label Mapping” section in that document. Its closest header is “Relabel Prometheus Alerts.”• File to check:
- docs/configuration/alertmanager-integration/troubleshooting-alertmanager.rst (lines 70–71)
- Currently links to
/setup-robusta/additional-settingsvia:doc:`Alert Label Mapping </setup-robusta/additional-settings>`• Target file:
- docs/setup-robusta/additional-settings.rst
- Contains a “Relabel Prometheus Alerts” section (around line 30), but no explicit anchor named “alert-label-mapping.”
Recommendations (optional):
- If you intend to link directly to the “Relabel Prometheus Alerts” section, add a section label in
additional-settings.rst, for example:Then update the link to.. _alert-label-mapping: Relabel Prometheus Alerts --------------------------:doc:`Alert Label Mapping </setup-robusta/additional-settings#alert-label-mapping>`- Otherwise, consider renaming the link text to “Relabel Prometheus Alerts” to match the existing header, keeping the page-level link as is.
docs/help.rst (5)
48-52: Add section labels to support intra-page references.Add explicit labels above each phase header to make the Quick Diagnosis links reliable.
+.. _phase-1-configuration-generation: Phase 1: Configuration Generation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ +.. _phase-2-helm-installation: Phase 2: Helm Installation ^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ +.. _phase-3-runtime-issues: Phase 3: Runtime Issues ^^^^^^^^^^^^^^^^^^^^^^^ @@ +.. _phase-4-integration-issues: Phase 4: Integration Issues ^^^^^^^^^^^^^^^^^^^^^^^^^^^Also applies to: 89-91, 129-131, 253-257
108-115: Minor formatting and clarity improvements.
- Trailing spaces and width attributes are fine, but add a short sentence explaining what “server-side apply” changes here.
- This is often a CRD issue which can be fixed by enabling server-side apply option as shown below. Check out `this blog <https://blog.ediri.io/kube-prometheus-stack-and-argocd-25-server-side-apply-to-the-rescue>`_ to learn more. + This is often a CRD issue that can be fixed by enabling the server-side apply option in Argo CD. See this blog post to learn more: `Kube-Prometheus-Stack and Argo CD: Server-Side Apply to the Rescue <https://blog.ediri.io/kube-prometheus-stack-and-argocd-25-server-side-apply-to-the-rescue>`_.Also applies to: 116-128, 122-128
193-219: Sanity-check small-cluster example line wrapping and consistency.
- Ensure the backslash continuation renders correctly (indent by at least two spaces after the first line).
- Requests memory for Prometheus is
512Mihere; earlier you recommend1Gi. Clarify when to use each to avoid confusion.- helm install robusta robusta/robusta -f ./generated_values.yaml --set clusterName=<YOUR_CLUSTER_NAME> --set isSmallCluster=true \ + helm install robusta robusta/robusta \ + -f ./generated_values.yaml \ + --set clusterName=<YOUR_CLUSTER_NAME> \ + --set isSmallCluster=true \Add one sentence above explaining that the
isSmallCluster=truepreset reduces default resource requests, and override examples may differ.
221-252: Holmes error section looks good; add a one-liner to validate the token format.Given the base64 error, add a quick command to validate the secret’s base64 and JSON structure.
See :ref:`Reading the Robusta UI Token from a secret in HolmesGPT` to configure Holmes to read the ``token`` + + To validate the token secret locally: + + .. code-block:: bash + + kubectl get secret -n <NS> <SECRET> -o jsonpath='{.data.token}' \ + | base64 -d 2>/dev/null | jq -e . >/dev/null && echo "OK" || echo "Invalid token"
303-305: Cross-link looks good. Consider duplicating the simulate-alert tip earlier.The simulation link is useful; consider referencing it in the Alertmanager tab in the troubleshooting page, too.
docs/configuration/exporting/custom-webhooks.rst (2)
40-55: Optional: document limits and retry semantics.Consider adding brief notes on payload size limits, rate limits, and retry/backoff expectations for non-2xx responses to set user expectations.
26-30: Minor clarity improvement on credentials.If both Account ID and API Key are required, state how they are submitted (header vs body) and whether the account ID is also derivable from the token.
-You'll need your API key and account ID: +You'll need your API key and account ID. Submit the API key as ``Authorization: Bearer <API_KEY>`` and include the ``account_id`` field in the JSON body (unless otherwise configured).docs/configuration/metric-providers.rst (3)
3-7: Rename page to “Metric Providers” for clarity.“General Settings” is vague for a hub page. Using “Metric Providers” matches navigation and user intent.
-General Settings -================ +Metric Providers +================
12-18: Qualify “Alert Silencing” capability.Silence management typically depends on Alertmanager integration. Clarify scope to avoid over-promising for non-Prometheus providers.
-- **Alert Silencing** - Create and manage silences directly from Robusta +- **Alert Silencing** - Create and manage silences directly from Robusta (when integrated with Alertmanager)
25-73: All linked provider pages verified – optional hidden toctree for better discoverabilityAll of the referenced provider documents (
metric-providers-in-cluster.rst,metric-providers-external.rst,metric-providers-azure.rst,metric-providers-aws.rst,metric-providers-google.rst,metric-providers-coralogix.rst, andmetric-providers-victoria.rst) exist in docs/configuration. Adding a hidden toctree in docs/configuration/metric-providers.rst will ensure these pages are indexed in the sidebar and search.• File to update:
docs/configuration/metric-providers.rst• Suggested diff:
:hide-toc: .. toctree:: + :hidden: + :maxdepth: 1 + + metric-providers-in-cluster + metric-providers-external + metric-providers-azure + metric-providers-aws + metric-providers-google + metric-providers-coralogix + metric-providers-victoriadocs/configuration/metric-providers-coralogix.rst (4)
12-12: Capitalize “URL”.Minor wording tweak for consistency with the rest of the docs.
-2. In your `generated_values.yaml` file add the endpoint url: +2. In your `generated_values.yaml` file add the endpoint URL:
25-29: Tighten UI capitalization and add a concrete kubectl example for the Secret.
- “Api Keys” → “API Keys”
- Provide an explicit, copy-pasteable command to reduce setup friction.
-3. On the Coralogix site, go to Data Flow -> Api Keys and copy the 'Logs Query Key' +3. On the Coralogix site, go to Data Flow -> API Keys and copy the 'Logs Query Key' @@ -4. Create a secret in your cluster with your key logs_query_key and the value as the key you just copied +4. Create a Kubernetes Secret holding the key under the `logs_query_key` entry. For example: + + .. code-block:: bash + + kubectl create secret generic MY_CORALOGIX_SECRET \ + -n robusta \ + --from-literal=logs_query_key='<PASTE_YOUR_KEY_HERE>'If you prefer, I can add variants for Helm or Kustomize.
37-39: Double-check whether PROMETHEUS_SSL_ENABLED is required (defaults may already enforce TLS).If HTTPS is used by default for the endpoint, this env var may be redundant. Keeping it is fine, but consider an inline note that it’s required only when connecting over TLS with strict verification.
51-52: Use absolute doc paths for consistency with other links.Elsewhere in this PR, absolute doc paths are used. Align this link to avoid relative-resolution surprises.
-- Learn about :doc:`common configuration options <metric-providers>` +- Learn about :doc:`common configuration options </configuration/metric-providers>`docs/configuration/alertmanager-integration/grafana-alert-manager.rst (1)
68-71: Fix small typo (“Click the”).Minor grammar polish.
-Click the ``Test`` button. If successful, you will receive a notification in the Robusta UI under the ``external`` cluster. +Click the ``Test`` button. If successful, you will receive a notification in the Robusta UI under the ``external`` cluster.docs/configuration/exporting/alert-statistics-api.rst (3)
46-48: Use clearer placeholders and show a canonical UUID format.The mixed underscores in the sample account_id can mislead. Prefer an explicit placeholder and a realistic UUID format.
- curl --location 'https://api.robusta.dev/api/query/report?account_id=XXXXXX-XXXX_XXXX_XXXXX7&start_ts=2024-10-27T04:02:05.032Z&end_ts=2024-11-27T05:02:05.032Z' \ - --header 'Authorization: Bearer API-KEY' + curl --location 'https://api.robusta.dev/api/query/report?account_id=YOUR_ACCOUNT_ID&start_ts=2024-10-27T04:02:05.032Z&end_ts=2024-11-27T05:02:05.032Z' \ + --header 'Authorization: Bearer YOUR_API_KEY'Optionally show a UUID example like 00000000-0000-0000-0000-000000000000 in a comment.
50-54: Standardize inline code formatting and naming (“API Key”).Use double backticks for inline code and consistent capitalization.
-In the command, make sure to replace the following placeholders: - -- `account_id`: Your account ID, which can be found in your `generated_values.yaml` file. -- `API-KEY`: Your API Key for authentication. Generate this token in the platform by navigating to **Settings** -> **API Keys** -> **New API Key**, and creating a key with the "Read Alerts" permission. +In the command, replace: + +- ``account_id``: Your account ID, which can be found in your ``generated_values.yaml`` file. +- ``YOUR_API_KEY``: An API key with the "Read Alerts" permission. Generate this in the UI at **Settings** → **API Keys** → **New API Key**.
72-76: Consider documenting error responses (optional).A short “Errors” section with 400/401 examples improves integrators’ DX.
I can add a minimal “Errors” block with sample payloads for 400 (invalid timestamps) and 401 (missing/invalid token) if desired.
docs/configuration/alertmanager-integration/azure-managed-prometheus.rst (2)
12-18: Tighten grammar and UI styling.
- “generated url” → “generated URL”
- Use double backticks for UI terms for consistency.
-1. Login to the Robusta UI and navigate to the ``Settings`` > ``Advanced`` tab. -2. In the Azure Webhook section click ``Generate URL`` and save the generated url. -3. Login to the Microsoft Azure Portal, go to ``Alerts`` > ``Action groups`` +1. Login to the Robusta UI and navigate to the ``Settings`` → ``Advanced`` tab. +2. In the ``Azure Webhook`` section, click ``Generate URL`` and save the generated URL. +3. Login to the Microsoft Azure Portal, go to ``Alerts`` → ``Action groups``. @@ -5. Under the `Actions` tabs (**not** the Notifications tab) add a ``Webhook`` and copy the url from step 2, into the URI input. Make sure to select ``Enable the common alert schema``. +5. Under the ``Actions`` tab (**not** the ``Notifications`` tab**)**, add a ``Webhook`` and paste the URL from step 2 into the URI input. Make sure to select ``Enable the common alert schema``.
19-23: Improve wording in the details admonition (optional).- This notification is displayed until the first alert to Robusta. + This notification is displayed until Robusta receives the first alert.docs/configuration/index.rst (3)
6-6: Remove the comma after “Robusta” (reads as a comma splice).Prefer “Connect your monitoring system to Robusta to enrich alerts and apply automation rules.”
Apply this diff:
-Connect your monitoring system to Robusta, to enrich alerts and apply automation rules. +Connect your monitoring system to Robusta to enrich alerts and apply automation rules.
25-26: Unify preposition: “via webhook” is more idiomatic than “by webhook.”Use one style consistently across cards.
Apply this diff:
- Forward Nagios alerts by webhook + Forward Nagios alerts via webhook- Forward SolarWinds alerts by webhook + Forward SolarWinds alerts via webhookAlso applies to: 32-33
13-16: Nit: Use Prometheus’ official capitalization “Alertmanager”.“AlertManager” is inconsistent with upstream docs.
Apply this diff:
- .. grid-item-card:: :octicon:`pulse;1em;` Prometheus & AlertManager + .. grid-item-card:: :octicon:`pulse;1em;` Prometheus & Alertmanagerdocs/configuration/alertmanager-integration/google-managed-prometheus.rst (1)
4-9: Avoid URL shorteners in docs + tighten warning copy.Bitly links can be blocked and aren’t transparent. Prefer a descriptive link label and direct/canonical URL, and streamline phrasing.
Apply this diff (adjust the Slack URL to your canonical one if different):
-.. warning:: - - Due to updates in the Google Managed Prometheus API, these instructions may be outdated. - Please contact our team for support on Slack (https://bit.ly/robusta-slack) or by email (support@robusta.dev). - We're working on updating the documentation. +.. warning:: + + Due to recent changes in the Google Managed Prometheus API, parts of this guide may be outdated. + Need help? Reach us on `Slack <https://bit.ly/robusta-slack>`_ or at support@robusta.dev. + We’re actively updating this page.docs/setup-robusta/installation/standalone-installation.rst (1)
10-10: Minor copy edit for flow.Replace the spaced hyphen with an em dash or commas.
Apply this diff:
-Robusta's AI Agent works with many monitoring tools beyond Prometheus - including Datadog, New Relic, PagerDuty, and more. This installation method is ideal when you already have monitoring infrastructure in place and want to enhance it with Robusta's AI-powered investigation and automation capabilities. +Robusta’s AI Agent works with many monitoring tools beyond Prometheus—including Datadog, New Relic, PagerDuty, and more. This installation method is ideal when you already have monitoring infrastructure in place and want to enhance it with Robusta’s AI‑powered investigation and automation capabilities.docs/configuration/alertmanager-integration/victoria-metrics.rst (3)
4-4: Fix preposition: send alerts “to” Robusta.Current phrasing reads awkwardly.
Apply this diff:
-This guide shows how to send alerts from `VictoriaMetrics <https://victoriametrics.com/>`_ with Robusta. +This guide shows how to send alerts from `VictoriaMetrics <https://victoriametrics.com/>`_ to Robusta.
41-43: Cross-reference phrasing consistency.Align with other pages: “see the metrics provider configuration docs.”
Apply this diff:
-To enable Robusta to query metrics from VictoriaMetrics, see metrics provider :doc:`/configuration/metric-providers-victoria` configuration docs. +To enable Robusta to query metrics from VictoriaMetrics, see the metrics provider configuration docs: :doc:`/configuration/metric-providers-victoria`.
11-11: Vendor name consistency: “VictoriaMetrics” (no space).Keep the brand name consistent throughout.
Apply this diff:
-Add the following to your Victoria Metrics Alertmanager configuration (e.g., Helm values file or VMAlertmanagerConfig CRD): +Add the following to your VictoriaMetrics Alertmanager configuration (e.g., Helm values file or VMAlertmanagerConfig CRD):docs/configuration/alertmanager-integration/coralogix_managed_prometheus.rst (3)
15-23: Tighten UI wording and casing (“URL”, “POST”).Small UX polish improves clarity.
Apply this diff:
-1. In the Coralogix site go to Data Flow, then Outbound Webhooks, and click ``Generic webhook``. -2. In the url insert: +1. In Coralogix, go to Data Flow → Outbound Webhooks, and click ``Generic webhook``. +2. In the URL, enter: @@ -3. Select the Post Method. +3. Select the POST method.
62-63: Minor wording: capitalize “Robusta” and add punctuation.Polish for consistency.
Apply this diff:
-6. Click the 'Test Config' button and check your robusta sink for a "Test configuration" alert. -7. Click Save +6. Click the “Test Config” button and check your Robusta sink for a “Test configuration” alert. +7. Click Save.
69-69: Clarify provider name (drop “Prometheus” to avoid confusion).Aligns with the linked page title.
Apply this diff:
-To enable Robusta to pull metrics from Coralogix Prometheus, see :doc:`/configuration/metric-providers-coralogix` metrics provider settings. +To enable Robusta to pull metrics from Coralogix, see :doc:`/configuration/metric-providers-coralogix` metrics provider settings.docs/configuration/metric-providers-google.rst (3)
48-52: Standardize “Alertmanager” capitalization across the page.Prometheus spells it “Alertmanager” (lowercase “m”). The current doc mixes “AlertManager” and “Alertmanager”. Aligning improves searchability and consistency with parameter names like alertmanager_url.
Apply:
-**AlertManager**: +**Alertmanager**: ... - # Check AlertManager service + # Check Alertmanager serviceAlso applies to: 60-61
4-9: Tighten the warning and convert links to proper reST links.
- Use reST link syntax instead of raw URLs in parentheses.
- Add a “last reviewed” date so readers know how current the note is.
-.. warning:: - - Due to updates in the Google Managed Prometheus API, these instructions may be outdated. - Please contact our team for support on Slack (https://bit.ly/robusta-slack) or by email (support@robusta.dev). - We're working on updating the documentation. +.. warning:: + + As of August 21, 2025, Google Managed Prometheus APIs may have changed and parts of this guide could be outdated. + Please contact our team on `Slack <https://bit.ly/robusta-slack>`_ or by email at ``support@robusta.dev``. + We’re updating this documentation.
83-85: Optional: Make the curl test more robust in clusters with restricted defaults.Explicitly set a namespace for the ephemeral pod to avoid surprises with non-default namespaces.
- kubectl run test-curl --image=curlimages/curl --rm -it -- \ + kubectl run test-curl -n default --image=curlimages/curl --rm -it -- \ curl -v http://frontend.default.svc.cluster.local:9090/-/healthydocs/configuration/exporting/robusta-pro-features.rst (3)
1-2: Rename header and fix wording (“on-premises”).“Overview” is vague given the filename. Also fix common wording nit.
-Overview -======== +Robusta Pro Overview +==================== @@ -Robusta Pro adds a web UI, additional integrations, and enterprise APIs to the open-source engine. Available as SaaS (we handle hosting) or self-hosted on-premise. +Robusta Pro adds a web UI, additional integrations, and enterprise APIs to the open-source engine. Available as SaaS (we handle hosting) or self-hosted on‑premises.Also applies to: 7-7
34-38: Remove duplication and align “Exporting Data” links with the split API pages.The paragraph linking “Alert History Import and Export API ” overlaps with the four new API links. Convert the paragraph to an overview and keep the split links. Also update the final “Getting Started” pointer to the exporting index (if that page is now the section index).
-Export alert history and generate reports using Robusta's REST APIs. - -:doc:`Alert History Import and Export API <exporting-data>` - Comprehensive API for exporting alert history, generating reports, and sending custom alerts programmatically. +Export alert history and generate reports using Robusta’s REST APIs. See the endpoints below: @@ -For detailed API documentation and examples, see :doc:`Alert History Import and Export API <exporting-data>`. +For an overview and navigation, see :doc:`Exporting Data <exporting-data>`.Also applies to: 41-44, 67-67
63-66: Minor: clarify wording for API keys path.Small copy tweak.
-3. **API Access**: Generate API keys in the Robusta platform under **Settings** → **API Keys** +3. **API Access**: Generate API keys in the Robusta platform under **Settings** → **API Keys**.docs/configuration/exporting/configuration-changes-api.rst (2)
78-81: Clarify the “labels” description (not alert labels).These labels annotate the configuration change, not alerts.
- * - ``labels`` - - dict - - Extra labels for the alert (optional). - - No + * - ``labels`` + - dict + - Extra labels for the configuration change (optional). + - No
101-109: Consider documenting idempotency/dedup and error semantics.
- You already expose an optional fingerprint field; recommend it for idempotency and deduplication.
- Clarify whether partial failures are possible (e.g., per-change validation) and if a multi-status (207) or per-item error list is returned.
I can draft a short “Best Practices” subsection and expand the Response section with a partial-failure example if helpful.
Also applies to: 165-176, 178-190
docs/configuration/metric-providers-victoria.rst (3)
9-9: Brand consistency: use “VictoriaMetrics” (no space).Also tighten the sentence.
-Robusta can query metrics and create silences using Victoria Metrics. If both are in the same Kubernetes cluster, Robusta can auto-detect the Victoria Metrics service. To verify, go to the "Apps" tab in Robusta, select an application, and check for usage graphs. +Robusta can query metrics and create silences using VictoriaMetrics. If Robusta and VictoriaMetrics run in the same cluster, Robusta can auto‑detect the VictoriaMetrics service. To verify, go to the “Apps” tab in Robusta, select an application, and check for usage graphs.
17-19: Unify placeholders and avoid trailing slash in example URL.Keep placeholders consistent and remove the trailing slash to match other examples.
- alertmanager_url: "http://<VM_ALERT_MANAGER_SERVICE_NAME>.<NAMESPACE>.svc.cluster.local:9093" # Example:"http://vmalertmanager-victoria-metrics-vm.default.svc.cluster.local:9093/" - prometheus_url: "http://VM_Metrics_SERVICE_NAME.NAMESPACE.svc.cluster.local:8429" # Example:"http://vmsingle-vmks-victoria-metrics-k8s-stack.default.svc.cluster.local:8429" + alertmanager_url: "http://<VM_ALERTMANAGER_SERVICE_NAME>.<NAMESPACE>.svc.cluster.local:9093" # Example: "http://vmalertmanager-victoria-metrics-vm.default.svc.cluster.local:9093" + prometheus_url: "http://<VM_METRICS_SERVICE_NAME>.<NAMESPACE>.svc.cluster.local:8429" # Example: "http://vmsingle-vmks-victoria-metrics-k8s-stack.default.svc.cluster.local:8429"
42-52: Clarify the default and recommended value for check_prometheus_flags.Make it explicit and provider-specific to reduce ambiguity.
-You can disable the Prometheus flags API check by setting the following option to false. +By default, Robusta enables a Prometheus flags API check. VictoriaMetrics supports Prometheus‑compatible APIs; leave this enabled unless you encounter a compatibility issue. To disable: @@ - check_prometheus_flags: true/false + check_prometheus_flags: falsedocs/configuration/metric-providers-external.rst (1)
58-67: Add a short security note on Basic Auth.Base64 is not encryption; nudge users toward stronger auth when possible.
**Basic Authentication**: @@ alertmanager_auth: "Basic dXNlcm5hbWU6cGFzc3dvcmQ=" + +.. note:: + Basic Authentication uses Base64 encoding, which is not encryption. Prefer Bearer tokens or mTLS where available, and always use HTTPS.docs/configuration/exporting/exporting-data.rst (4)
5-5: Clarify plan gating and link to plan detailsConsider linking to a “Plans/Pricing” or “Self-hosted licensing” page so readers know where to enable these features. If the project has a canonical doc for enabling Pro features, cross-reference it here.
7-8: Slight scope clarificationOptional: call these “REST APIs” if accurate. If there are multiple base URLs (SaaS vs. self-hosted), tee that up here or in “Getting Started” so users know where to point their requests.
9-16: Add a toctree caption and keep endpoint list future-proofAdding a caption improves navigation. Also, if you foresee more endpoints, consider grouping by domain (Alerts, Configuration, Statistics) later.
Apply this diff to add a caption:
.. toctree:: :maxdepth: 1 + :caption: API endpoints
18-26: Consider expanding “Getting Started” with base URL and authentication hintsA quick scan of all exporting endpoint pages shows consistent use of the
Authorization: Bearerheader and concrete cURL examples (e.g., send-alerts-api.rst, namespace-resources-api.rst, custom-webhooks.rst, configuration-changes-api.rst, alert-statistics-api.rst, alert-export-api.rst). Adding a brief overview here will help readers know where to send requests and how to authenticate, without duplicating per-endpoint details.• File:
docs/configuration/exporting/exporting-data.rst(lines 18–26)
• Suggestion: insert a “Base URL and authentication” subsection directly beneath the existing blockProposed diff:
Getting Started --------------- All APIs require authentication using an API key. Generate API keys in the Robusta UI: **Settings** → **API Keys** → **New API Key** Assign appropriate permissions to your API key based on the APIs you plan to use. + +Base URL and authentication +--------------------------- + +- SaaS vs. self-hosted base URL: see each endpoint page for the correct base URL and any deployment-specific notes. +- Authentication header: each endpoint page shows a concrete cURL example using the header `Authorization: Bearer YOUR_API_KEY`. +- Minimum permissions: each endpoint page lists the required permission(s)/scope(s).This is an optional, light-touch refactor to improve consistency and discoverability across the exporting docs.
2 participants
No description provided.