Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCollector will stop working September 2020 #405

Closed
HariSekhon opened this issue Aug 24, 2018 · 6 comments
Closed

TCollector will stop working September 2020 #405

HariSekhon opened this issue Aug 24, 2018 · 6 comments
Assignees
Milestone

Comments

@HariSekhon
Copy link
Contributor

HariSekhon commented Aug 24, 2018

This isn't that far away, the safety number in the following line of code should probably be increased to something a lot bigger before this breaks everyone's tcollector metrics:

MAX_REASONABLE_TIMESTAMP = 1600000000  # Good until September 2020 :)

Maybe something more like this:

MAX_REASONABLE_TIMESTAMP = 2209212000 # Good until Tue  3 Jan 14:00:00 GMT 2040

This will give everyone a chance to come back from Christmas / New Year break and be back around their desks when it breaks, if anybody is still using TCollector that far in the future and AI hasn't replaced all of our jobs by then....

@bysse
Copy link

bysse commented Sep 14, 2020

Got burned by this yesterday. I'll never get those hours back again :)

@HariSekhon
Copy link
Contributor Author

@bysse at least the answer and fix was just a search away... :)

@elfchief
Copy link
Contributor

Since many/most people using tcollector are probably using the latest official tcollector release (1.3.2), which predates this patch, it wouldn't be surprising if most tcollector users are now experiencing this problem. You may consider getting 1.3.3 out the door ASAP, or doing a quick point release with just this change.

Oddly, this was harder for me to track down than it otherwise would have been, because I somehow did get one data point every hour or two, so my graphs weren't completely missing data -- the data was just very, very coarse (temporally speaking).

@bysse
Copy link

bysse commented Sep 15, 2020

Yes, I should have included a search keyword like Timestamp is too far out in the future when posting my initial comment to help others find this issue. Not sure if we had any sporadic data points but we were getting disk alerts on the /var partition and uncommitted journal alerts caused by syslog input flooding as well.

@johann8384
Copy link
Member

johann8384 commented Sep 16, 2020 via email

@mzw-g
Copy link

mzw-g commented Sep 18, 2020

yes,i got it,our TCollector all down at 2020-09-13 ....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants