📚 课程目录第4章基础参数

基础参数：日志级别、工作目录、进程名、端口绑定

调参这件事，很多人一上来就盯着算法参数猛调，结果发现日志都没开，进程跑在哪都不知道。嗯，我见过不少新手在线上环境里翻车，就是因为这四个基础参数没配好。

今天咱们就把这四个参数掰开揉碎。它们不复杂，但它们是整个 THS-PREPARE 实例的“身份证”和“看门狗”。每个参数都有坑，我踩过的坑也不少。

先说日志。有人觉得日志级别就是个开关，随便设个 info 就行。其实不是。我遇到过线上服务突然变慢，查了半天发现日志级别是 debug，每秒刷几万行日志，磁盘 IO 直接打满。

THS-PREPARE 提供了这几个级别，按严重程度排列：

我个人习惯在生产环境里先设 INFO。如果某个模块有问题，再临时改成 DEBUG 或 TRACE。注意改完之后一定要复原，否则日志增长会很吓人。

我曾经翻过的一个车： 在配置文件里写死了 TRACE，部署到生产没注意。结果两天后磁盘满了，整个系统都挂了。从那以后我每次部署都检查日志级别，并且加了监控告警。

# 配置文件示例：log_level.yml
global:
  log_level: "INFO"         # 生产推荐 INFO
  log_format: "%d [%p] %c - %m%n"
  log_path: "/var/log/ths-prepare/"

工作目录，说白了就是进程启动后所在的根目录。很多临时文件、相对路径的配置文件都依赖于它。如果配错了，程序会找不到文件。

我见过一个案例：有人把工作目录设成了 /tmp，结果系统重启清空了 /tmp，所有运行时生成的缓存文件全部丢失，服务启动失败。真事。

建议： 工作目录不要放在临时目录下，最好是一个独立的有写权限的目录。比如 /opt/ths-prepare/work 或 /data/ths-prepare。

# 启动命令中指定工作目录
ths-prepare --work-dir /opt/ths-prepare/work

# 或者写在配置文件中
work_dir: "/opt/ths-prepare/work"

另外要留意 Windows 和 Linux 的路径分隔符差异。我习惯统一用正斜杠，兼容性好。相对路径是以工作目录为基准的，所以脚本里尽量用路径，避免猜谜。

进程名的作用？举个例子：线上有十几个 THS-PREPARE 实例在跑，你用 ps aux | grep ths 一看全叫 ths-prepare，根本分不清谁是谁。

这时候就需要自定义进程名。我用 --proc-name 参数给它起个辨识度高的名字，比如 ths_reader_1、ths_writer_2。方便定位、也方便监控系统识别。

# 命令行启动
ths-prepare --proc-name "ths_reader_1" --config reader.yaml

# 实际上，进程名会显示为 ths_reader_1，而不是 ths-prepare

  注意： 进程名最大长度通常受操作系统限制（Linux 下是 15 个字符左右）。我建议控制在 10 个字符以内，太长会被截断，等于没起。

我曾经在一个集群里同时跑了 8 个实例，因为没给进程名，出问题的时候根本分不清日志和性能数据来自哪个实例。后来我加了个统一命名规范：项目名_角色_序号，比如 alert_digest_3。从此排查问题效率翻倍。

端口绑定，就是告诉 THS-PREPARE 实例在哪一个端口上监听外部请求。这个简单，但坑很多。

# 配置端口
server:
  bind: "0.0.0.0"
  port: 8080

# 或者命令行
ths-prepare --port 8080

⚠️ 避坑： 如果 bind 地址设为 127.0.0.1，只有本机可以访问。对需要提供外部服务的场景，一定要设成 0.0.0.0 或具体的网卡 IP。

好了，这四个基础参数看似简单，却是整个 THS-PREPARE 稳定性与可维护性的地基。把日志级别、工作目录、进程名、端口绑定做对了，后续再调算法参数才能安心。你想想看，如果一个实例连名字都没有，出了事你都找不到它，还调什么优？