大数据产品日志服务问题排查思路
1.使用Nginx配置要和服务器的的Nginx的配置一致。
2.数据投递到maxCompute丢失,考虑下日志服务中是否包含了/,会被maxCompute丢弃
3.需要把group by order by的字段设置成索引。
4.默认查询的时候,分钟级别数据一定是严格有序的。但是一分钟内,多个s级别数据不一定有序。如果有严格要求,可以使用排序语句
5.分词符包含的符号不允许再查询时整体查找(并且不建议使用中文符号作为分词符,如【】)。
6.count_if(x)/count()出来是整型的,需要0.1变成double
7.通过rsync复制的日志可能会采集重复。
8.K8S集群采集日志阿里云的NAS文件系统管理 挂载到容器需要将logtail也挂载到这个nas
9.where ip = "192.168.0.1"报错,需改成单引号
10.json格式的数据key必须是英文,gbk的话搜索中文时也有可能返回不符合条件的数据
11.同一时刻运行的SQL并发最大为15
12.logstore和RDS关联查询仅支持,北京、青岛、杭州。可以把日志服务迁移到青岛,RDS可以在上海
13.想要查询必须添加字段为索引字段或者开启了全文索引
14.跨region访问日志服务只能走公网入口,会有一定的延迟,建议使用全球加速。全球加速不会影响现有业务
15.ip_to_country(ip,'en')和ip_to_country_code(ip) 结果一样,语义不一样,一个是英文国家名,一个是国家编码
16.日志服务不支持删除日志数据(可以设置日志保存时间),也不支持Quick BI,一个文件只能被一个Logtail采集
17.直接搜索和* and 字段:关键字。直接搜索是全文检索,另一个是字段检索。
18.投递到OSS,如果需要删除OSS的日志,需要进行OSS的设置,设置生效要过了当天的12:00
19.现搜索的__time__不准确,可查询服务器的时区是否是UTC
20.不支持使用代码中的方法获取sql的结果数量,如果想要获取sql结果数量,可以在SQL外层嵌套count(1)获取行数
21.K8S容器,一个物理机上的所有容器对应一个logtail容器。
22.internal-alert-history 不可删除
23.自定义域名在全球加速中遇到。
24.索引包含中文生效以后之前的数据不会再生效,并且可以进行拆分查找。
25.split log lines fail:please check log_begin_regex 需查看行首正则表达式
26.web Tracking 默认支持https
27.目前日志服务查询时间范围指定,确实只支持精确到分,不支持精确到秒的,即使以前支持配置精确到秒,实际上还是有分钟级别的误差的
28.from后面只能加log,如果想使用count(*)可以使用group by
29.SDK支持跨logstore查询,界面不支持。
30.livetail除非集群或者docker,否则只能采集单台机器的日志
31.查询的索引显示null,是文本文档的格式,不支持,建议使用文本的索引来实现。
32.目前只支持中国地图,世界地图,高德地图。
33.换行符,定位不到,不支持,换行符也无法高亮显示
34.投递到maxCompute报权限问题。ODPS-0420095: Access Denied - Authorization Failed [4019], You have NO privilege 'odps:Describe' on {acs:odps:*:projects//tables/}.
应该是因为默认添加的权限丢失,在MaxCompute上运行下面三个命令重新添加一下权限,ODPS_PROJECT_NAME ODPS_TABLE_NAME替换成自己的项目名和表名
ADD USER aliyun$shennong_open@aliyun.com;
GRANT Read, List ON PROJECT ODPS_PROJECT_NAME TO USER aliyun$shennong_open@aliyun.com;
GRANT Describe, Alter, Update ON TABLE ODPS_TABLE_NAME TO USER aliyun$shennong_open@aliyun.com;
35.ListTopics 接口后续不再维护了,可能出现topic获取不全的情况
36.目前默认project下的logstore和shard限制都是200,正常情况都是够用的,尽量都建议合并同类日志使用相同logstore
37.jmespath.exceptions.UnknownFunctionError: Unknown function: map()
需要升级python版本到3.6 重新安装客户端测试一下,多半是版本兼容性的问题。
38.服务端5分钟内至多收到一次通知,每个机器人每分钟最多发送20条。
39.导出日志如果只有100条的话建议加上limit N 这里N取一个足够大的值,比如100000
40.目前还不支持使用代码中的方法获取sql的结果数量,如果想要获取sql结果数量,可以在SQL外层嵌套count(1)获取行数
41.日志服务一直显示"服务开通中,请稍等1分钟后进行重试",如果确认主账号绑定了ak,可以考虑是否开通了日志服务,开通地址:https://common-buy.aliyun.com/?commodityCode=sls#/open
42.sls告警多条告警的时候只能告警出来一条。
43.关键词过滤只有30个,超出的需要加到where条件里
44.分词符是ASCII码的,不能加上中文的【】您需要为该字段打开包含中的选项,去掉分词符中的【】,点击查询时关键字中会自动带上 【】,就可以查询出结果了
45.date_parse(substr(time,1,19),'%Y-%m-%d %T')用于配置2011-11-11 11:11:11.111
46.app_info.json文件ip相同。查询时候通过这个IP进行搜索会同时过滤出这几台的日志,其他基本无影响。IP是相同的吗?不影响采集,查询时候不能通过__source__ 进行过滤
47.告警包含source和路径。- [Context] ${Results[0].FireResult.__source__}和- [Context] ${Results[0].FireResult.__tag__:__path__}
48.判断null可以使用: length("result.data.token") = 0
49.getLogs方法 目前SQL分析返回的字段长度不能超过2K;关键字过滤返回字段长度不超过10K,没办法改变这个限制的。
50.dataworks投递日志时字段: time 用 C_LogTime;__source__ 用 C_Source;__topic__ 用 C_Topic;tag字段,使用冒号后面的字段
51.日志服务订阅仪表盘权限:CreateJob。project级别的
修改,取消,查看等: CreateJob、UpdateJob、GetJob、ListJobs、DeleteJob
52.关闭统计功能之后写入的数据没办法通过SQL查询,返回的就是null,可以通过select * from log where进行过滤
53.控制台分享内嵌进自建网站iframe里,默认不支持设置黑色主题,如果是浏览器直接添加?theme=dark,iframe中需要增加sls_iframe=true
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
maxCompute(ODPS)问题排查思路
1.如果自己不小心手动删除数据无法提供恢复,如果是普通表,是没法恢复数据的。外部表可以配置到OSS上面,数据不会删除。2.用户删除行为,所有的副本也会删除的。如果是产品故障导致丢失,一般所有副本丢失的可能性并不大(可以提工单咨询)。 3.UDF由于沙箱限制,不支持请求外部链接4.不能实现的函数全部建议UDF5.客户端乱码的换考虑将use_instance_tunnel改为false6.pyodps查询最多10000条。SDK和API请求的话可设置:options.tunnel.use_instance_tunnel = True,并且设置options.tunnel.limit_instance_tunnel = false 7.自定义UDF的时候,类名必须写正确,要不然会报解析错误8.UDF的找不到参数、函数名问题参考:https://yq.aliyun.com/articles/684417?spm=a2c4e.11155435.0.0.192a3312uElBdJ9.使用like 如果like字段包含下划线_ ,不会生效,建议使用rlike + 正则的方式。10.Tunnel命令...
- 下一篇
千亿级的数据难题,优酷工程师怎么解决?
阿里妹导读:优酷一天的日志量会达到千亿级别,面对如此大的数据样本,2017年5月,优酷完成了从Hadoop迁移到阿里云MaxCompute,实现计算消耗和储存的消耗呈下降趋势,得到了非常大的收益。今天,阿里数据技术专家门德亮给大家做个分享,从为什么要用MaxCompute,到优酷的业务场景下典型的方案及应用分析,聊聊迁移后对业务及平台的具体价值。本文内容根据演讲视频以及PPT整理而成,希望对你有所助益。 大家好,我是门德亮,很荣幸,我正好见证了优酷从没有MaxCompute到有的,这样一个历程,我们正好是在快到5年的时候,做了从Hadoop到MaxCompute的这样一个升级。 2016年5月到2019年5月优酷的发展历程。整个用户数,还有表的数据,实际上是呈指数式增长的。但是在2017年5月,当优酷完成了整个Hadoop迁移MaxCompute后,优酷的计算消耗,还有储存的消耗实际上是呈下降趋势的,整个迁移得到了非常大的收益。 下面说一下优酷的业务特点。 第一个特点是大数据平台整个的用户复杂度,不止是数据的同学和技术的同学在使用,还会包括一些BI同学,测试同学,甚至产品运营都可能去使...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2全家桶,快速入门学习开发网站教程
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,CentOS7官方镜像安装Oracle11G
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Linux系统CentOS6、CentOS7手动修改IP地址