microsoft/ms-lumos

Tools to compare metrics between datasets, accounting for population differences and invariant features.

Lumos

Lumos is a library to compare metrics between two datasets, accounting for population differences and invariant features. Lumos is described in this technical paper:

  @inproceedings{Pool2020,
	title="Lumos: A Library for Diagnosing Metric Regressions in Web-Scale Applications",
	author="Jamie Pool, Ebrahim Beyrami, Vishak Gopal, Ashkan Aazami, Jayant Gupchup, Jeff Rowland, Binlong Li, Pritesh Kanani, Ross Cutler, Johannes Gehrke",
	booktitle="Proceedings of the ACM SIGKDD International Conference on Knowledge Discovery and Data Mining",
	year="2020"
}

Install

You can install latest release of Lumos directly from source:

pip install git+https://github.com/microsoft/MS-Lumos

Examples

Please refer to the examples folder.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

ms-lumos's Issues

Feature Request: Auto Clustering

I am using the feature ranking within MCT for automated Root Cause Analysis of incidents for our Rest API (e.g. increase in InternalServerError responses from our service). Our dataset is our IncomingRequests (uri, datacenter, responsecode, latency, requestId, etc.), merged with OutgoingRequests (target, responsecode, latency, requestId, etc.). If, for example, we are returning InternalServerError because we received 429 in our first call to DocDB, then our metric column, ResponseCode will equal InternalServerError and a feature column DocDB_GetThead_ResponseCode will equal 429 and we expect our automated Root Cause Analysis tool to tell us that the reason for InternalServerError increase is DocDB_GetThead_ResponseCode == 429.

Ours is a situation of multicollinearity. If the first call to DocDB fails, then all subsequent calls will not happen so for all of the failures, another column, say DocDB_UpdateThead_ResponseCode will be empty. We would like auto clustering, so that instead of producing some 200 "Features Explaining Metric Difference" with the actual root cause buried beneath the noise, we instead produce a handful of combinations of features that are correlated to our metric.

Thank you for your awesome work with this tool!