SPIKE: Document the timing and factors which affecting timing of SM Service Ping delivery
Summary
On self-managed instances, we collect instance level data via Service Ping. The data collected depends on the instance's setting (Service Ping = On/Off) and whether the license indicates the customer is obligated to report Operational Data.
In this issue, I'd like to document specifics related to the timing of data collection.
Success Criteria
Please research and document the answers to the following questions.
-
When does a SM instance generate and send the Service Ping payload? Is this on a static day of the week/time? - A: Service Pings are randomly distributed during the week (reference)
-
Can you explain the "randomly distributed" process in more detail? How does the instance know it's time to send the payload? -
Can the instance admin overwrite the date/time of delivery of the Service Ping payload? - A: Theoretically yes, as they can change the code or config. But it's unlikely that someone does it. (ref)
-
If an admin can change the delivery day/time and/or cadence, do we have any insights into the number of instances which have deviated from our established schedule? - A: No we would not have this insight. (ref)
-
Is it possible to receive partial payloads? Like in the instance of a failure during collection. - A: We can't receive partial payloads, but we can receive payloads where some metrics are failing. However, we added measurements to not fail the whole service ping when one metric fails. These reliability fixes got added over the last year(s). (ref)
-
What happens when there is a failure with receiving a payload? Do we retry that payload? - A: When a Service Ping generation fails, we retry it for three times. (ref)
Edited by Amanda Rueda