事情本身不复杂，线索都在日志里。集群从单机 Nginx 换到 Kubernetes，Ingress-nginx 1.9 的访问日志里只有 host、path、status 三个字段，$http_user_agent 不在默认 format 里。上线一周 Grafana 上的蜘蛛流量始终为 0，安全组那边却拦了两次伪装成 Googlebot 的扫描。
第一反应是「前面那层 CDN 回源时把 UA 改写成固定串，源站看到的全是同一个值」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。默认的 log-format-upstream 只输出上游相关字段，UA 得自己加进 ConfigMap。另一种情况是日志经 Filebeat 写进 ES 后，索引模板把 UA 标成 keyword 且没进 mapping。
少数情况下是统计脚本按 user_agent 字段取值，Ingress 里实际叫 http_user_agent。
先确认实际生效的日志格式
kubectl -n ingress-nginx get cm ingress-nginx-controller -o yaml | grep -A3 log-format随后在 ConfigMap 里补上 UA 字段
log-format-upstream: '$remote_addr - $host "$request" $status $body_bytes_sent "$http_user_agent"'再往下重载后抓一条新日志验证
kubectl logs deploy/ingress-nginx-controller -n ingress-nginx --tail=5剩下的就是把采集规则里的字段名对齐
grok: %{IPORHOST:client_ip} %{DATA:host} %{QS:request} %{NUMBER:status} %{QS:user_agent}怎么算真的好了，看的是同一批现象。重载后新日志里能直接看到 Googlebot 与 bingbot 的完整 UA，按 UA 聚合的日请求数和 CDN 侧报表误差收敛到 3% 以内。
这里还有个坑。UA 是统计口径的基础，数字为零时先别怀疑蜘蛛不来，先确认日志里到底有没有这个字段。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。