Failed Communication Alarm
This alarm is raised when a component in the Curity Identity Server fails to communicate with a remote host over an established connection.
This could be against a data source such as MySQL or LDAP, or an HTTP Service such as BankID or Duo. Compared to the Failed Connection Alarm , this alarm is raised when the component successfully did connect to the remote host, but the remote host responded with an invalid or unexpected message.
The reason for the alarm is that the remote host responded with unexpected data or with an unexpected status.
The severity is at least minor since parts of the system are already affected.
Immediate action is required. The remote resource cannot be accessed. Immediate action is required if the state of the alarm is raised.
Properties#
| Property | Value |
|---|---|
| ID | failed-communication |
| Type | external-service |
| Minimum Severity | minor |
| Node Specific | yes |
Alarming Resources#
This alarm can be raised by two types of components in the Curity Identity Server.
- Data Sources
- HTTP Clients
Data Sources#
Data Sources will report failed communication if an operation against the data source fails unexpectedly.
HTTP Clients#
HTTP clients will raise the alarm if the remote host responds with a 500 or higher response code.
It is also possible to configure the HTTP client to raise failed communication for 4xx errors (excluding 401)
but this is disabled by default.
Raising Conditions#
When an operation against the remote resource over an established connection fails unexpectedly.
Clearing Conditions#
The alarm is cleared when the remote host responds with an expected non-error response.
Suggested Actions#
- Inspect the logs of the remote host, or contact support of the service provider.
- Inspect the logs of the affected Curity Identity Server runtime node at the time of this alarm.
Sliding Window#
The failed communication alarm employs a sliding window which can be configured per HTTP Client and Data Source.
Configuration Options#
HTTP Clients#
It is possible to disable the failed communication alarm for HTTP clients. This can be necessary for back ends that are prone to instability with short outages.
To disable the failed communication alarm using the CLI, do:
configure
set facilities http client YOUR_HTTP_CLIENT_ID client-alarms enable-failed-communication-alarm false
commit
To enabled the failed communication alarm for 400,402-499 error codes using the CLI, do:
configure
set facilities http client YOUR_HTTP_CLIENT_ID client-alarms enable-failed-communication-alarm true
set facilities http client YOUR_HTTP_CLIENT_ID client-alarms raise-failed-communication-alarms-http-client-errors true
commit
To set the size of the sliding window and the number of faults required to raise the alarm using the CLI, do:
configure
set facilities http client YOUR_HTTP_CLIENT_ID client-alarms failed-communication-alarm sliding-window sliding-window-size 20
set facilities http client YOUR_HTTP_CLIENT_ID client-alarms failed-communication-alarm sliding-window faults-to-raise-alarm 100
commit
Data Sources#
To set the size of the sliding window and the number of faults required to raise the alarm using the CLI, do:
configure
set facilities data-sources data-source YOUR_DATA_SOURCE_ID data-source-alarms failed-communication-alarm sliding-window sliding-window-size 20
set facilities data-sources data-source YOUR_DATA_SOURCE_ID data-source-alarms failed-communication-alarm sliding-window faults-to-raise-alarm 100
commit