全部产品
Search
文档中心

容器服务 Kubernetes 版 ACK:可观测性FAQ

更新时间:Jun 25, 2025

分类

跳转链接

日志采集

应用监控

阿里云Prometheus监控

开源Prometheus监控(ack-prometheus-operator组件)

服务报警管理

其他问题

日志采集

如何排查容器日志采集异常?

问题现象

容器日志采集出现异常,导致无法上报新的日志内容。

解决方案

  • 排查机器组心跳是否异常

    您可以通过检查机器组心跳的状态来判断容器中的Logtail是否已正确安装。

    1. 查看机器组心跳状态。

      1. 登录日志服务控制台

      2. 在Project列表区域,单击目标Project。

        image

      3. 在左侧导航栏中,选择资源 > 机器组

      4. 在机器组列表中,单击目标机器组。

      5. 机器组配置页面,查看机器组状态并记录心跳状态为OK的节点数。

    2. 检查容器集群中Worker节点数。

      1. 连接集群

      2. 执行如下命令,查看集群中Worker节点数。

        kubectl get node | grep -v master

        系统会返回如下类似结果。

        NAME                                 STATUS    ROLES     AGE       VERSION
        cn-hangzhou.i-bp17enxc2us3624wexh2   Ready     <none>    238d      v1.10.4
        cn-hangzhou.i-bp1ad2b02jtqd1shi2ut   Ready     <none>    220d      v1.10.4
    3. 对比心跳状态为OK的节点数是否和容器集群中Worker节点数一致。根据对比结果选择排查方式。

      • 机器组中所有节点的心跳状态均为Failed

        • 如果您要采集标准Docker容器日志,请参见采集Docker容器文本日志,检查${your_region_name}${your_aliyun_user_id}${your_machine_group_user_defined_id}是否填写正确。

        • 如果您使用的是阿里云Kubernetes集群,请提交工单

        • 如果您使用的是自建Kubernetes集群,请参见通过Sidecar方式采集Kubernetes容器文本日志,检查{your-project-suffix}{regionId}{aliuid}{access-key-id}{access-key-secret}是否已正确填写。

          如果填写错误,请执行helm del --purge alibaba-log-controller命令,删除安装包,然后重新安装。

      • 机器组心跳状态为OK的节点数量少于集群中的Worker节点数量。

        • 判断是否已使用YAML文件手动部署DaemonSet。

          1. 执行如下命令。如果存在返回结果,则表示您之前已使用YAML文件手动部署DaemonSet。

            kubectl get po -n kube-system -l k8s-app=logtail
          2. 下载最新版本DaemonSet模板。

          3. 根据实际值,配置${your_region_name}${your_aliyun_user_id}${your_machine_group_name}等参数。

          4. 执行如下命令,更新文件。

            kubectl apply -f ./logtail-daemonset.yaml
        • 其他情况,请提交工单

  • 排查容器日志采集是否异常

    如果您在日志服务控制台的预览或Logstore查询页面未查到日志,则说明日志服务未采集到您的容器日志。请确认容器状态,然后执行如下检查。

    重要
    • 采集容器文件中的日志时,需注意如下事项。

      • Logtail只采集增量日志。如果下发Logtail配置后,日志文件无更新,则Logtail不会采集该文件中的日志。更多信息,请参见读取日志

      • 只支持采集容器默认存储或挂载到本地的文件中的日志,暂不支持其他存储方式。

    • 采集到日志后,您需要先创建索引,才能在Logstore中查询和分析日志。具体操作,请参见创建索引

    1. 查看机器组心跳是否存在异常。具体操作,请参见排查机器组心跳是否异常

    2. 检查Logtail配置是否正确。

      检查Logtail配置中的IncludeLabelExcludeLabelIncludeEnvExcludeEnv等配置是否符合您的采集需求。

      说明
      • 其中此处的Label为容器Label,即Docker inspect中的Label,不是Kubernetes中的Label。

      • 您可以将IncludeLabelExcludeLabelIncludeEnvExcludeEnv配置临时去除,查看是否可以正常采集到日志。如果可以,则说明是上述参数的配置存在问题。

  • 其他运维操作。

    • 查看Logtail的运行日志

      Logtail日志存储在Logtail容器中的/usr/local/ilogtail/目录中,文件名为ilogtail.LOGlogtail_plugin.LOG

      1. 登录Logtail容器。具体操作,登录Logtail容器

      2. 打开/usr/local/ilogtail/目录。

        cd /usr/local/ilogtail
      3. 查看ilogtail.LOGlogtail_plugin.LOG文件。

        cat ilogtail.LOG
        cat logtail_plugin.LOG
    • Logtail容器的标准输出(stdout)说明

      Logtail容器中的标准输出并不具备参考意义,请忽略以下标准输出内容。

      start umount useless mount points, /shm$|/merged$|/mqueue$
      umount: /logtail_host/var/lib/docker/overlay2/3fd0043af174cb0273c3c7869500fbe2bdb95d13b1e110172ef57fe840c82155/merged: must be superuser to unmount
      umount: /logtail_host/var/lib/docker/overlay2/d5b10aa19399992755de1f85d25009528daa749c1bf8c16edff44beab6e69718/merged: must be superuser to unmount
      umount: /logtail_host/var/lib/docker/overlay2/5c3125daddacedec29df72ad0c52fac800cd56c6e880dc4e8a640b1e16c22dbe/merged: must be superuser to unmount
      ......
      xargs: umount: exited with status 255; aborting
      umount done
      start logtail
      ilogtail is running
      logtail status:
      ilogtail is running
    • 查看Kubernetes集群中日志服务相关组件的状态

      执行如下命令,查看名称为alibaba-log-controller的Deployment的状态和信息。

      kubectl get deploy alibaba-log-controller -n kube-system

      返回结果:

      NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
      alibaba-log-controller   1/1     1            1           11d

      执行以下命令,查看关于DaemonSet资源的状态信息。

      kubectl get ds logtail-ds -n kube-system

      返回结果:

      NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR  AGE
      logtail-ds   2         2         2       2            2           **ux           11d
    • 查看Logtail的版本号、IP地址、启动时间

      相关信息存储在Logtail容器的/usr/local/ilogtail/app_info.json文件中。

      kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

      系统将返回如下类似结果。

      {
         "UUID" : "",
         "hostname" : "logtail-****k",
         "instance_id" : "0EB****_172.20.4.2_1517810940",
         "ip" : "172.20.4.2",
         "logtail_version" : "0.16.2",
         "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
         "update_time" : "2018-02-05 06:09:01"
      }

Project无法删除?

问题现象

如何删除Project,或是在删除过程中遇到“权限不足”的错误提示时无法删除?

解决方案

删除Project或Logstore的步骤,请参见管理Project管理Logstore。如果无法删除,请参见删除Project时提示“操作拒绝,权限不足”

日志服务采集数据常见的错误类型

如果您遇到其他问题,请提交工单处理。

错误类型

错误说明

解决方法

LOG_GROUP_WAIT_TOO_LONG_ALARM

数据包从产生到发送的过程中等待的时间较长。

检查发送是否正常,或者是否存在数据量超过默认配置、配额不足或者网络存在问题。

LOGFILE_PERMINSSION_ALARM

Logtail无权限读取指定文件。

检查服务器Logtail的启动账号,建议以root方式启动。

SPLIT_LOG_FAIL_ALARM

行首正则与日志行首匹配失败,无法对日志做分行。

检查行首正则正确性。

如果是单行日志可以配置为.*

MULTI_CONFIG_MATCH_ALARM

默认情况下,一个文件只能匹配一个Logtail配置。当多个Logtail配置匹配同一个文件时,只会生效一个。

说明

Docker标准输出可以被多个Logtail配置采集。

REGEX_MATCH_ALARM

完整正则模式下,日志内容和正则表达式不匹配。

复制错误信息中的日志样例,并生成新的正则表达式。

PARSE_LOG_FAIL_ALARM

JSON、分隔符等模式下,由于日志格式不符合定义而解析失败。

单击错误信息,查看失败的详细报错。

CATEGORY_CONFIG_ALARM

Logtail采集配置不合法。

常见的错误为正则表达式提取文件路径作为Topic失败,其它错误请提交工单

LOGTAIL_CRASH_ALARM

Logtail因超过服务器资源使用上限而崩溃。

修改CPU、内存使用上限。更多信息,请参见设置Logtail启动参数

REGISTER_INOTIFY_FAIL_ALARM

在Linux系统中注册日志监听失败,可能由于没有文件夹权限或文件夹被删除。

检查Logtail是否有权限访问该文件夹,或者该文件夹是否被删除。

DISCARD_DATA_ALARM

配置Logtail使用的CPU资源不够或网络发送流控。

修改CPU使用上限或网络发送并发限制。更多信息,请参见设置Logtail启动参数

SEND_DATA_FAIL_ALARM

  • 阿里云账号未创建AccessKey。

  • Logtail客户端所在机器与日志服务无法连通或者网络链路质量较差。

  • 日志服务端写入配额不足。

  • 使用阿里云账号创建AccessKey。

  • 检查本地配置文件/usr/local/ilogtail/ilogtail_config.json,执行curl <服务器地址>,查看是否有内容返回。

  • 为Logstore增加Shard数量,以支持更大数据量的写入。

REGISTER_INOTIFY_FAIL_ALARM

Logtail为日志目录注册的inotify watcher失败。

检查目录是否存在以及目录权限设置。

SEND_QUOTA_EXCEED_ALARM

日志写入流量超出限制。

在控制台上增加Shard数量。更多信息,请参见分裂Shard

READ_LOG_DELAY_ALARM

日志采集进度落后于日志产生进度,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。

修改CPU使用上限或网络发送并发限制。更多信息,请参见设置Logtail启动参数

在导入历史数据时,短时间内会采集大量数据,因此出现该错误可暂时忽略。

DROP_LOG_ALARM

日志采集进度落后于日志产生进度,且未处理的日志轮转超过20个,一般是由于配置Logtail使用的CPU资源不够或是网络发送流控导致。

修改CPU使用上限或网络发送并发限制。更多信息,请参见设置Logtail启动参数

LOGDIR_PERMINSSION_ALARM

没有日志监控目录读取权限。

检查日志监控目录是否存在。如果存在,请检查目录权限设置。

ENCODING_CONVERT_ALARM

编码转换失败。

检查日志编码格式配置是否与日志编码格式一致。

OUTDATED_LOG_ALARM

过期的日志,日志时间落后超过12小时。可能原因:

  • 日志解析进度落后超过12小时。

  • 用户自定义时间字段配置错误。

  • 日志记录程序时间输出异常。

  • 查看是否存在READ_LOG_DELAY_ALARM。

    如果存在,按照READ_LOG_DELAY_ALARM处理方式解决;如果不存在,请检查时间字段配置。

  • 检查时间字段配置。如果时间字段配置正确,请检查日志记录程序时间输出是否正常。

STAT_LIMIT_ALARM

日志采集配置目录中的文件数超限。

检查采集的目标目录下是否有较多的文件和子目录,合理设置监控的根目录和目录最大监控深度。

您也可以修改mem_usage_limit参数。更多信息,请参见设置Logtail启动参数

DROP_DATA_ALARM

进程退出时日志落盘到本地超时,此时会丢弃未落盘完成的日志。

该报错通常为采集严重阻塞导致。您可以修改CPU使用上限或网络发送并发限制。更多信息,请参见设置Logtail启动参数

INPUT_COLLECT_ALARM

输入源采集异常。

根据错误提示处理。

HTTP_LOAD_ADDRESS_ALARM

HTTP数据采集配置中,设置的Addresses不合法。

检查Addresses合法性。

HTTP_COLLECT_ALARM

HTTP数据采集异常。

根据错误提示排查,一般由于超时导致。

FILTER_INIT_ALARM

过滤器初始化异常。

一般由于过滤器的正则表达式非法导致,请根据提示修复。

INPUT_CANAL_ALARM

MySQL Binlog运行异常。

根据错误提示排查。

在配置更新时,canal服务可能重启,服务重启的错误可以忽略。

CANAL_INVALID_ALARM

MySQL Binlog内部状态异常。

此错误一般由于运行时表的schema信息变更导致meta不一致。请确认报错期间是否修改过表的schema。其他情况,请提交工单

MYSQL_INIT_ALARM

MySQL初始化异常。

根据错误提示处理。

MYSQL_CHECKPOING_ALARM

MySQL Checkpoint格式异常。

确认是否修改该配置中的Checkpoint相关配置。其他情况,请提交工单

MYSQL_TIMEOUT_ALARM

MySQL查询超时。

确认MySQL服务器和网络是否异常。

MYSQL_PARSE_ALARM

MySQL查询结果解析失败。

确认MySQL配置的Checkpoint格式是否匹配对应字段的格式。

AGGREGATOR_ADD_ALARM

向队列中添加数据失败。

由于数据发送过快。如果真实数据量很大,则可忽略。

ANCHOR_FIND_ALARM

processor_anchor插件错误、配置错误或存在不符合配置的日志。

单击错误查看详细报错,报错根据内容分为如下类型。请根据详细报错中的信息,检查相应的配置是否存在问题。

  • anchor cannot find key:配置中指定了SourceKey但日志中不存在对应的字段。

  • anchor no start:无法从SourceKey的值中找到Start对应的内容。

  • anchor no stop:无法从SourceKey的值中找到Stop对应的内容。

ANCHOR_JSON_ALARM

processor_anchor插件错误,对已配置的StartStop所确定的内容执行JSON展开时发生错误。

单击错误查看详细报错,检查所处理的内容以及相关的配置,确定是否有配置错误或不合法日志。

CANAL_RUNTIME_ALARM

Binlog插件运行时错误。

单击错误查看详细报错,根据错误信息进行进一步地排查。一般情况下,该错误与所连接的MySQL master相关。

CHECKPOINT_INVALID_ALARM

Checkpoint解析失败。

单击错误查看详细报错,根据其中的检查点键、检查点内容(前1024个字节)以及具体的错误信息进行进一步排查。

DIR_EXCEED_LIMIT_ALARM

Logtail同时监听的目录数超出限制。

检查当前Logstore的采集配置以及该Logtail上应用的其他配置是否会包含较多的目录数,合理设置监控的根目录和目录最大监控深度。

DOCKER_FILE_MAPPING_ALARM

执行Logtail命令添加Docker文件映射失败。

单击错误查看详细报错,根据其中的命令以及具体的错误信息进行进一步排查。

DOCKER_FILE_MATCH_ALARM

无法在Docker容器中查找到指定文件。

单击错误查看详细报错,根据其中的容器信息以及查找的文件路径进行进一步排查。

DOCKER_REGEX_COMPILE_ALARM

service_docker_stdout插件错误,根据配置中的BeginLineRegex编译失败。

单击错误查看详细报错,检查其中的正则表达式是否正确。

DOCKER_STDOUT_INIT_ALARM

service_docker_stdout插件初始化失败。

单击错误查看详细报错,报错根据内容分为如下类型。

  • host...version...error:检查配置中指定的Docker Engine是否可访问。

  • load checkpoint error:加载检查点失败,如无影响可忽略此错误。

  • container...:指定容器存在非法Label值,目前仅允许配置stdout和stderr。请结合详细错误进行检查。

DOCKER_STDOUT_START_ALARM

service_docker_stdout插件采集时,stdout大小超过限制。

一般由于首次采集时stdout已存在,可忽略。

DOCKER_STDOUT_STAT_ALARM

service_docker_stdout插件无法检测到stdout。

一般由于容器退出时无法访问到stdout,可忽略。

FILE_READER_EXCEED_ALARM

Logtail同时打开的文件对象数量超过限制。

一般由于当前处于采集状态的文件数过多,请检查采集配置是否合理。

GEOIP_ALARM

processor_geoip插件错误。

单击错误查看详细报错,报错根据内容分为如下类型。

  • invalid ip...:获取IP地址失败,请检查配置中的SourceKey是否正确或是否存在不合法日志。

  • parse ip...:根据IP地址解析城市失败,请查看详细错误信息进行排查。

  • cannot find key...:无法从日志中查看到指定的SourceKey,请检查配置是否正确或是否存在不合法日志。

HTTP_INIT_ALARM

metric_http插件错误,配置中指定的ResponseStringMatch正则表达式编译错误。

单击错误查看详细报错,检查其中的正则表达式是否正确。

HTTP_PARSE_ALARM

metric_http插件错误,获取HTTP响应失败。

单击错误查看详细报错,根据其中的具体错误信息对配置内容或所请求的HTTP服务器进行检查。

INIT_CHECKPOINT_ALARM

Binlog插件错误,加载检查点失败,插件将忽略检查点并从头开始处理。

单击错误查看详细报错,根据其中的具体错误信息来确定是否可忽略此错误。

LOAD_LOCAL_EVENT_ALARM

Logtail执行了本地事件处理。

此警告一般不会出现,如果非人为操作引起此警告,才需要进行错误排查。请单击错误查看详细报错,根据其中的文件名、配置名、project、logstore等信息进行进一步地排查。

LOG_REGEX_FIND_ALARM

processor_split_log_regex以及 processor_split_log_string插件错误,无法从日志中获取到配置中指定的SplitKey

单击错误查看详细报错,检查是否存在配置错误的情况。

LUMBER_CONNECTION_ALARM

service_lumberjack插件错误,停止插件时关闭服务器错误。

单击错误查看详细报错,根据其中的具体错误信息进行进一步排查,此错误一般可忽略。

LUMBER_LISTEN_ALARM

service_lumberjack插件错误,初始化进行监听时发生错误。

单击错误查看详细报错,报错根据内容分为如下类型。

  • init tls error...:请结合具体的错误信息检查TLS相关的配置是否正确

  • listen init error...:请结合具体的错误信息检查地址相关的配置是否正确。

LZ4_COMPRESS_FAIL_ALARM

Logtail执行LZ4压缩发生错误。

单击错误查看详细报错,根据其中的log lines、project、category、region等值来进行进一步排查。

MYSQL_CHECKPOINT_ALARM

MySQL插件错误,检查点相关错误。

单击错误查看详细报错,报错根据内容分为如下类型。

  • init checkpoint error...:初始化检查点失败,请根据错误信息检查配置指定的检查点列以及所获取的值是否正确。

  • not matched checkpoint...:检查点信息不匹配,请根据错误信息检查是否是由于配置更新等人为原因导致的错误,如果是则可忽略。

NGINX_STATUS_COLLECT_ALARM

nginx_status插件错误,获取状态发生错误。

单击错误查看详细报错,根据其中的URL以及具体的错误信息来进行进一步排查。

NGINX_STATUS_INIT_ALARM

nginx_status插件错误,初始化解析配置中指定的URL失败。

单击错误查看详细报错,根据其中的URL检查地址是否正确配置。

OPEN_FILE_LIMIT_ALARM

Logtail已打开文件数量超过限制,无法打开新的文件。

单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。

OPEN_LOGFILE_FAIL_ALARM

Logtail打开文件出错。

单击错误查看详细报错,根据其中的日志文件路径、Project、Logstore等信息进行进一步排查。

PARSE_DOCKER_LINE_ALARM

service_docker_stdout插件错误,解析日志失败。

单击错误查看详细报错,报错根据内容分为如下类型。

  • parse docker line error: empty line:日志为空。

  • parse json docker line error...:以JSON格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。

  • parse cri docker line error...:以CRI格式解析日志失败,请根据错误信息以及日志的前512个字节进行排查。

PLUGIN_ALARM

插件初始化及相关调用发生错误。

单击错误查看详细报错,报错根据内容分为如下类型,请根据具体的错误信息进行进一步排查。

  • init plugin error...:初始化插件失败。

  • hold on error...:暂停插件运行失败。

  • resume error...:恢复插件运行失败。

  • start service error...:启动 service input类型的插件失败。

  • stop service error...:停止 service input类型的插件失败。

PROCESSOR_INIT_ALARM

processor_regex插件错误,编译配置中指定的Regex正则表达式失败。

单击错误查看详细报错,检查其中的正则表达式是否正确。

PROCESS_TOO_SLOW_ALARM

Logtail日志解析速度过慢。

  1. 单击错误查看详细报错,根据其中的日志数量、缓冲区大小、解析时间来确定是否正常。

  2. 如果不正常,检查Logtail所在节点是否有其他进程占用了过多的CPU资源或是存在效率较低的正则表达式等不合理的解析配置。

REDIS_PARSE_ADDRESS_ALARM

redis插件错误,配置中提供的ServerUrls存在解析失败的情况。

单击错误查看详细报错,对其中报错的URL进行检查。

REGEX_FIND_ALARM

processor_regex插件错误,无法从日志中找到配置中SourceKey指定的字段。

单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。

REGEX_UNMATCHED_ALARM

processor_regex插件错误,匹配失败。

单击错误查看详细报错,报错根据内容分为如下类型,请根据具体的错误信息进行排查。

  • unmatch this log content...:日志无法匹配配置中的正则表达式

  • match result count less...:匹配的结果数量少于配置中指定的 Keys 数量。

SAME_CONFIG_ALARM

同一个Logstore下存在同名的配置,后发现的配置会被抛弃。

单击错误查看详细报错,根据其中的配置路径等信息排查是否存在配置错误的情况。

SPLIT_FIND_ALARM

split_char以及split_string插件错误,无法从日志中找到配置中SourceKey指定的字段。

单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。

SPLIT_LOG_ALARM

processor_split_char以及processor_split_string插件错误,解析得到的字段数量与SplitKeys中指定的不相同。

单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。

STAT_FILE_ALARM

通过LogFileReader对象进行文件采集时发生错误。

单击错误查看详细报错,根据其中的文件路径、错误信息进行进一步排查。

SERVICE_SYSLOG_INIT_ALARM

service_syslog插件错误,初始化失败。

单击错误查看详细报错,检查配置中的Address是否正确。

SERVICE_SYSLOG_STREAM_ALARM

service_syslog插件错误,通过TCP采集时发生错误。

单击错误查看详细报错,报错根据内容分为如下类型,请根据详细报错中的具体错误信息进行排查。

  • accept error...:执行Accept时发生错误,插件将等待一段时间后重试。

  • setKeepAlive error...:设置 Keep Alive失败,插件将跳过此错误并继续运行。

  • connection i/o timeout...:通过TCP读取时超时,插件将重设超时并继续读取。

  • scan error...:TCP 读取错误,插件将等待一段时间后重试。

SERVICE_SYSLOG_PACKET_ALARM

service_syslog插件错误,通过UDP采集时发生错误。

单击错误查看详细报错,报错根据内容分为如下类型,请根据详细报错中的具体错误信息进行排查。

  • connection i/o timeout...:通过UDP读取时超时,插件将重设超时并继续读取。

  • read from error...:UDP读取错误,插件将等待一段时间后重试。

PARSE_TIME_FAIL_ALARM

解析日志时间失败。

您可以通过以下两种方法定位及解决问题:

  • 正则表达式提取的时间字段是否正确。

  • 指定的时间字段内容是否匹配配置中的时间表达式。

应用监控

为什么ACK集群应用安装探针后没有监控数据?

问题原因

  1. 应用监控被暂停。

  2. 应用所在pod的探针没有被正确加载。

解决方案

  1. 检查应用监控是否被暂停

    1. 登录ARMS控制台,在左侧导航栏选择应用监控 > 应用列表

    2. 应用列表页面顶部选择目标地域,然后单击目标应用名称。

      如果未找到目标应用,请参考步骤二继续排查。

    3. 新版控制台请在上方导航栏选择应用配置 > 自定义配置,在探针开关设置区域确认是否暂停应用监控。

      • 如果暂停应用监控开关被开启,请关闭开关,然后单击保存

      • 如果暂停应用监控开关保持关闭,请参考步骤二继续排查。

    4. 旧版控制台请在左侧导航栏中单击应用设置,然后在右侧页面单击自定义配置页签。在Agent开关配置区域确认Agent总开关是否开启。

      • 如果Agent总开关未开启,请打开Agent总开关,然后单击页面底部的保存

      • 如果Agent总开关已开启,请参考步骤二继续排查。

  2. 检查探针是否被正确加载。

    1. 登录容器服务管理控制台,在集群列表页面,单击目标集群名称进入集群详情页。

    2. 在左侧导航栏选择工作负载 > 容器组

    3. 容器组页面顶部选择您的应用所在的命名空间,然后单击目标应用右侧单击YAML 编辑

    4. 编辑YAML对话框中查看YAML文件中是否存在initContainers。

      db_am_ack_apppod_yaml

      • 如果不存在,则说明未被注入one-pilot-initcontainer,执行步骤5

      • 如果存在,则说明已被注入one-pilot-initcontainer,执行步骤8

    5. 工作负载 > 容器组页面顶部选择命名空间为ack-onepilot。查看Pod列表中是否存在名称前缀为ack-onepilot的Pod,且ack-onepilot的所有Pod均已滚动更新完毕。

    6. 工作负载下的无状态有状态页面目标应用右侧操作列中选择image > YAML 编辑,在编辑YAML对话框查看YAML文件中的spec.template.metadata层级下是否存在以下Labels注解。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<your-deployment-name>"    # 请将<your-deployment-name>替换为您的应用名称。
        armsSecAutoEnable: "on"    # 如果需要接入应用安全,则需要配置此参数。
      • 如果存在,则执行步骤7

      • 如果不存在,则在编辑YAML对话框中的spec.template.metadata层级下添加以上Labels注解,然后单击更新

    7. 工作负载 > 容器组页面目标应用右侧选择更多 > 日志,查看ack-onepilot的Pod日志是否报STS错误,即提示"Message":"STS错误"

    8. 工作负载 > 容器组页面目标应用右侧单击YAML 编辑,在编辑YAML对话框中查看YAML文件中是否存在以下javaagent参数。

      -javaagent:/home/admin/.opt/ArmsAgent/aliyun-java-agent.jar
      说明

      如果您使用的探针版本在2.7.3.5以下,请将本文中的aliyun-java-agent.jar替换为arms-bootstrap-1.7.0-SNAPSHOT.jar。建议您尽快将探针升级至最新版本。

      • 如果存在,则单击容器组页面右侧的终端进入命令行页面,执行以下命令查看是否存在以.log为后缀的日志文件,然后提交工单

        cd /home/admin/.opt/ArmsAgent/logs
      • 如果不存在,请提交工单

集群中不存在ARMS Addon Token

问题现象

目标集群中不存在ARMS Addon Token。

  1. 登录容器服务管理控制台,在集群列表页面,单击目标集群名称进入集群详情页。

  2. 在左侧导航栏选择配置管理 > 保密字典

  3. 在顶部选择命名空间kube-system,查看addon.arms.token是否存在。

    ARMS Addon Token

解决方案

为容器服务Kubernetes版授予ARMS资源的访问权限。

手动添加权限策略。

  1. 登录容器服务管理控制台,在集群列表页面单击目标集群名称。

  2. 集群信息 > 基本信息页签的集群资源区域,单击Worker RAM角色右侧的链接。

  3. 权限管理页签单击新增授权

  4. 新增授权面板添加以下两个权限策略,然后单击确认新增授权

    • AliyunTracingAnalysisFullAccess:可观测链路 OpenTelemetry 版的完整权限。

    • AliyunARMSFullAccess:ARMS的完整权限。

为什么应用更换了集群或Namespace后监控数据异常?

问题现象

  • 使用指标自定义大盘,更换了Namespace后应用名称前面的Namespace没有同步更新。

    image.png

  • 应用更换了集群后,RED指标正常展示,但是容器监控下的CPU、内存无数据。

可能原因

Namespace、ClusterId这些容器相关的信息在应用创建时写入配置,且该部分配置信息目前并无自动刷新逻辑,当更换集群或者调整Namespace后会影响容器相关数据的查询和展示。

解决方案

  • 删除应用后,新建应用重新上报监控数据。具体操作,请参见删除应用

    该方式会导致历史数据丢失。

  • 提交工单。

如何自定义Java探针挂载路径

问题背景

在标准部署场景中,ack-onepilot 组件会通过注入 JAVA_TOOL_OPTIONS 环境变量指定 Java 探针(Agent)的挂载路径。但在某些场景下,用户可能需要自定义探针挂载路径以满足特定需求:

  • 统一配置管理

    需通过 Kubernetes ConfigMap 集中管理探针路径,实现多环境配置一致性。

  • 持久化存储需求

    企业安全规范或运维要求将探针文件存储在自定义持久化卷(PVC)中。

解决方案

自定义Java探针挂载路径对 ack-onepilot 与 Java 探针版本要求如下:

重要

ack-onepilot组件由 MSE 和 ARMS 共用,因此自定义 Java 探针挂载路径对于 MSE 服务治理应用同样生效。

  1. 为需要自定义挂载Java探针的Kubernetes工作负载(如Kubernetes Deployment)添加disableJavaToolOptionsInjection注解。

    添加该注解后ack-onepilot组件将不会通过JAVA_TOOL_OPTIONS环境变量自动指定Java探针的挂载路径及其他JVM参数。

    1. 执行以下命令查看目标无状态(Deployment)应用的YAML文件。

      kubectl get deployment {deployment名称} -o yaml
      说明

      若您不清楚{deployment名称},请先执行以下命令查看所有无状态(Deployment)应用,在执行结果中找到目标无状态(Deployment)应用,再查看目标无状态(Deployment)应用的YAML文件。

      kubectl get deployments --all-namespace
    2. 启动编辑目标无状态(Deployment)应用的YAML文件。

      kubectl edit deployment {Deployment名称} -o yaml
    3. 在YAML文件中的spec.template.metadata层级下添加以下内容。

      labels:
        armsPilotAutoEnable: "on"
        armsPilotCreateAppName: "<your-deployment-name>"    # 请将<your-deployment-name>替换为您的应用名称。
        disableJavaToolOptionsInjection: "true" # 如需自定义Java探针挂载路径,请将此开关设为true。
  2. 在您的应用启动脚本或Java启动命令中自行添加ARMS Java探针的挂载路径。

    其中,/home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar为探针默认挂载路径,请将该路径替换为需要自定义挂载的路径。

    java -javaagent:/home/admin/.opt/AliyunJavaAgent/aliyun-java-agent.jar ... ... -jar xxx.jar

    其余的重要信息,如上报Region、上报License Key等信息将由ack-onepilot通过环境变量的方式注入。

ACK集群如何跨区域上报数据?

问题现象

如果您需要在A区域跨区域向B区域上报数据,该如何处理?

解决方案

  1. 将ack-onepilot组件升级至4.0.0或以上版本。

  2. 在目标容器集群ack-onepilot命名空间下的ack-onepilot-ack-onepilot应用中添加ARMS_REPORT_REGION环境变量,值为ARMS所支持的RegionId(例如cn-hangzhou、cn-beijing)。

  3. 重启现有应用或部署一个新的应用,完成跨区域上报。

    说明

    当添加环境变量后,该集群下所有应用均会跨区域上报到上一步中指定地域。

如何卸载arms-pilot和安装ack-onepilot

问题背景

ACK旧版应用监控组件arms-pilot已不再维护,您可以安装升级后的ack-onepilot组件用于监控您的应用,ack-onepilot完全兼容arms-pilot,您无需修改应用配置即可无缝接入ack-onepilot。本文介绍如何卸载arms-pilot和安装ack-onepilot。

解决方案

  • 低于1.16版本的ACK集群无法安装ack-onepilot组件,请先升级集群版本。具体操作,请参见升级ACK集群K8s版本

  • 同时安装ack-onepilot和arms-pilot会导致探针挂载失败,因此,请卸载arms-pilot后再安装ack-onepilot。

  • 在卸载和安装的过程中,arms-pilot组件修改的配置无法自动继承到ack-onepilot中,请保存相关参数并在安装ack-onepilot后重新进行配置。

  • 需要等待arms-pilot组件卸载干净,才能安装ack-onepilot,否则ack-onepilot可能会认为环境中已经存在arms-pilot而不工作。

  1. 卸载arms-pilot

    1. 登录容器服务管理控制台,在集群列表页面单击目标集群名称。

    2. 在左侧导航栏选择应用 > Helm

    3. Helm页面的arms-pilot右侧操作列,单击删除

    4. 删除应用对话框单击确定

  2. 检查arms-pilot是否已卸载。

    进入容器服务管理控制台目标集群下的工作负载 > 无状态页面,在页面顶部选择命名空间arms-pilot,确认该命名空间下的Pod已经被删除。

    说明

    如果您修改了arms-pilot组件所在的命名空间,此处请选择对应命名空间。

  3. 安装ack-onepilot

    1. 登录容器服务管理控制台,在集群列表页面单击目标集群名称。

    2. 在左侧导航栏单击组件管理,然后通过关键字搜索ack-onepilot

    3. ack-onepilot卡片上单击安装

      说明

      ack-onepilot组件默认支持1000个pod规模,集群pod每超过1000个,ack-onepilot资源对应的CPU请增加0.5核、内存请增加512 MB。

    4. 在弹出的页面中可以配置相关的参数,建议使用默认值,单击确定

      说明

      安装完成后,您可以在组件管理页面升级、配置或卸载ack-onepilot组件。

  4. 检查ack-onepilot是否已安装

    进入容器服务管理控制台目标集群下的工作负载 > 无状态页面,在页面顶部选择命名空间ack-onepilot,确认该命名空间下的pod已在运行中。

    image

阿里云Prometheus监控

Prometheus监控页面显示未找到相关监控大盘

问题现象

如果您开启阿里云Prometheus监控后,在容器服务管理控制台运维管理 > Prometheus监控页面上,看到未找到相关监控大盘的提示,按照以下操作步骤解决。

image

解决方案

  1. 重新安装Prometheus监控组件。

    1. 卸载组件:

      1. 登录容器服务管理控制台,在左侧导航栏选择集群列表

      2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理

      3. 组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。单击卸载,然后在弹框中单击确认

    2. 重新安装组件:

      1. 确认卸载完成后,单击安装,然后在弹框中单击确认

      2. 等待安装完成后。返回到Prometheus监控页面查看问题是否已解决。

        如果问题仍未解决,请继续以下操作。

  2. 检查Prometheus实例接入。

    1. 登录ARMS控制台

    2. 在左侧导航栏,单击接入管理

    3. 已接入环境页签,查看容器环境列表,确认是否存在与集群名称相同的容器环境。

如果以上步骤未解决问题,请提交工单联系技术支持。

为什么可观测监控Prometheus版数据异常无法显示?

问题原因

可观测监控 Prometheus 版数据异常无法显示,可能是因为同步阿里云Prometheus云端服务时任务未成功,导致资源注册失败,或者由于Prometheus实例未正确接入。请按照以下流程检查并解决问题。

解决方案

  1. 检查接入可观测监控 Prometheus 版任务状态。

    1. 登录容器服务管理控制台,在左侧导航栏选择集群列表

    2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,选择工作负载 > 任务

    3. 任务页面顶部设置命名空间arms-prom,然后单击o11y-init-environment查看任务状态是否成功。

      若未成功,则可能是同步阿里云Prometheus云端服务并注册资源失败。可以通过查看其Pod日志获取具体失败原因,详情请参见Pod异常问题排查

      如果Pod已不存在,请按以下步骤继续操作。

  2. 重新安装Prometheus监控组件。

    1. 卸载组件:

      1. 登录容器服务管理控制台,在左侧导航栏选择集群列表

      2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理

      3. 组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。单击卸载,然后在弹框中单击确认

    2. 重新安装组件:

      1. 确认卸载完成后,单击安装,然后在弹框中单击确认

      2. 等待安装完成后。返回到Prometheus监控页面查看问题是否已解决。

        如果问题仍未解决,请继续以下操作。

  3. 检查Prometheus实例接入。

    1. 登录ARMS控制台

    2. 在左侧导航栏,单击接入管理

    3. 已接入环境页签,查看容器环境列表,确认是否存在与集群名称相同的容器环境。

如果以上步骤未解决问题,请提交工单联系技术支持获取帮助。

阿里云Prometheus监控无法重新安装出现报错“rendered manifests contain a resource that already exists”

问题现象

卸载可观测监控 Prometheus 版后,重新安装可观测监控 Prometheus 版时,出现以下报错信息。

rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: ClusterRole, namespace: , name: arms-pilot-prom-k8s

image

问题原因

通过命令手动删除arms-prom后,可能会存在角色等资源残留。

解决方案

  1. 执行以下命令,找到arms-prometheus的ClusterRole。

    kubectl get ClusterRoles --all-namespaces | grep prom

  2. 执行以下命令,删除上一步查询的ClusterRole。

     kubectl delete ClusterRole [$Cluster_Roles] -n arms-prom
    说明

    [$Cluster_Roles] 为上一步查询的ClusterRole。

  3. 如果删除后依然报错,需要查看报错信息中的kind值,查看是否存在ClusterRole以外的其他资源残留,使用类似方法,依次删除即可。

如何查看ack-arms-prometheus组件版本?

问题背景

您需要查看集群中部署的ack-arms-prometheus组件版本以及是否需要更新。

解决方案

  1. 登录容器服务管理控制台,在左侧导航栏选择集群列表

  2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理

  3. 组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。

    在组件下方显示当前版本信息,如有新版本需要升级,可单击版本右侧升级完成组件升级。

    说明

    当已安装的组件版本不是最新版本时,才会显示升级操作。

为什么GPU监控无法部署?

问题原因

如果您的GPU节点上存在污点,可能导致GPU监控无法部署。您可以通过以下步骤查看GPU节点的污点情况。

解决方案

  1. 执行以下命令,查看目标GPU节点的污点情况。

    如果您的GPU节点拥有自定义的污点,可找到污点相关的条目。本文以keytest-keyvaluetest-valueeffectNoSchedule为例说明:

    kubectl describe node cn-beijing.47.100.***.***

    预期输出:

    Taints:test-key=test-value:NoSchedule
  2. 通过以下两种方式处理GPU节点的污点。

    • 执行以下命令,删除GPU节点的污点。

      kubectl taint node cn-beijing.47.100.***.*** test-key=test-value:NoSchedule-
    • 对GPU节点的污点进行容忍度声明,允许Pod调度到该污点的节点上。

      # 1.执行以下命令,编辑ack-prometheus-gpu-exporter。
      kubectl edit daemonset -n arms-prom ack-prometheus-gpu-exporter
      
      # 2. 在YAML中添加如下字段,声明对污点的容忍度。
      #省略其他字段。
      #tolerations字段添加在containers字段上面,且与containers字段同级。
      tolerations:
      - key: "test-key"
        operator: "Equal"
        value: "test-value"
        effect: "NoSchedule"
      containers:
       #省略其他字段。

手动删除资源或将导致重新安装阿里云Prometheus失败,如何完整地手动删除ARMS-Prometheus?

问题背景

只删除阿里云Prometheus的命名空间,会导致资源删除后有残留配置,影响再次安装。您可以执行以下操作,完整地手动删除ARMS-Prometheus残余配置。

解决方案

  • 删除arms-prom命名空间。

    kubectl delete namespace arms-prom
  • 删除ClusterRole。

    kubectl delete ClusterRole arms-kube-state-metrics
    kubectl delete ClusterRole arms-node-exporter
    kubectl delete ClusterRole arms-prom-ack-arms-prometheus-role
    kubectl delete ClusterRole arms-prometheus-oper3
    kubectl delete ClusterRole arms-prometheus-ack-arms-prometheus-role
    kubectl delete ClusterRole arms-pilot-prom-k8s
    kubectl delete ClusterRole gpu-prometheus-exporter
    kubectl delete ClusterRole o11y:addon-controller:role
    kubectl delete ClusterRole arms-aliyunserviceroleforarms-clusterrole
  • 删除ClusterRoleBinding。

    kubectl delete ClusterRoleBinding arms-node-exporter
    kubectl delete ClusterRoleBinding arms-prom-ack-arms-prometheus-role-binding
    kubectl delete ClusterRoleBinding arms-prometheus-oper-bind2
    kubectl delete ClusterRoleBinding arms-kube-state-metrics
    kubectl delete ClusterRoleBinding arms-pilot-prom-k8s
    kubectl delete ClusterRoleBinding arms-prometheus-ack-arms-prometheus-role-binding
    kubectl delete ClusterRoleBinding gpu-prometheus-exporter
    kubectl delete ClusterRoleBinding o11y:addon-controller:rolebinding
    kubectl delete ClusterRoleBinding arms-kube-state-metrics-agent
    kubectl delete ClusterRoleBinding arms-node-exporter-agent
    kubectl delete ClusterRoleBinding arms-aliyunserviceroleforarms-clusterrolebinding
  • 删除Role及RoleBinding。

    kubectl delete Role arms-pilot-prom-spec-ns-k8s
    kubectl delete Role arms-pilot-prom-spec-ns-k8s -n kube-system
    kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s
    kubectl delete RoleBinding arms-pilot-prom-spec-ns-k8s -n kube-system

手动删除ARMS-Prometheus资源后,请在容器服务管理控制台运维管理>组件管理中,重新安装ack-arms-prometheus组件。

安装ack-arms-prometheus组件时报错xxx in use

问题原因

当您部署ack-arms-prometheus 组件时,报错提示“xxx in use”,应该是存在资源被占用或残留的问题,导致组件安装失败。

解决方案

  1. 登录容器服务管理控制台,在左侧导航栏单击集群列表

  2. 集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情

  3. 在集群管理页面左侧导航栏选择应用 > Helm,检查是否存在ack-arms-prometheus。

    • 存在:在Helm页面删除ack-arms-prometheus,并在组件管理页面重新安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件

    • 不存在:

      1. 若没有ack-arms-prometheus,表明删除ack-arms-prometheus helm有资源残留,需要手动清理。关于删除ack-arms-prometheus残留资源的具体操作,请参见阿里云Prometheus监控常见问题

      2. 组件管理页面安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件

      3. 执行以上步骤,如果仍无法安装ack-arms-prometheus,请提交工单

提示Component Not Installed后继续安装ack-arms-prometheus组件,安装失败

问题现象

尝试安装 ack-arms-prometheus 组件时,先出现“Component Not Installed”提示,再次尝试安装时仍然失败。

解决方案

  • 检查是否已经安装ack-arms-prometheus组件。

    1. 登录容器服务管理控制台,在左侧导航栏单击集群列表

    2. 集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情

    3. 在集群管理页面左侧导航栏选择应用>Helm

      Helm页面检查是否存在ack-arms-prometheus组件。

      • 已有ack-arms-prometheus:在Helm页面删除ack-arms-prometheus,并在组件管理页面重新安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件

      • 没有ack-arms-prometheus组件:需进行以下操作。

        1. 若没有ack-arms-prometheus,说明删除ack-arms-prometheus helm有资源残留,需要手动清理。关于删除ack-arms-prometheus残留资源的具体操作,请参见阿里云Prometheus监控常见问题

        2. 组件管理页面安装ack-arms-prometheus。操作入口,请参见管理组件

        3. 执行以上步骤,仍无法安装ack-arms-prometheus,请提交工单

  • 检查ack-arms-prometheus的日志是否有报错。

    1. 登录容器服务管理控制台,在左侧导航栏单击集群列表

    2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,选择工作负载 > 无状态

    3. 无状态页面顶部设置命名空间arms-prom,然后单击arms-prometheus-ack-arms-prometheus。

    4. 单击日志页签,查看日志中是否有报错。

      若日志中出现报错,请提交工单

  • 检查Agent是否安装报错。

    1. 登录ARMS控制台

    2. 在左侧导航栏,单击接入管理

    3. 已接入环境页签,查看容器环境列表,单击目标容器环境操作列的探针设置,进入探针设置页面。

    4. 检查安装探针是否正常运行。若有报错,请提交工单

开源Prometheus监控

如何配置钉钉告警通知?

问题现象

在部署开源 Prometheus 后,您需要配置通过钉钉发送告警通知。

解决方案

  1. 获取钉钉的webhook地址。请参见事件监控

  2. 找到dingtalk字段,将enabled设置为true,将Token字段填入钉钉的webhook地址。请参见告警配置中的钉钉告警配置

部署prometheus-operator时报错

问题现象

Can't install release with errors: rpc error: code = Unknown desc = object is being deleted: customresourcedefinitions.apiextensions.k8s.io "xxxxxxxx.monitoring.coreos.com" already exists

解决方案

在卸载prometheus-operator的时候没有将上一次部署的自定义资源(CRD)及时清理掉,执行如下命令,删除CRD并重新部署。

kubectl delete crd prometheuses.monitoring.coreos.com
kubectl delete crd prometheusrules.monitoring.coreos.com
kubectl delete crd servicemonitors.monitoring.coreos.com
kubectl delete crd alertmanagers.monitoring.coreos.com

邮件告警没有生效

问题现象

在部署开源 Prometheus 后,您配置的邮件告警没有发送告警通知。

解决方案

邮件告警没有生效,有可能是因为smtp_auth_password填写的是您的登录密码,而非授权码。另外SMTP的服务器地址需要加端口号。

单击YAML更新,出现“集群无法访问,请重试或提交工单反馈”

问题现象

在部署开源 Prometheus 后,当您单击YAML更新时,出现"当前集群暂时无法访问,请稍后重试或提交工单反馈" 报错

解决方案

此问题原因是tiller的配置文件过大,导致的集群无法访问,您可以先将部分注释删除,再将配置文件以ConfigMap形式,挂载到pod中,目前prometheus-operator只支持prometheus和alertmanager pod的挂载,详情请参见Prometheus挂载自定义ConfigMap中的方法二。

部署prometheus-operator后,如何开启其中的功能

问题现象

在部署开源 Prometheus 后,您可能需要进一步配置以启用其中功能。

解决方案

当部署好prometheus-operator后,如果要开启部分功能,在集群信息页面,选择应用 > Helm,在ack-prometheus-operator右侧,单击更新,找到对应的开关,进行相应的设置,然后单击确定开启您想要的功能。

TSDB和阿里云云盘如何选择

问题现象

在选择存储方案时,如何选择 TSDB和阿里云云盘,并且如何配置数据回收策略。

解决方案

TSDB支持的地域比较少,而阿里云云盘是全域支持,数据回收策略请参见以下配置。数据回收策略

Grafana Dashboard显示有问题

问题现象

在部署开源 Prometheus 后,Grafana Dashboard看板显示有问题。

解决方案

在集群信息页面选择应用 > Helm,在ack-prometheus-operator右侧,单击更新,查看clusterVersion的值是否为正确的集群版本。Kubernetes集群是1.16以前的版本,这里请填写1.14.8-aliyun.1,1.16及以后的版本,请填写1.16.6-aliyun.1。

删除ack-prometheus-operator的命名空间后,重新安装ack-prometheus-operator失败

问题原因

只删除ack-prometheus的命名空间,会导致资源删除后有残留配置,影响再次安装。您可以执行以下操作,删除残余配置。

解决方案

  1. 删除RBAC权限。

    1. 删除ClusterRole。

      kubectl delete ClusterRole ack-prometheus-operator-grafana-clusterrole
      kubectl delete ClusterRole ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRole psp-ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRole psp-ack-prometheus-operator-prometheus-node-exporter
      kubectl delete ClusterRole ack-prometheus-operator-operator
      kubectl delete ClusterRole ack-prometheus-operator-operator-psp
      kubectl delete ClusterRole ack-prometheus-operator-prometheus
      kubectl delete ClusterRole ack-prometheus-operator-prometheus-psp
    2. 删除ClusterRoleBinding。

      kubectl delete ClusterRoleBinding ack-prometheus-operator-grafana-clusterrolebinding
      kubectl delete ClusterRoleBinding ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-kube-state-metrics
      kubectl delete ClusterRoleBinding psp-ack-prometheus-operator-prometheus-node-exporter
      kubectl delete ClusterRoleBinding ack-prometheus-operator-operator
      kubectl delete ClusterRoleBinding ack-prometheus-operator-operator-psp
      kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus
      kubectl delete ClusterRoleBinding ack-prometheus-operator-prometheus-psp
  2. 删除CRD。

    kubectl delete crd alertmanagerconfigs.monitoring.coreos.com
    kubectl delete crd alertmanagers.monitoring.coreos.com
    kubectl delete crd podmonitors.monitoring.coreos.com
    kubectl delete crd probes.monitoring.coreos.com
    kubectl delete crd prometheuses.monitoring.coreos.com
    kubectl delete crd prometheusrules.monitoring.coreos.com
    kubectl delete crd servicemonitors.monitoring.coreos.com
    kubectl delete crd thanosrulers.monitoring.coreos.com

服务报警管理

报警规则同步失败且报错信息为The Project does not exist : k8s-log-xxx

问题现象

报警中心中报警规则同步状态,提示The Project does not exist : k8s-log-xxx

问题原因

未创建SLS事件中心资源。

解决方案

  1. 日志服务管理控制台确认是否达到Quota上限。资源详情请参见基础资源

    1. 如果已达Quota上限,删除多余的Project,或提交工单申请扩大Project资源Quota限制。关于如何删除Project,请参见管理Project

    2. 如果未达上限,请进行以下操作步骤。

  2. 重新安装ack-node-problem-detector组件。

    重新安装组件,会重新创建默认的名为k8s-log-xxxxxx的Project。

    1. 卸载ack-node-problem-detector组件。

      1. 容器服务管理控制台目标集群管理页左侧导航栏中,选择运维管理 > 组件管理

      2. 单击日志与监控页签,在ack-node-problem-detector组件的卡片中单击卸载。然后在弹框中单击确认

    2. 待卸载完成后,安装ack-node-problem-detector组件。

      1. 在左侧导航栏,选择运维管理 > 报警配置

      2. 报警配置页面,单击开始安装,控制台会自动创建Project,安装组件、升级组件。

  3. 然后在报警配置页面,将对应的报警规则集右侧的启动状态关闭,等待其报警规则状态规则已关闭后,再启动重试。

报警规则同步状态失败出现类似报错信息this rule have no xxx contact groups reference

问题现象

报警规则同步状态失败出现类似报错信息this rule have no xxx contact groups reference

问题原因

报警规则无订阅的联系人组。

解决方案

  1. 已创建联系人,并将联系人加入联系人分组中。

  2. 在对应报警规则集右侧单击编辑通知对象,为该组报警规则配置订阅的联系人分组。

其他问题

kubectl top pod/node为什么全部没有数据?

问题现象

在命令行中执行kubectl top pod或者kubectl top node没有数据。

解决方案

  1. 执行以下命令,检查metrics-server的API Service是否正常。

    kubectl get apiservices | grep metrics-server

    metris

    返回结果中v1beta1.metrics.k8s.io显示True,说明metrics-server的API Service正常。

  2. 可选:如果metrics-server的API Service不正常,在集群节点上执行以下命令,检查metrics-server的443端口与8082端口是否可以在集群中正常访问。

    curl -v <metrics-server_Pod_IP>:8082/apis/metrics/v1alpha1/nodes
    
    curl -v <metrics-server_Pod_IP>:443/apis/metrics/v1alpha1/nodes

    执行以上命令,能正常返回数据,说明metrics-server的443端口与8082端口可以在集群中正常访问。

  3. 可选:如果metrics-server的443端口与8082端口无法在集群中正常访问,重启metrics-server。

    您可以通过删除metrics-server的Pod的方式重启metrics-server。

    1. 登录容器服务管理控制台,在左侧导航栏选择集群列表

    2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,选择工作负载 > 无状态

    3. 无状态页面顶部设置命名空间为kube-system,单击metrics-server。

    4. 容器组页签下,选择metrics-server的Pod操作列下的更多>删除,然后在对话框单击确定

按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单

工单模板:

  1. API Service是否正常?

  2. metrics-server 443与8082端口是否可达?

  3. 提供集群ID。

kubectl top pod/node为什么部分没有数据?

问题现象

在命令行中执行kubectl top pod或者kubectl top node部分没有数据。

解决方案

请按照以下方式进行预检查。

  • 检查是特定的节点上所有Pod无数据,还是特定的Pod无数据。如果是特定的节点上所有Pod无数据,请检查节点是否存在时区漂移,可以通过NTP服务器的date命令进行时区校验。

  • 检查metrics-server Pod到特定的Node的10255端口的网络连通性。

按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单

工单模板:

  1. 单个Node上的Pod是否全部无数据?

  2. 节点时区是否有漂移?

  3. metrics-server到指定节点的连通性是否可达?

HPA无法获取metrics数据怎么办?

问题现象

在使用 Kubernetes 的HPA(水平Pod自动扩缩器)时,您可能会遇到无法获取指标metrics数据的情况。

解决方案

请按照以下方式进行预检查。

检查对应的Pod执行kubectl top pod 的结果。如果数据异常,请参见kubectl top pod/node为什么全部没有数据?kubectl top pod/node为什么部分没有数据?的检查方法进行检查。

按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单

工单模板:

  1. 监控数据是否有异常?

  2. 执行kubectl describe hpa <hpa_name>,提交元数据信息。

滚动发布时为什么HPA额外弹出了多余的Pod?

问题现象

在进行 Kubernetes 滚动发布(Rolling Update)时,您可能会发现 HPA(水平Pod自动扩缩器)意外地启动了额外的 Pod。

解决方案

请按照以下方式进行预检查。

检查metrics-server是否升级到了最新的版本。如果版本没有问题,您可以使用kubectl edit deployments -n kube-system metrics-server命令,在command中加入以下启动参数。

--metric-resolution=15s
--enable-hpa-rolling-update-skipped=true

按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单

工单模板:

  1. 检查metrics-server的版本是否为最新?

  2. 检查配置参数是否已经增加防误弹能力?

  3. 执行kubectl describe hpa <hpa_name>,提交HPA的描述。