|
| 1 | +[id='support-overview'] |
| 2 | += Support overview |
| 3 | +include::modules/common-attributes.adoc[] |
| 4 | +:context: support-overview |
| 5 | + |
| 6 | +toc::[] |
| 7 | + |
| 8 | +Red Hat offers cluster administrators tools for gathering data for your cluster, monitoring, and troubleshooting. |
| 9 | + |
| 10 | +[id='support-overview-get-support'] |
| 11 | +== Get support |
| 12 | +xref:../support/getting-support.adoc#getting-support[Get support]: Visit the Red Hat Customer Portal to review knowledge base articles, submit a support case, and review additional product documentation and resources. |
| 13 | + |
| 14 | +[id='support-overview-remote-health-monitoring'] |
| 15 | +== Remote health monitoring issues |
| 16 | +xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[Remote health monitoring issues]: |
| 17 | +{product-title} collects telemetry and configuration data about your cluster and reports it to Red Hat by using the Telemeter Client and the Insights Operator. Red Hat uses this data to understand and resolve issues in _connected cluster_. Similar to connected clusters, you can xref:../support/remote_health_monitoring/remote-health-reporting-from-restricted-network.adoc#remote-health-reporting-from-restricted-network[Use remote health monitoring in a restricted network]. {product-title} collects data and monitors health using the following: |
| 18 | + |
| 19 | +* *Telemetry*: The Telemetry Client gathers and uploads the metrics values to Red Hat every four minutes and thirty seconds. Red Hat uses this data to: |
| 20 | + |
| 21 | +** Monitor the clusters. |
| 22 | +** Roll out {product-title} upgrades. |
| 23 | +** Improve the upgrade experience. |
| 24 | + |
| 25 | +* *Insight Operator*: By default, {product-title} installs and enables the Insight Operator, which reports configuration and component failure status every two hours. The Insight Operator helps to: |
| 26 | + |
| 27 | +** Identify potential cluster issues proactively. |
| 28 | +** Provide a solution and preventive action in Red Hat OpenShift Cluster Manager. |
| 29 | + |
| 30 | +You can xref:../support/remote_health_monitoring/showing-data-collected-by-remote-health-monitoring.adoc#showing-data-collected-by-remote-health-monitoring[Review telemetry information]. |
| 31 | + |
| 32 | +If you have enabled remote health reporting, xref:../support/remote_health_monitoring/using-insights-to-identify-issues-with-your-cluster.adoc#using-insights-to-identify-issues-with-your-cluster[Use Insights to identify issues]. You can optionally disable remote health reporting. |
| 33 | + |
| 34 | +[id='support-overview-gather-data-cluster'] |
| 35 | +== Gather data about your cluster |
| 36 | +xref:../support/gathering-cluster-data.adoc#gathering-cluster-data[Gather data about your cluster]: Red Hat recommends gathering your debugging information when opening a support case. This helps Red Hat Support to perform a root cause analysis. A cluster administrator can use the following to gather data about your cluster: |
| 37 | + |
| 38 | +* *The must-gather tool*: Use the `must-gather` tool to collect information about your cluster and to debug the issues. |
| 39 | +* *sosreport*: Use the `sosreport` tool to collect configuration details, system information, and diagnostic data for debugging purposes. |
| 40 | +* *Cluster ID*: Obtain the unique identifier for your cluster, when providing information to Red Hat Support. |
| 41 | +* *Bootstrap node journal logs*: Gather `bootkube.service` `journald` unit logs and container logs from the bootstrap node to troubleshoot bootstrap-related issues. |
| 42 | +* *Cluster node journal logs*: Gather `journald` unit logs and logs within `/var/log` on individual cluster nodes to troubleshoot node-related issues. |
| 43 | +* *A network trace*: Provide a network packet trace from a specific {product-title} cluster node or a container to Red Hat Support to help troubleshoot network-related issues. |
| 44 | +* *Diagnostic data*: Use the `redhat-support-tool` command to gather(?) diagnostic data about your cluster. |
| 45 | + |
| 46 | +[id='support-overview-troubleshooting-issues'] |
| 47 | +== Troubleshooting issues |
| 48 | + |
| 49 | +A cluster administrator can monitor and troubleshoot the following {product-title} component issues: |
| 50 | + |
| 51 | +* xref:../support/troubleshooting/troubleshooting-installations.adoc#troubleshooting-installations[Installation issues]: {product-title} installation proceeds through various stages. You can perform the following: |
| 52 | + |
| 53 | +** Monitor the installation stages. |
| 54 | +** Determine at which stage installation issues occur. |
| 55 | +** Investigate multiple installation issues. |
| 56 | +** Gather logs from a failed installation. |
| 57 | + |
| 58 | +* xref:../support/troubleshooting/verifying-node-health.adoc#verifying-node-health[Node issues]: A cluster administrator can verify and troubleshoot node-related issues by reviewing the status, resource usage, and configuration of a node. You can query the following: |
| 59 | + |
| 60 | +** Kubelet’s status on a node. |
| 61 | +** Cluster node journal logs. |
| 62 | + |
| 63 | +* xref:../support/troubleshooting/troubleshooting-crio-issues.adoc#troubleshooting-crio-issues[Crio issues]: A cluster administrator can verify CRI-O container runtime engine status on each cluster node. If you experience container runtime issues, perform the following: |
| 64 | + |
| 65 | +** Gather CRI-O journald unit logs. |
| 66 | +** Cleaning CRI-O storage. |
| 67 | + |
| 68 | +* xref:../support/troubleshooting/troubleshooting-operating-system-issues.adoc#troubleshooting-operating-system-issues[Operating system issues]: {product-title} runs on Red Hat Enterprise Linux CoreOS. If you experience operating system issues, you can investigate kernel crash procedures. Ensure the following: |
| 69 | + |
| 70 | +** Enable kdump. |
| 71 | +** Test the kdump configuration. |
| 72 | +** Analyze a core dump. |
| 73 | + |
| 74 | +* xref:../support/troubleshooting/troubleshooting-network-issues.adoc#troubleshooting-network-issues[Network issues]: To troubleshoot Open vSwitch issues, a cluster administrator can perform the following: |
| 75 | + |
| 76 | +** Configure the Open vSwitch log level temporarily. |
| 77 | +** Configure the Open vSwitch log level permanently. |
| 78 | +** Display Open vSwitch logs. |
| 79 | + |
| 80 | +* xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-operator-issues[Operator issues]: A cluster administrator can do the following to resolve Operator issues: |
| 81 | + |
| 82 | +** Verify Operator subscription status. |
| 83 | +** Check Operator pod health. |
| 84 | +** Gather Operator logs. |
| 85 | + |
| 86 | +* xref:../support/troubleshooting/investigating-pod-issues.adoc#investigating-pod-issues[Pod issues]: A cluster administrator can troubleshoot pod-related issues by reviewing the status of a pod and completing the following: |
| 87 | + |
| 88 | +** Review pod and container logs. |
| 89 | +** Start debug pods with root access. |
| 90 | + |
| 91 | +* xref:../support/troubleshooting/troubleshooting-s2i.adoc#troubleshooting-s2i[Source-to-image issues]: A cluster administrator can observe the S2I stages to determine where in the S2I process a failure occurred. Gather the following to resolve Source-to-Image (S2I) issues: |
| 92 | + |
| 93 | +** Source-to-Image diagnostic data. |
| 94 | +** Application diagnostic data to investigate application failure. |
| 95 | + |
| 96 | +* xref:../support/troubleshooting/troubleshooting-storage-issues.adoc#troubleshooting-storage-issues[Storage issues]: A multi-attach storage error occurs when the mounting volume on a new node is not possible because the failed node cannot unmount the attached volume. A cluster administrator can do the following to resolve multi-attach storage issues: |
| 97 | + |
| 98 | +** Enable multiple attachments by using RWX volumes. |
| 99 | +** Recover or delete the failed node when using an RWO volume. |
| 100 | + |
| 101 | +* xref:../support/troubleshooting/investigating-monitoring-issues.adoc#investigating-monitoring-issues[Monitoring issues]: A cluster administrator can follow the procedures on the troubleshooting page for monitoring. If the metrics for your user-defined projects are unavailable or if Prometheus is consuming a lot of disk space, check the following: |
| 102 | + |
| 103 | +** Investigate why user-defined metrics are unavailable. |
| 104 | +** Determine why Prometheus is consuming a lot of disk space. |
| 105 | + |
| 106 | +* xref:../logging/cluster-logging.adoc#cluster-logging[Logging issues]: A cluster administrator can follow the procedures on the troubleshooting page for OpenShift Logging issues. Check the following to resolve logging issues: |
| 107 | + |
| 108 | +** xref:../logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-cluster-status[Status of the Logging Operator]. |
| 109 | +** xref:../logging/troubleshooting/cluster-logging-cluster-status.adoc#cluster-logging-cluster-status[Status of the Log store]. |
| 110 | +** xref:../logging/troubleshooting/cluster-logging-alerts.adoc#cluster-logging-alerts[OpenShift Logging alerts]. |
| 111 | +** xref:../logging/troubleshooting/cluster-logging-must-gather.adoc#cluster-logging-must-gather[Information about your OpenShift logging environment using `oc adm must-gather` command]. |
| 112 | + |
| 113 | +* xref:../support/troubleshooting/diagnosing-oc-issues.adoc#diagnosing-oc-issues[OpenShift CLI (oc) issues]: Investigate OpenShift CLI (oc) issues by increasing the log level. |
0 commit comments