feat(alertmanager): add alertmanager package

[grandwizard28]

Summary

Add a dedicated package for alertmanager

Related Issues / PR's

Closes https://github.com/SigNoz/platform-pod/issues/404

---

Important

Introduces a new alert management package with server setup, configuration, and state management using Prometheus Alertmanager.

• Behavior:
  • Introduces Server in server.go to manage alerts, silences, and notification logs using Prometheus Alertmanager.
  • Implements Start, Stop, SetConfig, and PutAlerts methods for server lifecycle and alert management.
  • Adds maintenance routines for silences and notification logs.
• Configuration:
  • Defines Config, RouteConfig, SMTPConfig, AlertsConfig, SilencesConfig, and NFLogConfig in config.go for alertmanager settings.
  • Provides default configuration setup and validation.
• State Management:
  • Implements memoryalertmanagerstore for in-memory storage of silences and notification logs.
  • Defines State, Config, Alert, and Receiver types in alertmanagertypes for alert and config handling.
• Error Handling:
  • Introduces custom error codes and handling in errors.go and code.go.
  • Provides error wrapping and unwrapping utilities.
• Testing:
  • Adds tests for server start/stop and default configuration in server_test.go.
  • Tests error handling and response rendering in render_test.go.

^{This description was created by for 0688b72. It will automatically update as commits are pushed.}

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 0688b72 in 2 minutes and 32 seconds

More details

• Looked at 2583 lines of code in 22 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. pkg/alertmanager/alertmanagerserver/server.go:173

• Draft comment:
  Check the error returned by NewAlertsFromPostableAlerts before proceeding to put alerts. This ensures that any conversion errors are handled appropriately.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The code appears to be deliberately structured to prioritize sending notifications over validation errors. The comment on line 175 explicitly states this is intentional behavior. The suggestion to check errors first would actually go against this design choice. The current implementation matches the stated intent.
  I could be wrong if there are serious validation errors that should never be ignored, or if sending invalid alerts could cause system issues.
  The code comment clearly documents this as an intentional design choice to prioritize notification sending. If this was dangerous, it likely wouldn't be explicitly documented as intended behavior.
  The comment should be deleted as it suggests changing intentionally designed behavior that is already documented in the code comments.

2. pkg/alertmanager/alertmanagertypes/config.go:76

• Draft comment:
  Validate the config after unmarshalling to ensure it is correct and complete. This can prevent issues with invalid configurations being used.
• Reason this comment was not posted:
  Comment did not seem useful.

3. pkg/alertmanager/alertmanagertypes/config.go:158

• Draft comment:
  Handle the case where the receiver or route to be deleted does not exist. This can prevent unexpected behavior when attempting to delete non-existent entries.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment points out a legitimate issue - the Delete method doesn't indicate whether the deletion was successful or if the item didn't exist. However, this could be an intentional design choice to make deletion idempotent. Without more context about the intended behavior or system requirements, we can't be certain that this is actually a problem that needs fixing.
  I might be overvaluing the importance of explicit error handling. Silent failure could be the desired behavior for idempotent operations.
  While idempotency is valuable, providing feedback about operation success can help with debugging and user experience. The comment raises a valid point worth considering.
  The comment raises a valid concern about error handling, but without more context about the intended behavior, we can't be certain it's an issue that needs fixing.

4. pkg/alertmanager/alertmanagerstore/memoryalertmanagerstore/provider.go:19

• Draft comment:
  Consider adding parameters to the New function to allow setting initial values for Silences, NFLog, and Config. This can be useful if these need to be pre-populated.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The New function in provider.go initializes a provider with default values but does not provide any mechanism to set initial values for Silences, NFLog, or Config. This could lead to issues if these need to be pre-populated.

5. pkg/alertmanager/alertmanagerserver/server.go:1

• Draft comment:
  Avoid using the component/index.tsx file structure approach, as it makes it difficult to debug and find components using global search tools like VS Code.
• Reason this comment was not posted:
  Comment was on unchanged code.

Workflow ID: wflow_jKduOyH0wG9QMlCa

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.