[pull] main from SigNoz:main - #950
Merged
Merged
Conversation
) ## Description Adds **incident.io** as a native alert notification channel, using incident.io's HTTP alert source (Alert Events V2 API) - A channel is configured with the alert source's **URL + token**; title and description templates are prefilled with the same defaults as Jira/JSM. - Alerts fire and auto-resolve in incident.io; the description is markdown (incident.io renders it natively) and carries the usual deep links — **View in SigNoz, related logs, related traces**. - All rule labels (severity, team, custom labels) are sent as **metadata**, so users can map them to incident.io attributes and route/escalate on them. Notes and decisions for the reviewer (full details in the [discussion ticket and doc](SigNoz/pulse-pod#171)): - **Dedup:** one incident.io alert per notification group, keyed by the group key hash (same identity Jira uses). A resolve targets the same key; re-fires after resolve correctly open a fresh alert — no key rotation needed. - **Repeat notifications are no-ops on incident.io** (it drops duplicate firing events) — unlike Jira, we cannot append updated values to an open alert; operators click through to SigNoz for current values. - **Limits:** description capped client-side under incident.io's documented 512 KB payload limit; retries only on 429/5xx (documented limit: 120 events/min per source). - **Channel-level metadata:** optional key-value pairs on the channel config, merged into every event's metadata on top of the alert's labels (channel wins on key clash — Opsgenie precedent). Values are template-expanded; a value that fails to expand is sent raw with a warning logged, so delivery never breaks on a bad template. - Upstream alertmanager ships its own basic incident.io notifier — our config **shadows it** so the SigNoz notifier (templates, dedup, metadata) handles delivery. - Frontend (channel form) follows in a stacked PR. ## Issues closed by this PR Closes SigNoz/pulse-pod#172 --------- Co-authored-by: Naman Verma <naman.verma@signoz.io>
## Description Frontend for the **incident.io** alert channel (backend in #12644 — this PR is stacked on it). - Adds **incident.io** to the channel-type dropdown with a settings form: alert source **URL** + **token** (both required), and **title/description** template fields prefilled with the backend defaults — same UX as Jira/JSM. - A tip above the form links to the setup docs (create an HTTP alert source in incident.io, copy URL + token). - Client-side validation mirrors the backend for a nicer error experience: both fields required, URL must be an alert events URL (`…/v2/alert_events/http/<source_config_id>`). - `send_resolved` is seeded **on** so incident.io alerts resolve with the rule (backend can't default it — same reasoning as JSM). - **Additional metadata** section: key-value rows merged into every alert's metadata on top of the alert's labels (channel wins on clash); values may use templates. - Create, edit and test-channel flows all wired; editing prefills from the stored `incidentio_configs`. Notes for the reviewer: - Follows the JSM Ops form/handler pattern file-for-file; no new patterns introduced. - Tests: 4 create-flow cases (fields render, required-field error, URL validation error, payload shape with defaults) + 1 edit-flow payload case. ## Issues closed by this PR Closes SigNoz/pulse-pod#173 --------- Co-authored-by: Naman Verma <naman.verma@signoz.io>
<!--A few plain bullets saying what changed and why, for a reviewer skimming it - not a wall of text, not a restatement of the diff, not generated boilerplate.--> #### Description Convert the existing `name` to store an immutable DNS1123 internal name of a notification_channel, and add a display name column where the data from the existing `name` column will go. This is just a database level change. The internal name is not being used by any consumer, be it the API or rules or route policies. All that will come in subsequent PRs <!--Reference issues using `Closes #issue-number` to enable automatic closure on merge. --> #### Issues closed by this PR Part of SigNoz/pulse-pod#296 <!--Anything reviewers should keep in mind while reviewing --> #### Additional Information Eventually references (rules, routing policies) migrate onto the internal name, freeing the display name to become a user-editable. But that will happen post rules migration so that all rules are on v2. <!--Please delete paragraphs that you did not use before submitting.-->
#### Description
- Adds first-class ingestion limit APIs under
`/api/v2/gateway/ingestion_limits`: create (`keyId` in body), get,
update, and delete by `{limitId}`. Get proxies the new upstream `GET
/v1/workspaces/me/limits/{limitID}`.
- Adds key read APIs: `GET /api/v2/gateway/ingestion_keys/{keyId}` (key
by id — upstream does not embed limits here) and `GET
/api/v2/gateway/ingestion_keys/{keyId}/limits` (limits for a key, with
current-period usage metrics).
- Marks the existing limit routes (`POST
/ingestion_keys/{keyId}/limits`, `PATCH/DELETE
/ingestion_keys/limits/{limitId}`) as deprecated; they keep working
unchanged.
- Renames the old create body to `DeprecatedPostableIngestionKeyLimit`;
`PostableIngestionKeyLimit` is now the first-class body carrying
`keyId`. Handlers decode via `binding.JSON` and the create response is
`types.Identifiable`.
Part of SigNoz/platform-pod#2651.
#### Additional Information
- OpenAPI spec and the generated frontend client are regenerated; the UI
stays on the deprecated routes for now.
- Requires the upstream get-by-id endpoints from
SigNoz/opentelemetry-gateway#96 (merged and deployed).
## Pull Request --- ### 📄 Summary * Span list (raw) queries can now leverage trace-level `trace.` filter conditions leading to the trace-level component being qualified with `__trace_scope`. * An error is now raised if the span list is ordered by the trace level key. The following constraint is known: in case of ordering by `timestamp`, the querier processes the span list by time bucket thus performing trace-level aggregates calculation per bucket not within a time window. The records are kept separately. #### Issues closed by this PR Fixes SigNoz/engineering-pod#5976 --- ### ✅ Change Type _Select all that apply_ - [✅ ] ✨ Feature - [ ] 🐛 Bug fix - [ ] ♻️ Refactor - [ ] 🛠️ Infra / Tooling - [ ] 🧪 Test-only --- ### 🧪 Testing Strategy > How was this change validated? - Tests added/updated: ✅ - Manual verification: ✅ - Edge cases covered: --- ###⚠️ Risk & Impact Assessment > What could break? How do we recover? - Blast radius: None - Potential regressions: - Rollback plan:
#### Description Adds support for related values in ai observability field values. <!--Reference issues using `Closes #issue-number` to enable automatic closure on merge. --> #### Issues closed by this PR Closes SigNoz/engineering-pod#5975
#### Description The old API didn't support telemetryFieldKey, so adding a new v2 API to support it. This PR * Migrates old data to the new one. * Existing API's now internally stores it in the new struct so that they don't break the UI. <!--Reference issues using `Closes #issue-number` to enable automatic closure on merge. --> #### Issues closed by this PR Closes SigNoz/engineering-pod#5947 ## Additional details * the old api is safe with new field as it is just a subset of it.
#### Description - Moves all ingestion key and limit routes from the legacy `EditAccess` gate to `CheckResources` + `ResourceDef`s (kinds `ingestion-key` / `ingestion-limit`) with scoped security schemes. - Limit create checks `create` on the limit plus `attach` on the parent key; limit delete checks `delete` plus `detach`, resolving the parent key via the new upstream get-limit call. - Grants `attach`/`detach` on `ingestion-key` to the admin and editor managed roles; migration 120 backfills all ingestion tuples for existing organizations and refreshes the managed roles' `transaction_groups`. Stacked on #12625. #### Issues closed by this PR Closes SigNoz/platform-pod#2651 #### Additional Information - Wiremock fixtures now use UUID key/limit IDs — the metaresource FGA selector only accepts UUIDs. - Delete requests make one extra upstream GET (parent-key resolution) before the authz verdict, mirroring the serviceaccount extractor pattern.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )