Logstash有多种Input、Filter和Output插件。发送到Elasticsearch、调用HTTP接口、写入消息队列或云服务时，插件可能使用不同协议和客户端。给Logstash JVM增加一个全局代理参数，并不能证明每种Output都会按相同方式联网。
先判断事件卡在哪个阶段
Input没有收到事件、Filter报错、Output无法连接，表面上都可能表现为目标端没有新数据。应同时观察Pipeline事件计数、插件错误、队列深度和目标端响应。先用本地受控输出确认事件确实通过Filter，再集中排查网络Output。
不同Output的网络边界
| Output类型 | 常见协议 | 代理注意 |
|---|---|---|
| Elasticsearch Output | HTTP/HTTPS | 插件连接配置、认证、CA与连接池 |
| HTTP Output | HTTP/HTTPS | 插件自身代理支持、请求重试 |
| Kafka/RabbitMQ | 专用TCP协议 | 普通HTTP代理通常不适用 |
| 对象存储或云服务 | 服务API | SDK、区域端点和凭据链 |
JVM代理参数为何不是万能配置
Logstash运行在JVM上，但插件可以使用各自的HTTP库和配置选项。有的读取JVM系统属性，有的要求插件级代理，有的根本不是HTTP协议。应查当前插件版本的配置说明，并从实际连接验证，不要只看进程参数。
Elasticsearch Output常见误区
Elasticsearch地址可能指向负载均衡器、多个节点或云端入口。认证成功后，批量写入仍可能遭遇429、413、502或读取超时。代理若限制请求体大小，会让小型健康检查成功、Bulk请求失败。
状态码如何判断
- 407：正向代理认证；
- 401/403：Elasticsearch或HTTP目标权限；
- 413：请求体超过代理或上游限制；
- 429：目标限流或写入压力；
- 502/504：代理上游连接或超时；
- x509错误：Logstash环境不信任证书。
持久队列能解决什么
Persistent Queue可以在Output暂时不可用时把事件保存在磁盘，帮助Logstash重启恢复。但容量有限，磁盘写满还会影响Pipeline。应按峰值事件速率和预计故障时间估算队列，并监控未确认事件、磁盘空间和最老事件年龄。
重试与死信队列不是一回事
网络错误通常由Output插件按规则重试；某些无法写入的事件可进入死信队列，但支持范围取决于插件和错误类型。持续401或字段映射错误不应无限重试。运维人员需要明确哪些错误可恢复、哪些应隔离处理。
TLS与证书放在哪里
Logstash容器或主机需要信任Elasticsearch、HTTP目标或企业代理使用的合法CA。Java信任库和插件CA文件的配置方式可能不同。证书轮换后，应滚动重启并验证每个实例，避免高可用集群中只有部分节点失败。
Java网络与证书边界可参考Java程序代理配置。
日志事件本身如何避免泄露
开启调试时不要输出完整Authorization、代理URL或带个人信息的事件正文。Logstash处理的原始日志可能含Cookie、查询参数和令牌，应在Filter阶段做最小化与脱敏，并限制死信队列和持久队列文件权限。
排查步骤
- 记录Logstash与Output插件版本；
- 确认事件已通过Input和Filter；
- 识别插件协议与代理支持；
- 区分407、目标认证、413、429和TLS；
- 观察持久队列、重试和磁盘；
- 用少量脱敏测试事件验证；
- 恢复正常日志级别并清理秘密。
结论
Logstash代理配置必须针对具体Output。先确认插件协议和客户端，再处理队列、批量大小、认证与证书，才能防止进程看似健康、日志却长期积压在磁盘里。
