Skip to content

Commit ea2e9f3

Browse files
authored
Merge pull request #94574 from eromanova97/OBSDOCS-1983
OBSDOCS-1983: Modify monitoring docs to allign with unified admin/dev perspective
2 parents cce7f17 + 7331bd7 commit ea2e9f3

File tree

28 files changed

+85
-304
lines changed

28 files changed

+85
-304
lines changed
-112 KB
Binary file not shown.
-90.6 KB
Binary file not shown.

modules/monitoring-about-monitoring-dashboards.adoc

Lines changed: 8 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,14 @@
33
// * observability/monitoring/reviewing-monitoring-dashboards.adoc
44

55
:_mod-docs-content-type: CONCEPT
6-
[id="mon-dashboards-adm-perspective_{context}"]
7-
= Monitoring dashboards in the Administrator perspective
6+
[id="about-monitoring-dashboards_{context}"]
7+
= About monitoring dashboards
88

9-
Use the *Administrator* perspective to access dashboards for the core {product-title} components, including the following items:
9+
{product-title} provides a set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads.
10+
11+
include::snippets/unified-perspective-web-console.adoc[]
12+
13+
As an administrator, you can access dashboards for the core {product-title} components, including the following items:
1014

1115
* API performance
1216
* etcd
@@ -16,13 +20,4 @@ Use the *Administrator* perspective to access dashboards for the core {product-t
1620
* USE method dashboards relating to cluster and node performance
1721
* Node performance metrics
1822
19-
.Example dashboard in the Administrator perspective
20-
image::monitoring-dashboard-administrator.png[]
21-
22-
[id="mon-dashboards-dev-perspective_{context}"]
23-
= Monitoring dashboards in the Developer perspective
24-
25-
In the *Developer* perspective, you can access only the Kubernetes compute resources dashboards:
26-
27-
.Example dashboard in the Developer perspective
28-
image::observe-dashboard-developer.png[]
23+
// to do: add a new image

modules/monitoring-accessing-the-alerting-ui.adoc

Lines changed: 4 additions & 40 deletions
Original file line numberDiff line numberDiff line change
@@ -5,45 +5,9 @@
55

66
:_mod-docs-content-type: PROCEDURE
77

8-
// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
8+
[id="monitoring-accessing-the-alerting-ui_{context}"]
9+
= Accessing the Alerting UI
910

10-
// tag::ADM[]
11-
[id="monitoring-accessing-the-alerting-ui-adm_{context}"]
12-
= Accessing the Alerting UI from the Administrator perspective
13-
// end::ADM[]
11+
The Alerting UI is accessible in the {product-title} web console.
1412

15-
// tag::DEV[]
16-
[id="monitoring-accessing-the-alerting-ui-dev_{context}"]
17-
= Accessing the Alerting UI from the Developer perspective
18-
// end::DEV[]
19-
20-
// Set attributes to distinguish between cluster monitoring example (core platform monitoring - CPM) and user workload monitoring (UWM) examples
21-
22-
// tag::ADM[]
23-
:perspective: Administrator
24-
// end::ADM[]
25-
26-
// tag::DEV[]
27-
:perspective: Developer
28-
// end::DEV[]
29-
30-
The Alerting UI is accessible through the *{perspective}* perspective of the {product-title} web console.
31-
32-
// tag::ADM[]
33-
* From the *Administrator* perspective, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages.
34-
// end::ADM[]
35-
36-
// tag::DEV[]
37-
* From the *Developer* perspective, go to *Observe* and go to the *Alerts* tab.
38-
* Select the project that you want to manage alerts for from the *Project:* list.
39-
40-
In this perspective, alerts, silences, and alerting rules are all managed from the *Alerts* tab. The results shown in the *Alerts* tab are specific to the selected project.
41-
42-
[NOTE]
43-
====
44-
In the *Developer* perspective, you can select from core {product-title} and user-defined projects that you have access to in the *Project: <project_name>* list. However, alerts, silences, and alerting rules relating to core {product-title} projects are not displayed if you are not logged in as a cluster administrator.
45-
====
46-
// end::DEV[]
47-
48-
// Unset the source code block attributes just to be safe.
49-
:!perspective:
13+
* In the {product-title} web console, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages.

modules/monitoring-configuring-alert-routing-console.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ The {product-title} web console provides fewer settings to configure alert routi
2020
2121
.Procedure
2222

23-
. In the *Administrator* perspective, go to *Administration* -> *Cluster Settings* -> *Configuration* -> *Alertmanager*.
23+
. In the {product-title} web console, go to *Administration* -> *Cluster Settings* -> *Configuration* -> *Alertmanager*.
2424
+
2525
[NOTE]
2626
====

modules/monitoring-creating-scrape-sample-alerts.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -74,6 +74,6 @@ $ oc apply -f monitoring-stack-alerts.yaml
7474

7575
. Additionally, you can check if a target has hit the configured limit:
7676

77-
.. In the *Administrator* perspective of the web console, go to *Observe* -> *Targets* and select an endpoint with a `Down` status that you want to check.
77+
.. In the {product-title} web console, go to *Observe* -> *Targets* and select an endpoint with a `Down` status that you want to check.
7878
+
7979
The *Scrape failed: sample limit exceeded* message is displayed if the endpoint failed because of an exceeded sample limit.

modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ endif::openshift-dedicated,openshift-rosa-hcp,openshift-rosa[]
3838

3939
.Procedure
4040

41-
. In the *Administrator* perspective, navigate to *Observe* -> *Metrics*.
41+
. In the {product-title} web console, go to *Observe* -> *Metrics*.
4242

4343
. Enter a Prometheus Query Language (PromQL) query in the *Expression* field.
4444
The following example queries help to identify high cardinality metrics that might result in high disk space consumption:

modules/monitoring-editing-silences.adoc

Lines changed: 4 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -4,17 +4,8 @@
44

55
:_mod-docs-content-type: PROCEDURE
66

7-
// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
8-
9-
// tag::ADM[]
10-
[id="editing-silences-adm_{context}"]
11-
= Editing silences from the Administrator perspective
12-
// end::ADM[]
13-
14-
// tag::DEV[]
15-
[id="editing-silences-dev_{context}"]
16-
= Editing silences from the Developer perspective
17-
// end::DEV[]
7+
[id="editing-silences_{context}"]
8+
= Editing silences
189

1910
You can edit a silence, which expires the existing silence and creates a new one with the changed configuration.
2011

@@ -28,23 +19,11 @@ ifdef::openshift-dedicated,openshift-rosa[]
2819
endif::openshift-dedicated,openshift-rosa[]
2920
* If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
3021
** The `cluster-monitoring-view` cluster role, which allows you to access Alertmanager.
31-
// tag::ADM[]
32-
** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts in the *Administrator* perspective in the web console.
33-
// end::ADM[]
34-
// tag::DEV[]
35-
** The `monitoring-rules-edit` cluster role, which permits you to create and silence alerts in the *Developer* perspective in the web console.
36-
// end::DEV[]
22+
** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts.
3723

3824
.Procedure
3925

40-
// tag::ADM[]
41-
. From the *Administrator* perspective of the {product-title} web console, go to *Observe* -> *Alerting* -> *Silences*.
42-
// end::ADM[]
43-
44-
// tag::DEV[]
45-
. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Silences* tab.
46-
. Select the project that you want to edit silences for from the *Project:* list.
47-
// end::DEV[]
26+
. In the {product-title} web console, go to *Observe* -> *Alerting* -> *Silences*.
4827

4928
. For the silence you want to modify, click {kebab} and select *Edit silence*.
5029
+

modules/monitoring-expiring-silences.adoc

Lines changed: 3 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -4,17 +4,8 @@
44

55
:_mod-docs-content-type: PROCEDURE
66

7-
// The ultimate solution DOES NOT NEED separate IDs and titles, it is just needed for now so that the tests will not break
8-
9-
// tag::ADM[]
10-
[id="expiring-silences-adm_{context}"]
11-
= Expiring silences from the Administrator perspective
12-
// end::ADM[]
13-
14-
// tag::DEV[]
15-
[id="expiring-silences-dev_{context}"]
16-
= Expiring silences from the Developer perspective
17-
// end::DEV[]
7+
[id="expiring-silences_{context}"]
8+
= Expiring silences
189

1910
You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently.
2011

@@ -34,24 +25,11 @@ ifdef::openshift-dedicated,openshift-rosa[]
3425
endif::openshift-dedicated,openshift-rosa[]
3526
* If you are a non-administrator user, you have access to the cluster as a user with the following user roles:
3627
** The `cluster-monitoring-view` cluster role, which allows you to access Alertmanager.
37-
// tag::ADM[]
38-
** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts in the *Administrator* perspective in the web console.
39-
// end::ADM[]
40-
// tag::DEV[]
41-
** The `monitoring-rules-edit` cluster role, which permits you to create and silence alerts in the *Developer* perspective in the web console.
42-
// end::DEV[]
28+
** The `monitoring-alertmanager-edit` role, which permits you to create and silence alerts.
4329

4430
.Procedure
4531

46-
// tag::ADM[]
4732
. Go to *Observe* -> *Alerting* -> *Silences*.
48-
// end::ADM[]
49-
50-
// tag::DEV[]
51-
. From the *Developer* perspective of the {product-title} web console, go to *Observe* and go to the *Silences* tab.
52-
53-
. Select the project that you want to expire a silence for from the *Project:* list.
54-
// end::DEV[]
5533

5634
. For the silence or silences you want to expire, select the checkbox in the corresponding row.
5735

modules/monitoring-exploring-the-visualized-metrics.adoc

Lines changed: 1 addition & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -10,8 +10,6 @@ After running the queries, the metrics are displayed on an interactive plot. The
1010

1111
.Procedure
1212

13-
In the *Administrator* perspective:
14-
1513
* Initially, all metrics from all enabled queries are shown on the plot. You can select which metrics are shown.
1614
+
1715
[NOTE]
@@ -33,16 +31,4 @@ By default, the query table shows an expanded view that lists every metric and i
3331
3432
* To display outputs for all queries at a specific point in time, hold the mouse cursor on the plot at that point. The query outputs will appear in a pop-up box.
3533
36-
. To hide the plot, select *Hide Graph*.
37-
38-
In the *Developer* perspective:
39-
40-
* To zoom into the plot and change the time range, do one of the following:
41-
42-
** Visually select the time range by clicking and dragging on the plot horizontally.
43-
44-
** Use the menu in the left upper corner to select the time range.
45-
46-
* To reset the time range, select *Reset Zoom*.
47-
48-
* To display outputs for all queries at a specific point in time, hold the mouse cursor on the plot at that point. The query outputs will appear in a pop-up box.
34+
. To hide the plot, select *Hide Graph*.

0 commit comments

Comments
 (0)