前一段, 我们写了一篇讲异地备份重要性的文章, 一周之后北京真的地震了, 当时的时间是傍晚 6 点多一点, 大部分工程师写代码正嗨的时候, 地震之后就看到朋友圈里有人说感觉到地震的第一反应就是 git push, 多么冰雪聪明尽职尽责, 可是你的线上数据做好备份了么?
在我们线上的生产环境中要备份的东西很多, 各种服务日志数据库数据用户上传数据代码等等用 JuiceFS 来备份可以节省你大量时间, 我们会围绕这个主题写一系列的教程, 整理出一套最佳实践, 方便大家
今天第一篇就写写最常用的 Nginx 日志备份
如何用 JuiceFS 备份 Nginx 日志
生产环境中的 Nginx 经常作为反向代理, 配置多台, 用来对接后面的各种应用服务日志主要有两类, 访问日志 (access.log) 和错误日志 (error.log)
日志是分散在每个 Nginx 节点的磁盘上的, 每台机器自己的磁盘并不安全, 而且分散的日志也难以维护和使用所以, 我们都会将日志汇总在一个更靠谱的存储系统中, 一方面长期存储安全可靠, 一方面也方便做分析使用
在日志的存储上需要里, 容量扩展性强, 稳定安全, 方便运维操作, 价格便宜, 最好按使用量付费是重点, 对于存储性能的要求会低一些目前常用的有 NFSHDFS 对象存储等, 把这些存储与 JuiceFS 做个比较:
说到日志的收集方式, 主要有两种: 定时收集 和 实时收集, 我们在下面分别说明 JuiceFS 使用客户自己的对象存储保存文件数据, 所以也自然继承了对象存储的好处, 在此之上, 我们提供了高性能的元数据服务和完整的 POSIX 兼容, 使用上又比对象存储便利的多
定时收集
通常按照 小时天, 把日志拷贝到一个统一的存储点这方面的工具集很多, 我们用 Linux 默认安装的 logrotate 举例说明
首先, 要在 JuiceFS 网站 注册个账号, 并创建了一个文件系统, 假设叫 super-backup
第一步, 每台机器安装 JuiceFS 客户端, 挂载到 /jfs
下载 JuiceFS 客户端
$ curl -L juicefs.io/static/juicefs -o juicefs && chmod +x juicefs
挂载文件系统
$ sudo ./juicefs mount super-backup /jfs
在自动化配置管理中使用 JuiceFS 也同样方便, 具体方法请在上手指南中查看 如何通过命令行认证 和 开机自动挂载, 我们支持 Docker 中挂载 和 Kubernates 中挂载
第二步, 在每台机器上用 logrotate 配置日志的滚动策略, 修改
- /etc/logrotate.d/nginx
- /var/log/nginx/*.log {
- daily # 每天滚动一次
- compress
- dateext # 把日期添加到文件名中
- sharedscripts
- postrotate
- [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` # 重新加载日志文件
- endscript
- lastaction
- rsync -au *.gz /jfs/nginx-logs/`hostname -s`/ # 把压缩好的日志同步到 JuiceFS
- endscript
- }
到此, Nginx 日志就可以每天 rotate 并保存到 JuiceFS 中了增加 Nginx 节点时, 只需要在新增节点上做同样的配置即可
如果使用 NFS, 在 logrotate 中的配置是基本一样的但是 NFS 有几个不足之处:
大部分 NFS 存在单点故障, 而 JuiceFS 是高可用的(专业版承诺 99.95% SLA)
NFS 协议传输不加密, 所以你需要保证 NFS 和 Nginx 在同一个 VPC 中, 如果还有其他要备份的服务, 部署上就很麻烦 JuiceFS 传输有 SSL 加密, 不受 VPC 限制
NFS 需要事先容量规划, JuiceFS 是弹性扩容, 按容量付费的, 更省心, 更便宜
如果使用 HDFS 或者 对象存储, 日后访问备份数据时, 就比较麻烦 JuiceFS 就简单很多, 比如可以直接用 zgrep 查询
再分享几个 Tips:
执行
logrotate -f /etc/logrotate.d/nginx
立即执行对 logrotate 配置做个验证还可以用 -d 做调试
Logrotate 基于 cron 运行, 无论你设置 weeklydaily 还是 hourly, 具体的执行时间可以在 /etc/crontab 中修改
如果你觉得日志文件太多, 我们还提供了 juicefs merge 命令可以快速合并 gzip 压缩过的日志文件
说完定时汇总, 下一节我们再说说日志实时收集
实时收集
日志的实时收集已经有了很多开源工具, 常用的有 LogstashFlumeScribeKafka 等
在集群不是很大的时候, 日志收集分析索引展示有个全家桶方案 ELK, 其中用 Logstash 做日志收集和分析
需要下面的部署方式:
在每台机器上部署一个 Logstash Agent(Flume 等其他工具同理);
部署一个 Logstash Central 做日志汇总;
部署一个 Redis 做整个服务的 Broker, 目的是在日志收集和写入中间做个缓冲, 避免 Central 挂了导致日志丢失;
然后再配置 Central 的落盘方式, 将日志存储到 JuiceFS / NFS / 对象存储 / HDFS 等
先看看架构图:
这里不讲 Logstash 在收集分析过滤环节的配置了, 网络上有很多文章可查(比如: Logstash 最佳实践), 说一下输出环节
把 Logstash 收集处理好的日志保存到 JuiceFS 只要在配置的 output 部分设置一下:
- output {
- file {
- path => "/jfs/nginx-logs/%{host}-%{ yyyy/MM/dd/HH}.log.gz"
- message_format => "%{message}"
- gzip => true
- }
- }
存储到 NFS 也可以用上面的配置, 缺点和上文定时收集部分提到的相同
如果要保存到对象存储 HDFS, 需要再配置 Logstash 的第三方插件, 大部分是非官方的, 随着 Logstash 版本的升级, 使用时可能需要折腾一下
最简单的实时收集方案
其实还有更简单的实时日志收集方法, 就是直接让 Nginx 把日志输出到 JuiceFS 中, 省去了维护和部署日志收集系统的麻烦使用这个方案可能会担心 JuiceFS 出问题时影响 Nginx 的正常运行, 有两方面可以帮大家减少一些顾虑:
1)JuiceFS 本身是一个高可用的服务, 专业版承诺 99.95% 的可用性, 应该跟你的数据库等服务在一个可用性级别;
2)Nginx 的日志输出是使用异步 IO 来实现的, 即使 JuiceFS 出现暂时性的抖动, 也基本不影响 Nginx 的正常运行(restart 或者 reload 可能会受影响)
如果不喜欢运维复杂的日志收集系统, 这个方案值得一试
给 Nginx 日志加一份异地备份
定时收集和实时收集都讲完了, 在 super-backup 中存储的 Nginx 日志如何做个异地备份呢?
只要两步:
一去 JuiceFS 网站控制台中, 访问你文件系统的设置菜单, 勾选 启动复制, 然后选择你要复制到的对象存储, 保存
二在所有挂载 super-backup 的机器上重新挂载 super-backup 即可之后新写入的数据会很快同步到要复制的 Bucket 中, 旧的数据也会在客户端定时扫描 (默认每周一次) 时同步
这样可以全自动的在另外一个对象存储中同步一份数据, 有效防止单一对象存储的故障或者所在区域的灾难
你一定会问: JuiceFS 挂了怎么办? 元数据访问不了, 光有对象存储里的数据也没用啊
我们最近发布了一个重要功能 兼容模式的 JuiceFS, 所有的文件会按原样保存在对象存储中, 脱离 JuiceFS 的元数据服务, 也仍然可以访问里面的文件对于备份这类一次写入不做修改的场景适合使用
后记
上面我们详细讲解了在 JuiceFS 备份 Nginx 日志的方法, 后续还会介绍如何备份 GitlabMySQLMongoDB 用户上传数据等等, 欢迎大家踊跃提需求和投稿
来源: https://juejin.im/entry/5aa62bf1f265da23a228c074