1.2 接入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": "192.186.1.1",
    "hostname": "localhost",
    "level": "INFO",
    "app_id": "webserver",
    "env": "PRO",
    "customerId": "14322287",
    "method": "",
    "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字段为部门名称,,由运维同学统一进行分配

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

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

  • nginx

  • traefik

  • jenkins-slave

  • mysql

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

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

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

关于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

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

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

filebeat收集

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

k8s环境下使用标准输出

新日志接入申请流程

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

  • 日志说明

  • deplartment字段值

  • logtype字段值

  • 接入方式

  • 传入方式

  • 使用场景及方法

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

  • 归档策略

例:

括号中为注释,删掉即可

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

  • deplartment字段值

  • logtype字段值

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

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

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

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

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

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

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

申请需要提供:

  • 部门ldap组名

程序读取elasticsearch权限申请

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

申请需要提供:

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

  • 需要查询的索引

上一页1.1 git分支管理规范下一页1.3 健康检测接口规范

最后更新于