DOC-6304 DOC-6305 DOC-6306 DOC-6308 Client observability docs#2854
DOC-6304 DOC-6305 DOC-6306 DOC-6308 Client observability docs#2854andy-stark-redis wants to merge 22 commits intomainfrom
Conversation
🛡️ Jit Security Scan Results✅ No security findings were detected in this PR
Security scan by Jit
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
| you are interested in, although all metrics in the group will be collected even | ||
| if you don't use them. The metrics in each group are described in the |
There was a problem hiding this comment.
although all metrics in the group will be collected even if you don't use them
This is not accurate. We have two metric groups that are enabled by default, (resiliency and connection-basic) and the metrics in those groups are only collected when OTel is enabled.
| visualize the metrics collected by OTel. This provides a target endpoint | ||
| that you specify when you configure the client in your application. The tool then |
There was a problem hiding this comment.
This provides a target endpoint that you specify when you configure the client in your application
We actually push metrics to an otel collector. The otel collector provides an endpoint for Prometheus (or other storage layers) to scrape, and Grafana (or other monitoring tools) can then get the metrics from Prometheus. But it's not accurate to say that we Grafana provides an endpoint we use in the client init.
There was a problem hiding this comment.
We did a few small changes in the spec in the past 2 weeks. Pls verify if everything is up to date 🙏
| error rate (suggesting a deeper problem that could be fixed to improve reliability). | ||
| --> | ||
|
|
||
| ## Metrics overview |
There was a problem hiding this comment.
We should mention that the clients follow the push model, where we push metrics to an OTel collector using OTLP (with both gRPC and HTTP).
The flow is:
+------------------+
| App |
| (Redis SDK + |
| OTel SDK) |
+------------------+
|
v
+------------------+
| OTel Collector |
| (otlp receiver) |
| (prom exporter |
| exposes /metrics)
+------------------+
^
| HTTP scrape
|
+------------------+
| Prometheus |
+------------------+
^
|
+------------------+
| Grafana |
+------------------+
But we're only responsible for the part that pushes to the Otel collector, users can set up the rest of the system based on their requirements.
Co-authored-by: Elena Kolevska <elena-kolevska@users.noreply.github.com>
Don't be deceived by the branch name, the epic for this is actually DOC-6304 :-) node-redis will have support for this soon, but I'll make a separate PR for the docs to merge when it is released.
A few things to consider:
Note
Medium Risk
Mostly documentation/content, but it adds new site-wide template hooks plus JS/CSS that render JSON-driven content, which could affect page builds or client-side behavior on pages using the new shortcode.
Overview
Adds a new Redis client observability documentation section: an overview page (
content/develop/clients/observability.md) plus new client-specific setup guides forgo-redisandredis-py(including runnable local examples).Introduces a rendered metrics reference driven by a new
data/client_obs_metrics.jsonspec andotel-metric-groupsshortcode, with conditional loading of newstatic/js/otel-metrics.jsandstatic/css/otel-metrics.cssvialayouts/_default/baseof.html.Updates cross-links to point to the new observability pages (including from error-handling and production-usage docs), removes the old Go landing-page observability section, and tweaks navigation ordering (
clients/patternsweight).Written by Cursor Bugbot for commit 9e35c84. This will update automatically on new commits. Configure here.