日志太多，靠眼睛看根本来不及
以前查服务器出问题，基本靠翻日志。一个服务挂了，登录机器，cd到log目录，tail -f看最新记录，grep关键字一条条筛。小规模系统还能应付，可现在动不动几十台机器，微服务一拆，每个请求跨五六个服务，日志分散在各处，再这么搞根本玩不转。
比如上周我们电商活动上线，订单服务突然响应变慢。按老办法，得一台台登录查日志，等找到是数据库连接池打满的时候，已经丢了三百多单。事后复盘，其实早有征兆——日志里连续出现"connection timeout"，但没人实时盯着。
把日志扔进大数据平台，问题自动浮出水面
后来我们把所有服务的日志统一采集，通过Filebeat发到Kafka，再写入Elasticsearch。前端用Kibana做可视化，关键指标做成仪表盘。现在只要打开页面，请求量、错误率、响应时间曲线全在上面。
有一次凌晨两点，报警提示某接口5xx错误突增。值班同事点开Kibana，发现错误集中在某个节点，进一步查日志内容，原来是本地缓存文件被误删，服务启动时加载失败。问题定位不到十分钟，比过去快了十几倍。
典型流程长这样
应用日志 -> Filebeat -> Kafka -> Logstash -> Elasticsearch -> Kibana中间Kafka抗住流量高峰，Logstash做字段解析和过滤，比如把JSON格式的日志拆成status、url、duration等字段，方便后续查询。
不只是查错，还能预判风险
我们把用户登录失败的日志单独建了索引，每天跑一次脚本统计同一IP的失败次数。前几天就发现某个IP在一分钟内试了47次密码，系统自动封禁并通知安全组，避免了可能的撞库攻击。
还有个例子，服务GC日志也被收集进来。通过分析Young GC频率和耗时趋势，提前发现内存泄漏苗头。上个月一个服务就是靠这个发现缓存没设过期时间，差点把堆撑爆。
大数据平台的好处不是“存得多”，而是“算得快”。一条日志是线索，百万条日志拼起来就是真相。别再手动grep了，早点把日志流接进平台，运维才能从“救火”变成“防火”。