PrivateEdition/Current/Operations/Monitoring Approach - Revision history

WikiSysop at 19:32, March 12, 2023

2023-03-12T19:32:03Z

WikiSysop at 10:46, September 29, 2022

2022-09-29T10:46:13Z

WikiSysop at 08:31, September 29, 2022

2022-09-29T08:31:04Z

WikiSysop at 17:46, June 30, 2022

2022-06-30T17:46:09Z

WikiSysop at 18:16, May 12, 2022

2022-05-12T18:16:11Z

Jabashree.amudha@genesys.com: Published

2021-12-20T18:03:43Z

Published

New page

{{Article
|Standalone=No
|DisplayName=Monitoring overview and approach
|TocName=Monitoring overview and approach
|Context=Learn about the monitoring approach for your services.
|ComingSoon=No
|Section={{Section
|sectionHeading=Monitoring approach in a private edition deployment
|anchor=MonitoringOverviewApproach
|alignment=Vertical
|structuredtext====Overview===
This section encompasses information regarding metrics, alerts, and the monitoring approach for services. Services provide the necessary interface to use your own monitoring and logging tools, Prometheus-based metrics, and the endpoint that the Prometheus platform can scrape for alerting and monitoring. The default operators do not scrape user workload or user-defined applications like Genesys services. You must enable Prometheus to scrape user workload. Once enabled, Prometheus scrapes all metrics from endpoints exposed by services.

Some services optionally use Pushgateway to push metrics from jobs that cannot be scraped.

===Approach===
In general, the monitoring approach in a private edition deployment is Prometheus-based. Through Prometheus support, the metrics that are generated by Genesys services are made available for visualization (using tools like Grafana). For more details, see the respective sections based on your cloud platform. {{NoteFormat|If you are not using Prometheus or an APM tool that supports Prometheus CRDs and PodMonitor or ServiceMonitor objects, then you must build your own solution until Genesys includes the Prometheus annotation support.|}}There are two types of metrics: system and service.

For most services, you must enable 'user workload monitoring', and then create ServiceMonitor or PodMonitor per your requirement. However, services that do not use CRD or annotation, run the Cron job to collect metrics and push them into the Prometheus gateway.

*System metrics contain data pertaining to cluster performance and status such as CPU usage, memory usage, network I/O pressure, disk usage, and so on. When Prometheus is deployed, by default the system metrics are automatically collected. They provide monitoring of cluster components and ship with a set of alerts to immediately notify the cluster administrator about any occurring problems
*Service metrics contain data pertaining to Genesys services. For links to information about the service-level metrics, see [[Draft:PrivateEdition/Current/Operations/MonitoringServices#Summary of monitoring support|Summary of monitoring support]].

===OpenShift monitoring===
A core feature of the Prometheus operator is to monitor the Kubernetes API server for changes to specific objects and ensure the current Prometheus deployments match these objects. The operator acts on the following custom resource definitions (CRDs):

*'''Prometheus''': Defines a preferred Prometheus deployment.
*'''Alertmanager''': Defines a preferred Alertmanager deployment.
*'''ThanosRuler''': Defines a preferred Thanos Ruler deployment.
*'''ServiceMonitor''': Declaratively specifies how groups of Kubernetes services must be monitored. The operator automatically generates Prometheus scrape configuration based on the current state of the objects in the API server.
*'''PodMonitor''': Declaratively specifies how a group of pods should be monitored. The operator automatically generates Prometheus scrape configuration based on the current state of the objects in the API server.
*'''Probe''': Declaratively specifies how groups of ingresses or static targets should be monitored. The Operator automatically generates Prometheus scrape configuration based on the definition.
*'''PrometheusRule''': Defines a preferred set of Prometheus alerting and/or recording rules. The operator generates a rule file, which can be used by Prometheus instances.
*'''AlertmanagerConfig''': Declaratively specifies subsections of the Alertmanager configuration, allowing routing of alerts to custom receivers, and setting inhibit rules.

The following diagram illustrates the monitoring approach for private edition documentation. When you deploy Red Hat OpenShift cluster, the '''OpenShift monitoring''' operators are installed by default as a part of the OpenShift cluster, in read-only format.[[File:MonitoringServices.png]]

To monitor your user-defined projects that are deployed in the cluster, you must enable the monitoring feature. For more details, refer to [[Draft:PrivateEdition/Current/Operations/MonitoringServices|Monitoring your services]] page.

When you enable this feature, the '''Openshift-user-workload-monitoring''' namespace is created.

In the '''Application''' namespace, you can modify Alerts per your requirement. The ServiceMonitor/PodMonitor specifies the port on which these metrics are exposed, which are collected by the Prometheus operator.

Each service can contain more than one service or pod monitor that exposes the metrics.

===GKE monitoring===
There are two approaches in GKE for monitoring: Google Cloud operations suite and Prometheus-based approach. For more details, refer to the following sections:

'''Google Cloud operations suite'''

*<span lang="EN-CA">https://cloud.google.com/stackdriver/docs</span>
*<span lang="EN-CA">https://cloud.google.com/monitoring/docs</span>

'''Prometheus-based approach'''

*https://prometheus.io/docs/introduction/overview

By default, GKE clusters are natively integrated with monitoring. When you create a GKE cluster, monitoring is enabled by default. Cloud Monitoring collects metrics, events, and metadata from Google Cloud. Prometheus is the monitoring tool that is often used with Kubernetes. Prometheus covers a full stack of Kubernetes cluster components, deployed microservices, alerts, and dashboards. If you configure Cloud Operations for GKE and include Prometheus support, then the metrics that are generated by services using the [https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md Prometheus exposition format] can be exported from the cluster and made visible as [https://cloud.google.com/monitoring/api/metrics_other#externalgoogleapiscom external metrics] in Cloud Monitoring.

Click [[Draft:PrivateEdition/Current/Operations/Grafana configuration#Deploying Prometheus|here]] to learn about deploying Prometheus.
|Status=No
}}
}}

@@ Line 19: / Line 19: @@
 *Service metrics contain data pertaining to Genesys services. For most services, you must enable  'user workload monitoring', and then create ServiceMonitor or PodMonitor per your requirement. However, services that do not use CRD or annotation, run the Pushgateway (Cron job) to collect metrics and push them into the Prometheus gateway.
-{{AnchorDiv|openshiftmonitoring}}
+{{AnchorDiv|openshiftmonitoring}}.
 {{AnchorDiv|gkemonitoring}}
 ===GKE monitoring===
@@ Line 55: / Line 36: @@
 Click {{Link-SomewhereInThisVersion|manual=Operations|topic=Grafana_configuration|anchor=Deploying_Prometheus|display text=here}} to learn about deploying Prometheus.
 {{AnchorDiv|enablemonitoring}}
@@ Line 60: / Line 47: @@
 To set up monitoring for the cluster and your private edition services in cloud platforms, find instructions here:
 *{{Link-SomewhereInThisVersion|manual=Operations|topic=EnableMonitoringServicesGKE|display text=Enabling monitoring in GKE Platform}}
 |Status=No
 }}
 }}

@@ Line 57: / Line 57: @@
 {{AnchorDiv|enablemonitoring}}
-==Enabling monitoring your services==
+==Enabling monitoring for your services==
 To set up monitoring for the cluster and your private edition services in cloud platforms, find instructions here:

@@ Line 19: / Line 19: @@
 *Service metrics contain data pertaining to Genesys services. For most services, you must enable  'user workload monitoring', and then create ServiceMonitor or PodMonitor per your requirement. However, services that do not use CRD or annotation, run the Pushgateway (Cron job) to collect metrics and push them into the Prometheus gateway.
 ===OpenShift monitoring===
 A core feature of the Prometheus operator is to monitor the Kubernetes API server for changes to specific objects and ensure  the current Prometheus deployments match these objects. The operator acts on the following custom resource definitions (CRDs):
@@ Line 38: / Line 39: @@
 Each service can contain more than one service or pod monitor that exposes the metrics.
+{{AnchorDiv|gkemonitoring}}
 ===GKE monitoring===
 GKE monitoring enables you to identify issues related to the performance of your services, and acquire visibility into containers, nodes, and pods within your GKE environment. There are two approaches in GKE for monitoring: Google Cloud operations suite and Prometheus-based approach. For more details, refer to the following sections:
@@ Line 55: / Line 56: @@
 Click {{Link-SomewhereInThisVersion|manual=Operations|topic=Grafana_configuration|anchor=Deploying_Prometheus|display text=here}} to learn about deploying Prometheus.
 ==Enabling monitoring your services==
 To set up monitoring for the cluster and your private edition services in cloud platforms, find instructions here:

@@ Line 3: / Line 3: @@
 |DisplayName=Monitoring overview and approach
 |TocName=Monitoring overview and approach
-|Context=Learn about the monitoring approach for your services.
+|Context=Learn about the types of metrics, and the monitoring approach for your Genesys Multicloud CX services that are used in private edition.
 |ComingSoon=No
 |Section={{Section
-|sectionHeading=Monitoring approach in a private edition deployment
+|sectionHeading=Metrics, alerts, and monitoring approach for services
 |anchor=MonitoringOverviewApproach
 |alignment=Vertical
-|structuredtext====Overview===
+|structuredtext=Services provide the necessary interface to use your own monitoring and logging tools, Prometheus-based metrics, and the endpoint that the Prometheus platform can scrape for alerting and monitoring. The default operators do not scrape user workload or user-defined applications like Genesys services. You must enable Prometheus to scrape user workload. Once enabled, Prometheus scrapes all metrics from endpoints exposed by services.
 Some services optionally use Pushgateway to push metrics from jobs that cannot be scraped.
@@ Line 17: / Line 16: @@
 In general, the monitoring approach in a private edition deployment is Prometheus-based. Through Prometheus support, the metrics that are generated by Genesys services are made available for visualization (using tools like Grafana). For more details, see the respective sections based on your cloud platform. {{NoteFormat|If you are not using Prometheus or an APM tool that supports Prometheus CRDs and PodMonitor or ServiceMonitor objects, then you must build your own solution until Genesys includes the Prometheus annotation support.|}}There are two types of metrics: system and service.
-For most services, you must enable  'user workload monitoring', and then create ServiceMonitor or PodMonitor per your requirement. However, services that do not use CRD or annotation, run the Cron job to collect metrics and push them into the Prometheus gateway.
+*{{Link-SomewhereInThisVersion|manual=Operations|topic=SystemMetrics}} contain data pertaining to cluster performance and status such as CPU usage, memory usage, network I/O pressure, disk usage, and so on. When Prometheus is deployed, by default the system metrics are automatically collected. They provide monitoring of cluster components and ship with a set of alerts to immediately notify the cluster administrator about any occurring problems
+*Service metrics contain data pertaining to Genesys services. For most services, you must enable  'user workload monitoring', and then create ServiceMonitor or PodMonitor per your requirement. However, services that do not use CRD or annotation, run the Pushgateway (Cron job) to collect metrics and push them into the Prometheus gateway.
 ===OpenShift monitoring===
@@ Line 35: / Line 32: @@
 The following diagram illustrates the monitoring approach for private edition documentation. When you deploy Red Hat OpenShift cluster, the '''OpenShift monitoring''' operators are installed by default as a part of the OpenShift cluster, in read-only format.[[File:MonitoringServices.png]]
 When you enable this feature, the '''Openshift-user-workload-monitoring''' namespace is created.
@@ Line 45: / Line 40: @@
 ===GKE monitoring===
-There are two approaches in GKE for monitoring: Google Cloud operations suite and Prometheus-based approach. For more details, refer to the following sections:
+GKE monitoring enables you to identify issues related to the performance of your services, and acquire visibility into containers, nodes, and pods within your GKE environment. There are two approaches in GKE for monitoring: Google Cloud operations suite and Prometheus-based approach. For more details, refer to the following sections:
-'''Google Cloud operations suite'''
+====='''Google Cloud operations suite'''=====
 *<span lang="EN-CA">https://cloud.google.com/stackdriver/docs</span>
-*<span lang="EN-CA">https://cloud.google.com/monitoring/docs</span>
+*https://cloud.google.com/monitoring/docs
-'''Prometheus-based approach'''
+====='''Prometheus-based approach'''=====
 *https://prometheus.io/docs/introduction/overview
-By default, GKE clusters are natively integrated with monitoring. When you create a GKE cluster, monitoring is enabled by default. Cloud Monitoring collects metrics, events, and metadata from Google Cloud. Prometheus is the monitoring tool that is often used with Kubernetes. Prometheus covers a full stack of Kubernetes cluster components, deployed microservices, alerts, and dashboards. If you configure Cloud Operations for GKE and include Prometheus support, then the metrics that are generated by services using the [https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md Prometheus exposition format] can be exported from the cluster and made visible as [https://cloud.google.com/monitoring/api/metrics_other#externalgoogleapiscom external metrics] in Cloud Monitoring.
+Click {{Link-SomewhereInThisVersion|manual=Operations|topic=Grafana_configuration|anchor=Deploying_Prometheus|display text=here}} to learn about deploying Prometheus.
-Click {{Link-SomewhereInThisVersion|manual=Operations|topic=Grafana_configuration|display text=here}} to learn about deploying Prometheus.
+*{{Link-SomewhereInThisVersion|manual=Operations|topic=EnableMonitoringServicesOCP|display text=Enabling monitoring in OpenShift Container Platform}}
 |Status=No
 }}
 }}

@@ Line 20: / Line 20: @@
 *System metrics contain data pertaining to cluster performance and status such as CPU usage, memory usage, network I/O pressure, disk usage, and so on. When Prometheus is deployed, by default the system metrics are automatically collected. They provide monitoring of cluster components and ship with a set of alerts to immediately notify the cluster administrator about any occurring problems
-*Service metrics contain data pertaining to Genesys services. For links to information about the service-level metrics, see [[Draft:PrivateEdition/Current/Operations/MonitoringServices#Summary of monitoring support|Summary of monitoring support]].
+*Service metrics contain data pertaining to Genesys services. For links to information about the service-level metrics, see {{Link-SomewhereInThisVersion|manual=Operations|topic=MonitoringServices}}.
 ===OpenShift monitoring===
@@ Line 36: / Line 36: @@
 The following diagram illustrates the monitoring approach for private edition documentation. When you deploy Red Hat OpenShift cluster, the '''OpenShift monitoring''' operators are installed by default as a part of the OpenShift cluster, in read-only format.[[File:MonitoringServices.png]]
-To monitor your user-defined projects that are deployed in the cluster, you must enable the monitoring feature. For more details, refer to [[Draft:PrivateEdition/Current/Operations/MonitoringServices|Monitoring your services]] page.
+To monitor your user-defined projects that are deployed in the cluster, you must enable the monitoring feature. For more details, refer to the {{Link-SomewhereInThisVersion|manual=Operations|topic=MonitoringServices}} page.
 When you enable this feature, the '''Openshift-user-workload-monitoring''' namespace is created.
@@ Line 58: / Line 58: @@
 By default, GKE clusters are natively integrated with monitoring. When you create a GKE cluster, monitoring is enabled by default. Cloud Monitoring collects metrics, events, and metadata from Google Cloud. Prometheus is the monitoring tool that is often used with Kubernetes. Prometheus covers a full stack of Kubernetes cluster components, deployed microservices, alerts, and dashboards. If you configure Cloud Operations for GKE and include Prometheus support, then the metrics that are generated by services using the [https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md Prometheus exposition format] can be exported from the cluster and made visible as [https://cloud.google.com/monitoring/api/metrics_other#externalgoogleapiscom external metrics] in Cloud Monitoring.
-Click [[Draft:PrivateEdition/Current/Operations/Grafana configuration#Deploying Prometheus|here]] to learn about deploying Prometheus.
+Click {{Link-SomewhereInThisVersion|manual=Operations|topic=Grafana_configuration|display text=here}} to learn about deploying Prometheus.
 |Status=No
 }}
 }}