mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
72 lines
2.7 KiB
Plaintext
72 lines
2.7 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * support/troubleshooting/troubleshooting-installations.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="monitoring-installation-progress_{context}"]
|
|
= Monitoring installation progress
|
|
|
|
You can monitor high-level installation, bootstrap, and control plane logs as an {product-title} installation progresses. This provides greater visibility into how an installation progresses and helps identify the stage at which an installation failure occurs.
|
|
|
|
.Prerequisites
|
|
|
|
* You have access to the cluster as a user with the `cluster-admin` cluster role.
|
|
* You have installed the {oc-first}.
|
|
* You have SSH access to your hosts.
|
|
* You have the fully qualified domain names of the bootstrap and control plane nodes.
|
|
+
|
|
[NOTE]
|
|
====
|
|
The initial `kubeadmin` password can be found in `<install_directory>/auth/kubeadmin-password` on the installation host.
|
|
====
|
|
|
|
.Procedure
|
|
|
|
. Watch the installation log as the installation progresses:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ tail -f ~/<installation_directory>/.openshift_install.log
|
|
----
|
|
|
|
. Monitor the `bootkube.service` journald unit log on the bootstrap node, after it has booted. This provides visibility into the bootstrapping of the first control plane. Replace `<bootstrap_fqdn>` with the bootstrap node's fully qualified domain name:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
The `bootkube.service` log on the bootstrap node outputs etcd `connection refused` errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.
|
|
====
|
|
+
|
|
. Monitor `kubelet.service` journald unit logs on control plane nodes, after they have booted. This provides visibility into control plane node agent activity.
|
|
.. Monitor the logs using `oc`:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc adm node-logs --role=master -u kubelet
|
|
----
|
|
.. If the API is not functional, review the logs using SSH instead. Replace `<master-node>.<cluster_name>.<base_domain>` with appropriate values:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service
|
|
----
|
|
|
|
. Monitor `crio.service` journald unit logs on control plane nodes, after they have booted. This provides visibility into control plane node CRI-O container runtime activity.
|
|
.. Monitor the logs using `oc`:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc adm node-logs --role=master -u crio
|
|
----
|
|
+
|
|
.. If the API is not functional, review the logs using SSH instead. Replace `<master-node>.<cluster_name>.<base_domain>` with appropriate values:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service
|
|
----
|