4、策略执行点配置：配置文件详解、日志级别设置、性能参数调优
配置策略执行点，说白了就是告诉系统三件事：读哪个文件、记什么日志、跑多快。这三件事要是没捋顺，后面运维起来会非常痛苦。我见过不少团队，上线前随便改两下配置就扔到生产环境，结果出问题连日志都捞不到，性能瓶颈也找不到根因。
这一章，咱们就掰开揉碎，把配置文件的每个字段、日志级别的选择逻辑、以及性能参数怎么调才不翻车，一次性讲清楚。
4.1 配置文件详解：别让 YAML 坑了你
策略执行点的核心配置文件，通常叫 pep.yaml 或 policy-enforcer.yml。我个人习惯用 YAML 格式，可读性好，但缩进问题也最容易翻车。嗯，这里要注意：YAML 对缩进极其敏感，不要用 Tab，只能用空格。
一个典型的配置文件结构如下：
# pep.yaml - 策略执行点主配置
server:
host: "0.0.0.0"
port: 8443
tls:
enabled: true
cert_path: "/etc/pep/certs/server.crt"
key_path: "/etc/pep/certs/server.key"
engine:
mode: "enforcing" # enforcing | monitoring | disabled
policy_file: "/etc/pep/policies/default_policy.json"
cache_ttl: 300 # 策略缓存时间，单位秒
max_eval_depth: 10 # 最大嵌套评估深度
logging:
level: "INFO" # DEBUG | INFO | WARN | ERROR
output: "file" # file | stdout | syslog
file_path: "/var/log/pep/pep.log"
max_size_mb: 100
max_backups: 7
max_age_days: 30
performance:
worker_threads: 4
queue_capacity: 1024
request_timeout_ms: 5000
retry_count: 3
retry_backoff_ms: 200
关键字段解读：
engine.mode：我最常用的三个模式。enforcing 是生产模式，拒绝违规请求；monitoring 只记录不拦截，适合灰度验证；disabled 直接放行，一般用于紧急恢复。engine.cache_ttl：策略缓存时间。设太短（比如 10 秒）会导致频繁加载策略文件，CPU 飙升；设太长（比如 3600 秒）又可能策略更新不及时。我一般建议 300 秒起步。engine.max_eval_depth：防止策略递归过深导致栈溢出。我曾经遇到过策略里嵌套了 20 层条件，直接撑爆了线程栈。设个上限，保命用。
我的小技巧： 配置文件里所有路径都用绝对路径。别问我为什么——有一次我用了相对路径，结果 systemd 启动时工作目录不对，策略文件死活加载不上，排查了俩小时才发现是路径问题。
4.2 日志级别设置：多一分则肥，少一分则瘦
日志级别这事，说白了就是在信息量和性能之间找平衡。你想想看，生产环境开 DEBUG 日志，每秒几万条请求，磁盘 IO 直接被打满，系统响应时间瞬间翻倍。但要是只开 ERROR 级别，出了问题连上下文都看不到，排查起来像大海捞针。
我一般遵循这个原则：
| 环境 | 推荐日志级别 | 说明 |
|---|---|---|
| 开发环境 | DEBUG | 打印所有请求详情、策略评估过程、变量值 |
| 测试环境 | INFO | 记录请求摘要、策略命中结果、异常情况 |
| 预发布环境 | WARN | 只记录警告和错误，减少日志量 |
| 生产环境 | WARN 或 ERROR | 仅记录异常，配合采样日志做问题定位 |
日志配置示例：
logging:
level: "WARN"
output: "file"
file_path: "/var/log/pep/pep.log"
max_size_mb: 100 # 单个日志文件最大 100MB
max_backups: 7 # 保留最近 7 个备份
max_age_days: 30 # 日志保留 30 天
# 采样配置：生产环境按 1% 采样记录完整请求日志
sampling:
enabled: true
rate: 0.01
我曾经踩过的坑： 有一次生产环境出了个诡异问题，策略执行点偶尔会拒绝合法请求。我打开 DEBUG 日志想抓现场，结果日志量太大，直接把磁盘写满了，系统直接挂掉。后来我学乖了——生产环境永远不要开 DEBUG，真要排查问题，用采样日志 + 动态调整日志级别的方式。
关于日志轮转，我个人建议用 按大小轮转 + 按时间清理 的组合策略。单文件设 100MB 上限，保留 7 个备份，超过 30 天的自动删除。这样既不会丢日志，也不会撑爆磁盘。
4.3 性能参数调优：别让默认值害了你
性能调优这块，我见过太多人直接用默认配置上线。默认值通常是为了兼容最差环境，而不是为了最优性能。你想想看，一个 64 核的服务器跑着 4 个 worker 线程，这不是浪费吗？
核心参数调优清单：
| 参数 | 默认值 | 推荐范围 | 调优原则 |
|---|---|---|---|
| worker_threads | 4 | CPU 核心数 × 2 | IO 密集型任务可以适当增加，CPU 密集型则不宜超过核心数 |
| queue_capacity | 1024 | 2048 ~ 8192 | 根据峰值 QPS 估算，队列太长会增加延迟，太短会丢请求 |
| request_timeout_ms | 5000 | 1000 ~ 10000 | 取决于上游策略服务的响应时间，建议比上游超时时间略短 |
| retry_count | 3 | 2 ~ 5 | 重试次数太多会加剧系统压力，太少则容错不足 |
| retry_backoff_ms | 200 | 100 ~ 1000 | 指数退避策略，避免重试风暴 |
调优实战建议：
- 先压测，再调参。 用 wrk 或 locust 模拟真实流量，观察 CPU、内存、延迟、错误率四个指标。
- 一次只改一个参数。 我见过有人同时改了线程数、队列深度、超时时间，结果性能下降了，根本不知道是哪个参数导致的。
- 关注 99 分位延迟。 平均延迟会骗人，99 分位延迟才是用户体验的真实反映。
举个例子，假设你的服务器是 8 核 CPU，策略评估主要是 CPU 密集型操作（比如正则匹配、规则树遍历），那么 worker_threads 设 8 就差不多了。如果策略评估里还有大量数据库查询或 RPC 调用（IO 密集型），可以适当增加到 12 或 16。
performance:
worker_threads: 8 # 8 核 CPU，CPU 密集型任务
queue_capacity: 4096 # 预估峰值 QPS 2000，队列能缓冲约 2 秒的请求
request_timeout_ms: 3000 # 上游策略服务平均响应 500ms，设 3 秒足够
retry_count: 2 # 重试 2 次，总共尝试 3 次
retry_backoff_ms: 500 # 第一次重试等待 500ms，第二次 1000ms
我的压测经验： 调优完成后，一定要做 极限压测——把 QPS 压到正常峰值的 2 倍，看看系统什么时候开始丢请求、延迟什么时候开始飙升。这样你心里就有底了，知道系统的真实水位线在哪里。
最后说一句，配置不是写一次就完事的。业务在变，流量在变，策略复杂度也在变。我建议每季度 review 一次配置参数，结合线上监控数据做微调。嗯，这才是运维该有的节奏。