DT-594: WEC documentation and device updates#405
Conversation
📝 WalkthroughWalkthroughRestructures documentation: removes many Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Deploying virtualmetric-docs-test with
|
| Latest commit: |
665efa5
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://aedfa90b.virtualmetric-docs-test.pages.dev |
| Branch Preview URL: | https://dev-wec.virtualmetric-docs-test.pages.dev |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (6)
docs/configuration/devices/management.mdx (1)
40-40: Consider normalizing the empty-state phrasing.To match nearby messaging style (e.g., “No devices found”), consider “No directors found” instead of “Directors not found.”
As per coding guidelines, "**/*.mdx: Ensure consistency in terminology and formatting across all documentation files."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/management.mdx` at line 40, Replace the empty-state message string "Directors not found" with "No directors found" to match nearby wording conventions; update any adjacent explanatory sentence to use the same lowercase "directors" term and ensure the <gui>Create director</gui> button label remains unchanged unless other docs use "Create Director" — keep terminology consistent with "No devices found" style.docs/configuration/devices/aws/amazon-security-lake.mdx (1)
3-4: Add explicit spacing between the two badges.Line 3 renders both badges back-to-back; adding an explicit separator keeps badge formatting consistent across device pages.
♻️ Proposed formatting fix
-<span className="theme-doc-version-badge badge badge--secondary">Amazon AWS</span><span className="theme-doc-version-badge badge badge--secondary">Security Lake</span> +<span className="theme-doc-version-badge badge badge--secondary">Amazon AWS</span>{" "} +<span className="theme-doc-version-badge badge badge--secondary">Security Lake</span>As per coding guidelines, "Ensure consistency in terminology and formatting across all documentation files."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/aws/amazon-security-lake.mdx` around lines 3 - 4, The two badge spans (elements with className="theme-doc-version-badge badge badge--secondary") are rendered back-to-back; add explicit spacing between them by inserting a small separator (e.g., a single space or non-breaking space) or wrapping them in a container that applies margin (CSS class or inline style) so the badges don’t touch and match formatting used elsewhere on device pages.docs/configuration/routes/overview.mdx (1)
5-5: Consider a more contextual H1 for standalone clarity.Line 5 (
# Overview) may be ambiguous in search/export contexts where section hierarchy is not visible. A scoped title like# Routes Overviewwould improve clarity with minimal change.As per coding guidelines, "Ensure consistency in terminology and formatting across all documentation files."♻️ Suggested tweak
-# Overview +# Routes Overview🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/routes/overview.mdx` at line 5, Change the ambiguous H1 "# Overview" to a scoped, clearer title such as "# Routes Overview" so the document is self-contained in search/exports and consistent with other docs; locate the header line containing the literal "# Overview" in this file and replace it with the new scoped header (e.g., "Routes Overview") while preserving surrounding formatting and capitalization conventions used in other documentation files.docs/configuration/devices/aws/amazon-s3.mdx (1)
3-3: Standardize badge wording to “Long-Term Storage.”Small terminology polish for consistency and readability in badge text.
✏️ Suggested tweak
-<span className="theme-doc-version-badge badge badge--secondary">Amazon AWS</span><span className="theme-doc-version-badge badge badge--secondary">Long Term Storage</span> +<span className="theme-doc-version-badge badge badge--secondary">Amazon AWS</span>{" "} +<span className="theme-doc-version-badge badge badge--secondary">Long-Term Storage</span>As per coding guidelines,
**/*.mdx: Ensure consistency in terminology and formatting across all documentation files.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/aws/amazon-s3.mdx` at line 3, Update the badge text "Long Term Storage" to the standardized hyphenated form "Long-Term Storage" in the span element that currently reads <span className="theme-doc-version-badge badge badge--secondary">Long Term Storage</span>; ensure the exact phrasing "Long-Term Storage" is used (with the hyphen) for consistency across MDX docs and leave the "Amazon AWS" badge unchanged.docs/configuration/devices/azure/azure-blob-storage.mdx (1)
3-4: Use “Long-Term Storage” for badge consistency.Minor wording cleanup to keep terminology formatting consistent across device pages.
✏️ Suggested tweak
-<span className="theme-doc-version-badge badge badge--secondary">Microsoft Azure</span><span className="theme-doc-version-badge badge badge--secondary">Long Term Storage</span> +<span className="theme-doc-version-badge badge badge--secondary">Microsoft Azure</span>{" "} +<span className="theme-doc-version-badge badge badge--secondary">Long-Term Storage</span>As per coding guidelines,
**/*.mdx: Ensure consistency in terminology and formatting across all documentation files.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/azure/azure-blob-storage.mdx` around lines 3 - 4, Update the second version badge text to use the consistent hyphenated term "Long-Term Storage" (match casing and punctuation), i.e., edit the span element with className="theme-doc-version-badge badge badge--secondary" that currently reads "Long Term Storage" so it becomes "Long-Term Storage" to ensure terminology consistency across MDX docs.docs/configuration/devices/other/wec.mdx (1)
83-86: Add a routing caveat for defaulthostname.Line 85 defaults
hostnameto the listen address. With defaultaddress: "0.0.0.0", that is typically not client-resolvable. A brief note to set an explicit FQDN would prevent deployment confusion.Suggested doc tweak
|`hostname`|N|listen address|FQDN advertised to clients in subscription endpoint URIs| + +:::note +If `address` is `0.0.0.0`, set `hostname` explicitly to a client-resolvable FQDN. +:::As per coding guidelines, "Ensure consistency in terminology and formatting across all documentation files."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/other/wec.mdx` around lines 83 - 86, The documentation currently notes that `hostname` defaults to the listen address, which with `address: "0.0.0.0"` is not client-resolvable; update the `hostname` row to include a brief caveat instructing users to set an explicit FQDN for client-facing subscription endpoints (e.g., “defaults to listen address — if listen address is 0.0.0.0, set an explicit FQDN for `hostname` so clients can resolve subscription endpoints”), keeping terminology consistent with `address` and `port`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/configuration/devices/azure/azure-monitor.mdx`:
- Around line 11-24: Update the Azure Monitor device docs to explicitly list the
required collection definition keys so users can produce valid YAML: in the
example block and the surrounding text mention that each collection must include
id, name, type (must be "azmon"), properties with tenant_id, client_id,
client_secret, and event_frequency, plus any optional fields like description,
tags, pipelines and status; ensure the YAML example and the prose state which
fields are required vs optional (reference the example fields id, name,
description, type: azmon, tags, pipelines, status, properties, tenant_id,
client_id, client_secret, event_frequency) and replicate the same clarification
at the other affected sections (lines referenced in the comment).
- Around line 66-68: The relative links in this file point to './azure/alerts',
'./azure/logs', and './azure/metrics' which add an extra "azure" path segment;
update the three link targets for "Alerts", "Logs", and "Metrics" to remove the
redundant "azure/" prefix (use './alerts', './logs', './metrics') so the links
resolve correctly from this document's directory and match the other docs.
In `@docs/configuration/devices/management.mdx`:
- Around line 207-209: The documentation uses inconsistent casing for the
eStreamer product; within the "Protocol Devices" section update the differing
spelling to match the project's canonical term (e.g., change "Estreamer" or any
other variant to "eStreamer") so terminology is consistent across the file; edit
the text that currently lists "(Syslog, HTTP, UDP, TCP, eStreamer)" to use the
canonical "eStreamer" form everywhere in that section and run a quick search in
this document to correct any other mismatched occurrences.
In `@docs/configuration/devices/other/wec.mdx`:
- Around line 92-100: Update the TLS option descriptions to use consistent "file
name (relative to service root)" wording: change `tls.cert_name` and
`tls.key_name` from "TLS certificate file path" / "TLS private key file path" to
"TLS certificate file name (relative to service root)" and "TLS private key file
name (relative to service root)"; also change `tls.client_ca_cert_file` from
"Path to PEM-encoded CA certificate" to "CA certificate file name (relative to
service root)" (or note it may accept a path if the implementation differs), and
update the note about placement to explicitly state that certificate and key
values are file names located in the service root and not full paths so
terminology is consistent across `tls.cert_name`, `tls.key_name`, and
`tls.client_ca_cert_file`.
---
Nitpick comments:
In `@docs/configuration/devices/aws/amazon-s3.mdx`:
- Line 3: Update the badge text "Long Term Storage" to the standardized
hyphenated form "Long-Term Storage" in the span element that currently reads
<span className="theme-doc-version-badge badge badge--secondary">Long Term
Storage</span>; ensure the exact phrasing "Long-Term Storage" is used (with the
hyphen) for consistency across MDX docs and leave the "Amazon AWS" badge
unchanged.
In `@docs/configuration/devices/aws/amazon-security-lake.mdx`:
- Around line 3-4: The two badge spans (elements with
className="theme-doc-version-badge badge badge--secondary") are rendered
back-to-back; add explicit spacing between them by inserting a small separator
(e.g., a single space or non-breaking space) or wrapping them in a container
that applies margin (CSS class or inline style) so the badges don’t touch and
match formatting used elsewhere on device pages.
In `@docs/configuration/devices/azure/azure-blob-storage.mdx`:
- Around line 3-4: Update the second version badge text to use the consistent
hyphenated term "Long-Term Storage" (match casing and punctuation), i.e., edit
the span element with className="theme-doc-version-badge badge badge--secondary"
that currently reads "Long Term Storage" so it becomes "Long-Term Storage" to
ensure terminology consistency across MDX docs.
In `@docs/configuration/devices/management.mdx`:
- Line 40: Replace the empty-state message string "Directors not found" with "No
directors found" to match nearby wording conventions; update any adjacent
explanatory sentence to use the same lowercase "directors" term and ensure the
<gui>Create director</gui> button label remains unchanged unless other docs use
"Create Director" — keep terminology consistent with "No devices found" style.
In `@docs/configuration/devices/other/wec.mdx`:
- Around line 83-86: The documentation currently notes that `hostname` defaults
to the listen address, which with `address: "0.0.0.0"` is not client-resolvable;
update the `hostname` row to include a brief caveat instructing users to set an
explicit FQDN for client-facing subscription endpoints (e.g., “defaults to
listen address — if listen address is 0.0.0.0, set an explicit FQDN for
`hostname` so clients can resolve subscription endpoints”), keeping terminology
consistent with `address` and `port`.
In `@docs/configuration/routes/overview.mdx`:
- Line 5: Change the ambiguous H1 "# Overview" to a scoped, clearer title such
as "# Routes Overview" so the document is self-contained in search/exports and
consistent with other docs; locate the header line containing the literal "#
Overview" in this file and replace it with the new scoped header (e.g., "Routes
Overview") while preserving surrounding formatting and capitalization
conventions used in other documentation files.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (71)
docs/about/applications.mdxdocs/about/architecture.mdxdocs/about/key-features.mdxdocs/about/licensing.mdxdocs/about/siem-optimization.mdxdocs/appendix/cli/agent.mdxdocs/appendix/cli/director.mdxdocs/configuration/devices/aws/amazon-s3.mdxdocs/configuration/devices/aws/amazon-security-lake.mdxdocs/configuration/devices/azure-alerts.mdxdocs/configuration/devices/azure-logs.mdxdocs/configuration/devices/azure-metrics.mdxdocs/configuration/devices/azure/azure-blob-storage.mdxdocs/configuration/devices/azure/azure-monitor.mdxdocs/configuration/devices/azure/event-hubs.mdxdocs/configuration/devices/azure/microsoft-graph-api.mdxdocs/configuration/devices/azure/microsoft-sentinel.mdxdocs/configuration/devices/datasets-and-profiles.mdxdocs/configuration/devices/management.mdxdocs/configuration/devices/mq/kafka.mdxdocs/configuration/devices/mq/nats.mdxdocs/configuration/devices/mq/rabbitmq.mdxdocs/configuration/devices/mq/redis.mdxdocs/configuration/devices/os/agents.mdxdocs/configuration/devices/os/linux.mdxdocs/configuration/devices/os/windows.mdxdocs/configuration/devices/other/proofpoint-on-demand.mdxdocs/configuration/devices/other/wec.mdxdocs/configuration/devices/overview.mdxdocs/configuration/devices/protocols/estreamer.mdxdocs/configuration/devices/protocols/http.mdxdocs/configuration/devices/protocols/ipfix.mdxdocs/configuration/devices/protocols/netflow.mdxdocs/configuration/devices/protocols/sflow.mdxdocs/configuration/devices/protocols/smtp.mdxdocs/configuration/devices/protocols/snmp-trap.mdxdocs/configuration/devices/protocols/syslog.mdxdocs/configuration/devices/protocols/tcp.mdxdocs/configuration/devices/protocols/tftp.mdxdocs/configuration/devices/protocols/udp.mdxdocs/configuration/directors/clusters.mdxdocs/configuration/directors/deployment.mdxdocs/configuration/directors/management.mdxdocs/configuration/directors/overview.mdxdocs/configuration/directors/troubleshooting.mdxdocs/configuration/directors/updates.mdxdocs/configuration/pipelines/debugging.mdxdocs/configuration/pipelines/overview.mdxdocs/configuration/pipelines/processors/join-kv.mdxdocs/configuration/pipelines/processors/overview.mdxdocs/configuration/quick-start.mdxdocs/configuration/routes/content-routing.mdxdocs/configuration/routes/management.mdxdocs/configuration/routes/overview.mdxdocs/configuration/scheduling/overview.mdxdocs/configuration/targets/management.mdxdocs/configuration/targets/overview.mdxdocs/content-hub/integration.mdxdocs/content-hub/overview.mdxdocs/getting-started/add-your-first-device.mdxdocs/getting-started/next-steps.mdxdocs/organization/audit.mdxdocs/organization/overview.mdxdocs/siem/microsoft-sentinel/automation/arm-templates.mdxdocs/siem/microsoft-sentinel/automation/bicep-templates.mdxdocs/siem/microsoft-sentinel/integration.mdxdocs/siem/microsoft-sentinel/overview.mdxdocs/siem/overview.mdxsidebars.tssrc/includes/port-open-for-inbound-traffic.mdxtopics.json
💤 Files with no reviewable changes (27)
- docs/configuration/devices/protocols/tcp.mdx
- docs/about/siem-optimization.mdx
- docs/configuration/devices/azure-logs.mdx
- docs/configuration/devices/azure-metrics.mdx
- docs/configuration/devices/protocols/netflow.mdx
- docs/getting-started/next-steps.mdx
- docs/configuration/devices/protocols/smtp.mdx
- docs/about/licensing.mdx
- docs/configuration/devices/protocols/syslog.mdx
- docs/about/key-features.mdx
- docs/configuration/devices/protocols/snmp-trap.mdx
- docs/configuration/devices/mq/nats.mdx
- docs/organization/audit.mdx
- docs/configuration/devices/protocols/estreamer.mdx
- docs/configuration/devices/mq/rabbitmq.mdx
- docs/configuration/devices/protocols/udp.mdx
- docs/configuration/devices/other/proofpoint-on-demand.mdx
- docs/configuration/devices/protocols/tftp.mdx
- docs/about/architecture.mdx
- docs/configuration/devices/protocols/ipfix.mdx
- docs/configuration/devices/protocols/http.mdx
- docs/configuration/devices/protocols/sflow.mdx
- docs/configuration/devices/mq/kafka.mdx
- docs/configuration/devices/azure-alerts.mdx
- docs/configuration/pipelines/processors/join-kv.mdx
- docs/configuration/devices/mq/redis.mdx
- docs/about/applications.mdx
- Fix eStreamer casing in management.mdx (Estreamer -> eStreamer) - Fix azure-monitor.mdx relative link paths (./azure/alerts -> ./alerts) - Hyphenate Long-Term Storage badge text in amazon-s3 and azure-blob-storage - Add hostname caveat note to WEC connection table Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
📄 Docs Preview: https://dev-wec.virtualmetric-docs.pages.dev |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (2)
docs/configuration/devices/other/wec.mdx (1)
96-105:⚠️ Potential issue | 🟡 MinorStandardize TLS file references as service-root file names.
tls.cert_nameandtls.key_nameare still described as “file path,” but the note and examples use service-root file names.tls.client_ca_cert_filealso uses path wording; this should be made consistent.Suggested doc fix
-|`tls.cert_name`|N*||TLS certificate file path (required if TLS enabled)| -|`tls.key_name`|N*||TLS private key file path (required if TLS enabled)| +|`tls.cert_name`|N*||TLS certificate file name (relative to service root) (required if TLS enabled)| +|`tls.key_name`|N*||TLS private key file name (relative to service root) (required if TLS enabled)| |`tls.client_auth`|N|`0`|TLS client authentication mode (maps to `tls.ClientAuthType`)| -|`tls.client_ca_cert_file`|N||Path to PEM-encoded CA certificate used to verify client certificates| +|`tls.client_ca_cert_file`|N||CA certificate file name (relative to service root) used to verify client certificates| @@ -TLS certificate and key files must be placed in the service root directory. Port `5986` is the standard WEF/HTTPS port. Plain HTTP on port `5985` is not recommended for production. +TLS certificate, key, and client CA certificate values are file names located in the service root directory (not full paths). Port `5986` is the standard WEF/HTTPS port. Plain HTTP on port `5985` is not recommended for production.As per coding guidelines, "Ensure consistency in terminology and formatting across all documentation files."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/other/wec.mdx` around lines 96 - 105, Update documentation to consistently describe TLS file settings as service-root file names rather than generic "file path": change `tls.cert_name` and `tls.key_name` descriptions from "TLS certificate file path" / "TLS private key file path" to "TLS certificate file name in service root" / "TLS private key file name in service root", and change `tls.client_ca_cert_file` to "CA certificate file name in service root (PEM‑encoded)" or "path relative to service root" if full paths are supported; ensure the conditional note referencing `tls.status` and the example that mentions file names/ports matches this terminology and that `tls.client_auth` description remains unchanged.docs/configuration/devices/azure/azure-monitor.mdx (1)
11-24:⚠️ Potential issue | 🟠 MajorDocument the required collection definition keys and where they live.
Line 74 says at least one definition is required, but the schema and examples (Lines 11-24, 76-85) do not show the required definition fields (for alerts/logs/metrics), so users cannot build a valid minimal config confidently.
Suggested doc patch
properties: tenant_id: <string> client_id: <string> client_secret: <string> event_frequency: <numeric> + alerts: <alerts_definition[]> + logs: <logs_definition[]> + metrics: <metrics_definition[]>properties: tenant_id: "00000000-0000-0000-0000-000000000000" client_id: "11111111-1111-1111-1111-111111111111" client_secret: "your-client-secret" + alerts: + - name: "default-alerts" + # ... required alert definition fieldsAlso applies to: 74-85
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/azure/azure-monitor.mdx` around lines 11 - 24, The docs are missing the required "definitions" collection schema and examples, so add a clear minimal YAML example showing where definitions live (under properties.definitions) and the required keys for each definition type (e.g., id, name, type/kind (alert|log|metric), and the type-specific fields like query/resource/metric_name and collection_interval or event_frequency), and update the prose around the "at least one definition is required" note to reference these fields and point to the example; ensure the sample uses the existing top-level keys shown (id, name, type: azmon, properties: tenant_id/client_id/client_secret/event_frequency) and then includes a minimal definitions array with one example for alert, log, and metric so users can build a valid minimal config.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/configuration/devices/management.mdx`:
- Line 73: The "Applies to" lists mix internal identifiers with friendly names;
replace AzureBlobStorage and AzureEventHubs with reader-facing labels "Azure
Blob Storage" and "Azure Event Hubs" (and ensure the same replacements are made
where they appear on the other occurrence) so the Applies to entries read
consistently alongside Syslog, HTTP, UDP, TCP, eStreamer.
- Around line 430-432: The heading "Azure Cloud Devices" and the subsequent body
text use different capitalization; update the body text to match the heading's
Title Case (or change the heading to match the body if you prefer sentence case)
so both occurrences use identical capitalization—locate the heading "Azure Cloud
Devices" and the corresponding body sentence on the same section and make their
casing consistent (prefer Title Case: "Azure Cloud Devices") to satisfy the MDX
consistency rule.
- Around line 232-234: The sentence under the "### Windows and Linux Devices"
heading that states Windows and Linux have "different tab structures" conflicts
with later text saying Linux follows the same structure as Windows; update that
sentence to accurately reflect that Linux generally follows the same tab
structure as Windows except for deployment-specific differences (or state that
Windows and Linux share the same tab structure with a note about
deployment-specific variations) so terminology is consistent with the later
description.
In `@docs/configuration/devices/other/wec.mdx`:
- Around line 196-203: Pick one canonical behavior and make both paragraphs
consistent: either (A) bookmarks persist across subscription version bumps and
allow resume (update the sentence that currently states "the server
automatically bumps its version identifier and invalidates all stored
bookmarks..." to state bookmarks persist and describe how clients use the
bookmark and read_existing_events to resume), or (B) bookmarks are invalidated
on version change (update the earlier sentence that claims bookmarks allow
resume after a subscription version change to state they are invalidated and
clients must re-subscribe and replay according to read_existing_events). Ensure
the terms "bookmark", "version identifier", "read_existing_events",
"Enumerate/Subscribe/Events/Heartbeat" are used consistently and adjust the
surrounding sentences so both paragraphs describe the same chosen behavior.
---
Duplicate comments:
In `@docs/configuration/devices/azure/azure-monitor.mdx`:
- Around line 11-24: The docs are missing the required "definitions" collection
schema and examples, so add a clear minimal YAML example showing where
definitions live (under properties.definitions) and the required keys for each
definition type (e.g., id, name, type/kind (alert|log|metric), and the
type-specific fields like query/resource/metric_name and collection_interval or
event_frequency), and update the prose around the "at least one definition is
required" note to reference these fields and point to the example; ensure the
sample uses the existing top-level keys shown (id, name, type: azmon,
properties: tenant_id/client_id/client_secret/event_frequency) and then includes
a minimal definitions array with one example for alert, log, and metric so users
can build a valid minimal config.
In `@docs/configuration/devices/other/wec.mdx`:
- Around line 96-105: Update documentation to consistently describe TLS file
settings as service-root file names rather than generic "file path": change
`tls.cert_name` and `tls.key_name` descriptions from "TLS certificate file path"
/ "TLS private key file path" to "TLS certificate file name in service root" /
"TLS private key file name in service root", and change
`tls.client_ca_cert_file` to "CA certificate file name in service root
(PEM‑encoded)" or "path relative to service root" if full paths are supported;
ensure the conditional note referencing `tls.status` and the example that
mentions file names/ports matches this terminology and that `tls.client_auth`
description remains unchanged.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
docs/configuration/devices/aws/amazon-s3.mdxdocs/configuration/devices/azure/azure-blob-storage.mdxdocs/configuration/devices/azure/azure-monitor.mdxdocs/configuration/devices/management.mdxdocs/configuration/devices/other/wec.mdx
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/configuration/devices/aws/amazon-s3.mdx
There was a problem hiding this comment.
🧹 Nitpick comments (2)
docs/configuration/devices/other/wec.mdx (2)
85-85: Minor formatting inconsistency in default value.Other fields use backticks for defaults (e.g.,
"0.0.0.0"), buthostnameuses plain text. Consider wrapping in backticks for consistency.Suggested fix
-|`hostname`|N|listen address|FQDN advertised to clients in subscription endpoint URIs| +|`hostname`|N|`<listen address>`|FQDN advertised to clients in subscription endpoint URIs|As per coding guidelines, "Ensure consistency in terminology and formatting across all documentation files."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/other/wec.mdx` at line 85, The table entry for the hostname default is inconsistent: the `hostname` default value is plain text while other defaults use backticks; update the table cell for `hostname` so its default is wrapped in backticks (i.e., use `hostname` and surround the default value with backticks) to match the formatting used elsewhere in this file and keep terminology/formatting consistent.
98-98: Document validtls.client_authvalues.The description references
tls.ClientAuthTypebut doesn't explain what numeric values are valid. Users need to know their options (e.g., 0=NoClientCert, 1=RequestClientCert, 2=RequireAnyClientCert, etc.).Suggested enhancement
-|`tls.client_auth`|N|`0`|TLS client authentication mode (maps to `tls.ClientAuthType`)| +|`tls.client_auth`|N|`0`|TLS client authentication mode: `0` (no client cert), `1` (request), `2` (require any), `3` (verify if given), `4` (require and verify)|🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/configuration/devices/other/wec.mdx` at line 98, Add a short table or inline list documenting the valid numeric values for tls.client_auth and their corresponding tls.ClientAuthType names (e.g., 0=NoClientCert, 1=RequestClientCert, 2=RequireAnyClientCert, 3=VerifyClientCertIfGiven, 4=RequireAndVerifyClientCert) so readers can map the numeric configuration to the tls.ClientAuthType enum; update the docs entry that currently reads "TLS client authentication mode (maps to `tls.ClientAuthType`)" to include this numeric mapping and a brief note about default/typical usage if applicable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/configuration/devices/other/wec.mdx`:
- Line 85: The table entry for the hostname default is inconsistent: the
`hostname` default value is plain text while other defaults use backticks;
update the table cell for `hostname` so its default is wrapped in backticks
(i.e., use `hostname` and surround the default value with backticks) to match
the formatting used elsewhere in this file and keep terminology/formatting
consistent.
- Line 98: Add a short table or inline list documenting the valid numeric values
for tls.client_auth and their corresponding tls.ClientAuthType names (e.g.,
0=NoClientCert, 1=RequestClientCert, 2=RequireAnyClientCert,
3=VerifyClientCertIfGiven, 4=RequireAndVerifyClientCert) so readers can map the
numeric configuration to the tls.ClientAuthType enum; update the docs entry that
currently reads "TLS client authentication mode (maps to `tls.ClientAuthType`)"
to include this numeric mapping and a brief note about default/typical usage if
applicable.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
docs/configuration/devices/aws/amazon-s3.mdxdocs/configuration/devices/azure/azure-blob-storage.mdxdocs/configuration/devices/azure/azure-monitor.mdxdocs/configuration/devices/management.mdxdocs/configuration/devices/other/wec.mdx
🚧 Files skipped from review as they are similar to previous changes (3)
- docs/configuration/devices/azure/azure-monitor.mdx
- docs/configuration/devices/azure/azure-blob-storage.mdx
- docs/configuration/devices/management.mdx
This pull request primarily updates documentation for the DataStream project, focusing on improving clarity, organization, and consistency across device configuration and product overview files. The most significant changes involve the removal of sidebar labels, the addition of descriptive badges to device documentation, and the reorganization of AWS and Azure device docs into more logical directories. Several Azure device documentation files were also removed, likely as part of a broader restructuring.
Documentation structure and metadata:
sidebar_labelmetadata from all major overview and feature documentation files (applications.mdx,architecture.mdx,key-features.mdx,siem-optimization.mdx, and others) to streamline navigation and metadata usage. [1] [2] [3] [4] [5]agent.mdxanddirector.mdxto simplify section titles. [1] [2]Device documentation improvements:
Amazon AWS,Long Term Storage,Security Lake) to AWS and Azure device documentation files for improved clarity and visual consistency. [1] [2] [3]awssubdirectory for better organization. [1] [2]azuresubdirectory.Azure device documentation removal:
azure-alerts.mdx,azure-logs.mdx,azure-metrics.mdx), possibly to consolidate or restructure Azure device documentation. [1] [2] [3]Summary by CodeRabbit
https://vmetric.atlassian.net/browse/DT-591
https://vmetric.atlassian.net/browse/DT-594