Reason=FailedScheduling 的事件不会被收集到 SLS

[5long]

部署环境: 阿里云 ACK Managed K8S 集群 部署方式: 照搬这个项目 README 里的 manifest, 只用了一个 SLS Sink

实际效果:

• 在配置的 SLS logstore 处, 用 eventId.reason: Unhealthy 这样的语法查询, 可以读到 reason=Unhealthy 事件, 说明 kube-eventer 的配置正确.
• 手动部署了一个 resources.requests.cpu: 200 的 Deployment. 因为我们没有 200 核 CPU 的节点, 这会制造资源不足而无法部署 Pod 的事件
  • 在阿里云的 运维管理 => 事件列表里可以看到这制造了 FailedScheduling 事件
  • 用 kubectl get events -A --field-selector reason=FailedScheduling 也能看到此类事件
  • 在 SLS logstore 里却看不到此类事件.

期望效果: 在 SLS logstore 里也能看到 Reason=FailedScheduling 的事件. 因为这类事件的原因可能是配置错误 / 集群资源不足, 是运维人员需要重点关注的. 我们想要为这类事件在 SLS 上配置告警.

[ringtail]

FailedScheduling

原始事件是什么样子的

[5long]

刚刚重新制造了一下这类事件, 用 kubectl get -o yaml 输出了一份: https://gist.github.com/5long/f79c2f3a759512c72214d3506f6c8d5f

[ringtail]

刚刚重新制造了一下这类事件, 用 kubectl get -o yaml 输出了一份: https://gist.github.com/5long/f79c2f3a759512c72214d3506f6c8d5f

看了下，事件应该没有问题，会到SLS中，是报警没有出来吗

[5long]

看了下，事件应该没有问题，会到SLS中，是报警没有出来吗

如 Issue 标题所说，不会进 SLS。配置报警是最原始的需求，但现在日志不进 SLS，也就没法配置报警。

你所说的“会到SLS中”我可以尝试去重现。我该如何重现？

[ringtail]

有一种简单的方式，可以配置下钉钉的sink，确认下这个事件是否会被钉钉报警，原则来讲，钉钉和SLS的报警链路是一个，如果钉钉可以收到，SLS也是可以收到的。

[ringtail]

@5long 问题还可以复现吗？

[ringtail]

/rotten