You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I understand ZoneMTA currently lacks a built-in health check system. While the Zone status (http://localhost:8080/counter/zone/) may be used, it's not clear from my understanding if this truly indicates ZoneMTA's readiness to send emails.
I'm using ZoneMTA behind Traefik for zero-downtime blue-green deployments, and a reliable health check is crucial for this setup.
Requested Feature
Implement hooks for a comprehensive health check system that verifies the entire email pipeline is functioning correctly (including setup outside of ZoneMTA itself). This system needs:
A startup hook that runs as soon as ZoneMTA is ready to start processing emails.
An optional shutdown hook for cleanup operations.
(A dedicated health check endpoint that accurately reflects ZoneMTA's operational status.)
Use Case
This feature would enable more reliable deployments, especially in scenarios like blue-green deployments, by ensuring that new instances are fully operational before being added to the load balancer.
Benefits
Improved reliability in various deployment scenarios
Reduced risk of serving traffic to partially operational instances
Enhanced ability to detect and respond to issues in the email pipeline
Better integration with container orchestration and service discovery systems
Proposed Implementation Details
Startup Hook:
Configurable through ZoneMTA's configuration file
Triggered when core services are initialized
Shutdown Hook:
Configurable cleanup operations to be performed when an instance is being taken out of service
Health Check Endpoint:
A new /health endpoint that returns detailed status information
Should include checks for critical components (e.g., database connections, queue status)
What I'm trying to do
I was thinking that on Startup as soon as ZoneMTA is ready it would add's itself to my database with an ID and send an email to a test inbox. When I was able to receive the email I automatically mark the the instance healthy in the database.
On termination of the instance I would remove the database entry.
A /health endpoint could be useful but I think it's better to test the whole pipeline like I described and have the /health endpoint return 2xx if the instance is marked as healthy in the database and a NOT 2xx response otherwise.
I can try to create a PR for this feature if it aligns with the project's goals.
The text was updated successfully, but these errors were encountered:
Current Situation
As far as I understand ZoneMTA currently lacks a built-in health check system. While the Zone status (http://localhost:8080/counter/zone/) may be used, it's not clear from my understanding if this truly indicates ZoneMTA's readiness to send emails.
I'm using ZoneMTA behind Traefik for zero-downtime blue-green deployments, and a reliable health check is crucial for this setup.
Requested Feature
Implement hooks for a comprehensive health check system that verifies the entire email pipeline is functioning correctly (including setup outside of ZoneMTA itself). This system needs:
Use Case
This feature would enable more reliable deployments, especially in scenarios like blue-green deployments, by ensuring that new instances are fully operational before being added to the load balancer.
Benefits
Proposed Implementation Details
Startup Hook:
Shutdown Hook:
Health Check Endpoint:
/health
endpoint that returns detailed status informationWhat I'm trying to do
I was thinking that on Startup as soon as ZoneMTA is ready it would add's itself to my database with an ID and send an email to a test inbox. When I was able to receive the email I automatically mark the the instance healthy in the database.
On termination of the instance I would remove the database entry.
A /health endpoint could be useful but I think it's better to test the whole pipeline like I described and have the /health endpoint return 2xx if the instance is marked as healthy in the database and a NOT 2xx response otherwise.
I can try to create a PR for this feature if it aligns with the project's goals.
The text was updated successfully, but these errors were encountered: