kolla出现问题时的定位方式

Posted 2021-01-21 potato-chip

前提，对官网问题的一个翻译

Troubleshooting Guide
排障手册

1、Failures(失败)

If Kolla fails, often it is caused by a CTRL-C during the deployment process or a problem in the globals.yml configuration.
如果kolla失败，经常是由于部署过程中使用了ctrl-c或者globals.yml配置文件中的配置错误

To correct the problem where Operators have a misconfigured environment,
the Kolla community has added a precheck feature which ensures the deployment targets are in a state where Kolla may deploy to them.
为了解决操作人员环境配置错误的问题，Kolla社区添加了预检功能，确保部署目标处于Kolla可以部署状态
To run the prechecks, execute:
执行预检查，执行如下命令
kolla-ansible prechecks

If a failure during deployment occurs it nearly always occurs during evaluation of the software.
Once the Operator learns the few configuration options required, it is highly unlikely they will experience a failure in deployment.
如果在部署期间发生故障，则几乎总是在评估软件期间发生。 一旦操作人员了解到所需的少数配置选项，他们就不太可能遇到部署失败。

Deployment may be run as many times as desired, but if a failure in a bootstrap task occurs,
a further deploy action will not correct the problem.
In this scenario, Kolla’s behavior is undefined.
部署可以根据需要运行多次，但如果发生引导任务失败，则进一步的部署操作将无法解决问题。
在这种情况下，Kolla的行为是不确定的。

The fastest way during to recover from a deployment failure is to remove the failed deployment:
从部署失败中恢复的最快方法是删除失败的部署：
kolla-ansible destroy -i <<inventory-file>>
--inventory, -i <inventory_path> Specify path to ansible inventory file(指定all-in-one或者multinode文件所在的目录)
Destroy Kolla containers, volumes and host configuration
(--include-images to also destroy Kolla images)使用该参数使用需要使用如下形式：
kolla-ansible destroy --include-images --yes-i-really-really-mean-it

Any time the tags of a release change, it is possible that the container implementation from older versions won’t match the Ansible playbooks in a new version.
If running multinode from a registry, each node’s Docker image cache must be refreshed with the latest images before a new deployment can occur.
任何时候版本标签发生变化，旧版本的容器实现可能与新版本中的Ansible playbooks不匹配。
如果从一个仓库运行多节点，则必须使用最新镜像刷新每个节点的Docker镜像缓存，然后才能进行新的部署。
To refresh the docker cache from the local Docker registry:
从本地docker镜像仓库刷新docker缓存
kolla-ansible pull

2、Debugging Kolla(调试kolla)

The status of containers after deployment can be determined on the deployment targets by executing:
可以通过执行以下命令在部署目标上确定部署后容器的状态：
docker ps -a

The logs can be examined by executing:
容器的Log可以在通过执行如下命令检查：
docker exec -it heka bash

The logs from all services in all containers may be read from /var/log/kolla/SERVICE_NAME
可以从/var/log/kolla/SERVICE_NAME中读取所有容器中所有服务的日志
If the stdout logs are needed, please run:
如果需要stdout日志，请运行
docker logs <container-name>

Note that most of the containers don’t log to stdout so the above command will provide no information.
请注意，大多数容器不会记录到stdout，因此上面的命令将不提供任何信息
When enable_central_logging is enabled, to view the logs in a web browser using Kibana, go to:
启用enable_central_logging后，可以使用Kibana在Web浏览器中查看日志，访问方式如下
http://<kolla_internal_vip_address>:<kibana_server_port> 或者http://<kolla_external_vip_address>:<kibana_server_port>
使用<kibana_user>和<kibana_password>进行身份验证。

The values <kolla_internal_vip_address>, <kolla_external_vip_address> <kibana_server_port> and <kibana_user> can be found in <kolla_install_path>/kolla/ansible/group_vars/all.yml or if the default values are overridden, in /etc/kolla/globals.yml. The value of <kibana_password> can be found in /etc/kolla/passwords.yml.
可以在<kolla_install_path> /kolla/ansible/group_vars/all.yml中找到值<kolla_internal_vip_address>，<kolla_external_vip_address> <kibana_server_port>和<kibana_user>，或者在/etc/kolla/globals.yml中覆盖默认值。。 <kibana_password>的值可以在/etc/kolla/passwords.yml中找到。

Note When you log in to Kibana web interface for the first time, you are prompted to create an index.
Please create an index using the name log-*.
This step is necessary until the default Kibana dashboard is implemented in Kolla.
注意首次登录Kibana Web界面时，系统会提示您创建索引。 请使用名称log- *创建索引。 在Kolla中实施默认Kibana仪表板之前，此步骤是必需的。

官网路径：https://docs.openstack.org/kolla-ansible/4.0.1/troubleshooting.html