Metric points missing after 6 points or 3 boxes

[ramennbowls]

Hi, I recently installed Cachet 2.4.0-dev, using PHP 7.2, MySQL databases, and file for the driver and queue (APC just stopped working and started giving me an error 500 after clearing the cache). This is all on Ubuntu 18.04.

Metrics is alright, and I've seen some issues with it that people have reported, but this one is odd. For some reason, when ever my Metric points go past the last three boxes (fourth box or more), they just disappear and go into a straight line?

I'm not sure what the issue is or how to fix it. If you have any ideas, please let me know. I've also attached an image of what it looks like.

[welcome]

👋 Thank you for opening your first issue. I'm just an automated bot that's here to help you get the information you need quicker, so please ignore this message if it doesn't apply to your issue.
If you're looking for support, you should try the Slack group by registering your email address at https://cachethq-slack.herokuapp.com. Alternatively, email [email protected] for our Professional support service (please note, this a paid service.)
If you're issue is with documentation, you can suggest edits by clicking the Suggest Edits link on any page, or open an issue at https://github.com/CachetHQ/Docs

[nalysius]

Hi,
Metrics are (supposed to be) the reflection of the datas, so in theory it would mean that you have no datas for the given times. If you have no data for a given point it is set to the default value configured in the metric.
If you do have datas for these times and the straight line is anormal, could you upload your database so we can import it and try to reproduce/debug the problem?

[nalysius]

Thank you @Romanthefrog10 I just imported your tables in my database. In the metric_point table the datas start the 2020-04-26 so it's normal that before this date your line is at 0. You just have no more data.

I saw something that could be a problem for you, your metrics are configured to display datas as "Sum". You are monitoring the response time of a daemon or something. If you monitore twice, the first time it might take 10ms and the second time it might take 20ms, it'd be interesting to have 15ms as the average instead of 30ms as the sum. That's why currently there is one point with its value of 150008ms.

[nalysius]

Ok I think I understand @Romanthefrog10. The problem is the disappearing of the datas. I will use a curl command to post datas into a metric every minute and try to reproduce it.

EDIT: Below the Bash script if someone wants to test.

#!/usr/bin/env bash

delay=60
apikey=yourKeyHere
value=10
metricid=4

while :
do
    
    # Compute the current timestamp
    now=$(($(date +"%s")+7200))
    curl -X POST -H "Content-Type: application/json;" -H "X-Cachet-Token: $apikey" \
	 -d "{\"value\":\"$value\",\"timestamp\":\"$now\"}" \
	 http://cachet.local/api/v1/metrics/$metricid/points
    value=$((($value+15) % 100))
    sleep $delay
done

[nalysius]

I'm not able to reproduce your problem when different values are posted each time. @Romanthefrog10 could you try to run the Bash script I posted in the previous comment and see if it's able to reproduce the problem?

In my case I got this

Cachet metric

[marek-knappe]

The fix for me was changing the postgresql timezone to be the same as timezone in cachet

[marek-knappe]

Hi Marek, as Cachet uses UTC and not the specified time zone in some instances, me being in the UK and it being BST right now caused a load of issues, as some places like the UK don't always stick with one time zone, so it can change depending on what point we are into the year.

After changing some time zones, and making everything UTC to comply with Cachet, the metric being completely broken and many cachet functions started to all work. But this problem I have reported, is still an issue and have contacted many other developers which are stumped on what could be causing this issue.

It could very well be the 3rd Party monitoring tool I have, that I got off of the Cachet Documentations page but I need that to do what I need. Without making my own monitoring software for cachet, and all the other monitoring software for cachet being quite bad in my opinion, I won't be able to do what I need with the metrics. Considering the tool was last updated two years ago, posting the issue there would not be of much use.

It's not an issue that can be reproduced easily. Due to the way Cachet is made, stuff like the Time zone can affect results, reproducing the issue can be very hard and maybe near impossible as it may not even be cachet causing the issue. As far as I've tested, I get this issue on every machine with what ever I try.

Do you have it running now with the issue? Can you check my fix branch if that helps:
https://github.com/marek-knappe/Cachet/tree/fixing-issue-3842

This is very weird thing that is happening there - which is adding to timeframe, everytime it doesn't find correct values, in mine it caused in wrong timezone to be like yours, in correct timezone was like in the issue #3842

[ramennbowls]

Looking at this two years later... I do wanna apologize for my attitude, sorry! 😅
Also closing this for being stale, and for the fact that I don't wanna see my own comments