View the Environment Logs and Status

Monitoring Area

In this area, you can see the environment logs and also information about the environment current status. Almost all log options allow you to export the logs to Excel so that members of the operations team can analyze these logs and share them if needed.

Errors

This screen presents all errors generated by the platform, either implicitly like system errors or explicitly, such as exceptions raised by an application on its logic. This screen also presents any native app shell log entries with log type Error and Fatal, containing errors that occurred in mobile devices of end users. Security exceptions are also displayed on this screen, such as when an unregistered user tries to access a page.

By clicking the Detail link of the log, it is possible to analyze the execution stack trace.

General

This screen displays system and application activity, either implicitly like slow query warnings, or explicitly by invoking the System Action LogMessage in the applications. This screen also lists the deployment steps when an application is being deployed, as well as native app shell log entries with log type General.

It allows you to understand the probable causes of slowness in your applications.

Traditional Web Requests

This screen displays the time the server took to serve Traditional Web Apps requests.

It allows you to understand which Traditional Web Apps screens are taking too long to be delivered to end users.

Screen Requests

This screen displays the time the server took to serve the Mobile and Reactive Web Apps requests.

It allows you to understand which Mobile and Reactive Web screens are taking too long to be delivered to end users.

Service Actions

This screen displays the time the server took to execute a Service Action.

The amount of information in each Service Actions log depends on the Logging Level set for the Module where that Service Action lives. The following image shows the details of an error log entry, available at Troubleshoot and Full Logging Levels.

Service Action logs contain a Request Key field that can be used to pinpoint the origin of a chain of requests by allowing you to relate all logs from the same top-level request.

Integrations

This screen displays the time the server took to execute the actions of your exposed and consumed integrations, such as REST, SOAP or SAP.

It allows understanding the incoming requests to the environment at any given moment, and the troubleshooting of errors in your applications due to external services you are consuming.

Extensions

This screen displays all extensions actions that run during a request, the caller module, and how long the extension action took to reply.

Timers

This screen displays each Timer that was executed, when the Timer was scheduled to run, how much time it took to execute, and when it's scheduled to run again.

It allows troubleshooting asynchronous logic that relies on Timers for its execution.

Emails

This screen displays all emails sent, and if they were successfully delivered or are still pending. When developing your applications, it's also possible to choose if the content of the email is logged or not.

It allows you to troubleshoot application logic and understand if emails are being correctly sent.

Processes

This screen displays the number of currently active, suspended and closed instances for each business process. It also shows the number of instances with errors.

It's also possible to see if a business process instance has executed successfully or with errors, and suspend or terminate it.

Mobile Apps

This screen displays the list of mobile app packages requested per application, including the native platform for which the package was generated and the status.

Environment Health

Displays the status of the OutSystems services, including the services running on each front-end. It also displays the status of asynchronous tasks, such as processes, emails, and Timers. It provides an overview of the status of your environment.

Security

Displays the IP addresses that were blocked by the Platform Server due to multiple failed login attempts. You will be able to unblock those IP addresses.

Native App Shell Logging

OutSystems allows you to have full visibility of all the errors that may be occurring in the devices of end users of your mobile apps. This capability allows you to understand and act fast on any problems detected in your mobile apps.

The native app shell logs are displayed in the Errors and the General screens of the environment’s Monitoring section in Service Center console. Each log entry contains the OutSystems native plugin that triggered the log message in the "Module" field, while the "Stack" field displays the stack trace of all native components used until reaching the point that triggered the log message.

Native app shell logs contain the following device information:

DeviceModel

The Android/iOS device model (e.g. SM-G950).

OperatingSystem

The native platform version (e.g. Android 5.1.1).

Cordova

The cordova version used to build the app (e.g. 6.5.0).

DeviceUUID

The device universal unique identifier (e.g. 7abcde123abcd).

NetworkType

The network connection type (e.g. 3G, Wifi, unknown).

NativeShell

The base version used to generate your application (e.g. 2.3.1).

NetworkStatus

The network connection status (e.g. Online or Offline).

OutSystems Services

In the Environment Health section of the Monitoring area, you can see the status of the following OutSystems Services:

Deployment Controller Service

The Deployment Controller service is responsible for compiling and coordinating the deployment of application modules. For each environment, exactly one instance of this service must be running in one of the front-end servers. This service is a Windows Service.

Scheduler Service

The Scheduler service is responsible for triggering asynchronous processes. It periodically checks for the need to execute Timers, send emails or execute Processes, and it's also responsible for triggering their execution. If you have an application that executes Timers, there should be at least one Scheduler service running in one of the front-end servers where the application is published. This service is a Windows Service.

Deployment Service

The Deployment service is responsible for ensuring that published application modules are deployed to the environment’s front-end servers. This service should be running in every front-end server. Turning this service off in a front-end server will prevent modules from being published or deleted to that front-end server. This service is a Windows Service.

Server.API

The Server.API is responsible for exposing some of the platform’s functionality through REST APIs. Server.API must be running in every front-end server where Service Center is published. This service is managed by Internet Information Services (IIS) and runs in its own application pool.

Server.Identity

The Server.Identity is responsible for authenticating users and access control for the APIs exposed by the Server.API. The Server.Identity must be running in every front-end where Server.API is also present. This service is managed by IIS and runs in its own application pool.