Browse Prior Art Database

System and method for virtualizing logging and tracing in a multi-tenant cloud environment including a logging query api

IP.com Disclosure Number: IPCOM000201734D
Publication Date: 2010-Nov-19
Document File: 2 page(s) / 30K

Publishing Venue

The IP.com Prior Art Database

Abstract

A system and method for virtualizing logging and tracing in a multi-tenant cloud environment including a logging query api

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 01 of 2

System and method for virtualizing logging and tracing in a multi -tenant cloud environment including a logging query api

Software as a service (Saas) offerings using a multi-tenant architecture are becoming more and prominent in the industry. In this type of architecture, all customers and their users are using the service from the same set of software and hardware resources. One big problem with this architecture is that all logging and tracing messages, vital to diagnose and resolve problems, are all interspersed in central log files causing extra delay to find the root cause of a problem that happens for a particular customer.

In this article, discussed is a system and method for virtualizing the logging and tracing of messages into repositories specific to each customers, making it easier to build APIs for querying logs and traces for each customers and their users. These query APIs can then be used to build applications that help Customer Support representative to quickly and easily access all the information that will help diagnose and solve the problem.

Throughout this article, the term Customer is used to refer to a company that has subscribed to a SaaS service. The term User is used to refer to a particular individual that belongs to a Customer.

The main idea is to use for each executing thread, dedicated contexts that identify the customer for which the current request is. In addition, if the information is available, the context can also identify the current user as well. When the executing thread is trying to log or trace a message, the logging component will first access the customer context and if available will use the customer information to store the message in a repository associated with the customer.

In addition, using the logging multi-repository defined above, a logging query api provides easy access to logging and tracing messages based on a customer and optionally a user identifier. The api will show only the messages relevant to the customer/user filtering all the other messages. This makes it easier to diagnose a problem and increase serviceability of the system.

The customer context described above is at the core of this idea. At the very minimum, it must contain the customer unique identifier and optionally the user id. Implementations can use this information to locate the logging repository store. For example, if using a file system, the customer id can be used as the name of root directory, or if using a relational database, it can be used as the primary keys for all the logging records. Of course the logging query api must use the same repository location algorithm as the logging component.

To minimize code change as to avoid passing around the logging context, the logging component should be able to access the logging context in a fast, reliable global way. One natural solution for implementations is to use Thread-local storage (TLS) to store the logging context variable at the Thread entry point...