系统日志

文章目录 实验环境 journald journalctl命令的用法 用journald服务永久存放日志 rsyslog 自定义日志采集路径 日志类型 日志级别 如何更改日志采集格式 日志的远程同步 timedatectl 时间同步服务 实验环境 两台网络可以互通的主机： rhel7:192.168.1.11 rhel8:192.168.1.10 journald 服务名称：systemd-journald.service 默认日志存放路径： /run/log journalctl命令的用法 参数 作用 journalctl 查看全部日志 -n 3 日志的最新3条 –since “2020-02-13 17：00” 显示17：00以后的日志 –until “2020-02-13 17:00” 显示日志到17：00 -o 设定日志的显示方式 -o short 经典模式显示日志 -o verbose 显示日志的全部字节 -o export 适合传出和备份的二进制格式 -o json js格式显示输出 -p 显示制定级别的日志 -p 0(emerg) 系统的严重问题日志 -p 1(alert) 系统中立即要更改的信息 -p 2(crit) 严重级别会导致系统软件不能正常工作 -p 3(err) 程序报错 -p 4(warning) 程序警告 -p 5(notice) 重要信息的普通日志

本文由 网易云 发布。 作者：刘超，网易云首席解决方案架构师 最近总在思考，为什么在支撑容器平台和微服务的竞争中，Kubernetes 会取得最终的胜出，事实上从很多角度出发三大容器平台从功能方面来看，最后简直是一摸一样。（可参考 《容器平台选型的十大模式：Docker、DC/OS、K8S 谁与当先？》 ） 经过一段时间的思索，以及采访了从早期就开始实践 Kubernetes 的 网易云 架构师们后，我把反思所得总结为今天的这篇文章。 一、从企业上云的三大架构看容器平台的三种视角 如图所示，企业上云的三大架构为 IT 架构、应用架构和数据架构，在不同的公司，不同的人、不同的角色，关注的重点不同。 对大部分的企业来讲，上云的诉求是从 IT 部门发起的，发起人往往是运维部门，他们关注计算、网络、存储，试图通过云计算服务来减轻 CAPEX 和 OPEX。 有的公司有 ToC 的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。 从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验。业务量上往往会有短期内出现爆炸式增长的现象，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。 在容器出现之前，这三种架构往往通过虚拟机云平台的方式解决。当容器出现之后

本文将介绍微服务架构和相关的组件，介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景，因此不会涉及具体如何使用组件等细节。 要理解微服务，首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。 一：最初的需求 几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。 我们整理一下功能清单： 网站 用户注册、登录功能 商品展示 下单 管理后台 用户管理 商品管理 订单管理 由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。总体架构图如下： 小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。 二：随着业务发展…… 好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。 在竞争的压力下

Docker的安全性 Docker的安全性主要体现在如下几个方面： Docker容器的安全性这是指容器是否会危害到宿主机或其他容器； 镜像的安全性用户如何确保下载下来的镜像是可信的、未被篡改过的； Docker daemon的安全性如何确保发送给daemon的命令是由可信用户发起的。用户通过CLI或者REST API向daemon发送命令已完成对容器的各种操作，例如通过docker exec命令删除容器里的数据，因此需要保证client与daemon的连接时可信的。 Docker容器的安全性 容器的安全性问题的根源在于容器和宿主机共用内核，因此受攻击的面特别大，另外，如果容器里的应用导致Linux内核崩溃，那么毫无疑问，整个系统哥都会崩溃。这一点与虚拟机是不同的，虚拟机与宿主机的接口非常有限，而且虚拟机崩溃一般不会导致宿主机崩溃。 在共用内核的前提下，容器主要通过内核的Cgroup和Namespace这两大特性来达到容器隔离和资源限制的目的。目前Cgroup对系统资源的限制已经比较完善了，但Namespace的隔离还是不够完善，只有PID、mount、network、UTS、IPC和user这几种。而对于未隔离的内核资源，容器访问时也就会存在影响到宿主机及其他容器的风险。 比如，procfs里的很多接口都没有被隔离，因此通过procfs可以查询到整个系统的信息，例如系统的CPU

Docker的安全性 Docker的安全性主要体现在如下几个方面： Docker容器的安全性这是指容器是否会危害到宿主机或其他容器； 镜像的安全性用户如何确保下载下来的镜像是可信的、未被篡改过的； Docker daemon的安全性如何确保发送给daemon的命令是由可信用户发起的。用户通过CLI或者REST API向daemon发送命令已完成对容器的各种操作，例如通过docker exec命令删除容器里的数据，因此需要保证client与daemon的连接时可信的。 Docker容器的安全性 容器的安全性问题的根源在于容器和宿主机共用内核，因此受攻击的面特别大，另外，如果容器里的应用导致Linux内核崩溃，那么毫无疑问，整个系统哥都会崩溃。这一点与虚拟机是不同的，虚拟机与宿主机的接口非常有限，而且虚拟机崩溃一般不会导致宿主机崩溃。 在共用内核的前提下，容器主要通过内核的Cgroup和Namespace这两大特性来达到容器隔离和资源限制的目的。目前Cgroup对系统资源的限制已经比较完善了，但Namespace的隔离还是不够完善，只有PID、mount、network、UTS、IPC和user这几种。而对于未隔离的内核资源，容器访问时也就会存在影响到宿主机及其他容器的风险。 比如，procfs里的很多接口都没有被隔离，因此通过procfs可以查询到整个系统的信息，例如系统的CPU

一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。 b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？ 引入消息队列

为什么会需要消息队列(MQ)？ 一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式 a、串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。 b、并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢

介绍 ApacheKafka®是一个分布式流媒体平台。这到底是什么意思呢？ 我们认为流媒体平台具有三个关键功能： 它可以让你发布和订阅记录流。在这方面，它类似于消​​息队列或企业消息传递系统。它允许您以容错方式存储记录流。它可以让您在发生记录时处理记录流。什么是卡夫卡好？ 它被用于两大类的应用程序： 构建可在系统或应用程序之间可靠获取数据的实时流数据管道构建实时流应用程序，可以转换或响应数据流要了解卡夫卡如何做这些事情，让我们深入探索卡夫卡的能力。 首先几个概念： Kafka作为一个或多个服务器上的集群运行。Kafka集群以称为主题的类别存储记录流。每个记录由一个键，一个值和一个时间戳组成。卡夫卡有四个核心API： 该制片API允许应用程序发布的记录流至一个或多个卡夫卡的话题。该消费者API允许应用程序订阅一个或多个主题，并处理所产生的对他们记录的数据流。所述流API允许应用程序充当流处理器，从一个或多个主题消耗的输入流，并产生一个输出流至一个或多个输出的主题，有效地变换所述输入流，以输出流。该连接器API允许构建和运行卡夫卡主题连接到现有的应用程序或数据系统中重用生产者或消费者。例如，连接到关系数据库的连接器可能会捕获对表的每个更改。 在Kafka中，客户端和服务器之间的通信是通过一个简单的，高性能的，与语言无关的TCP协议完成的。这个协议是版本化的，并保持与旧版本的向后兼容性

Linux操作系统的开机过程是这样的，即从BIOS开始，然后进入Boot Loader，再加载系统内核，然后内核进行初始化，最后启动初始化进程。初始化进程作为Linux系统的第一个进程，它需要完成Linux系统中相关的初始化工作，为用户提供合适的工作环境。RHEL 7、CentOS7等linux发行版系统已经替换掉了熟悉的初始化进程服务System V init，正式采用全新的systemd初始化进程服务。systemd初始化进程服务采用了并发启动机制，开机速度得到了不小的提升。 一、systemd概述 systemd即为system daemon，是linux下的一种init软件，由Lennart Poettering带头开发，并在LGPL 2.1及其后续版本许可证下开源发布，开发目标是提供更优秀的框架以表示系统服务间的依赖关系，并依此实现系统初始化时服务的并行启动，同时达到降低Shell的系统开销的效果，最终代替现在常用的System V与BSD风格init程序。 systemd是一个专用于 Linux 操作系统的系统与服务管理器。当作为启动进程(PID=1)运行时，它将作为初始化系统运行，也就是启动并维护各种用户空间的服务。 为了与传统的 SysV 兼容，如果将 systemd 以 init 名称启动，并且"PID≠1"，那么它将执行 telinit

Linux上的日志系统 syslog syslog-ng：开源 syslog服务： syslogd：系统，非内核产生的信息 klogd：内核，专门负责记录内核产生的日志信息 配置文件：/etc/syslog.conf 服务状态查看命令：service syslog status kernel --> 物理终端（/dev/console） --> /var/log/dmesg #dmesg #cat /var/log/dmesg 日志需要滚动（日志切割）： message message.1 message.2 message.3 /sbin/init /var/log/messages：系统标准错误日志信息，非内核产生引导信息，各子系统产生的信息 /var/log/mailog：邮件系统 /var/log/secure：安全 信息详细程序：日志级别 子系统：facility，设施 配置文件按定义格式未：facility.priority aciton facility，可以理解为日志的来源 priority（log level）日志的级别，一般有以下几种级别（从低到高） debug # 程序或系统的调试信息 info # 一般信息 notice # 不影响正常功能，需要注意的消息 warning/warn # 可能影响系统功能，需要提醒永固的重要事件 err/error #