automation-suite
2022.4
false
Automation Suite 安装指南
- 概述
- 要求
- 安装
- 安装后
- 集群管理
- 监控和警示
- 迁移和升级
- 特定于产品的配置
- 最佳实践和维护
- 故障排除
- 无法获取沙盒映像
- Pod 未显示在 ArgoCD 用户界面中
- Redis 探测器失败
- RKE2 服务器无法启动
- 在 UiPath 命名空间中找不到密码
- 初始安装后,ArgoCD 应用程序进入“进行中”状态
- MongoDB Pod 处于 CrashLoopBackOff 状态或在删除后处于“等待 PVC 配置”状态
- 意外错误:不一致;手动运行 fsck
- 集群还原后 MongoDB 或业务应用程序降级
- 缺少 Self-heal-operator 和 Sf-k8-utils 存储库
- 集群还原或回滚后服务不正常
- RabbitMQ Pod 卡在 CrashLoopBackOff 中
- Prometheus 处于 CrashLoopBackoff 状态,并出现内存不足 (OOM) 错误
- 监控仪表板中缺少 Ceph-rook 指标
- Pod 无法在代理环境中与 FQDN 通信
- 使用 Automation Suite 诊断工具
- 使用 Automation Suite 支持捆绑包
- 探索日志
重要 :
请注意,此内容已使用机器翻译进行了部分本地化。
新发布内容的本地化可能需要 1-2 周的时间才能完成。
Prometheus 处于 CrashLoopBackoff 状态,并出现内存不足 (OOM) 错误
描述
在某些情况下,Prometheus Pod 可能由于内存不足 (OOM) 错误而无法启动。要识别受影响的 Prometheus Pod,请搜索与 OOM 错误明确相关的上一个终止状态。
解决方案
要解决此问题,请执行以下步骤:
-
通过更新
resource.exclusions来更新argocd configmap以忽略service-monitors。-
创建旧
configmap的备份:kubectl get configmap argocd-cm -n argocd -o yaml >> argocd-cm-old.yamlkubectl get configmap argocd-cm -n argocd -o yaml >> argocd-cm-old.yaml -
编辑
argocd-cm:kubectl edit configmap argocd-cm -n argocdkubectl edit configmap argocd-cm -n argocd -
为
resource.exclusions添加新的数据条目:data: resource.exclusions: | - apiGroups: - monitoring.coreos.com kinds: - ServiceMonitor clusters: - "*"data: resource.exclusions: | - apiGroups: - monitoring.coreos.com kinds: - ServiceMonitor clusters: - "*"
-
-
删除
istio-system命名空间下的envoy-stats-monitor服务监控:kubectl -n istio-system delete servicemonitor envoy-stats-monitorkubectl -n istio-system delete servicemonitor envoy-stats-monitor -
强制删除 Prometheus Pod:
kubectl delete pod prometheus-rancher-monitoring-prometheus-0 -n cattle-monitoring-system kubectl delete pod prometheus-rancher-monitoring-prometheus-1 -n cattle-monitoring-systemkubectl delete pod prometheus-rancher-monitoring-prometheus-0 -n cattle-monitoring-system kubectl delete pod prometheus-rancher-monitoring-prometheus-1 -n cattle-monitoring-system -
等待
cattle-monitoring-system下的 Prometheus Pod 成功重新启动。
重要提示:
Deleting the the wal and chunks_head directories results in a loss of all monitoring data gathered during the days these files were accumulated. However, once Prometheus is up and running again, any new alerts and metrics data will be accessible.