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

Upgrade for new versions #8

Merged
merged 7 commits into from
Apr 7, 2016
Merged

Upgrade for new versions #8

merged 7 commits into from
Apr 7, 2016

Conversation

Elbandi
Copy link
Contributor

@Elbandi Elbandi commented Feb 10, 2016

Here are some changes:

  1. A field is added and one is removed from serverStatus.globalLock. First two commit handle this.
  2. in new zabbix (2.4), dot is the separaton in item keys (like system.cpu.load)
  3. Databases can be discovered by zabbix, and own items for every databases.
  4. No need to use temporally file for data, zabbix_sender can accept datas from stdin
  5. Output the errors to stderr, sysop can save the log to somewhere (/var/log/...), or just ignore it (/dev/null)

I dont know if this changes are backward compatible with old mongos or zabbix, but it is compatible with current stable releases (zabbix 2.4, mongodb 3.0)

@nightw
Copy link
Owner

nightw commented Feb 11, 2016

This changeset is very big and looks promising. Thank you for submitting it.

But unfortunately I have a big concern about backward compatibility. It has two main parts:

  • One is that Zabbix 2.2 is said to be an LTS version which mean it still has updates released to it at the same time as for 2.4.x. So I would like to keep the compatibility with it for at least until it's still supported by the Zabbix team
  • The other part is about renaming the keys in the XML file. I agree that it looks better and may be the new standard from now on, but it means that if you were running a previous version of this monitoring script, then you have to install the new template and that basically means losing item history for the old keys.

Do you have any proposed solution about keeping backward compatibility (with item keys and Zabbix 2.2 in general)? Maybe a separate XML file and a command line option for the script to decide about which one to output?

@Elbandi
Copy link
Contributor Author

Elbandi commented Feb 11, 2016

magyarul mondom, mert az konnyebb nekem :)

Sajna en 2.4-et telepitettem, igy nem tudom megnezni hogy az exportalt templatet megeszi-e egy 2.2-es zabbix. (dockerbol is csak 2.4/3-as vezio van elerhetoben)
Ha nem eszi meg akkor az gaz, megprobalom valahogy kideriteni.

A kulcs atnevezes problema, mert valoban elveszik a history. De akik mar hasznaljak a cuccot annak nem is kell frissiteniuk, ezek a valtozasok azoknak szolnak akik ezutan kezdik hasznalni a zabbixot.

Igy akar lehetne nyitni egy uj agat: master-new vagy master-2.4 vagy akar maradhat ez a master agon, es a regi szupportalni egy master-lts aggal.

@nightw
Copy link
Owner

nightw commented Feb 18, 2016

FYI for English speakers: We're discussing details about supporting older versions (old keys, Zabbix 2.2) besides accepting these new changes

Bocs, hogy csak most valaszolok. Szerintem is jo otlet az, hogy legyen ket "verzio". Viszont a branch-es dolog annyira nem feltetlenul jo otlet szerintem, mert nem eleg atlathato elsore, aki ideteved a GitHub repo oldalara. Mit szolnal, ha az lenne, hogy 1 branch marad igy:

  • Az osszes olyan commit-ot kivalogatnank a change-bol, ami siman mehet master-be kompatibilitasi problemak nelkul, that azok a PHP valtozasok a kulcsok atnevezesen kivul, amik csak javitjak a meglevo dolgokat (logolas kezelese, temp fajlok mellozese, globalLock uresseg fix)
  • Az ossze tobbi dolgok egy uj PHP fajlba menjen (ami masolat + ezek a change-ek egyben egy masik fajlban), aminek legyen a neve -2.4 vagy -new vagy valami hasonlo. Valamint legyen egy kulon XML fajl is az uj kulcsokal meg discovery item-ekkel, stb. szinten masik neven
  • A parancs verzioja is legyen a PHP fajl elejen 2.0 vagy ilyesmi (ez a neve es a 32. sorban van most: $command_version)
  • README-t en kibovitem az ennek megfelelo infokkal majd

Ha ez oke neked is, akkor tudod ugy modositani ezt a pull request-et, hogy ez legyen benne legyszives?

@nightw
Copy link
Owner

nightw commented Mar 11, 2016

@Elbandi Ez igy megfelel neked?

@Elbandi
Copy link
Contributor Author

Elbandi commented Mar 11, 2016

igen, megfelel. megprobalok majd erre is idot allokalni... :)

@nightw
Copy link
Owner

nightw commented Apr 3, 2016

Tudsz mondani valamilyen varhato datumot ezzel kapcsolatban?

@Elbandi
Copy link
Contributor Author

Elbandi commented Apr 4, 2016

mar tobb mint ket hete bepusholtam az uj fajlokat, lehet hulyen mutatja itt a github, nezd meg a repomat

@nightw
Copy link
Owner

nightw commented Apr 7, 2016

Valoban nem vettem eszre, hogy volt frissules. Elnezest. Megneztem, tetszik. Koszonom szepen a kodot. Beolvasztom es meg a README-t frissitem mindjart hozza es megvagyunk szerintem. :)

@nightw
Copy link
Owner

nightw commented Apr 7, 2016

FYI to English speakers: the implemented solution is to use separate template and script file to keep the old code which is compatible up to Zabbix 2.4 and the "default" files will contain the newer code for Zabbix 3.0. And it was done and merged. Thanks for Elbandi for the work.

@nightw nightw merged commit 80bec45 into nightw:master Apr 7, 2016
@Elbandi
Copy link
Contributor Author

Elbandi commented Apr 7, 2016

Csak egy megjegyzes: a -24 vegu fajlok a 2.4-hez valok (es ebbe raktam bele a pontelvalasztot+database discoveryt), a vegzodes nelkuliek pedig tovabbra is a 2.2-hoz valo.
En meg nem frissitettem 3.0-asra (tervben van), akkor megnezem hogy lehet-e importalni a 2.4-hez valot.

@nightw
Copy link
Owner

nightw commented Apr 10, 2016

Most visszaolvastam ezt a pull request-et es mar latom, hogy eredetileg is errol volt szo, csak en beneztem. Elenezest. Most frissitettem a README.md-t ennek megfeleloen. Ha megcsinalod a 3.0-hoz is azt nagyon megkoszonom amugy. :)

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

Successfully merging this pull request may close these issues.

None yet

2 participants