[Bushi]

mysql_tzinfo_to_sql помог, cacti рисует теперь правильно графики

[s.lobanov]

Кстати, если изначально не вливать таймзоны в mysql, то он умеет брать системную и тогда нужен только его перезапуск

[st_re]

 

у меня дырка на час.

 

только дырка? без спайка?

 

Сейчас еще раз посмотрел. Где дырка в 2 часа ночи, там чисто разрыв, без всяких всплесков, а вот в том месте где Burst+забытые обновления дляmysql там в час ночи всплеск и дырка уже днем..

 

Всплеск только на расчетных значениях естественно, типа трафика. на абсолютных, типа памяти, там есесвтенно всплескивать нечему, там все ровно.

 

Кстати, если изначально не вливать таймзоны в mysql, то он умеет брать системную и тогда нужен только его перезапуск

may be, я еще в 11 году залил везде :) а перезапуск походу по любому нужен..

[s.lobanov]

st_re

всплески будете выпиливать или так оставите?

[karpa13a]

cron еще покорёжило.

[st_re]

st_re

всплески будете выпиливать или так оставите?

 

Я на вскидку ничего страшного не увидел, слишком большие походу не прошли по лимитам трафика. Если нигде петайбайтов не вылезет, то так оставлю. Вообще у меня валяется скриптик для отрезания пиков.

 

2 karpa13a После обновления TZDATА крон нужно переапустить.. Как и сендмел, постфикс, сислог и еще кучу разной мелочи...

[st_re]

st_re

всплески будете выпиливать или так оставите?

 

Походу там реальные всплески трафика были... Завтра нетфлоу разгребу еще.

 

 

Я вообще плохо понимаю источник проблем, ладно, у нас оно раз в 3 года. тут наложилось что не всему софту объяснили про новые веяния. А вся Европа и штаты, они же какждый год время переводят. Эти дырки у них раз в год должны вылезать.

[st_re]

Т.е. это cacti неправильно запихивает данные в rrd? или rrd должно быть правильной версии?

Я не помню, как cacti работает. Может и само считает. Или шаблон генерации графика настроен так, что в качестве скорости строится значение, вычисляемое вне rrd.

 

В любом случае такой явной ошибки быть не должно. Summer time и связанный с ним перевод часов как бы много где существует.

 

В rrd заливается значение из snmp. Для типа данных counter оно считает разницу между переданным и предыдущим, и делит на прошедшее время.

 

Судя по всему в какомто варианте пулера оно пытается передать время преобразуя в тамстамп не слишком верно учитывая до перевода или после перевода или вообще забивая на таймзоны. И получается что оно 1 раз залило для 1:55 потом время скакнуло назад и оно заливает для 1:00, а такое по его версии уже было, он режектит, и так ло 2:00, тут оно считает что прошло 5 минут и принимает данные (реально прошло час 5 минут, а не 5 минут) соответственно вместо 100 мегабит обычных оно насчитало гиг.

 

Внутри РРД время хранится в тамстапмах, оно монотонно растет в независисмости от постановлений правительства и текущей тайм зоны... В общем необязательно было ломать график.

 

А вот почему у меня дырки, надо еще посмотреть в сорцах. Возможно оно дату файла еще смотрит, с тами же проблемами, (например /usr/bin/stat оказался крив в том месте. Весь первый промежуток с 1 до 2 (до перевода) он неверно отдавал тамстамп для файла.)

[Sergey Gilfanov]

Судя по всему в какомто варианте пулера оно пытается передать время преобразуя в тамстамп не слишком верно учитывая до перевода или после перевода или вообще забивая на таймзоны.

Это возможно, если вообще время пулер пытается указать. Стандартное поведение - это 'положить текущее значение' а rrd само уже внутри себя timestamp возьмет.

 

Возможно оно дату файла еще смотрит, с тами же проблемами, (например /usr/bin/stat оказался крив в том месте. Весь первый промежуток с 1 до 2 (до перевода) он неверно отдавал тамстамп для файла.)

А это точно /usr/bin/stat был? А не что-нибудь встроенное в шелл? Если последнее и шелл (сессия) древний - то измененные зоны оно бы не увидело.

[st_re]

AFAIR кактус время пихает. там есть 2 варианта вызова ф-кции. С временем и без него. С временем можно заливать отложенно данные, что мой планин и делает.Там вообще все льется в базу а плагин потом переливает в rrd. Но никто не мешает с временем указывать всегда.

 

Со статом проблемы вылезла и на freebsd и на RHEL и /bin/sh на фре и /bin/bash на линуксе и версии очень разных годов, включая достаточно свежие. Так получилось, что в мониторинге у нас широко используется скрипт который проверяет актуальность ранее собранных данных именно статом... ВНЕЗАПНО за час до перевода часов все данные стали не актуальными :) если бы не увидело изменеий /etc/localtime то все бы работало до перевода часов... А тут нате. Я в общем до момента перевода часов подвоха не ждал. С чего бы, казалось. После да, может где чо забылось. а что ему до то ломаться. Ан нет...

 

Еще както криво ucd-snmp время отдавать начал ( HOST-RESOURCES-MIB::hrSystemDate.0) но тут у них от версии к версии вообще что угодно выдается. Гдето сразу после обновления localtime оно +3 написало, еще месяц назад, гдето за час до перевода, гдето так все еще и пишет +4, хотя уже перезапускалось и после обновления и даже после перевода.. Этим вооще надо чтото оторвать за такой код. То у них диски ни так считаются, то -HUP крашит потому что ктото массив обнулил а счетчик нет, то еще какато хрень.

 

 

зы

Но скорее всего часть проблем от того, что мы переходим не с летнего на стандартное, а со стандартного на стандартное, т.е. не как оно было до 2011 MSD->MSK а MSK->MSK

т.е.

# date

Вс окт 26 01:00:18 MSK 2014

 

может оказаться как

1414274418, так и на 3600 меньше...

[Bushi]

Столкнулся с новой бякой - на стораже приложение zfs-snapshot-mgmt херит все снэпшоты старше одних суток, которые должны были хранится несколько месяцев, пока не разобрался с таким поведением.