📚 课程目录第3章创建第一个定时Lambda函数

3、创建第一个定时Lambda函数：控制台创建、测试

好，我们直接上手。前面聊了那么多理论，现在终于到动手环节了。我个人习惯是先把“跑通最小闭环”放在第一位 —— 你想想看，只有看到代码真的跑起来，后面那些复杂配置才有意义。

这一章的目标很简单：在 AWS 控制台里创建一个 Lambda 函数，让它按 Cron 表达式定时执行，并在 CloudWatch Logs 里留下日志。 说白了，就是给后面三十天的巡检工作搭个“调度引擎”。

核心逻辑：把“手动检查”变成“定时触发”，这就是 Lambda + EventBridge 的组合拳。

3.1 控制台创建：从头开始

选择「从头创建」，按下面这张表填就行：

配置项	推荐值	说明
函数名称	`log-audit-patrol`	见名知意，表明职责
运行时	Python 3.12	我习惯用最新稳定版，生态好
架构	x86_64	兼容性最好，省钱省心
权限	创建基础角色	系统会帮你建一个最小权限角色

我的小习惯：函数名用连字符（-）而不是下划线（_）。Lambda 资源 ARN 里连字符可读性更好，排查问题时一眼就能认出来。

点击「创建函数」，大概等 5 到 10 秒。你会看到一个在线代码编辑器，左边是函数代码，下面是测试事件配置。我个人觉得 AWS 这个编辑器做得还不错 —— 对于简单的日志巡检来说，完全够用，不需要本地 IDE。

3.2 配置定时触发器：EventBridge 才是核心

创建完函数，页面会自动跳到函数详情页。往下翻，找到「触发器配置」区域。点击「添加触发器」。

在触发器列表里，选择 EventBridge (CloudWatch Events)。这里要说明一下：EventBridge 是 CloudWatch Events 的升级版，功能更多。但 Lambda 控制台里它俩的入口是分开的。我建议直接用 EventBridge。

配置内容如下：

规则类型 → 选择“创建新规则”
规则名称 → patrol-every-5min
调度表达式 → 选择“Cron 表达式”

表达式填什么？我们想要每 5 分钟触发一次：

cron(0/5 * * * ? *)

你看，这个 Cron 格式跟 Linux 的有点不一样。它有 6 个字段，多了一个「年份」字段（最后一位）。而且「星期几」和「月份中的日期」不能同时指定，要留一个为 ?。我曾经在这个坑里摔过一次 —— 写了个 * 代替 ?，结果函数在特定日期就是不触发，查了半天才发现。

Cron 位置	含义	示例取值
第 1 位	分钟	`0/5` 表示从 0 分开始，每 5 分钟
第 2 位	小时	`*` 表示任意小时
第 3 位	日	`*` 表示任意天
第 4 位	月	`*` 表示任意月
第 5 位	星期	`?` 表示不指定
第 6 位	年份	`*` 表示任意年份

注意：cron(0/5 * * * ? *) 与 cron(*/5 * * * ? *) 不一样！前者在整点 0,5,10... 分钟触发；后者在每分钟的 0,5,10... 秒触发，触发次数会非常频繁。谨慎选择。

点击「添加」，触发器就配置好了。回到函数详情页，你会看到触发器列表里多了一条记录，状态显示为“已启用”。

3.3 编写测试事件：模拟触发

好，代码还没写呢。我们来写一段最简单的日志打印代码：

import json
import logging
from datetime import datetime

# 配置日志输出
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    """
    定时巡检入口函数
    每次触发记录当前时间 + 事件来源
    """
    now = datetime.utcnow().isoformat()
    source = event.get('source', 'unknown')
    
    message = f"[巡检日志] 时间: {now} | 来源: {source}"
    logger.info(message)
    
    # 返回结果给 Lambda 执行环境
    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': message,
            'timestamp': now
        })
    }

我个人写 Lambda 函数时，有个固定习惯：把日志级别设置为 INFO，并且每条日志都带上时间戳和事件来源。这看起来不起眼，但在排查触发次数、判断延迟时特别有用。

写完代码，点击「Deploy」。别忘！很多新手在这里栽跟头 —— 代码改了半天，没部署，触发的还是老版本。

接下来，测试。点击页面右上角的「Test」按钮，弹出一个配置测试事件的窗口：

事件名称 → TestEvent
事件 JSON → 选默认模板，或者用这个：

{
  "source": "aws.events",
  "detail-type": "Scheduled Event",
  "resources": [],
  "detail": {},
  "time": "2024-01-01T00:00:00Z"
}

点击「创建」，然后点击「Test」。稍等几秒钟，你会看到返回结果：

{
  "statusCode": 200,
  "body": "{\"message\": \"[巡检日志] 时间: 2024-01-01T00:00:00 | 来源: aws.events\", \"timestamp\": \"2024-01-01T00:00:00\"}"
}

绿色勾号表示执行成功！这时候，去 CloudWatch Logs 里看看：

在 Lambda 页面点击「监控」标签
点击「查看 CloudWatch 日志」
你会看到一个以 /aws/lambda/log-audit-patrol 命名的日志组
点进去，能看到刚才测试生成的日志流

日志内容大概长这样：

START RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Version: $LATEST
[巡检日志] 时间: 2024-01-01T00:00:00 | 来源: aws.events
END RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
REPORT RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Duration: 2.10 ms Billed Duration: 3 ms Memory Size: 128 MB Max Memory Used: 38 MB

检查一下：Duration 只有几毫秒，说明函数执行很快。Max Memory Used 38 MB，远低于 128 MB 限制。这是正常现象。如果你的 Duration 超过 1000 ms，就要考虑优化代码了。

3.4 验证定时触发是否生效

配置完 Cron 触发器之后，怎么确认它真的在按计划跑？你可以等 5 分钟，然后去 CloudWatch Logs 里看日志组。正常情况下，每 5 分钟会新增一条日志流。

不过我个人更常用的方法是：手动缩短 Cron 间隔，先测一分钟的版本。把表达式改成 cron(* * * * ? *) —— 每分钟触发一次。等看到日志稳定输出后，再改回 cron(0/5 * * * ? *)。这样一来，你能快速确认触发器配置是对的，而不是傻等 5 分钟。

避坑提醒：测试完记得改回来！我曾经有一次忘了改回到正常频率，结果每分钟触发一次的函数跑了整整一个周末。月底看到账单时，虽然没花多少钱（Lambda 费用极低），但 CloudWatch Logs 的存储费用确实涨了不少。

好，到这里，你已经成功创建并测试了一个定时 Lambda 函数。它每 5 分钟打印一次巡检日志。后面的章节，我们会在这个基础上，加入真正的日志分析和报警逻辑。