可观测性FAQ
分类 | 跳转链接 |
日志采集 | |
应用监控 | |
阿里云Prometheus监控 | |
开源Prometheus监控(ack-prometheus-operator组件) | |
服务报警管理 | |
其他问题 |
日志采集
如何排查容器日志采集异常?
问题现象
容器日志采集出现异常,导致无法上报新的日志内容。
解决方案
排查机器组心跳是否异常。
您可以通过检查机器组心跳的状态来判断容器中的Logtail是否已正确安装。
查看机器组心跳状态。
登录日志服务控制台。
在Project列表区域,单击目标Project。
在左侧导航栏中,选择 。
在机器组列表中,单击目标机器组。
在机器组配置页面,查看机器组状态并记录心跳状态为OK的节点数。
检查容器集群中Worker节点数。
连接集群。
执行如下命令,查看集群中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
对比心跳状态为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。
执行如下命令。如果存在返回结果,则表示您之前已使用YAML文件手动部署DaemonSet。
kubectl get po -n kube-system -l k8s-app=logtail
根据实际值,配置${your_region_name}、${your_aliyun_user_id}、${your_machine_group_name}等参数。
执行如下命令,更新文件。
kubectl apply -f ./logtail-daemonset.yaml
其他情况,请提交工单。
排查容器日志采集是否异常。
如果您在日志服务控制台的预览或Logstore查询页面未查到日志,则说明日志服务未采集到您的容器日志。请确认容器状态,然后执行如下检查。
查看机器组心跳是否存在异常。具体操作,请参见排查机器组心跳是否异常。
检查Logtail配置是否正确。
检查Logtail配置中的IncludeLabel、ExcludeLabel、IncludeEnv、ExcludeEnv等配置是否符合您的采集需求。
说明其中此处的Label为容器Label,即Docker inspect中的Label,不是Kubernetes中的Label。
您可以将IncludeLabel、ExcludeLabel、IncludeEnv和ExcludeEnv配置临时去除,查看是否可以正常采集到日志。如果可以,则说明是上述参数的配置存在问题。
其他运维操作。
查看Logtail的运行日志
Logtail日志存储在Logtail容器中的
/usr/local/ilogtail/
目录中,文件名为ilogtail.LOG
和logtail_plugin.LOG
。登录Logtail容器。具体操作,登录Logtail容器。
打开/usr/local/ilogtail/目录。
cd /usr/local/ilogtail
查看ilogtail.LOG和logtail_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配置采集。 |
详细的解决方案,请参见使用CloudLens排查iLogtail文件重复配置问题。 |
REGEX_MATCH_ALARM | 完整正则模式下,日志内容和正则表达式不匹配。 | 复制错误信息中的日志样例,并生成新的正则表达式。 |
PARSE_LOG_FAIL_ALARM | JSON、分隔符等模式下,由于日志格式不符合定义而解析失败。 | 单击错误信息,查看失败的详细报错。 |
CATEGORY_CONFIG_ALARM | Logtail采集配置不合法。 | 常见的错误为正则表达式提取文件路径作为Topic失败,其它错误请提交工单。 详细的解决方案,请参见使用CloudLens排查iLogtail采集配置错误问题。 |
LOGTAIL_CRASH_ALARM | Logtail因超过服务器资源使用上限而崩溃。 | 修改CPU、内存使用上限。更多信息,请参见设置Logtail启动参数。 |
REGISTER_INOTIFY_FAIL_ALARM | 在Linux系统中注册日志监听失败,可能由于没有文件夹权限或文件夹被删除。 | 检查Logtail是否有权限访问该文件夹,或者该文件夹是否被删除。 |
DISCARD_DATA_ALARM | 配置Logtail使用的CPU资源不够或网络发送流控。 | 修改CPU使用上限或网络发送并发限制。更多信息,请参见设置Logtail启动参数。 |
SEND_DATA_FAIL_ALARM |
|
|
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小时。可能原因:
|
|
STAT_LIMIT_ALARM | 日志采集配置目录中的文件数超限。 | 检查采集的目标目录下是否有较多的文件和子目录,合理设置监控的根目录和目录最大监控深度。 您也可以修改mem_usage_limit参数。更多信息,请参见设置Logtail启动参数。 详细的解决方案,请参见使用CloudLens排查文件、目录数超限问题(STAT_LIMIT_ALARM、 DIR_EXCEED_LIMIT_ALARM)。 |
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_JSON_ALARM | processor_anchor插件错误,对已配置的Start和Stop所确定的内容执行JSON展开时发生错误。 | 单击错误查看详细报错,检查所处理的内容以及相关的配置,确定是否有配置错误或不合法日志。 |
CANAL_RUNTIME_ALARM | Binlog插件运行时错误。 | 单击错误查看详细报错,根据错误信息进行进一步地排查。一般情况下,该错误与所连接的MySQL master相关。 |
CHECKPOINT_INVALID_ALARM | Checkpoint解析失败。 | 单击错误查看详细报错,根据其中的检查点键、检查点内容(前1024个字节)以及具体的错误信息进行进一步排查。 |
DIR_EXCEED_LIMIT_ALARM | Logtail同时监听的目录数超出限制。 | 检查当前Logstore的采集配置以及该Logtail上应用的其他配置是否会包含较多的目录数,合理设置监控的根目录和目录最大监控深度。 详细的解决方案,请参见使用CloudLens排查文件、目录数超限问题(STAT_LIMIT_ALARM、 DIR_EXCEED_LIMIT_ALARM)。 |
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插件初始化失败。 | 单击错误查看详细报错,报错根据内容分为如下类型。
|
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插件错误。 | 单击错误查看详细报错,报错根据内容分为如下类型。
|
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插件错误,初始化进行监听时发生错误。 | 单击错误查看详细报错,报错根据内容分为如下类型。
|
LZ4_COMPRESS_FAIL_ALARM | Logtail执行LZ4压缩发生错误。 | 单击错误查看详细报错,根据其中的log lines、project、category、region等值来进行进一步排查。 |
MYSQL_CHECKPOINT_ALARM | MySQL插件错误,检查点相关错误。 | 单击错误查看详细报错,报错根据内容分为如下类型。
|
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插件错误,解析日志失败。 | 单击错误查看详细报错,报错根据内容分为如下类型。
|
PLUGIN_ALARM | 插件初始化及相关调用发生错误。 | 单击错误查看详细报错,报错根据内容分为如下类型,请根据具体的错误信息进行进一步排查。
|
PROCESSOR_INIT_ALARM | processor_regex插件错误,编译配置中指定的Regex正则表达式失败。 | 单击错误查看详细报错,检查其中的正则表达式是否正确。 |
PROCESS_TOO_SLOW_ALARM | Logtail日志解析速度过慢。 |
|
REDIS_PARSE_ADDRESS_ALARM | redis插件错误,配置中提供的ServerUrls存在解析失败的情况。 | 单击错误查看详细报错,对其中报错的URL进行检查。 |
REGEX_FIND_ALARM | processor_regex插件错误,无法从日志中找到配置中SourceKey指定的字段。 | 单击错误查看详细报错,检查是否存在SourceKey配置错误或日志不合法的情况。 |
REGEX_UNMATCHED_ALARM | processor_regex插件错误,匹配失败。 | 单击错误查看详细报错,报错根据内容分为如下类型,请根据具体的错误信息进行排查。
|
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采集时发生错误。 | 单击错误查看详细报错,报错根据内容分为如下类型,请根据详细报错中的具体错误信息进行排查。
|
SERVICE_SYSLOG_PACKET_ALARM | service_syslog插件错误,通过UDP采集时发生错误。 | 单击错误查看详细报错,报错根据内容分为如下类型,请根据详细报错中的具体错误信息进行排查。
|
PARSE_TIME_FAIL_ALARM | 解析日志时间失败。 | 您可以通过以下两种方法定位及解决问题:
|
应用监控
为什么ACK集群应用安装探针后没有监控数据?
问题原因
应用监控被暂停。
应用所在pod的探针没有被正确加载。
解决方案
检查应用监控是否被暂停。
检查探针是否被正确加载。
登录容器服务管理控制台,在集群列表页面,单击目标集群名称进入集群详情页。
在左侧导航栏选择
。在容器组页面顶部选择您的应用所在的命名空间,然后单击目标应用右侧单击YAML 编辑。
在编辑YAML对话框中查看YAML文件中是否存在initContainers。
在
页面顶部选择命名空间为ack-onepilot。查看Pod列表中是否存在名称前缀为ack-onepilot的Pod,且ack-onepilot的所有Pod均已滚动更新完毕。如果存在,则执行步骤6。
如果不存在,则在应用市场中安装ack-onepilot。具体操作,请参见如何卸载arms-pilot和安装ack-onepilot。
在工作负载下的无状态或有状态页面目标应用右侧操作列中选择
,在编辑YAML对话框查看YAML文件中的spec.template.metadata层级下是否存在以下Labels注解。labels: armsPilotAutoEnable: "on" armsPilotCreateAppName: "<your-deployment-name>" # 请将<your-deployment-name>替换为您的应用名称。 armsSecAutoEnable: "on" # 如果需要接入应用安全,则需要配置此参数。
如果存在,则执行步骤7。
如果不存在,则在编辑YAML对话框中的spec.template.metadata层级下添加以上Labels注解,然后单击更新。
在
"Message":"STS错误"
。 页面目标应用右侧选择 ,查看ack-onepilot的Pod日志是否报STS错误,即提示如果报STS错误,则需为应用所在集群授权,并重启应用所在Pod。具体操作,请参见为容器服务Kubernetes版授权。
如果未报STS错误,请提交工单。
在javaagent参数。 页面目标应用右侧单击YAML 编辑,在编辑YAML对话框中查看YAML文件中是否存在以下
-javaagent:/home/admin/.opt/ArmsAgent/aliyun-java-agent.jar
说明如果您使用的探针版本在2.7.3.5以下,请将本文中的aliyun-java-agent.jar替换为arms-bootstrap-1.7.0-SNAPSHOT.jar。建议您尽快将探针升级至最新版本。
集群中不存在ARMS Addon Token
问题现象
目标集群中不存在ARMS Addon Token。
登录容器服务管理控制台,在集群列表页面,单击目标集群名称进入集群详情页。
在左侧导航栏选择 。
在顶部选择命名空间为kube-system,查看addon.arms.token是否存在。
解决方案
为容器服务Kubernetes版授予ARMS资源的访问权限。
为什么应用更换了集群或Namespace后监控数据异常?
问题现象
使用指标自定义大盘,更换了Namespace后应用名称前面的Namespace没有同步更新。
应用更换了集群后,RED指标正常展示,但是容器监控下的CPU、内存无数据。
可能原因
Namespace、ClusterId这些容器相关的信息在应用创建时写入配置,且该部分配置信息目前并无自动刷新逻辑,当更换集群或者调整Namespace后会影响容器相关数据的查询和展示。
解决方案
删除应用后,新建应用重新上报监控数据。具体操作,请参见删除应用。
该方式会导致历史数据丢失。
提交工单。
如何自定义Java探针挂载路径
问题背景
在标准部署场景中,ack-onepilot 组件会通过注入 JAVA_TOOL_OPTIONS
环境变量指定 Java 探针(Agent)的挂载路径。但在某些场景下,用户可能需要自定义探针挂载路径以满足特定需求:
统一配置管理
需通过 Kubernetes ConfigMap 集中管理探针路径,实现多环境配置一致性。
持久化存储需求
企业安全规范或运维要求将探针文件存储在自定义持久化卷(PVC)中。
解决方案
自定义Java探针挂载路径对 ack-onepilot 与 Java 探针版本要求如下:
ack-onepilot 版本不低于 4.1.0。
ARMS Java 探针版本不低于4.2.2,您也可以根据需求自主控制Java探针版本。
ack-onepilot组件由 MSE 和 ARMS 共用,因此自定义 Java 探针挂载路径对于 MSE 服务治理应用同样生效。
为需要自定义挂载Java探针的Kubernetes工作负载(如Kubernetes Deployment)添加
disableJavaToolOptionsInjection
注解。添加该注解后ack-onepilot组件将不会通过JAVA_TOOL_OPTIONS环境变量自动指定Java探针的挂载路径及其他JVM参数。
执行以下命令查看目标无状态(Deployment)应用的YAML文件。
kubectl get deployment {deployment名称} -o yaml
说明若您不清楚{deployment名称},请先执行以下命令查看所有无状态(Deployment)应用,在执行结果中找到目标无状态(Deployment)应用,再查看目标无状态(Deployment)应用的YAML文件。
kubectl get deployments --all-namespace
启动编辑目标无状态(Deployment)应用的YAML文件。
kubectl edit deployment {Deployment名称} -o yaml
在YAML文件中的spec.template.metadata层级下添加以下内容。
labels: armsPilotAutoEnable: "on" armsPilotCreateAppName: "<your-deployment-name>" # 请将<your-deployment-name>替换为您的应用名称。 disableJavaToolOptionsInjection: "true" # 如需自定义Java探针挂载路径,请将此开关设为true。
在您的应用启动脚本或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区域上报数据,该如何处理?
解决方案
将ack-onepilot组件升级至4.0.0或以上版本。
在目标容器集群ack-onepilot命名空间下的ack-onepilot-ack-onepilot应用中添加ARMS_REPORT_REGION环境变量,值为ARMS所支持的RegionId(例如cn-hangzhou、cn-beijing)。
重启现有应用或部署一个新的应用,完成跨区域上报。
说明当添加环境变量后,该集群下所有应用均会跨区域上报到上一步中指定地域。
如何卸载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而不工作。
卸载arms-pilot。
登录容器服务管理控制台,在集群列表页面单击目标集群名称。
在左侧导航栏选择
。在Helm页面的arms-pilot右侧操作列,单击删除。
在删除应用对话框单击确定。
检查arms-pilot是否已卸载。
进入容器服务管理控制台目标集群下的 页面,在页面顶部选择命名空间为arms-pilot,确认该命名空间下的Pod已经被删除。
说明如果您修改了arms-pilot组件所在的命名空间,此处请选择对应命名空间。
安装ack-onepilot。
登录容器服务管理控制台,在集群列表页面单击目标集群名称。
在左侧导航栏单击组件管理,然后通过关键字搜索ack-onepilot。
在ack-onepilot卡片上单击安装。
说明ack-onepilot组件默认支持1000个pod规模,集群pod每超过1000个,ack-onepilot资源对应的CPU请增加0.5核、内存请增加512 MB。
在弹出的页面中可以配置相关的参数,建议使用默认值,单击确定。
说明安装完成后,您可以在组件管理页面升级、配置或卸载ack-onepilot组件。
检查ack-onepilot是否已安装。
进入容器服务管理控制台目标集群下的 页面,在页面顶部选择命名空间为ack-onepilot,确认该命名空间下的pod已在运行中。
阿里云Prometheus监控
Prometheus监控页面显示未找到相关监控大盘
问题现象
如果您开启阿里云Prometheus监控后,在容器服务管理控制台的 页面上,看到未找到相关监控大盘的提示,按照以下操作步骤解决。
解决方案
重新安装Prometheus监控组件。
卸载组件:
登录容器服务管理控制台,在左侧导航栏选择集群列表。
在集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理。
在组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。单击卸载,然后在弹框中单击确认,
重新安装组件:
确认卸载完成后,单击安装,然后在弹框中单击确认。
等待安装完成后。返回到Prometheus监控页面查看问题是否已解决。
如果问题仍未解决,请继续以下操作。
检查Prometheus实例接入。
登录ARMS控制台。
在左侧导航栏,单击接入管理。
在已接入环境页签,查看容器环境列表,确认是否存在与集群名称相同的容器环境。
没有相应容器环境:参见通过ARMS或Prometheus控制台接入。
有相应容器环境:单击目标容器环境操作列的探针设置,进入探针设置页面。
检查安装探针是否正常运行。若有报错,请提交工单。
如果以上步骤未解决问题,请提交工单联系技术支持。
为什么可观测监控Prometheus版数据异常无法显示?
问题原因
可观测监控 Prometheus 版数据异常无法显示,可能是因为同步阿里云Prometheus云端服务时任务未成功,导致资源注册失败,或者由于Prometheus实例未正确接入。请按照以下流程检查并解决问题。
解决方案
检查接入可观测监控 Prometheus 版任务状态。
重新安装Prometheus监控组件。
卸载组件:
登录容器服务管理控制台,在左侧导航栏选择集群列表。
在集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理。
在组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。单击卸载,然后在弹框中单击确认,
重新安装组件:
确认卸载完成后,单击安装,然后在弹框中单击确认。
等待安装完成后。返回到Prometheus监控页面查看问题是否已解决。
如果问题仍未解决,请继续以下操作。
检查Prometheus实例接入。
登录ARMS控制台。
在左侧导航栏,单击接入管理。
在已接入环境页签,查看容器环境列表,确认是否存在与集群名称相同的容器环境。
没有相应容器环境:参见通过ARMS或Prometheus控制台接入。
有相应容器环境:单击目标容器环境操作列的探针设置,进入探针设置页面。
检查安装探针是否正常运行。若有报错,请提交工单。
如果以上步骤未解决问题,请提交工单联系技术支持获取帮助。
阿里云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
问题原因
通过命令手动删除arms-prom后,可能会存在角色等资源残留。
解决方案
执行以下命令,找到arms-prometheus的ClusterRole。
kubectl get ClusterRoles --all-namespaces | grep prom
执行以下命令,删除上一步查询的ClusterRole。
kubectl delete ClusterRole [$Cluster_Roles] -n arms-prom
说明[$Cluster_Roles] 为上一步查询的ClusterRole。
如果删除后依然报错,需要查看报错信息中的kind值,查看是否存在ClusterRole以外的其他资源残留,使用类似方法,依次删除即可。
如何查看ack-arms-prometheus组件版本?
问题背景
您需要查看集群中部署的ack-arms-prometheus组件版本以及是否需要更新。
解决方案
登录容器服务管理控制台,在左侧导航栏选择集群列表。
在集群列表页面,单击目标集群名称,然后在左侧导航栏,单击组件管理。
在组件管理页面,单击日志与监控页签,找到ack-arms-prometheus组件。
在组件下方显示当前版本信息,如有新版本需要升级,可单击版本右侧升级完成组件升级。
说明当已安装的组件版本不是最新版本时,才会显示升级操作。
为什么GPU监控无法部署?
问题原因
如果您的GPU节点上存在污点,可能导致GPU监控无法部署。您可以通过以下步骤查看GPU节点的污点情况。
解决方案
执行以下命令,查看目标GPU节点的污点情况。
如果您的GPU节点拥有自定义的污点,可找到污点相关的条目。本文以
key
为test-key
、value
为test-value
、effect
为NoSchedule
为例说明:kubectl describe node cn-beijing.47.100.***.***
预期输出:
Taints:test-key=test-value:NoSchedule
通过以下两种方式处理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”,应该是存在资源被占用或残留的问题,导致组件安装失败。
解决方案
登录容器服务管理控制台,在左侧导航栏单击集群列表。
在集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情。
在集群管理页面左侧导航栏选择
,检查是否存在ack-arms-prometheus。存在:在Helm页面删除ack-arms-prometheus,并在组件管理页面重新安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件。
不存在:
若没有ack-arms-prometheus,表明删除ack-arms-prometheus helm有资源残留,需要手动清理。关于删除ack-arms-prometheus残留资源的具体操作,请参见阿里云Prometheus监控常见问题。
在组件管理页面安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件。
执行以上步骤,如果仍无法安装ack-arms-prometheus,请提交工单。
提示Component Not Installed后继续安装ack-arms-prometheus组件,安装失败
问题现象
尝试安装 ack-arms-prometheus 组件时,先出现“Component Not Installed”提示,再次尝试安装时仍然失败。
解决方案
检查是否已经安装ack-arms-prometheus组件。
登录容器服务管理控制台,在左侧导航栏单击集群列表。
在集群列表页面中,单击目标集群名称或者目标集群右侧操作列下的详情。
在集群管理页面左侧导航栏选择应用>Helm。
在Helm页面检查是否存在ack-arms-prometheus组件。
已有ack-arms-prometheus:在Helm页面删除ack-arms-prometheus,并在组件管理页面重新安装ack-arms-prometheus。关于安装ack-arms-prometheus的具体操作,请参见管理组件。
没有ack-arms-prometheus组件:需进行以下操作。
若没有ack-arms-prometheus,说明删除ack-arms-prometheus helm有资源残留,需要手动清理。关于删除ack-arms-prometheus残留资源的具体操作,请参见阿里云Prometheus监控常见问题。
在组件管理页面安装ack-arms-prometheus。操作入口,请参见管理组件。
执行以上步骤,仍无法安装ack-arms-prometheus,请提交工单。
检查ack-arms-prometheus的日志是否有报错。
检查Agent是否安装报错。
开源Prometheus监控
如何配置钉钉告警通知?
问题现象
在部署开源 Prometheus 后,您需要配置通过钉钉发送告警通知。
解决方案
部署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后,如果要开启部分功能,在集群信息页面,选择
,在ack-prometheus-operator右侧,单击更新,找到对应的开关,进行相应的设置,然后单击确定开启您想要的功能。TSDB和阿里云云盘如何选择
问题现象
在选择存储方案时,如何选择 TSDB和阿里云云盘,并且如何配置数据回收策略。
解决方案
TSDB支持的地域比较少,而阿里云云盘是全域支持,数据回收策略请参见以下配置。
Grafana Dashboard显示有问题
问题现象
在部署开源 Prometheus 后,Grafana Dashboard看板显示有问题。
解决方案
在集群信息页面选择
,在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的命名空间,会导致资源删除后有残留配置,影响再次安装。您可以执行以下操作,删除残余配置。
解决方案
删除RBAC权限。
删除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
删除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
删除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事件中心资源。
解决方案
重新安装ack-node-problem-detector组件。
重新安装组件,会重新创建默认的名为k8s-log-xxxxxx的Project。
卸载ack-node-problem-detector组件。
在容器服务管理控制台目标集群管理页左侧导航栏中,选择 。
单击日志与监控页签,在ack-node-problem-detector组件的卡片中单击卸载。然后在弹框中单击确认。
待卸载完成后,安装ack-node-problem-detector组件。
在左侧导航栏,选择
在报警配置页面,单击开始安装,控制台会自动创建Project,安装组件、升级组件。
然后在报警配置页面,将对应的报警规则集右侧的启动状态关闭,等待其报警规则状态为规则已关闭后,再启动重试。
报警规则同步状态失败出现类似报错信息this rule have no xxx contact groups reference
问题现象
报警规则同步状态失败出现类似报错信息this rule have no xxx contact groups reference
。
问题原因
报警规则无订阅的联系人组。
解决方案
已创建联系人,并将联系人加入联系人分组中。
在对应报警规则集右侧单击编辑通知对象,为该组报警规则配置订阅的联系人分组。
其他问题
kubectl top pod/node为什么全部没有数据?
问题现象
在命令行中执行kubectl top pod
或者kubectl top node
没有数据。
解决方案
执行以下命令,检查metrics-server的API Service是否正常。
kubectl get apiservices | grep metrics-server
返回结果中
v1beta1.metrics.k8s.io
显示True
,说明metrics-server的API Service正常。可选:如果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端口可以在集群中正常访问。
可选:如果metrics-server的443端口与8082端口无法在集群中正常访问,重启metrics-server。
您可以通过删除metrics-server的Pod的方式重启metrics-server。
登录容器服务管理控制台,在左侧导航栏选择集群列表。
在集群列表页面,单击目标集群名称,然后在左侧导航栏,选择 。
在无状态页面顶部设置命名空间为kube-system,单击metrics-server。
在容器组页签下,选择metrics-server的Pod操作列下的更多>删除,然后在对话框单击确定。
按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单。
工单模板:
API Service是否正常?
是
metrics-server 443与8082端口是否可达?
是
提供集群ID。
kubectl top pod/node为什么部分没有数据?
问题现象
在命令行中执行kubectl top pod
或者kubectl top node
部分没有数据。
解决方案
请按照以下方式进行预检查。
检查是特定的节点上所有Pod无数据,还是特定的Pod无数据。如果是特定的节点上所有Pod无数据,请检查节点是否存在时区漂移,可以通过NTP服务器的
date
命令进行时区校验。检查metrics-server Pod到特定的Node的10255端口的网络连通性。
按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单。
工单模板:
单个Node上的Pod是否全部无数据?
是
节点时区是否有漂移?
无
metrics-server到指定节点的连通性是否可达?
是
HPA无法获取metrics数据怎么办?
问题现象
在使用 Kubernetes 的HPA(水平Pod自动扩缩器)时,您可能会遇到无法获取指标metrics数据的情况。
解决方案
请按照以下方式进行预检查。
检查对应的Pod执行kubectl top pod
的结果。如果数据异常,请参见kubectl top pod/node为什么全部没有数据?和kubectl top pod/node为什么部分没有数据?的检查方法进行检查。
按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单。
工单模板:
监控数据是否有异常?
无
执行
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
按上述说明检查后,如果仍然没有发现问题,请按照以下工单模板提交工单。
工单模板:
检查metrics-server的版本是否为最新?
是
检查配置参数是否已经增加防误弹能力?
是
执行
,提交HPA的描述。kubectl describe hpa
<hpa_name>