Search Results for

    Show / Hide Table of Contents

    Troubleshoot with Casewhere logs

    Casewhere logs are one of the most crucial tools you need to get familiar with to troubleshoot problems in production. The Casewhere Troubleshoot Tools can be found at /debugging or via the Troubleshooting menu in Casewhere Admin. The menu is only available for users with the Administrator role.

    Troubleshoot menu

    image-20231219221757012

    System log viewer

    By default, Casewhere stores logs in MongoDB. From Casewhere Admin, you can access the log data using Log Viewer at the path "/logviewer". For example, https://admin-dev.casewhere.com/logviewer.

    In this page, you can drill down to view error logs, operating logs of Casewhere System.

    System log viewer

    It's possible to filter log data using the below fields:

    Field name Description
    CorrelationId All HTTP requests in the same context will share a CorrelationId. For example, workflow A creates data object B, that triggers a workflow C through a data trigger. Workflow A and workflow C will share the same CorrelationId. Casewhere automatically set the CorrelationId, which can be found in the HTTP response header.
    RequestId Casewhere will assign each HTTP request a unique ID, which can be found in the HTTP response header. From v2.7.0, you can query log data by RequestId.
    Context The logging context in which Casewhere writes log. One typical use case for the Context is to view log for a specific workflow. You can use this syntax Workflow:<workflow_guid_id> to filter log data. For example, Workflow:6a24b3dd-bff0-4396-9ffc-ac2b00a33b66.
    Applications The sources generate log data.
    Timestamp The time log data is created.
    Log Levels Casewhere write logs at different levels and each level has its own purposes. You can read more here.
    Log Fields You can use this setting to choose which fields you want to see in the Log Viewer. This setting is available from v2.7.0 and it's applicable for the Plain Text view mode only.
    View Mode Plain Text or Json.

    Logging levels

    Below are the logging levels Casewhere is writing logs with. It's possible to configure the minimum level specifically for a Casewhere deployment.

    Level Usage
    Verbose Verbose is the noisiest level, rarely (if ever) enabled for a production app.
    Debug Debug is used for internal system events that are not necessarily observable from the outside, but useful when determining how something happened.
    Information Information events describe things happening in the system that correspond to its responsibilities and functions. Generally these are the observable actions the system can perform.
    Warning When service is degraded, endangered, or may be behaving outside of its expected parameters, Warning level events are used.
    Error When functionality is unavailable or expectations broken, an Error event is used.
    Fatal The most critical level, Fatal events demand immediate attention. This level is available from v2.7.0.

    Tips

    • Where to find the CorrelationId and RequestId?

    Performance log viewer

    Casewhere tracks the response time of all HTTP requests and stores the data in MongoDB by default. If you can access the log database, you will find the data in the PerfLogs collection.

    Performance log viewer

    In this page, you can check the availability and performance of Casewhere API. The filtering of performance logs same as System log viewer.

    Below are the properties of a performance-log entry:

    Name Description
    Timestamp The time log data is created. Use this field if you want to query data by time.
    Properties.RequestUri The full URI of the HTTP request.
    Properties.Uri The URI of the HTTP request without the query string.
    Properties.ResponseTime Response time in milliseconds.
    Properties.HttpMethod The HTTP method. For example, POST, GET, PUT, DELETE.
    Properties.StatusCode The HTTP response status code. For example, 200 means success.
    Properties.CorrelationId The unique Id you can use to trace data in the system log. All related HTTP requests will share the same CorrelationId.
    Properties.RequestId The unique Id you can use to trace data in the system log. Each HTTP request has an Id assigned by Casewhere.
    Properties.Type Type of the request. Possible values are: WorkerApiRequest, PluginRequest, HttpApiRequest. The last two represent external calls.
    Properties.AppName The sources generate log data.

    Here is an example of performance-log data:

    {
        "_id" : ObjectId("615a7aaef9d398600cc8bd79"),
        "Timestamp" : ISODate("2021-10-04T03:53:17.597Z"),
        "Level" : "Information",
        "MessageTemplate" : "api/v0.1/worker-site/worker-site-components/worker-local.casewhere.com",
        "RenderedMessage" : "api/v0.1/worker-site/worker-site-components/worker-local.casewhere.com",
        "Properties" : {
            "RequestUri" : "/api/v0.1/worker-site/worker-site-components?workerSiteId=989d20c0-c0ff-4a4b-ad8f-ad81010c4292",
            "ResponseTime" : 7.3167,
            "HttpMethod" : "GET",
            "StatusCode" : "200",
            "Uri" : "api/v0.1/worker-site/worker-site-components/worker-local.casewhere.com",
            "Type" : "WorkerApiRequest",
            "CorrelationId" : "58be16a31f0347e5936d6054e83f4502",
            "RequestId" : "f82caaaea4114c9eb4e5ad9a58f0bcb7",
            "RequestTimestamp" : "2021-10-04T03:53:17.5908466Z",
            "AppName" : "WorkerAPI PerfLog"
        },
        "UtcTimestamp" : "2021-10-04 03:53:17Z"
    }
    

    Tips

    • How to query the top slowest endpoints in Casewhere?

    Audit log viewer

    Audit logs are a valuable resource for admins and auditors who want to examine suspicious activity or diagnose and troubleshoot issues. It's possible to configure Casewhere to track data changes and important events that happened in the system and store them in a more consistent, readable format.

    Currently, Casewhere audits the following events:

    • Data change events: All changes are logged. It's possible to specify what to log and what to ignore at the field level
    • Read events: It’s possible to enable logging for read access to critical data sources
    • Authentication: All events related to authentication are logged by default
    • Custom logging: It’s possible to hook into any workflow/process for custom logging

    Using the tool, you can get log records related to user data, activity, and events

    Audit log viewer

    Below are the properties of an audit-log entry:

    Field name Description
    EventName The event being logged. For example, auditlog_Send, User authorized
    UserId Id of the user
    UserClaims Username, roles, and other claims. It's possible to select which claims to log
    WorkerSite The site in which the event happened
    CorrelationId It's possible to use a business value, e.g., CustomerID, to track all related events
    SysCorrelationId All HTTP requests in the same business context will share a SysCorrelationId generated by the system
    Timestamp The time the event happened
    IsCustomLog The event is built-in or custom
    PlatformVersion The version of the Casewhere platform
    IpAddress The client's IP address
    BrowserAgent The browser sending the request
    Data For data change events, the system will track changed information in the following format [{AttributeName: "Status", FromValue: "Submitted", ToValue: "Approved"}]
    DataObjectId The data object being changed, which emits the event
    DataSourceId The data source being read, which emits the query event
    ActivityId The activity that emits the event
    WorkflowId The workflow that emits the event
    CaseId The case that emits the event

    Below is an example of an audit log record:

    {
        "_id" : NUUID("f0458910-ec3b-4e68-a271-d348668aad6a"),
        "_t" : [ 
            "AuditLog", 
            "DataObjectAuditLog"
        ],
        "EventName" : "auditlog_Auto approve",
        "UserId" : "pnk",
        "WorkerSite" : "Caseworker Site",
        "UserClaims" : [ 
            {
                "Key" : "Username",
                "Values" : [ 
                    "pnk", 
                    "GLOBETEAM\\pnk"
                ]
            }, 
            {
                "Key" : "Roles",
                "Values" : [ 
                    "Employee", 
                    "Administrator"
                ]
            }
        ],
        "CorrelationId" : null,
        "SysCorrelationId" : "cc645a2cba0f45eeb8df32a6a98085f1",
        "Timestamp" : ISODate("2022-08-25T07:41:38.249Z"),
        "IsCustomLog" : false,
        "PlatformVersion" : "2.8.0.0",
        "DataObjectId" : "CwUatTx2Application/ab77d7ee-6e33-4984-879b-aefc007ecada",
        "ActivityId" : NUUID("2e97482e-82f8-401c-bd62-aefc007ecadc"),
        "WorkflowId" : NUUID("d43210ff-71d6-4101-9292-aefc007ecadb"),
        "CaseId" : NUUID("c6ab7fd3-8adc-4f42-8539-ae91006484ad"),
        "Data" : [ 
            {
                "AttributeName" : "Status",
                "FromValue" : "Submitted",
                "ToValue" : "Approved"
            }
        ],
        "IpAddress" : "127.0.0.1",
        "BrowserAgent" : "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
    }
    

    Casewhere also provides an audit-log viewer that developers can embed in worker sites.

    Audit log viewer in Worker-sites

    Runtime log viewer

    You can use this tool to examine the state of a workflow, a data object, or Casewhere events. This is useful in many cases

    Runtime log viewer

    • EventProviderId: The data object ID.
    • WorkflowId: The workflow ID.
    • DataObjectId: The data object ID.

    Note: Sensitive information will be masked following the rules defined in the System log rules.

    In This Article
    Back to top Generated by DocFX