An array of field names that are the names of the data properties in the health monitoring message. It is always assumed that Producer and TimeGenerated will be in the message. These are emitted even if the AdditionalFields property is not present.

The additional field options are:

• "ProducerStarted", which is the time the producer was started.

• "LastEventSent", which is the time of the last health monitoring message for a period that contained any events.

• "EventsSentToDeadLetter", which is the number of events that have been sent to the FileReaderUndeliverableDirectory in the lifetime of this Producer run.

• "ErrorsInPeriod", which is a count of any errors that have occurred while sending events to the broker since the last health message.

• "EventsInPeriod", which is the count of event sends to all topics since the last health message.

If present, this section allows the user to modify the packet from the standard schema. It has the following fields.

• AzureMonitor. If present and true, the health monitoring message is inserted into a JSON array (which will then have the health monitoring message as its only member). This complies with the Azure Monitor data requirements.

• CamelCasedPropertyNames. If present and true, the property names will switch from Pascal case to Camel case (that is, the property names will have a lowercase first character.) This could be useful for health consumers written in Jade.

If present, this is an object that specifies a REST endpoint to which the health monitoring message is sent. It has the following fields.

• Endpoint, which specifies the URL endpoint to which the health message is sent.

• Authentication. The authentication Type can be one of the following.

  • AzureLogin

  • AzureClientSecret

  • AzureEnvironment

  • AzureManagedIdentity

  • None

  For details, see "Type‑Specific Parameters", later in this chapter.

• RetryOptions, which optionally configures the retry behavior of the REST connection. It allows fine‑tuning of the retry mechanism to make the availability of the service more resilient. Even if you do not specify a RetryOptions value, the retry will occur using the default values in the following list. The retry options are:

  • "MaxRetries", which is the maximum number of retry attempts before reporting an error. The default value is 3.

  • "RetryDelay", which is the minimum delay in milliseconds between retry attempts. The default value is 800 milliseconds.

  • "MaxRetryDelay", which is the maximum delay in milliseconds between retry attempts. The default value is 60 seconds.

  • "StatusCodes", which is an array of status codes as Integers that indicate when an operation should be retried. The default values are HTTP status codes 408 (RequestTimeout), 500 (InternalServerError), 502 (BadGateway), 503 (ServiceUnavailable), 504 (GatewayTimeout).

    If you specify status codes, the default codes are not included; that is, if you do not specify any codes, you will get 408, 500, 502, 503, and 504. If you specify [500, 601], you will only get 500 and 601 (and not 408, 502, 503, or 504).

• HttpLogging, which is a Boolean value that indicates whether Azure internal HTTP logging should be logged or reported for this connection. This parameter defaults to a value of false if unspecified. If true, logging will be sent to the logger specified in the "Logger" section of the configuration file and log‑level filtering will be performed based on the level of that log. (This logging can be quite verbose, so it is recommended to turn it on only for debug scenarios.)

If present, the health monitoring message will be produced to a topic in the current broker (either an Azure EventHub or a Kafka topic).

The Topic parameter specifies the name of the topic to which to send the health monitoring message.