从0到1搭建Puppet：日志收集方案 | 零故障部署

▌ 技术引导
我见过太多人用Puppet部署日志收集方案，要么砸钱买商业产品，要么自己写脚本，结果要么效率低下，要么系统挂掉。Puppet不是万能的，但它是日志收集场景中最值得信赖的工具之一，尤其在零故障部署方面，如果你做到了配置自动化、状态管理、监控反馈，系统能稳定运行365天。我用过Logsene、Fluentd、Logstash，但最终还是踩着Puppet的模板、模块和资源类型搭建了自己的一套日志采集系统。关键在资源类型选型、配置文件组织、依赖关系处理，还有错误恢复机制。别相信模板能直接复制粘贴，必须根据实际环境做本地化调整，否则分分钟让你的系统日志变成死日志。日志收集方案要能自愈，比如在服务重启后自动重新绑定日志路径，否则你得半夜看日志报错。我用的是Puppet的file资源配合logrotate，还有自定义的logstash模块，确保每一步都可控。

▌ 技术参考
Puppet是基于声明式语言的配置管理工具，核心是资源类型与资源定义。日志收集方案中，我常用的是`file`、`exec`、`package`、`service`这四个资源类型。`file`用来创建日志配置文件，`exec`用于启动或停止日志服务，`package`确保日志工具已安装，`service`用于管理日志服务的运行状态。比如在配置logrotate时，用`file`资源定义路径，用`exec`资源调用`logrotate -f /etc/logrotate.d/app.log`，定期刷新日志。如果日志路径变更，必须在`file`资源中提前设置变量，避免硬编码。


在部署过程中，我用`Package`资源确保logrotate已安装，使用`ensure => latest`来保持版本更新，不过要注意，有些Linux发行版可能自带旧版本，需要在`Package`资源中指定`source`，或者通过`apt`、`yum`模块指定仓库。比如在Debian系统中，`package { 'logrotate': ensure => latest, provider => 'apt'}`。同时，为了防止logrotate执行失败影响主服务，我设置了`onlyif`条件，检查`/etc/logrotate.d/app.log`是否存在再执行。这样即使配置文件没准备好，也不会误触发服务重启。


日志收集方案需要考虑日志存储路径、权限、轮转策略。我一般用`file`资源确保日志目录存在，并设置`owner => root, group => root, mode => '0755'`。有时候会遇到权限问题，比如`/var/log/app`没有被正确挂载或者被其他进程占用。这时候需要用`exec`资源检查目录是否存在，并用`file`资源强制创建。比如`exec { 'create_log_dir': command => 'mkdir -p /var/log/app', onlyif => 'test -d /var/log/app || true'}`。这部分配置需要特别注意，特别是多用户环境，权限弄错会导致日志无法写入。


我用过Fluentd和Logstash作为日志收集工具，但最终还是选了Logstash作为入口。Logstash的配置文件结构清晰，包含input、filter、output三个部分。我通常在`input`部分用`file`类型监听日志路径，配置`path => /var/log/app/.log`，`start_position => beginning`确保日志不会漏掉。在`filter`中，用`grok`解析日志格式，比如`%{TIMESTAMP_ISO8601:timestamp} %{DATA:level} %{NOTSPACE:message}`，这样日志就能被结构化处理。配置文件路径一般放在`/etc/logstash/conf.d/`下，并用`file`资源管理，这样更新更方便。


日志收集方案必须具备自愈能力，否则单点故障会直接导致服务崩溃。我在Puppet中通过`exec`资源写了一个简单的自愈脚本，检查Logstash服务状态，如果失败则重启。比如`exec { 'restart_logstash': command => '/etc/init.d/logstash restart', refreshonly => true, onlyif => 'ps aux | grep -v grep | grep logstash'}`。这个逻辑会判断Logstash是否在运行，如果没运行则触发重启。不过还要注意，如果Logstash的日志文件被误删，这个脚本可能无法恢复，需要配合`file`资源做备份。


在处理日志轮转时，我用`logrotate`配合`logstash`，确保日志不会无限增长。配置文件中会设置`daily`、`rotate 7`、`compress`等参数。不过很多人会遇到一个问题：logrotate没按预期工作。我遇到过日志文件名不匹配、权限不足、定期任务没执行等情况。解决方法是用`file`资源确保logrotate配置文件存在，并用`service`资源管理`logrotate`服务。比如`service { 'logrotate': enable => true, hasstatus => true, subscribe => File['/etc/logrotate.d/app.log']}`，让logrotate在配置文件更新后自动触发。


日志收集方案需要考虑性能问题，尤其是在高并发场景。我发现logrotate在高峰期会卡住，导致日志堆积。解决方案是用`logrotate`的`postrotate`指令触发logstash重载配置，比如`postrotate\n /etc/init.d/logstash reload\nendrotate`。这样可以避免logrotate执行时阻塞日志写入。另外，Logstash的filter部分如果处理不当，比如没设置`queue_type => memory`，可能会导致性能瓶颈。我一般会将`queue_type`设为`memory`，并配置`queue_max_bytes`，控制内存使用。


日志收集方案的部署需要确保一致性，尤其是在多节点环境中。我用的是Puppet的`node`分类和`classes`组合，每个节点有不同的日志策略。比如，内网节点用`file`收集，外网节点用`syslog`收集。这样能减少网络传输压力，提高效率。同时，我用`file`资源监控配置文件变化，触发logrotate或logstash重载。比如`file { '/etc/logstash/conf.d/app.conf': notify => Exec['restart_logstash'],}`。这样配置变更后会自动重启服务，避免手动干预。


日志收集方案中，配置文件的管理是关键。我将logstash的配置文件拆分成多个模块，比如`input.conf`、`filter.conf`、`output.conf`，每个配置文件对应一个`file`资源。这样便于维护和更新，避免配置混乱。使用`concat`模块合并多个配置文件，确保最终配置文件正确。比如`file { '/etc/logstash/conf.d/app.conf': content => concat_content('/etc/logstash/conf.d/input.conf', '/etc/logstash/conf.d/filter.conf', '/etc/logstash/conf.d/output.conf')}`。这样配置更清晰，也更容易排查问题。


日志收集方案要能与监控系统集成，否则很难发现故障。我用的是Prometheus加上Grafana，监控Logstash的JVM内存、GC时间、输入输出速率。具体配置是用`exec`资源启动`node_exporter`，并配置`/etc/prometheus/prometheus.yml`，将`logstash`作为目标。比如`exec { 'start_node_exporter': command => '/usr/local/bin/node_exporter --web.listen-address=:9101',}`。这样就能在监控界面上看到日志处理的实时状态，及时发现异常。


日志收集方案的部署要考虑网络延迟和丢包问题。我发现有时候logstash会因为网络不稳定导致日志丢失，用了`input`部分的`tcp`协议，配置`codec => line`，并设置`workers => 4`来提升吞吐量。但需要确保`tcp`端口开放，并且防火墙规则正确。比如在`input`中写`input {\n tcp {\n port => 5044\n codec => line\n workers => 4\n }\n}`。如果遇到端口占用或者连接超时，可以检查`netstat`，或者用`exec`资源重启`logstash`服务。


日志收集方案的稳定性取决于脚本的健壮性，我写过一个自愈脚本，检测`/var/log/app`目录是否存在，如果不存在则`mkdir`，并设置权限。比如`exec { 'check_and_create_log_dir': command => 'if [ ! -d /var/log/app ]; then mkdir -p /var/log/app && chown -R root:root /var/log/app; fi',}`。这个脚本在部署时会自动执行，确保日志目录存在。不过这个脚本不能放在`exec`资源中，而是用`file`资源的`require`和`notify`来触发，这样更安全。


日志收集方案的模块化设计很重要，我创建了一个名为`logstash`的Puppet模块，包含`params`、`manifests`、`templates`三个子目录。`params`用于定义变量，比如日志路径、输出地址；`manifests`包含主配置文件；`templates`用于动态生成日志配置。比如，`params.pp`中写`$log_path = '/var/log/app'`，然后在`manifests/init.pp`中引用这个变量。这样模块化后，换服务器、换日志路径、换输出地址都只需要改参数，不需要改动逻辑。


日志收集方案需要考虑错误日志的处理，我用`file`资源监控`/var/log/logstash/logstash.log`，一旦发现错误日志，就用`exec`资源发送告警。比如`file { '/var/log/logstash/logstash.log': notify => Exec['send_alert'],}`，然后在`send_alert.pp`中用`exec`调用`curl`发送告警到监控系统。这样能及时发现异常，避免日志系统崩溃。不过要注意，`send_alert`的`onlyif`条件要设置为`test -s /var/log/logstash/logstash.log`，防止空日志触发告警。


日志收集方案要能自动恢复，我用`exec`资源配合`systemd`，确保logstash在崩溃后能自动重启。比如`service { 'logstash': ensure => running, enable => true, subscribe => File['/etc/logstash/conf.d/app.conf'],}`。这个配置会让logstash在配置文件更新后自动重启，同时确保服务始终在运行。不过有时候logstash会卡住，这时候需要用`--force`参数重启，或者用`kill -9`强制杀掉进程，再启动。


日志收集方案的部署需要考虑权限问题，特别是`/var/log`目录下，有些系统默认权限严格，导致logstash无法写入日志。我用`file`资源设置`owner => root, group => root, mode => '0755'`，确保logstash有写入权限。如果遇到权限问题，可以用`chmod`和`chown`修复，但最好是用`file`资源统一管理，这样能避免人为操作失误。比如`file { '/var/log/app': owner => root, group => root, mode => '0755',}`。


日志收集方案要能适配不同系统，我写了多个`node`分类，比如`node 'linux' { include logstash }`，`node 'windows' { include logstash_windows }`。每个系统对应的配置略有不同，比如Windows用`eventlog`收集，Linux用`file`收集。这样能保证方案在不同平台上都能运行。不过要注意，Windows的`logstash`配置需要额外处理路径问题，比如`path => 'C:/Program Files/Logstash/logs/app.log'`，这个路径在Puppet中要写成`'C:\\Program Files\\Logstash\\logs\\app.log'`，否则会报错。


日志收集方案的部署要避免依赖冲突，我用`Package`资源确保logstash、logrotate、syslog-ng等工具已安装，并用`require`确保依赖关系正确。比如`package { 'logrotate': ensure => installed, require => Package['logstash']}`。这样能避免因为依赖缺失导致部署失败。如果遇到依赖版本冲突，可以手动指定版本号，或者用`ensure => latest`确保版本一致。


日志收集方案要能通过测试验证，我写了一个简单的测试脚本，模拟日志写入，并检查是否被正确采集。比如用`echo "Test log" > /var/log/app/test.log`，然后用`file`资源监控该文件，再用`exec`资源调用`logstash`命令确认日志是否被处理。这个测试能提前发现问题，比如路径错误、权限不足、配置缺失。不过要确保测试脚本不会影响真实日志写入，最好在测试环境中运行。


日志收集方案要考虑日志保留策略，我用`logrotate`配合`/etc/logrotate.d/app.log`配置日志保留天数，比如`rotate 7`，并设置`compress`压缩旧日志。这样能节省磁盘空间，同时保留历史数据。如果遇到日志文件过大，可以用`size`参数控制文件大小，比如`size => 100M`。不过要注意，压缩后的日志可能无法被某些分析工具读取，需要配置`input`部分支持.gz格式。


日志收集方案需要定期刷新配置，我用`file`资源的`subscribe`属性，让logstash在配置文件更新后自动重载。比如`file { '/etc/logstash/conf.d/app.conf': subscribe => File['/etc/logstash/conf.d/input.conf'], notify => Exec['reload_logstash']}`。这样能确保配置变更后服务及时更新，而不需要重启整个服务。如果配置文件没被正确加载，可以用`logstash -t -f /etc/logstash/conf.d/app.conf`手动验证。


日志收集方案的部署要考虑多租户环境，我用`file`资源为每个租户生成独立的日志配置，用`$tenant_id`变量替换路径。比如`path => "/var/log/app/${tenant_id}/app.log"`，然后在`manifests/init.pp`中定义`$tenant_id`。这样能确保不同租户的日志不会互相干扰，也能方便管理。不过在生产环境中，每个租户的日志目录需要独立管理，避免权限混乱。