6.1 elk使用规范和指南

新日志接入ELK时,请先仔细阅读此文档,能解决大部分疑惑 文档定会存在不完善之处,欢迎交流,随时更新

[TOC]

关于ELK日志集群

• 每个集群根据实际情况会各自部署两套kafka集群,分别对应生产kafka和非生产kafka,两套kafka集群通过安全组进行限制,仅能访问对应kafka

• 生产与测试日志均可在同一套ELK集群内进行操作,分别以-prod及-dev为后缀进行区分

• 默认情况下生产日志保留最近一个月时间可查,一个月前日志进行归档,查询之前需要进行恢复,所有日志永久保留

日志流转流程

生产环境服务(producer) --> kafka-prod --> logstash --> elasticsearch --> kibana
测试环境服务(producer) --> kafka-nonprod ----┘

原则上日志统一输出到kafka,作为缓存,避免elk由于性能,故障,升级或其他问题造成的暂时不可用导致无法收集日志的问题

日志保存策略

生产环境

• hot-level: 最近7天日志,使用ssd磁盘储存,查询速度快

• warm-level: 7天-30天日志,使用一般磁介质磁盘储存,查询速度一般

• cold-level: 30天以上日志,使用Aliyun OSS储存,日志可永久储存,查询需要提前恢复

测试环境

以各种匹配logstash-.*-(nonprod|dev)-.*的索引为测试或非生产环境日志,只保存三天

一般业务日志字段格式及约定

日志输出时最优先使用json格式,每条日志中需要具有以下几个字段:

字段名	字段类型	必要性	内容	备注	示例
department	string(keyword)	必须	部门或项目	不可使用大写字母 运维统一分配	consumer
logtype	string(keyword)	必须	具体业务线	不可使用大写字母 运维统一分配	primeloan | java | python
level	string(keyword)	建议	日志级别		INFO
app_id	string(keyword)	建议	来源服务
instance_id	string(keyword)	建议	来源实例	通过调用此接口获取	i-2zeek01e891uemj8npnt
host	string(keyword)	建议	来源IP	通过调用此接口获取	10.40.34.183
created	date	建议	日志产生时间	ISO8601标准格式,务必含有时区信息	2018-08-04T15:59:01.607Z 2018-08-04T15:59:01.607123Z 2018-08-04T15:59:01.607+00:00
message	string(text)	建议	主要内容	自动分词,不可聚合,无最大长度限制

注意事项:

• 如果日志中不存在department字段,则会被logstash丢弃

• department字段不可包含大写字母，否则会导致无法进入elasticsearch

• 相同department与logtype的日志的中同一类字段以的类型必须一致,具体字段由各个部门自行维护

• 字段数量控制在1000以内,超过将导致日志无法进入elasticsearch

例:

{
    "created": "2019-05-17T09:31:34.187Z",
    "department": "consumer",
    "logtype": "java",
    "host": "10.40.36.214",
    "hostname": "dub-consumer01cn-p011.pek4.gxd88.cn",
    "level": "INFO",
    "app_id": "business-investor-impl",
    "env": "PRO",
    "customerId": "14322287",
    "method": "com.business.investor.service.impl.InvestorServiceImpl.listInvestorByCustomer",
    "thread": "DubboServerHandler-10.40.36.214:20030-thread-1241",
    "traceId": "8360edb59c3e5dd7",
    "message": "filter investor:KAN_SFEE,customer:32859275,status:0",
    "port": "20030"
}

最终生产的索引名称为logstash-consumer-java-prod-2019.05.17

关于department字段和logtype字段的定义依据

• department字段为部门名称,如capital 资方平台, consumer c端, model 数模等,由运维同学统一进行分配

• logtype字段为业务线,在同一部门中,同一个业务线的多个服务要求共享同一套日志规范,不同的业务线可以根据自己的需求独立指定日志规范,如c端的nginx日志,c端的前端日志,和c端的公共服务日志,c端的大额贷业务日志等,都可以算作不同logtype.但是对于同一业务线中的两个不同服务,如tomcat-platform和tomcat-system,则需要共同遵守同一套日志标准,使用相同的logtype,由运维同学统一进行分配

logtype通常的类型通常划分为:

• nginx

• traefik

• jenkins-slave

• mysql

• 采用相同语言开发及统一日志规范的业务A

• 采用相同语言开发及统一日志规范的业务B

• 另一语言开发及统一日志规范的业务C

对于同一部门的索引命名冲突的处理方式

• 如capital在增加新类型日志的过程中,无法与老索引进行兼容,所以department字段采用capital.v2的形式命名

关于elasticsearch中date类型的自动识别

• es不能直接将常用的yyyy-MM-dd HH:mm:ss类型当作date类型处理,实际会当作string类型对待

• 如果通过模板强行转换此类型为date类型,会出现时区异常,由于此字段没有任何时区信息,会默认当作UTC时间处理,导致日志与实际北京时间相差八小时,所以不推荐这种日期类型

• 推荐使用 strict_date_time(yyyy-MM-dd'T'HH:mm:ss.SSSZZ)或者epoch_millis(1557130513812)作为日志中的时间输出格式

• 对于es原生支持识别为date类型的所有匹配规则,可以参考此官方文档

日志收集方式参考

主动输出至kafka(推荐)

• 开发统一的日志模块,通过程序直接将日志输出至kafka

• 由有经验的开发提供ELK的sdk,包含规范以及字段校验的功能,上传公共仓库并交付使用

• 禁止传入@或者_开头的key

filebeat收集

• 通过filebeat收集落地日志,传输至kafka

k8s环境下使用标准输出

新日志接入申请流程

新日志接入,需要向运维同学提供以下信息

• 日志说明

• deplartment字段值

• logtype字段值

• 接入方式

• 传入方式

• 使用场景及方法

• 需要查询日志的ldap用户组

• 归档策略

例:

括号中为注释,删掉即可

• 日志说明: c端大额贷日志接入

• deplartment字段值: consumer

• logtype字段值: primeloan

• 接入方式: kafka(建议方式)

• 传入方式: 开发统一模块输出(或通过filebeat采集并输出)

• 使用场景及方法: 只用作人为查询,通过kibana查询

• 需要查询日志的ldap用户组: ConsumerDEV

• 归档策略: 30天内可查,30天以上归档永久保留

个人或团队查询kibana权限申请

kibana查询对应es索引日志,需要单独进行权限申请,一般来说为整个部门ldap组赋予查看权限,赋权完成后使用个人公司ldap账户登录

申请需要提供:

• 部门ldap组名

程序读取elasticsearch权限申请

凡是涉及程序需要读取elasticsearch的情况,需要单独申请账号,并且需要在代码中配置公共es账户,不可使用自己个人账户

**申请前务必阅读此注意事项十分重要

申请需要提供:

• 程序场景及用途(用于评估集群压力及方案可行性)

• 需要查询的索引