# kube-eventer: pushing Kubernetes Normal and Warning events out to chat and databases

> kube-eventer watches cluster events and forwards them to sinks such as dingtalk, Kafka, Elasticsearch, InfluxDB and MySQL, so a Warning does not die in kubectl output. The project is Apache 2.0 licensed, but its last push was on 2026-04-14 and its own manifest still points at a 2023 image tag.

**AliyunContainerService/kube-eventer** — kube-eventer emit kubernetes events to sinks 

- Repository: https://github.com/AliyunContainerService/kube-eventer
- Stars: 1,092 · Forks: 293
- Language: Go
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/aliyuncontainerservice-kube-eventer

## The problem: a Warning event exists for minutes, then kubectl output scrolls away

Kubernetes events are short lived by design. The core of the platform is a state machine, so a Normal event marks a transition into the desired state and a Warning event marks a transition into an unexpected one, and the documentation is explicit that kube-eventer exists to help diagnose, analyse and alarm on problems. The practical gap is delivery. By default a Warning shows up when you happen to be running kubectl describe, and it is gone from the terminal soon after. kube-eventer is an event emitter that reads those events and pushes them to a sink, so the same Warning lands in a chat channel or a database where something else can watch it. The audience is an operator or platform team that already has a chat or logging system and wants cluster events in it, rather than someone who needs to build an alerting product from scratch.

## Sources and sinks: the pipe runs from a source URL to a parameterised sink

The repository layout makes the architecture visible. The sources/ directory holds where events come from, the sinks/ directory holds where they go, and core/, manager/, common/ and util/ hold the machinery in between, with api/ and metrics/ alongside them. The single binary at the repository root, eventer.go, is wired up by two command line flags in the documented deployment. The source flag names a kubernetes source with an API server address, and the sink flag names a sink type followed by its own parameter string, a colon and then ampersand-separated parameters. One process can be pointed at a different sink by changing that string, which is what makes the tool usable without a config file. The documented sink table lists ten targets: dingtalk, sls, elasticsearch, honeycomb, influxdb, kafka, mysql, wechat, webhook and mongodb, each with its own documentation page under docs/en.

## Deploying the sample manifest and what you should see

The documentation gives a complete Kubernetes Deployment, ClusterRole, ClusterRoleBinding and ServiceAccount as one YAML file, which is the quickest path to a running emitter. Three details in it are worth calling out before you copy it. The image is registry.aliyuncs.com/acs/kube-eventer:v1.2.7-ca03be0-aliyun, a tag that corresponds to the v1.2.7 release from 2023-05-31 rather than the newest published release, so deploying the sample as written means running an older build. The container gets a service account named kube-eventer, and the ClusterRole grants get, list and watch on configmaps and events in the core API group, which is the entire permission surface the emitter needs. The container also mounts host time zone files read only and sets a TZ environment variable, because event timestamps in a chat message are only useful if they line up with the reader's clock.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: kube-eventer
  name: kube-eventer
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kube-eventer
  template:
    metadata:
      labels:
        app: kube-eventer
    spec:
      serviceAccount: kube-eventer
      containers:
        - image: registry.aliyuncs.com/acs/kube-eventer:v1.2.7-ca03be0-aliyun
          name: kube-eventer
          command:
            - "/kube-eventer"
            - "--source=kubernetes:https://kubernetes.default"
            - --sink=dingtalk:[your_webhook_url]&label=[your_cluster_id]&level=[Normal or Warning(default)]
          env:
          - name: TZ
            value: "Asia/Shanghai"
```

## The level filter decides whether your chat group becomes noise

The sink parameter string in the documented example ends with level, and the comment marks Normal or Warning as the choice with Warning as the default. That single parameter is the most consequential line in the whole manifest. A cluster in a steady state still emits Normal events for every scheduled operation, so pointing the emitter at a level that includes them fills a chat channel with a continuous stream of pod images pulled and deployments scaled. Leaving it at Warning gives you a channel that only speaks up when something looks wrong. The label parameter carries a cluster identifier, which is what lets one sink receive events from several clusters and still be readable. Both values are embedded in the flag string, so changing either means editing the Deployment and letting the pod restart, and the sink is configured at process start rather than through a file that could be reloaded.

## Ten sinks, each documented separately, and a generic webhook for everything else

The sink table is where the project's breadth shows. Two sinks are chat oriented, dingtalk and wechat, which is the chatops use case the documentation demonstrates end to end with a bot token from a group. Two are log oriented, sls for the Alibaba Cloud log service and honeycomb. Two are time series or document stores, influxdb and elasticsearch, the latter wired through the olivere/elastic client at version v7. Two are relational or document databases, mysql through the go-sql-driver and mongodb through the mongo-driver. Kafka is present through the Shopify sarama client, and a generic webhook sink exists for anything not on the list. The trade-off is that each sink is a separate code path with its own documentation page, so behaviour on a given sink, including exactly how the event is serialised, has to be read sink by sink rather than assumed from a general model.

## Building from source: the Makefile pins a default version that is not the newest release

The Makefile in the repository root builds a single static binary with CGO disabled and stamps the version and git commit into it through ldflags, and it cross compiles for amd64, arm, arm64, ppc64le and s390x. The build target is preceded by a clean step, and test-unit runs the format and vet checks from the hack/ directory before building and then runs the Go tests with the race detector on amd64. Two details tell you how to treat this as a pinned artefact rather than a rolling one. The VERSION variable defaults to v1.2.0, which is older than both the v1.2.7 tag in the sample manifest and the 1.2.14 release, so a plain make build produces a binary reporting a version from 2020 unless you override VERSION. The module also vendors its dependencies in a vendor/ directory, and go.mod declares go 1.24 as the language and toolchain requirement while pinning the Kubernetes client libraries at k8s.io/api, apimachinery and client-go v0.17.16.

```bash
make build

GOARCH=$(ARCH) CGO_ENABLED=0 go build -ldflags "$(KUBE_EVENTER_LDFLAGS)" -o kube-eventer  github.com/AliyunContainerService/kube-eventer
```

## Client libraries from the 1.17 era against a modern API server

The dependency list is where a careful reader should stop and check. The module requires k8s.io/api, k8s.io/apimachinery and k8s.io/client-go at v0.17.16, which corresponds to the Kubernetes 1.17 generation, alongside much newer libraries such as the AWS SDK for Go at v1.34.28 and the Alibaba Cloud EventBridge SDK. A client-go that old is a genuine compatibility question for clusters running current control planes, because the emitter talks to the API server through that library and not through raw HTTP. The documentation does not address this, and it does not describe a minimum or maximum supported Kubernetes version anywhere in the README. The repository also carries a .travis.yml and a Makefile whose test path runs against the vendored tree, so upstream CI is Travis based rather than a modern GitHub Actions workflow, which is a sign of the age of the build setup as well as of the dependency pins.

## Maintenance state: a 2026 release, a 2023 image tag and an April push

The version history is uneven. Releases are listed for v1.2.0 on 2020-06-02, v1.2.7 on 2023-05-31 and 1.2.14 on 2026-01-06, so the project did publish a recent build, even though the numbering jumps from the v1.2.x tags to a bare 1.2.14 tag. The last push to the repository was on 2026-04-14, which is more than six months ago, so the project should not be described as actively maintained, and any statement to the contrary would be guesswork. The repository is not archived, and the licence is Apache 2.0, which is permissive and imposes no copyleft obligation on code that merely links against it. The documentation points contributors at a CONTRIBUTING.md file and points users at two Dingtalk groups, one of which it labels as full, which is a reasonable picture of a project with a small community and no large maintainer bench.

## Conclusion

kube-eventer suits an operator who wants Warning events delivered into a chat group or a log store that survives the terminal, and who is prepared to pin a specific image tag because the sample manifest in the documentation is not current. It is the wrong tool for a team that wants the event stream to be a durable, replayable log of its own, since the sinks are push targets rather than a queryable store, and it is a poor fit for clusters where the Kubernetes client libraries the module pins are too old for the API server in front of them. Before adopting it, check the image tag you deploy against the release list, since the documented manifest uses v1.2.7 while the newest published release is 1.2.14 from 2026-01-06, and verify the RBAC rules cover only the events and configmaps the watcher needs.

## FAQ

### What does kube-eventer do in a Kubernetes cluster?

It watches Kubernetes events and forwards them to external sinks so that Normal and Warning entries reach a chat bot or a database instead of scrolling away in the terminal. The documentation frames it as helping to diagnose, analyse and alarm on problems.

### Which sinks does kube-eventer support?

The documented sink table lists dingtalk, sls, elasticsearch, honeycomb, influxdb, kafka, mysql, wechat, webhook and mongodb, with a separate documentation page for each under docs/en. The generic webhook sink covers targets that are not on the list.

### How do I deploy kube-eventer and send events to a dingtalk bot?

Add a chatbot to a Dingtalk group to get a bot token, then apply the sample Deployment, ClusterRole, ClusterRoleBinding and ServiceAccount from the documentation, replacing the webhook URL in the sink flag. The sink parameter string also takes a label for the cluster id and a level of Normal or Warning, with Warning as the default.

### What permissions does kube-eventer need?

The documented ClusterRole grants get, list and watch on configmaps and events in the core API group, and the deployment runs under a service account named kube-eventer in the kube-system namespace. No other resource rules are listed.

### How current is the kube-eventer release history?

The last push to the repository was on 2026-04-14, and the newest listed release is 1.2.14 from 2026-01-06, after v1.2.7 from 2023-05-31. The sample manifest in the documentation still references the v1.2.7 image tag, so the version you deploy should be checked before you copy it.

## Sources

- [AliyunContainerService/kube-eventer on GitHub](https://github.com/AliyunContainerService/kube-eventer)
- [Issues](https://github.com/AliyunContainerService/kube-eventer/issues)
- [License: Apache-2.0](https://github.com/AliyunContainerService/kube-eventer/blob/master/LICENSE)
- [README](https://github.com/AliyunContainerService/kube-eventer/blob/master/README.md)
- [Releases](https://github.com/AliyunContainerService/kube-eventer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aliyuncontainerservice-kube-eventer