Usage logging is selectively logging the requests and responses going to and from an application. This is done by installing a small logger library, which selectively records HTTP calls made to the application -- including details about the HTTP request, HTTP response, and user session. On the backend, resurface.io processes all this raw data and provides meaningful and actionable datasets in a responsible and repeatable way.
Usage logging with resurface.io is decentralized by design. We enable highly selective "data streams" of real HTTP calls and/or user sessions. Each data stream is suited to a specific business purpose, and has its own infrastructure and data storage, as well as its own access rights and data protection rules. This is very flexible and pairs nicely with decentralized microservices.
With these solutions, customers install operating system agents to collect and upload application and OS events to a third-party logging service. Examples of these events are the startup or shutdown of an OS process, or a stack trace for an unhandled error within an application. The logging service provides convenient APIs and UIs to search and analyze events across all servers used by an application.
Server logs are primarily intended to monitor basic server and application health. These solutions tend to discourage collection of sensitive user information, where usage logging includes specific privacy and security safeguards needed to do so. Server logs are typically intended for devops teams for debugging, not to provide datasets to other groups in the organization.
In this case, customers install a library into their cloud application that detects unhandled errors, which are uploaded to a third-party logging service. The logging service alerts customers to new problems as they are detected, and provides helpful detail to speed resolution.
While error logs give helpful visibility into application failures, this visibility does not extend to cases where the application worked properly. Combining error logging and usage logging together makes sense as each represents an different proportion of user experiences.
These old-school solutions require installing a packet sniffer on the customer's internal network. This is quite intrusive and costly, and sniffers do not work reliably in typical cloud environments. Sniffers require extensive configuration that is difficult to keep synchronized as applications constantly change. Since a sniffer can only see network traffic, they are also unable to gather any details about active user sessions or other application internal state.