共 4 篇相关文章
这篇讲的是作者在使用 Logstash 处理 Tengine/Nginx 通过 syslog 发送的访问日志时，遇到的几个实际性能瓶颈及优化方案。文章首先指出，在高压力下 Logstash 的 Grok 插件容易成为瓶颈，因此作者建议在日志格式可控时，优先考虑用分隔符格式配合 Ruby 脚本或自定义 LogFormat 来替代 Grok 解析。 然而真正的坑在后面：运行后发现日志接收带宽异常低，排查发现是 Logstash 的 syslog input 插件采用了单线程 UDP 监听，导致接收队列（Recv-Q）持续堆积。作者对比了 Fluentd 的异步实现，并考虑到 Logstash 基于 JRuby 的扩展复杂性，最终选择了一个更直接的方案：用 Perl 的高性能 AnyEvent 库重写了一个专门的异步日志收集脚本。这个脚本同样将日志输出为 Elasticsearch 兼容格式，使得原有的 Kibana 仪表盘无需任何改动。最终效果立竿见影，日志接收带宽从瓶颈时的 60 MBps 恢复到了正常的 300 MBps。
这篇讲的是日志管理工具Rsyslog的上手指南。作者从日志管理的重要性切入，提到业界热门的ELK三件套虽强，但自己更偏好快速上手的方案，由此引出Linux传统日志工具Syslog及其配置逻辑——通过Facility和Severity来分类和路由日志。面对Syslog在功能和性能上的不足，作者选择了当前多数发行版默认的Rsyslog。 文章重点在于快速实践。作者以CentOS为例，演示了通过RPM安装Rsyslog、关闭旧Syslog服务、启用调试模式等基础步骤。核心部分结合一个具体场景——“将多台Web服务器的access日志集中到一台App服务器”，详细拆解了Rsyslog的工作流程（输入、过滤、输出）。通过配置示例，讲解了如何在Web服务器端用`imfile`模块读取本地日志，并通过TCP发送；在App服务器端则开启TCP接收、使用`omfile`模块和模板来汇总存储。文中还提及了`StateFile`的持久化策略，以及利用`omprog`模块进行更高级处理的可能性。 作者最后也指出，Rsyslog的主要缺点在于版本间的兼容性差异较大，使用时需留意文档。整体而言，这是一篇注重实操、逻辑清晰的入门教程，适合希望快速部署集中式日志管理又不想陷入复杂生态的运维或开发人员。
这篇讲的是作者在安装了 Mate 1.4 桌面环境后，遭遇了一个烦人的问题：某些应用程序的图标莫名其妙地消失了，同时系统会闪现一个与 `mate-settings-daemon` 相关的错误提示。问题虽然看似不大，但足以破坏日常使用的体验。 为了揪出元凶，作者深入系统日志（`/var/log/syslog`）进行了排查。日志中明确的警告信息，最终将故障源头指向了负责管理桌面设置的 `mate-settings-daemon` 服务本身。文章详细记录了从发现问题、分析日志定位根因，到最终找到并实施解决方案的全过程。这个解决过程对于其他遇到类似 Mate 桌面环境稳定性问题的用户，具有直接的参考价值。
这篇讲的是如何将 MySQL 的错误日志统一纳入系统级日志管理，以提升运维效率。 作者从实际运维的痛点出发：默认情况下，MySQL 将错误日志写在数据目录下的 hostname.err 文件中。这导致日志分散，当服务器增多时，逐一排查非常不便，难以进行集中化的监控与分析。为了解决这个问题，文章详细介绍了利用 MySQL 的 log_error_verbosity 和 log_error 等参数，配合系统服务（如 rsyslog）的配置，将 MySQL 的错误日志重定向输出到 syslog 的具体步骤。 通过这样配置，MySQL 日志便能与其他系统日志（如内核、应用日志）汇聚到同一地方，方便使用 grep、journalctl 等工具统一检索和后续的集中式日志平台对接。这不仅仅是一个简单的日志路径变更，更是构建标准化、可扩展的日志体系的关键一步，为后续的日志分析与告警打下了基础。
