Icinga2 HA setting with graphite/gelf

  • Hi all,


    Maybe my question sounds silly but I really want to know about this. I believe the HA for icinga2 IDO is already possible. So, setting two masters in the master zone doesn't matter for recording to IDO database I believe. What about graphite and gelf? If I enable graphite and gelf on both nodes in the master zone, will it record only one time (which means they are aware of the cluster) or both nodes record the same data? Cheers.

  • These features are not noted to be HA-ready.

    So both nodes should write the same data (possibly to different servers, in case of influxdb, perhaps that enables you to run multiple replica sets, i do not know).


    To be sure what happens even when it comes to delays, latency, failover etc you should build a virtual environment and check it.

  • I wish I could contribute to. I have to learn programming first though. Just for curiosity, how does HA work for IDO? Should HA for graphite and gelf be the same?

  • Just for curiosity, how does HA work for IDO? Should HA for graphite and gelf be the same?

    https://docs.icinga.com/icinga…-high-availability-db-ido


    These features are completely independent - they can not work the same way.


    You do not need to learn programming - just start testing what is there.

    For example, what happens if you

    create two GraphiteWriter Objects with different server addresses ?


  • HA for Graphite/Gelf would probably look the same as the notification component - only fire a notification if the object is not paused && enable_ha=true

    https://github.com/Icinga/icin…ficationcomponent.cpp#L88


    That way both nodes will only process checkresults/notifications where they feel responsible for. If enable_ha=false (the sane default for not breaking upgrades), then both nodes would process everything on their own.

  • HA for Graphite/Gelf would probably look the same as the notification component - only fire a notification if the object is not paused && enable_ha=true

    https://github.com/Icinga/icin…ficationcomponent.cpp#L88


    That way both nodes will only process checkresults/notifications where they feel responsible for. If enable_ha=false (the sane default for not breaking upgrades), then both nodes would process everything on their own.

    Right, so can I safely guess that if 'enable_ha' is set to true, HA for gelf and graphite might be working as I expected? Also, should 'enable_ha=true' option be written on each configuration file (gelf.conf/graphite.conf) like putting in 'ido-mysql.conf' file? Or, putting the statement in 'ido-mysql.conf' file is enough? Thanks in advance.

  • can I safely guess that if 'enable_ha' is set to true, HA for gelf and graphite might be working as I expected?

    f you're looking into making this possible, we gladly review your patch

    For me, that sounds like:

    • No, that is not currently implemented.
    • Implementation would probably not be too hard and could follow the example found in the feature notification.
  • For me, that sounds like:

    • No, that is not currently implemented.
    • Implementation would probably not be too hard and could follow the example found in the feature notification.

    Sorry, I think I am having a bit of English difficulty here. When you say the example, does that mean this? https://docs.icinga.com/icinga…vailability-notifications


    Also, the patch work is involved in changing the source code, isn't it? If so, I really have to start studying programming.

  • While thinking about it, I'd say it probably makes more sense to implement it like DB IDO - have the feature enabled on both nodes, but only one has the feature active, the other one is paused.