Skip to main content

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout
Documentation
OutSystems 11
Managing the Applications Lifecycle
Monitor and Troubleshoot
View the Environment Logs and Status
Monitor and Troubleshoot

 

Template:OutSystems/OSLanguageSwitcher
Language:
English|日本語

 

 

 

 

 
OutSystems

View the Environment Logs and Status

  1. Last updated
  2. Save as PDF
Template:OutSystems/Documentation_KB/ContentCollaboration
  • Edit
    Collaborate with us
    Edit this page on GitHub

    • You can view the logs and other useful information to monitor your OutSystems applications and the environment’s status in the Monitoring area of the Service Center console.

    To access the environment's Monitoring area, do one of the following:

    • In the Applications section of your LifeTime console (https://<lifetime_environment>/lifetime), click the View Logs link for the environment you want to access. You will be redirected to the Monitoring area of the environment’s Service Center console.

      View logs

    • Access directly to the environment’s Service Center console (https://<environment>/ServiceCenter) and click Monitoring.

      Monitoring

    Monitoring Area

    In this area, you can see the environment logs for the last two weeks 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.

    Although this area shows the environment logs for the last two weeks, OutSystems can keep the logs for a maximum of 9 weeks. You can configure the logs retention period in the Configuration Tool > Log Tab. Check the Logging database and architecture for further details.

    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 Error Detail

    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.

    The information about the Scheduler Service in the Environment Health screen applies only to applications that are not running in a Container.

    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.