运维烂笔头

一个 SA 老兵的工作日志

背景介绍

最近要做个 log server,把所有服务器的系统日志都收上来。我现在的服务器,操作系统有两种:Amazon Linux 2023 和 Ubuntu,但其实 Ubuntu 又有 22.04 和 24.04 两种,所以,其实是一共有三种操作系统。

好在这三种系统,其缺省跑的日志应用,Amazon Linux 2023 是 systemd-journald,而 Ubuntu(22.04 和 24.04) 都是既跑有 systemd-journald,又跑的有 rsyslogd。这两种日志应用,都是支持集中的日志服务器的,或者很容易支持。但是为什么不就用一套 rsyslogd 的日志服务器呢?毕竟大家都支持 rsyslogd 的。主要是因为 systemd-journald 相对于 rsyslogd 是很新的东西,所以这里也拿出来练练手。

rsyslogd

server

rsyslog 的 log server 配置还是相当简单的

1
2
vim /etc/rsyslog.d/remote.conf
# 新建 /etc/rsyslog.d/remote.conf 文件

加入如下内容:

1
2
3
4
5
6
7
8
9
10
11
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

template(name="RemoteLogsWithHostIPDate" type="string" string="/var/log/remote/rsyslog/%fromhost-ip%_%hostname%/%programname%-%$YEAR%-%$MONTH%-%$DAY%.log")

if ($fromhost-ip == "127.0.0.1") then {
stop
}
*.* action(type="omfile" dynaFile="RemoteLogsWithHostIPDate")

重启 rsyslogd

1
systemctl restart rsyslog

client

客户端的配置也相当简单

1
2
vim /etc/rsyslog.d/99-remote.conf
# 新建文件:/etc/rsyslog.d/99-remote.conf

写入如下内容:

1
2
3
*.* @logserver.xxx.xxx:514
# 用 udp 把日志打到前面配好的 rsyslog 日志服务器
# 地址假设是 `logserver.xxx.xxx`

最后重启 rsyslog

1
systemctl restart rsyslog

systemd-journal-remote

server

1
2
3
4
5
6
dnf install systemd-journal-remote
# install software depended, log server is based on Amazon Linux 2023
systemctl edit systemd-journal-remote.service
# change the configuration of service systemd-journal-remote
# NOTE: must write in the special blank lines
# 注意:必须在指定的空行内输入配置

指定的空行内输入如下内容:

1
2
3
4
5
6
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/remote/journal/
LogsDirectory=remote/journal
# 如果 ExecStart 那一行的 --output 参数指定的目录没改的话
# 最后那一行是不需要的

保存以后,使得

1
cat /etc/systemd/system/systemd-journal-remote.service.d/override.conf

能看到之前输入的内容即可。

1
2
mkdir /var/log/remote/journal
systemctl edit systemd-journal-remote.socket

指定的空行里输入:

1
2
3
[Socket]
ListenStream=
ListenStream=19532

保存后退出。使得

1
cat /etc/systemd/system/systemd-journal-remote.socket.d/override.conf

输出的内容正是之前输入的即可。

1
2
systemctl enable --now systemd-journal-remote.socket
# enable and start systemd-journal-remote.socket

client

1
2
3
4
5
6
7
8
9
10
dnf install systemd-journal-remote
# install software depended
mkdir /etc/systemd/journal-upload.conf.d/
cat <<EOF > /etc/systemd/journal-upload.conf.d/override.conf
[Upload]
URL=http://logserver.xxx.xxx:19532
EOF

systemctl enable --now systemd-journal-upload.service
# enable and start service of systemd-journal-upload

参考

简介

这是之前有一家公司招 SRE,我投了简历,然后被给了份题让先做一下,于是便有了这篇“水”文。

当然,最终我并没有拿到这个 offer,最早是说一周内安排面试的,后来又说是这个岗位暂停了。

阅读全文 »

简介

这是之前有一家海外公司招 DevOps 工程师,我投了简历,期望薪资写了薪资范围的最下限,然后被给了份题让先做一下,于是便有了这篇“水”文。

当然,最终我并没有拿到这个 offer,甚至连下一轮见 CTO 的机会都没有。(关于这个,我其实心里还是有一点小小的不服气的。)

阅读全文 »

起因

在搭建新环境时,我们选择了 OpenTofu——这是在 Terraform 更改了 license 之后从 Terraform 代码库分支并且开放源码的工具——用于构建VPC、RDS、Redis等基础设施。

但当基础设施就位、开始部署应用程序时,问题出现了。每次部署都不成功,查看日志说是 JDBC 相关错误,DB Proxy 的日志中充斥着诸多 “internal error”,却若隐若现关于具体错误原因的描述。尝试直接通过 MySQL 客户端连接 DB Proxy 时,大多数命令执行都引发错误(help 命令除外)提示:

ERROR 1105 (HY000): Unknown error

错误截图参见:

阅读全文 »

背景

项目有一些非常重要的后台应用是跑在 AWS 的 lambda 上的,老板和产品非常关注这些应用的执行情况,一旦出错,都会是很严重的故障。

方案变迁

前面做过一些基础设施级别的监控报警,如:监控 AWS 的 RDS 并通过企业微信来报警,那个完全是利用基础设施自动打到 CloudWatch 的基础的 metrics 来做的。

于是,我这里下意识的就想利用现有的 CloudWatch 里现成的 Metrics 来做这个事情,于是我就弄了三个(种)监控:

阅读全文 »

缘起

本来这台 HP Chromebook 11A G6 EE( 加了一张 128G 的 TF 卡 ),我安装好了 Arch Linux(Xfce),都弄好了的,但最近在知乎上老被安利说装 Debian 的 testing 版,于是我又开始折腾,把 Debian 13 testing(trixie) 安装到这台 Chromebook 上。

安装时,使用 lvm 分区不成功,系统报错:

partman-lvm: pvcreate: error while loading shared libraries: libaio.so.1: cannot open shared object file: no such file or directory

现在想想可能还有其他办法,比如想办法把这个需要的包注入进去,但当时选择了先用 ext4 分区安装系统自带的 16G 的卡里,装完以后再想办法转成 lvm 并把 TF 卡的空间加进来。

阅读全文 »

引言

监控在云资源管理中占据了核心地位,它可以帮助我们实时追踪资源状态,从而快速发现并处理潜在的问题。本文将介绍如何利用 AWS CloudWatch 监控云数据库服务RDS,并通过企业微信发送报警通知,以达到高效运维的目的。

阅读全文 »

缘起

大家好,我是老杨。在这篇文章中,我将带大家深入了解如何利用 GitHub Action 自动化部署 Chalice 应用到 AWS Lambda。这不仅是一个技术实践,也是对 CI/CD 流程优化的一次探索。

在现代软件开发中,快速迭代和持续部署是提高开发效率的关键。Chalice 是一个用于部署 Python 应用到 AWS Lambda 的框架,而 GitHub Action 提供了一个强大的自动化平台。结合这两者,我们可以创建一个无缝的部署流程。

阅读全文 »
0%