feat: system coverage, deploy verdicts and incidents
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- go
- Lĩnh vực
- backend-api-design, observability
Hướng nghiên cứu
Start with the existing System overview dashboard, deploy markers and split, alert rules, webhook delivery, and email sending described in the issue. Then trace how Fanout accepts and processes OpenTelemetry data, and review the Collector receiver and CI/CD semantic convention details referenced here. Done means the database, queue, and TLS panels, deploy verdicts, panel alerts, incidents, and email delivery work end to end as listed; the issue says each part ships separately.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Goal
Fanout becomes the one place to see a whole system and act on what goes wrong in it. It keeps doing only what it does today — accept OpenTelemetry data and do everything after that — and builds on what already exists: the System overview default dashboard, deploy markers and the deploy split, alert rules with webhook delivery, and Fanout's email sending.
Principle
The boundary is the input, not the feature set. Telemetry arrives only as OpenTelemetry, a standard, so anything that sends OTLP works without a Fanout integration. On top of that data Fanout should be rich and full-featured: dashboards, analysis, alerts, deploy verdicts and incidents all belong here.
1. More of the system on System overview
Recognise standard Collector receiver output and present it, with no per-source integration in Fanout:
- Databases and queues from the
postgresql,mysql,redisandkafkametricsreceivers: connections, slow or failed queries, replication lag, consumer lag. Panels appear when their data exists and their descriptions name the receiver otherwise. - TLS certificate expiry from the
tlscheckreceiver: days until expiry per endpoint, bad when close. - The Send telemetry guide gains the receiver configuration for each.
2. Know what changed, and whether it broke something
- Real change events. Accept deploys and pipeline runs that arrive as OpenTelemetry data (the CI/CD semantic conventions, or the Collector's
githubreceiver) and draw them as deploy markers, alongside today's markers inferred from a newservice.version. - A verdict for each deploy — pass, fail or inconclusive — from the existing before-and-after deploy split, shown on the marker and in the System overview versions table.
3. Act on problems: incidents on top of alerts
- Alerts on dashboard panels, so a System overview panel turning bad (a filesystem above 90%, a host not reporting, a check with no recent result) can fire. Today alert rules see only per-service span and log rollups.
- Incidents: a firing alert opens one, with acknowledgement, an owner, and a timeline that includes nearby deploys; it is recovered only once the alert has stayed resolved.
- Email notifications next to webhooks, using the email sending Fanout already has.
Out of scope
Performance work (a scale benchmark, per-minute summaries, faster metric queries), AI and API cost tracking, and checks run by Fanout itself — Fanout does not gather or probe.
Done when
- A Collector with the receivers above produces database, queue and TLS-expiry panels on System overview, verified end to end through OTLP.
- A deploy event arriving as OpenTelemetry data appears as a marker with a pass, fail or inconclusive verdict.
- A panel-based alert opens an incident, it can be acknowledged and assigned, and it closes only after recovery holds; email and webhook delivery both work.
Each part ships on its own, in this order.
- Ngôn ngữ chính
- Go
- Star
- 6
- Fork
- 0
- Merge trung bình
- 2 giờ 25 phút
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của labstack/fanout
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của labstack/fanout
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area: watch bug priority: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
mariadb-operator/mariadb-operator#1962 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
eugenioenko/ttt#919 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày