Overview
The Eleos Error Console shows the recent errors the Eleos Platform has encountered relating to client web services or integration. To access the error console, log on to your company’s Drive Axle account. On the Eleos App Manager click on the App Configuration drop down and then Error Console. Alternatively, it can be accessed using the following link and signing into Drive Axle: https://dashboard.driveaxleapp.com/#errors
During periods of large error volume, a percentage of web service errors may not be reflected in the Error Console or the Error Console API to protect overall system stability. Please note that periods of large error volume are infrequent, and if it does occur those who subscribe to the Eleos Status Page will be notified.
Troubleshooting with Error Console
When there are multiple drivers experiencing an issue signing into the Eleos application and receive the following error: "There was a problem signing in. Check that you have a strong cell signal or are connected to a Wi-Fi Network, then try again.”, you can use the Eleos - Determining if the Webserver is Offline guide to check the Error Console and if the console is being flooded with non-stop errors up to the minute (meaning nothing on the console older than a minute would show), it could indicate that the web server is offline.
However, there are times when drivers may see the error, “There was a problem signing in……. Wi-Fi Network, then try again.”, but it is not related to the web server being offline. Repeating errors that are not up to the minute, if the web server offline is ruled out, a client will need to help verify if there is: (1) database slowness, (2) changes with integration procedures they may have made internally, (3) conflicting process or services that run on their server same time that can interfere, (4) firewall or certificate changes that impact web traffic. If the company has a Geotab database, Geotab server connection can also affect certain integration functions.
If drivers receive pop-up errors and failed login attempts, check for details in the console for invalid JSON errors which sometimes helps indicate where to look to resolve. If sign-in is an issue for one driver using the correct password, and the company has a Geotab database, errors in the console may show problems creating the Geotab user. Then you will want to make sure that the user is set up properly with the correct username and email address in Geotab.
The Eleos Error Console should also be checked if there are any reports or slowness or general connectivity issues within the application as that could be caused by timeouts.
Types of Errors
A small number of intermittent or errors is usually not indicative of an issue (referred to as a transient error). A single failure is usually transient due to Azure, SQL, Network Infrastructure, etc. If there is no error, then the HTTP status code 200 OK is returned, meaning that the request was successful. With Eleos Version 1.54 the errors now point out which property is missing in a nested object and provide details about required fields in your web service’s response.
Clicking on an error reveals more information about the error including the request information and response information. The request information details which web service was requested, and below that will show the details of the server response as well. You can also see what driver was impacted in the error shown in the console, as well as when clicking into the error to expand the details.
In some cases, you may click on the error and there will be limited details. Or that there will be no response header or body. A blank error is not necessarily a concern unless it occurs repeatedly in the Error Console.
Web Services
The web service that is listed for the error can help you determine an area of the app that may be having an issue. The most common web service errors that occur in the console are Authentication, Driver Status, Loads, Messaging, Payroll, and TODOs services. To view the web service configuration, go to App Configuration > Service Config. in the Eleos App Manager. The web service URLs generally look like the following load service URL: https://asr-solutions.azure-api.net/company/Load , where company is the company name, but some may follow a different convention such as https://eleos.company.com/api/Loads.
Each service could throw distinct types of errors. For example, the TODO service could return a network/timeout error, or it could show a status code such as 500 in the console, rather than the expected 200.
Some clients do not have every service configured. For example, some clients might not use the Payroll Service, but may see errors related to that service in the console. The errors occur because the service is not set up, so these errors are not a concern and are not affecting functionality of the application. Even if the client has a URL listed in a Web Service, it does not mean that service is fully functional.
Common Errors
In cases where an error is not repeating in the console, it could be that it was an intermittent error due to any of the common error codes/reasons listed below. If the driver didn't see any error, or saw an error for a moment, then the screen refreshed successfully, this is usually no reason for concern. The easiest way to tell if an error is impactful is by trying to log in as the user the error is listed for and checking to see if there is functionality within the application. For example, if there is an error relating to the Load Service and it lists User DERLIL as the driver impacted, log in as the user and navigate to the loads list to see if there is concern.
Below we have listed the most common errors that are seen in the error console:
- The service could not be contacted due to a network error: timeout.
The timeout is the most common error that is found in the Eleos Error console for any of the web services. If these are seen and continue minute after minute for a long time, this is usually related to the webserver as mentioned above. If there are a burst of the timeout errors and then they stop for a time of 15 minutes or longer, it's likely just system loading.
There are two 15-second timeouts, listed below. If 1 is slow by 5 seconds, it doesn't count against the second timeout, so the observed duration could be up to 30 seconds if both the TCP connection step and the response step are slow.- A 15-second TCP connection timeout (time to the connection being established).
- A 15-second response timeout (time from when we finish sending the HTTP request to receiving a complete response).
If there is a timeout on a message, the request will be retried up to 10 times until it is successful. If you only see one error relating to a network timeout, and that error did not come through to the console repeatedly, then it is likely that the message was successful on retry. When clicking on a network time out error for the Messaging Service, the request URL also references a message handle, which is the ID for a message that can help track further into the error in question, if needed.
- Error retrieving driver status for user: DriverID.
Errors in the console will specify which user the error was for. This error could be blank and is likely intermittent unless the driver is experiencing an issue in the application with their HOS card display. In most cases though, the error just indicates slowness in getting driver status. - The service returned HTTP status 204 instead of the expected HTTP 200.
This can happen when the request has been completed but there is no content. In these cases, you may see invalid or unexpected JSON response in the response body. Like other errors, this is not concerning unless it is repeating in the console, or the driver is seeing a JSON error within the application. - The service returned HTTP status 400 instead of the expected HTTP 200.
The server cannot or will not process the request due to something being passed that does not appear to be valid (i.e., malformed syntax or "invalid request" coming back). This is usually intermittent because the request was corrupted in transit but was fine on retry. If it's persistent, integration should be investigated as possibly having bad code in it. Always ask if anything has changed recently (i.e., new feature added, server and software upgrades) before escalating. - The service returned HTTP status 500 instead of the expected HTTP 200.
The server encountered an unexpected condition when the request was being processed. Clicking into the error can provide added details in the response body about where exactly the error occurred. This is usually intermittent, because maybe the webserver was getting inundated with a lot of requests at the time and didn't have the bandwidth but was fine on retry. If persistent, the customer should check into webservers, connected services, and any changes that may have been made to coincide. - The service returned HTTP status 502 instead of the expected HTTP 200.
This indicates a bad gateway, and typically when clicking into the error, the response body shows that there is unexpected JSON. Like the other errors his is not concerning unless it is repeating in the console, or the driver is seeing a JSON error within the application. - The service returned HTTP status 503 instead of the expected HTTP 200.
This means that the service is unavailable or not ready to receive a request, possibly due to being overloaded or being down for maintenance. Sometimes, the response body will reveal that there was an invalid JSON response. If the error is persistent and does not seem intermittent, check to see if the webserver is down or if there is planned maintenance that might be degrading service. - The JSON Response does not conform to the schema.
This error will say invalid JSON when clicking into it. The request and response will specify if any required properties are missing from the nested object.
Background Error Service
ASR has created the background error service feature to support the error console API in the Eleos platform. The Eleos API calls for console errors allows pulling the most recent errors in the console to look for outage issues or other failures that can be captured in real-time. It also includes information on the type of errors that occur, which include both platform errors and schema errors, which includes all the errors that were listed in the previous section. A schema error occurs when the client web service responds with a JSON body that does not match the respective format. The most common schema error types include missing_required_property, wrong_length, and wrong_type. In the database, it may show more information about each error compared to viewing the same error in the Drive Axle Error Console.
The background error service pulls errors from the platform at an interval and stores them in the client's database as an audit, allowing for more than 100 errors to be tracked and viewed. The errors will be stored in the database for a specified amount of time with information about the error such as type, when it was created, the username, and additional error properties. Clients can take advantage of this feature by creating processes on hooks that pull and audit errors from the database for further processing and reporting. This would require use of an SQL hook into our ELEOS.PlatformErrors and ELEOS.SchemaErrorInfo tables. For example, clients could create a process to notify staff when certain errors occur.
Certain aspects of the background error service are controllable via application settings, and when this feature is enabled, “GetPlatformErrorsEnabled” will be set to true, and “SavePlatformError” is configured to a procedure name. The error service pulls errors on an interval that is specified in settings. There is also an automated data cleanup for this process, considering that the error service has the potential ability to create a lot of data in the underlying database. If “DeleteOldPlatformErrors” is set to true, then errors will be deleted from the database table after the number of days that is specified by “PlatformErrorDaysHistory”. Below is a screenshot example of what the settings could look like in appsettings:
Clients that received the Fall/Winter 2023 enhancements have received some of the functionality of the background errors service, but the feature will not be fully available until after the next upcoming enhancements are deployed. That would include updated columns to the ELEOS.PlatformErrors and ELEOS.SchemaErrorInfo tables so that clients can add their own processes to take advantage of the background error service. Once that occurs, to confirm if this feature was deployed to you, check appsettings for the settings regarding this the background error service, as shown in the screenshot above. Another way to confirm if you have this feature is to query the SQL database, selecting from the ELEOS.PlatformErrors table or the ELEOS.SchemaErrorInfo table. Not seeing these settings in appsettings or being able to select from these tables would mean that this feature is not yet available to you. Using the background error service to do any custom processes will only work with clients who have SQL, since it will require hooking into the ELEOS.PlatformErrors and ELEOS.SchemaErrorInfo tables.
Future Enhancements
Eleos during Client Summit 2024 announced that they will be working on a future feature where clients can sign up for a subscription to the error console, like how one can sign up for the status page subscription. Time is TBD by Eleos Technologies.