原生产项目中日志服务器搭建及日志配置

1、日志服务器搭建 1、 环境准备 搭建日志服务器，需要事先使用init_server.sh 脚本对日志服务器进行初始化。 随后在taishan上进行操作 执行：docker images -a
查看是否有docker.baiwang-inner.com/ops-logging-archive:0.2.0 如果存在，进行“2、安装命令”。 如果不存在在泰山服务器中：source/data/install/taishan.conf 1，docker load -i $DATA_DIR/ops-logging-archive_0.2.0.tar 安装OPS镜像,在泰山服务上/data目录下 2，docker tag build.baiwang-inner.com/ops-logging-archive:0.2.0 $DOCKER_REGISTRY/ops-logging-archive:0.2.0 标记OPS，将镜像放入仓库中 docker tag docker.baiwang.com/filebeat:5.5.2 $DOCKER_REGISTRY/filebeat:5.5.2标记filebeat，将镜像放入仓库中 3，docker push $DOCKER_REGISTRY/ops-logging-archive:0.2.0 推送镜像

2、 安装命令 进入taishan平台安装服务器的/data/taishan/src/Taishan/config/taishan.yaml文件中查看具体配置信息

log_achive： log_achive 拼写错误，修改为log_archive:log_archive（已修改。不需修改，可查看）

在kafka服务器上如果kafka是单节点执行： kafka-topics.sh --create --topic log-archive --zookeeper 10.10.11.158:2181 --partitions 1 --replication-factor 1 创建topic
如果是集群，修改 partitions 1 --replication-factor 1 单机用1 若是集群：3是3台集群主机。如 (kafka-topics.sh --create --topic log-archive --zookeeper 92.12.78.66:2181，92.12.78.67:2181,92.12.78.68:2181 --partitions 1 --replication-factor 3)

随后进入日志服务器上运行： source /etc/deploy/basic.conf && docker run -d
--net=host
--name log-archive
-e TZ=Asia/Shanghai
-v $DATA_DIR/archive:/logs
$DOCKER_REGISTRY/ops-logging-archive:0.2.0
python /logging/logger.py
--bootstrap-servers 10.10.11.158:9092
--topic log-archive
--app-name bwcloud-logs-11
--saved-dir /logs
--config /logging/config.json 参数说明： --bootstrap-servers kafkaserver1:9092,kafkaserver2:9092 kafka集群地址，多个地址用',' 分割

将日志采集器推送到仓库(在发版平台服务器上执行)： docker push docker.baiwang-inner.com/filebeat:5.5.2 重启泰山：docker restart taishan

在发版平台中对微服务点击编辑，然后提交，用以激活日志采集。

3、 日志存储路径 收集的日志存储在：$DATA_DIR/archive/微服务名/日期/ip-容器名-日志名-小时.log 下，其中$DATA_DIR 取自/etc/deploy/basic.conf 中配置的数据盘路径。

4、 日志压缩脚本

默认压缩3天前产生的日志，如需修改将脚本最后一行 compress_log_by_createtime $DATA_DIR/archive 3 的3 改成需要的天数

2、日志服务配置 2.1 Kafka相关配置 日志服务器的配置运维管理平台统一管理，所有需要修改运维管理平台taishan.yaml 配置文件，修改完成后重启运维管理平台。 2.1.1 Kafka地址 第一次安装运维管理平台时，修改安装配置文件taishan.conf即可，多个ip用逗号分隔 安装完成后则可以通过修改运维管理平台配置文件完成。运维管理平台配置文件采用yaml格式，配置key为：kafka_hosts，值为：kafkaip:端口组成的list。配置文件路径，$DATA_DIR/taishan/src/Taishan/config/taishan.yaml可为如下形式：

或

修改完成后执行 dockerrestarttaishan重启运维管理平台。各个日志采集器将在下次编辑模块信息或者重启、发版模块时将日志收集到新配置的kafka中。 2.1.2 Topic 配置 运维管理平台release_2.1.1 及以后版本已添加日志收集默认topic:log-archive。如需修改则修改运维平台配置文件taishan.yaml ->log_type-> log-archive, 将log-archive 改成需要的topic。

修改完成后执行 dockerrestarttaishan重启运维管理平台。各个日志采集器将在下次编辑模块信息或者重启、发版模块时将日志收集到新配置的topic中。

2.2 日志路径及类型配置 日志路径可通过运维管理平台模块编辑页面进行配置。配置步骤如下： 1、在运维管理平台上找到需要收集日志的模块，点击编辑

2、选择日志收集，添加日志路径，日志类型选择“日志服务器采集”

日志路径支持具体日志名或通配符，如error.log,*.log 日志路径填写应用log4j或logback等配置日志路径,如应用内配置的日志路径为 /mnt/logs/webapi/error.log 则在文本框中填写 webapi/error.log 注：应用配置的日志路径必须在 /mnt/logs 下，否则会造成无法收集日志且有docker内硬盘写满的风险。

2.3日志收集的触发条件 日志收集的前提是至少配置了一种需要收集的日志。日志收集的触发条件有两个： 1、 对模块进行重启、发版 2、 对模块进行编辑 日志收集是已服务器为单位的，所有服务器上有一个模块满足以上任意一个条件将会触发日志收集，触发后服务器上所有模块均会进行日志收集（前提是这些模块都进行了日志收集配置）。 对模块进行编辑时 将会收集模块所在的所有服务器对应的日志。

3、日志服务运维 3.1 Docker命令 日志服务使用docker容器运行。以下命令为一些通用的docker命令，除了日志服务之外也适用其他使用docker容器运行的服务。但是除日志服务等几基础服务外，其他的docker容器是通过运维管理平台统一管理的，不建议使用命令对其操作。 3.1.1 dockerps / docker ps -a docker ps和 docker ps -a命令的用途为列出服务器上的docker容器。区别在于dockerps只列出正在运行的docker容器，而dockerps-a则会列出所有容器。

docker ps 每一列的含义： CONTAINER ID： 容器id IMAGE： 生成容器的镜像 COMMAND： 容器的启动命令 CREATED： 容器创建时间 STATUS： 容器运行状态，Up为正常状态 PORTS： 容器转发的端口，为空则表示没有转发或使用宿主机端口 NAMES： 容器名称 其中容器id和 容器名称可以标识一个唯一的容器，常用于其他docker命令

3.1.2 dockerstart/stop/restart docker start 容器名或容器id用于启动docker容器。 docker stop容器名或容器id用于停止docker容器。 docker restart 容器名或容器id用于重启docker容器。 如上面提到的重启运维管理平台的命令为 dockerrestarttaishan其中taishan即为容器名。

如图例子中，docker restart 7c22f3829412或 docker restart registry-nginx0001均可实现重启改容器。 注：重启之后务必执行 dockerps或 docker ps -a 查看重启是否成功，如果重启成功容器状态应为Up，且日志和业务正常。

3.1.3 docker rm -vf docker rm -vf容器名或容器id用于删除一个容器。删除后只能重新用dockerrun命令或重新发版产生，新的容器，所以该命令比较危险，请谨慎执行

3.1.4 docker images docker images用于列出本机所有镜像。注意区别镜像和容器。

dockerimages 每一列含义 REPOSITORY： 镜像的仓库地址/镜像名 TAG： 镜像标签 IMAGE ID： 镜像id CREATED： 镜像创建时间 VIRTUAL SIZE： 镜像虚拟大小，可理解为使用改镜像创建的容器的大小 其中REPOSITORY:TAG和 IMAGE ID都可标识一个唯一的镜像，区别在于一个镜像只能有一个 IMAGE ID，可以有多个 REPOSITORY:TAG。如下图：

build.baiwang-inner.com/ops-logging-archive:0.2.0和 docker.baiwang-inner.com/ops-logging-archive:0.2.0 为同一个镜像。

3.1.5 docker pull/push docker pull REPOSITORY:TAG从仓库中拉取一个镜像 docker push REPOSITORY:TAG 将一个镜像推至仓库中 如：docker push docker.baiwang-inner.com/ops-logging-archive:0.2.0 就是将 ops-logging-archive:0.2.0 推送至 docker.baiwang-inner.com仓库中。 3.1.6 systemctl start/stop/restart/status docker 严格来说该命令不属于docker的命令，该命令用于启停docker服务或显示docker服务状态。 systemctl start docker用于启动docker服务 systemctl stop docker用于停止docker服务 systemctl restart docker用于重启docker服务 systemctl status docker用于显示docker服务运行状态或报错信息 注意此处操作的是docker服务而不是docker容器。如果将docker容器比喻为虚拟机话，docker服务相当于VMware或是kvm。

3.2 日志服务维护 3.2.1 日志服务启停 根据上面介绍的docker命令可以很容易的得到日志服务的重启，停止，启动等操作方法。假设日志服务容器名为：log-archive，则： 重启日志服务： dockerrestart log-archive 停止日志服务： docker stop log-archive 启动日志服务： docker start log-archive

3.2.2 日志输出路径及规则 根据服务器初始化配置，日志服务将把所收集的业务日志存储在：$DATA_DIR/archive/微服务名/日期/ip-容器名-日志名-小时.log下，其中$DATA_DIR 取自 /etc/deploy/basic.conf中配置的数据盘路径。其中 $DATA_DIR/archive/log-archive下的日志为日志服务自身的日志。

如图： 1：微服务名 2：日期 3：产生日志的服务器ip 4：产生日志的容器名 5：原始日志名 6：产生日志的小时 注：2日期和6产生日志的小时 来源于日志内容，而非系统日期时间。因此请确保日志是日期和时间开头，且日期时间格式为：yyyy-mm-dd hh:mm:ss

3.3 日志采集器维护 一般情况下日志采集由运维管理平台统一自动安装、配置，不需要人工参与维护。如出现异常情况可以按如下操作进行排查和恢复 3.3.1 日志采集器 日志采集使用的是filebeat，因此在正确配置了日志路径且触发了日志收集的每一台服务器执行 dockerps上都应该看到一个filebeat容器。如下图：

3.3.2 日志采集器配置 日志采集器的配置文件在配置了收集日志的服务的 $DATA_DIR/采集器容器名/config目录下。如上图配置文件路径为：/data/dev-filebeat-1-1/config。日志采集器配置由运维管理平台自动生成，不建议手动修改。 配置示例如下：

Filebeat配置采用yaml格式，可分为 input和 output两个部分。Input配置日志路径（paths）、日志类型（document_type）、自定义字段(fields)，折行规则(multiline.pattern)等，output配置kafka相关配置。如图 document_type到 paths为一个input，从output.kafka到文档结束为 output。上图一共3个input和1个output，实际input数量与部署和配置日志收集的模块数据量有关，output始终只有1个。 发现日志收集有问题时，可查看该文件核对 日志路径是否正确，kafka地址是否正确。

4、常见问题 1、 没有新的日志输出 可以先查看 $DATA_DIR/archive/log-archive下日志服务的日志有没有正常输出。如果有报错，则根据报错内容尝试清理硬盘，检查kafka是否正常。恢复后执行 docker restart log-archive重启日志服务。如果长时间（几个小时）没有日志输出，则尝试直接执行 docker restart log-archive重启观察是否能恢复。

2、 日志有延迟 根据日志服务器性能、kafka集群性能、日志量等因素，日志收集会出现不等时间的延迟，正常情况下日志延迟在1-5秒，即在应用服务器上产生的日志1-5秒后能在日志服务器上看到。如果延迟较大可检查日志服务器、kafka集群是否有压力。日志量是否过大。 如日志服务中途停止，下次启动时将消费停止过程中没有消费的日志，也有可能造成日志延迟，可以通过查看最新的日志服务日志观察收集进度。

3、 日志不全 filebeat默认设置了单行日志大小为1MB，如果通过折行后单行日志超过1MB则该行日志将被filebeat抛弃，同时单个行日志大小还应该小于kafka设置的消息最大长度，否则无法被kafka接收。

4、 新配置的日志没有收集到日志服务器 如果是通过数据导入的方式添加的日志收集路径，则在运维管理平台上点击编辑->提交来触发日志收集。 收集之后还有问题，可参看问题1，排查日志服务是否正常、kafka集群是否正常。