运维烂笔头

背景介绍

最近要做个 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

参考

• https://idle.nprescott.com/2024/journald-for-centralized-logging.html

简介

要把 Python 项目部署到 AWS 的 Lambda function，AWS 官方提供了两种方法：Chalice 和 SAM(AWS Serverless Application Model)，当然，其实比较常用的还有第三方的 serverless。

简介

这是之前有一家公司招 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 提供了一个强大的自动化平台。结合这两者，我们可以创建一个无缝的部署流程。

缘起

最近相当长一段时间，都在调 GitHub action 的 workflow 比较多，而 GitHub 官网时不时抽风，于是就有了在命令行看 GitHub action jobs 的执行情况的需求。