HMC Monitor System Events fails to deliver message if SMTP server is unavailable

This item is unlikely to be given high enough priority to be placed into the product plan.

It is still possible that a syslog forwarding solution will achieve the desired results. Many log consolidation products (i.e. Splunk) provide ways to match on specific messages from specific sources and generate actions when a match occurs. One of the common actions is to send an email and this would achieve the desired results. An additional benefit to this approach is that the log that caused the email would be preserved by the log consolidation product for historical purposes.

Hi. Thank you for your response. I did not find any attached presentations you referenced.

However, by providing a syslog service in future processors will not address the issue I outlined here. If the HMC is to send out an e-mail, then it need to run a local SENDMAIL or POSTFIX instance that will handle the sending of the mail. As it is now, the process attempts to send the mail using the configured SMTP port and address and if it fails, then the message is lost. If the HMC allowed a local SMTP on the HMC to handle the sending of the message, then the the local SMTP will deal with retrying the message until it is sent. Providing a SYSLOG service is not going to help.

Thanks,
Aria

The z15 HMC offers Remote Syslog Server support for both z15 and z14 CPCs, and that will address the situation when the connection is broken or server is down for reporting log event data. Assuming that you are looking for Security or Audit Log event data or other types of log data which we support, this would address the issue that you identified with our SMTP HMC support. Please view the attached presentation to see the details on this Remote Syslog Server support.

Thank you for considering this request. Your suggestion to add additional SMTP servers that the HMC will try to deliver messages with is a reasonable solution. However, it may not resolve the core problem with the way SMTP mail delivery is implemented on the HMC based on my understanding. In other words, since the HMC is running Linux, would it not be more appropriate to allow the HMC to run a mailer application locally such as postfix that is primarily responsible for delivering mail originated from the HMC to configured external SMTP servers (one or more per your recommendation). In this manner, the HMC can configure proper action to be taken based on standard SMTP (postfix or other) rules for mail delivery. The mailer daemon will take care of repeated attempts to reach the designated (one or more) SMTP servers based on configured parameters of retry interval and for how long. This will relieve the HMC from being responsible for actual mail delivery to the remote SMTP server. In my case, my SMTP server designated for my organization is running on an LPAR. If the LPAR is taken down, then any messages generated by the HMC are lost. It is correct to assume that adding more SMTP server options will address this problem but perhaps allowing the HMC to retry sending a message more than once over a period of time would also be an acceptable option. For example, attempt to deliver message X times with a delay of Y minutes between each attempt.

Thanks.

The problem described in this RFE is that the SMTP server configured to the HMC can sometimes be unavailable due to maintenance of the server, etc. and email notifications can be lost if they are sent when the SMTP server is not available. While it is technically possible for some code to be added to the HMC to remember and hold onto emails that could not be sent for retry later, such an approach would introduce other issues that need to be solved. For example, how many email notifications are to be remembered and for how long, should any correlation be performed for subsequent notifications that are related to previously unset ones (i.e. should a prior status change notification for an object be thrown away when a new one occurs before the original could be delivered to the server), etc. The fundamental issue seems to be that the HMC only supports a single SMTP server and it is not reasonable to expect this single server to be available 100% of the time. We would propose a different solution that addresses the fundamental issue without introducing any new complications. That is, allow more than one SMTP server to be configured to the HMC so that when one of the servers is unavailable the HMC would simply move onto the next server and keep moving down the list until the email notification is successfully sent or the list of servers is exhausted. This would enable one or more of the configured SMTP servers to be taken down for maintenance as long as at least one of the servers is still running. Such an approach is more straight forward and does not introduce any additional complications.

Would such an approach be acceptable as a solution to this request?