131
edits
MetricsDataPing: Difference between revisions
Jump to navigation
Jump to search
→Server-side
DEinspanjer (talk | contribs) |
DEinspanjer (talk | contribs) |
||
| Line 130: | Line 130: | ||
</pre> | </pre> | ||
*Clients will POST data to the configured URL not more than once every 24 hours. | *Clients will POST data to the configured URL not more than once every 24 hours. | ||
*The first timer check should be one minute after startup. | *The first timer check should be one minute after startup. | ||
*The POST data will consist of a JSON document containing a document ID and all the metrics that were collected since the last submission. | *The POST data will consist of a JSON document containing a document ID and all the metrics that were collected since the last submission. | ||
*The server side will receive the POST request and perform GeoIP location on the IP address. ''The raw IP will never be stored. ''The GeoIP data and submission timestamp will be added to the JSON document. | |||
== Server-side == | |||
*The server side will receive the POST request and perform GeoIP location on the IP address. ''The raw IP will never be stored in the document.'' The GeoIP data and submission timestamp will be added to the JSON document. | |||
*The server will store the JSON document into a daily staging collection with all other documents received during that date, UTC. | *The server will store the JSON document into a daily staging collection with all other documents received during that date, UTC. | ||
*If the POST request contains a header with the ID of a previously submitted document, the server will delete that old document as part of the transaction of storing the new one. | |||
*The server will return an HTTP response to the client indicating success of the storage and a document ID. For the initial feature release, this ID will be the same as the one passed in (i.e. an installation GUID). It can easily be changed to be new each time (i.e. a document GUID). If the ID is new, the client should store it to be returned on the next submission. | *The server will return an HTTP response to the client indicating success of the storage and a document ID. For the initial feature release, this ID will be the same as the one passed in (i.e. an installation GUID). It can easily be changed to be new each time (i.e. a document GUID). If the ID is new, the client should store it to be returned on the next submission. | ||
*In the future this response might also include instructions to the client for things such as changing timing or MetricsDataPing configuration. | *In the future this response might also include instructions to the client for things such as changing timing or MetricsDataPing configuration. | ||
*Longitudinal data for 6 months (e.g. intensity of use) is stored cumulatively in the JSON objects indexed by document ID. ''Documents older than 6 months are deleted.'' | |||
*Longitudinal data for 6 months (e.g. intensity of use) is stored cumulatively in the JSON objects indexed by | *''At the end of the day, UTC, the server will aggregate all the documents submitted on that date and store the aggregate data (with no document IDs) in aggregate history tables in our data warehouse.'' (In subsequent releases of the MDP project, there will be a public API to retrieve information from these aggregate views to support additional analysis by users and the community. | ||
*''At the end of the day, UTC, the server will aggregate all the documents submitted on that date and store the aggregate data (with no | |||
= Data Access Policies = | = Data Access Policies = | ||