Add an additional flag that will change the behavior of returning "NaN" values. By using a optional flag we maintain backward compatibility.
Current measurement API returns "NaN" values to calls. This can affect some downstream information that is unable to handle or cleanup these values. By adding an optional flag to measurement calls, override this behavior to return "0" values when a "NaN" would be returned.
Current Use Case: Passing data to HoltWinters algorithm for use in forcasting is unable to parse "NaN" values. Current upstream monitoring cannot guarantee all intervals will return data due to the possibilities of maintenance, outages, or potential unforeseen issues. And in our instance, downstream applications are unable to clean out "NaN" values.
I was able to get this to work in the newer versions of Helm 5.x and Grafana 6.6.x using the above described methods above.
Jesse White December 20, 2019 at 4:15 PM
If the purpose is to use the series for forecasting, replacing NaNs will 0s will give misleading results. A better approach would be to interpolate the missing values and deriving these from the data point that are known - this is what the "Outlier" filter does already.
Can you show an example where the Outlier filter fails?
Add an additional flag that will change the behavior of returning "NaN" values. By using a optional flag we maintain backward compatibility.
Current measurement API returns "NaN" values to calls.
This can affect some downstream information that is unable to handle or cleanup these values.
By adding an optional flag to measurement calls, override this behavior to return "0" values when a "NaN" would be returned.
Current Use Case:
Passing data to HoltWinters algorithm for use in forcasting is unable to parse "NaN" values. Current upstream monitoring cannot guarantee all intervals will return data due to the possibilities of maintenance, outages, or potential unforeseen issues. And in our instance, downstream applications are unable to clean out "NaN" values.