ਆਸਟ੍ਰੇਲੀਆ ਵਿੱਚ ਨਾਗੀਓਸ ਤੋਂ ਆਈਸਿੰਗਾ 2 ਤੱਕ ਪ੍ਰਵਾਸ

ਹਾਈ ਹਰ ਕੋਈ

ਮੈਂ ਇੱਕ ਲੀਨਕਸ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਹਾਂ, ਮੈਂ 2015 ਵਿੱਚ ਇੱਕ ਸੁਤੰਤਰ ਪੇਸ਼ੇਵਰ ਵੀਜ਼ੇ 'ਤੇ ਰੂਸ ਤੋਂ ਆਸਟਰੇਲੀਆ ਗਿਆ, ਪਰ ਲੇਖ ਇਸ ਬਾਰੇ ਨਹੀਂ ਹੋਵੇਗਾ ਕਿ ਇੱਕ ਸੂਰ ਲਈ ਟਰੈਕਟਰ ਕਿਵੇਂ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ। ਅਜਿਹੇ ਲੇਖ ਪਹਿਲਾਂ ਹੀ ਕਾਫ਼ੀ ਹਨ (ਫਿਰ ਵੀ, ਜੇਕਰ ਕੋਈ ਦਿਲਚਸਪੀ ਹੈ, ਤਾਂ ਮੈਂ ਇਸ ਬਾਰੇ ਵੀ ਲਿਖਾਂਗਾ), ਇਸ ਲਈ ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹਾਂਗਾ ਕਿ ਕਿਵੇਂ, ਇੱਕ ਲੀਨਕਸ-ਓਪਸ ਇੰਜੀਨੀਅਰ ਵਜੋਂ ਆਸਟ੍ਰੇਲੀਆ ਵਿੱਚ ਮੇਰੇ ਕੰਮ ਤੇ, ਮੈਂ ਇੱਕ ਸਿਸਟਮ ਨਿਗਰਾਨੀ ਤੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ। ਕਿਸੇ ਹੋਰ ਨੂੰ. ਖਾਸ ਤੌਰ 'ਤੇ - Nagios => Icinga2.

ਲੇਖ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਤਕਨੀਕੀ ਹੈ ਅਤੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਲੋਕਾਂ ਨਾਲ ਸੰਚਾਰ ਅਤੇ ਸੱਭਿਆਚਾਰ ਅਤੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਵਿੱਚ ਅੰਤਰ ਨਾਲ ਜੁੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਹੈ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, "ਕੋਡ" ਟੈਗ ਕਠਪੁਤਲੀ ਅਤੇ yaml ਕੋਡ ਨੂੰ ਉਜਾਗਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਮੈਨੂੰ "ਪਲੇਨਟੈਕਸਟ" ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਈ।

21 ਦਸੰਬਰ, 2016 ਦੀ ਸਵੇਰ ਨੂੰ ਮੁਸੀਬਤ ਦੇ ਕੋਈ ਸੰਕੇਤ ਨਹੀਂ ਸਨ. ਆਮ ਵਾਂਗ, ਮੈਂ ਕੰਮ ਵਾਲੇ ਦਿਨ ਦੇ ਪਹਿਲੇ ਅੱਧੇ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਗੈਰ-ਰਜਿਸਟਰਡ ਅਗਿਆਤ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਹਾਬਰ ਪੜ੍ਹ ਰਿਹਾ ਸੀ, ਕੌਫੀ ਪੀਂਦੇ ਹੋਏ, ਅਤੇ ਸਾਹਮਣੇ ਆਇਆ ਇਹ ਲੇਖ.

ਕਿਉਂਕਿ ਮੇਰੀ ਕੰਪਨੀ ਨੇ ਨਾਗਿਓਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ, ਬਿਨਾਂ ਦੋ ਵਾਰ ਸੋਚੇ, ਮੈਂ ਰੈੱਡਮਾਈਨ ਵਿੱਚ ਇੱਕ ਟਿਕਟ ਬਣਾਈ ਅਤੇ ਲਿੰਕ ਨੂੰ ਜਨਰਲ ਚੈਟ ਲਈ ਭੇਜਿਆ, ਕਿਉਂਕਿ ਮੈਂ ਇਸਨੂੰ ਮਹੱਤਵਪੂਰਨ ਸਮਝਿਆ. ਪਹਿਲਕਦਮੀ ਆਸਟ੍ਰੇਲੀਆ ਵਿੱਚ ਵੀ ਸਜ਼ਾਯੋਗ ਹੈ, ਇਸ ਲਈ ਲੀਡ ਇੰਜੀਨੀਅਰ ਨੇ ਮੈਨੂੰ ਇਸਦੀ ਖੋਜ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਮੱਸਿਆ ਨੂੰ ਪਿੰਨ ਕਰ ਦਿੱਤਾ।

Redmine ਤੋਂ ਸਕਰੀਨਸ਼ਾਟ

ਸਾਡੇ ਵਿਭਾਗ ਵਿੱਚ, ਆਪਣੀ ਰਾਏ ਜ਼ਾਹਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਘੱਟੋ ਘੱਟ ਇੱਕ ਵਿਕਲਪ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਨ ਦਾ ਰਿਵਾਜ ਹੈ, ਭਾਵੇਂ ਚੋਣ ਸਪੱਸ਼ਟ ਹੋਵੇ, ਇਸ ਲਈ ਮੈਂ ਗੂਗਲਿੰਗ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਵਰਤਮਾਨ ਵਿੱਚ ਢੁਕਵੇਂ ਹਨ, ਕਿਉਂਕਿ ਰੂਸ ਵਿੱਚ ਮੇਰੇ ਕੰਮ ਦੇ ਆਖਰੀ ਸਥਾਨ 'ਤੇ ਮੈਂ ਮੇਰੀ ਆਪਣੀ ਸਵੈ-ਲਿਖਤ ਪ੍ਰਣਾਲੀ ਸੀ, ਬਹੁਤ ਹੀ ਮੁੱਢਲੀ, ਪਰ ਇਸ ਦੇ ਬਾਵਜੂਦ ਇਸ ਨੂੰ ਸੌਂਪੇ ਗਏ ਸਾਰੇ ਕਾਰਜ ਕਾਫ਼ੀ ਕੰਮ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਕਰ ਰਿਹਾ ਸੀ। ਪਾਈਥਨ, ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਪੌਲੀਟੈਕਨਿਕ ਅਤੇ ਮੈਟਰੋ ਨਿਯਮ। ਨਹੀਂ, ਸਬਵੇਅ ਖਰਾਬ ਹੈ। ਇਹ ਨਿੱਜੀ ਹੈ (11 ਸਾਲ ਦਾ ਕੰਮ) ਅਤੇ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਦੇ ਯੋਗ ਹੈ, ਪਰ ਹੁਣ ਨਹੀਂ।

ਮੇਰੇ ਮੌਜੂਦਾ ਸਥਾਨ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਬਦਲਾਅ ਕਰਨ ਦੇ ਨਿਯਮਾਂ ਬਾਰੇ ਥੋੜ੍ਹਾ ਜਿਹਾ। ਅਸੀਂ ਕੋਡ ਸਿਧਾਂਤ ਵਜੋਂ ਕਠਪੁਤਲੀ, ਗਿਟਲਬ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਇਸ ਲਈ:

• ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ ਕਿਸੇ ਵੀ ਫਾਈਲ ਨੂੰ ਹੱਥੀਂ ਬਦਲ ਕੇ SSH ਦੁਆਰਾ ਕੋਈ ਦਸਤੀ ਤਬਦੀਲੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਤਿੰਨ ਸਾਲਾਂ ਦੇ ਕੰਮ ਦੌਰਾਨ, ਮੈਂ ਇਸ ਲਈ ਕਈ ਵਾਰ ਟੋਪੀ ਨਾਲ ਮਾਰਿਆ, ਆਖਰੀ ਵਾਰ ਇੱਕ ਹਫ਼ਤਾ ਪਹਿਲਾਂ ਸੀ ਅਤੇ ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਆਖਰੀ ਵਾਰ ਸੀ। ਖੈਰ, ਅਸਲ ਵਿੱਚ - ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਨੂੰ ਠੀਕ ਕਰੋ, ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ ਅਤੇ ਵੇਖੋ ਕਿ ਕੀ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਹੈ - 10 ਸਕਿੰਟ. Gitlab ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਸ਼ਾਖਾ ਬਣਾਓ, ਤਬਦੀਲੀਆਂ ਨੂੰ ਅੱਗੇ ਵਧਾਓ, Puppetmaster 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ r10k ਦੀ ਉਡੀਕ ਕਰੋ, Puppet -environment=mybranch ਚਲਾਓ ਅਤੇ ਕੁਝ ਮਿੰਟ ਹੋਰ ਉਡੀਕ ਕਰੋ ਜਦੋਂ ਤੱਕ ਇਹ ਸਭ ਕੰਮ ਨਹੀਂ ਕਰਦਾ - ਘੱਟੋ-ਘੱਟ 5 ਮਿੰਟ।
• Gitlab ਵਿੱਚ ਇੱਕ ਮਰਜ ਬੇਨਤੀ ਬਣਾ ਕੇ ਕੋਈ ਵੀ ਬਦਲਾਅ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਟੀਮ ਮੈਂਬਰ ਦੁਆਰਾ ਮਨਜ਼ੂਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਟੀਮ ਲੀਡ ਦੁਆਰਾ ਲਏ ਗਏ ਮੁੱਖ ਬਦਲਾਅ ਲਈ ਦੋ ਜਾਂ ਤਿੰਨ ਮਨਜ਼ੂਰੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਟੈਕਸਟ ਹੁੰਦੀਆਂ ਹਨ (ਕਿਉਂਕਿ ਕਠਪੁਤਲੀ ਮੈਨੀਫੈਸਟ, ਸਕ੍ਰਿਪਟ ਅਤੇ ਹੀਰਾ ਡੇਟਾ ਟੈਕਸਟ ਹਨ), ਬਾਈਨਰੀਆਂ ਬਹੁਤ ਨਿਰਾਸ਼ ਹਨ ਅਤੇ ਅਜਿਹੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਲਈ ਇੱਕ ਮਜਬੂਰ ਕਾਰਨ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਲਈ, ਮੈਂ ਵਿਚਾਰੇ ਗਏ ਵਿਕਲਪ:

• ਮੁਨਿਨ - ਜੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ 10 ਤੋਂ ਵੱਧ ਸਰਵਰ ਹਨ, ਤਾਂ ਪ੍ਰਸ਼ਾਸਨ ਨਰਕ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ (ਤੋਂ ਇਹ ਲੇਖ. ਮੈਨੂੰ ਇਸ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਕੋਈ ਖਾਸ ਇੱਛਾ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਮੈਂ ਇਸਦੇ ਲਈ ਉਸਦਾ ਸ਼ਬਦ ਲਿਆ)।
• ਜ਼ੈਬਿਕਸ - ਮੈਂ ਇਸਨੂੰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਦੇਖ ਰਿਹਾ ਸੀ, ਵਾਪਸ ਰੂਸ ਵਿੱਚ, ਪਰ ਫਿਰ ਇਹ ਮੇਰੇ ਕੰਮਾਂ ਲਈ ਬੇਲੋੜਾ ਸੀ। ਇੱਥੇ - ਇੱਕ ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਕ ਦੇ ਤੌਰ ਤੇ ਕਠਪੁਤਲੀ ਅਤੇ ਇੱਕ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਸਿਸਟਮ ਦੇ ਤੌਰ ਤੇ ਗਿਟਲੈਬ ਦੀ ਵਰਤੋਂ ਕਾਰਨ ਰੱਦ ਕਰਨਾ ਪਿਆ। ਉਸ ਸਮੇਂ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਿਆ, ਜ਼ੈਬਿਕਸ ਸਾਰੀ ਸੰਰਚਨਾ ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਲਈ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਕਿ ਮੌਜੂਦਾ ਹਾਲਤਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੈ ਅਤੇ ਤਬਦੀਲੀਆਂ ਨੂੰ ਕਿਵੇਂ ਟਰੈਕ ਕਰਨਾ ਹੈ।
• ਪ੍ਰੋਮੀਥੀਅਸ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਵਿਭਾਗ ਦੇ ਮੂਡ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ ਅੰਤ ਵਿੱਚ ਆਵਾਂਗੇ, ਪਰ ਉਸ ਸਮੇਂ ਮੈਂ ਇਸ ਵਿੱਚ ਮੁਹਾਰਤ ਨਹੀਂ ਰੱਖਦਾ ਸੀ ਅਤੇ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੇ ਨਮੂਨੇ (ਸੰਕਲਪ ਦਾ ਸਬੂਤ) ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ, ਇਸ ਲਈ ਮੈਨੂੰ ਇਨਕਾਰ ਕਰਨਾ ਪਿਆ।
• ਇੱਥੇ ਕਈ ਹੋਰ ਵਿਕਲਪ ਵੀ ਸਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜਾਂ ਤਾਂ ਸਿਸਟਮ ਦੇ ਸੰਪੂਰਨ ਪੁਨਰ-ਵਰਕ ਦੀ ਲੋੜ ਸੀ, ਜਾਂ ਉਹਨਾਂ ਦੇ ਬਚਪਨ ਵਿੱਚ / ਛੱਡ ਦਿੱਤੇ ਗਏ ਸਨ ਅਤੇ ਉਸੇ ਕਾਰਨ ਕਰਕੇ ਰੱਦ ਕਰ ਦਿੱਤੇ ਗਏ ਸਨ।

ਅੰਤ ਵਿੱਚ, ਮੈਂ ਤਿੰਨ ਕਾਰਨਾਂ ਕਰਕੇ Icinga2 'ਤੇ ਸੈਟਲ ਹੋ ਗਿਆ:

1 - Nrpe (ਇੱਕ ਕਲਾਇੰਟ ਸੇਵਾ ਜੋ Nagios ਤੋਂ ਕਮਾਂਡ ਚੈਕ ਚਲਾਉਂਦੀ ਹੈ) ਨਾਲ ਅਨੁਕੂਲਤਾ। ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸੀ, ਕਿਉਂਕਿ ਉਸ ਸਮੇਂ ਸਾਡੇ ਕੋਲ 135 (ਹੁਣ 2019 ਵਿੱਚ 165 ਹਨ) ਕਸਟਮ-ਲਿਖੀਆਂ ਸੇਵਾਵਾਂ/ਚੈਕਾਂ ਦੇ ਝੁੰਡ ਵਾਲੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਸਨ, ਅਤੇ ਇਸ ਸਭ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਇੱਕ ਅਸਲ ਦਰਦ ਹੋਣਾ ਸੀ।
2 - ਸਾਰੀਆਂ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਟੈਕਸਟ ਹਨ, ਜੋ ਇਸ ਮਾਮਲੇ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਇਹ ਦੇਖਣ ਦੀ ਯੋਗਤਾ ਨਾਲ ਮਰਜ ਬੇਨਤੀਆਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕੀ ਜੋੜਿਆ ਜਾਂ ਮਿਟਾਇਆ ਗਿਆ ਹੈ।
3 ਇੱਕ ਜੀਵਤ ਅਤੇ ਵਿਕਾਸਸ਼ੀਲ ਓਪਨਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਅਸੀਂ ਸੱਚਮੁੱਚ ਓਪਨਸੋਰਸ ਨੂੰ ਪਿਆਰ ਕਰਦੇ ਹਾਂ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਪੁੱਲ ਬੇਨਤੀਆਂ ਅਤੇ ਮੁੱਦੇ ਬਣਾ ਕੇ ਇਸ ਵਿੱਚ ਹਰ ਸੰਭਵ ਯੋਗਦਾਨ ਦਿੰਦੇ ਹਾਂ।

ਇਸ ਲਈ, ਚਲੋ, ਆਈਸਿੰਗਾ 2.

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਮੈਨੂੰ ਮੇਰੇ ਸਾਥੀਆਂ ਦੀ ਜੜਤਾ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ। ਹਰ ਕੋਈ Nagios/Naggios (ਹਾਲਾਂਕਿ ਇੱਥੇ ਵੀ ਉਹ ਇਸਦਾ ਉਚਾਰਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਸਮਝੌਤਾ ਨਹੀਂ ਕਰ ਸਕੇ) ਅਤੇ CheckMK ਇੰਟਰਫੇਸ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਆਈਸਿੰਗਾ ਇੰਟਰਫੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਇਹ ਇੱਕ ਘਟਾਓ ਸੀ), ਪਰ ਕਿਸੇ ਵੀ ਪੈਰਾਮੀਟਰ ਲਈ ਫਿਲਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਤੁਹਾਨੂੰ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ (ਇਹ ਇੱਕ ਪਲੱਸ ਸੀ, ਪਰ ਮੈਂ ਇਸਦੇ ਲਈ ਬਹੁਤ ਲੜਿਆ)।

ਫਿਲਟਰ

ਸਕ੍ਰੋਲ ਪੱਟੀ ਦੇ ਆਕਾਰ ਅਤੇ ਸਕ੍ਰੋਲ ਖੇਤਰ ਦੇ ਆਕਾਰ ਦੇ ਅਨੁਪਾਤ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ।

ਦੂਜਾ, ਹਰ ਕੋਈ ਇੱਕ ਮਾਨੀਟਰ 'ਤੇ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਦੇਖਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ CheckMk ਤੁਹਾਨੂੰ ਕਈ Nagios ਮੇਜ਼ਬਾਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ Icinga ਇੰਟਰਫੇਸ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਿਆ (ਅਸਲ ਵਿੱਚ, ਇਹ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਹੇਠਾਂ ਇਸ 'ਤੇ ਹੋਰ)। ਬਦਲ ਨੂੰ ਥ੍ਰੁਕ ਕਿਹਾ ਜਾਂਦਾ ਸੀ, ਪਰ ਇਸ ਦੇ ਡਿਜ਼ਾਈਨ ਨੇ ਟੀਮ 'ਤੇ ਇੱਕ ਨੂੰ ਛੱਡ ਕੇ ਹਰ ਕਿਸੇ ਨੂੰ ਗੈਗ ਬਣਾ ਦਿੱਤਾ - ਜਿਸ ਨੇ ਇਸਦਾ ਸੁਝਾਅ ਦਿੱਤਾ (ਮੈਂ ਨਹੀਂ)।

ਥਰੂਕ ਭੱਠੀ ਵਿੱਚ - ਟੀਮ ਦਾ ਸਰਬਸੰਮਤੀ ਨਾਲ ਫੈਸਲਾ

ਕੁਝ ਦਿਨਾਂ ਦੇ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਕਲੱਸਟਰ ਨਿਗਰਾਨੀ ਦਾ ਵਿਚਾਰ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ, ਜਦੋਂ ਉਤਪਾਦਨ ਜ਼ੋਨ ਵਿੱਚ ਇੱਕ ਮਾਸਟਰ ਹੋਸਟ ਅਤੇ ਦੋ ਸਲੇਵ ਹੁੰਦੇ ਹਨ - ਇੱਕ ਦੇਵ/ਟੈਸਟ ਵਿੱਚ ਅਤੇ ਇੱਕ ਬਾਹਰੀ ਹੋਸਟ ਦੂਜੇ ਪ੍ਰਦਾਤਾ 'ਤੇ ਸਥਿਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਸਾਡੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾ ਸਕੇ। ਇੱਕ ਗਾਹਕ ਜਾਂ ਇੱਕ ਬਾਹਰੀ ਨਿਰੀਖਕ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਸੇਵਾਵਾਂ। ਇਸ ਸੰਰਚਨਾ ਨੇ ਇੱਕ ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦੇਖਣਾ ਸੰਭਵ ਬਣਾਇਆ ਅਤੇ ਕਾਫ਼ੀ ਵਧੀਆ ਢੰਗ ਨਾਲ ਕੰਮ ਕੀਤਾ, ਪਰ ਕਠਪੁਤਲੀ... ਕਠਪੁਤਲੀ ਨਾਲ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਮਾਸਟਰ ਹੋਸਟ ਨੂੰ ਹੁਣ ਸਿਸਟਮ ਵਿੱਚ ਸਾਰੇ ਮੇਜ਼ਬਾਨਾਂ ਅਤੇ ਸੇਵਾਵਾਂ/ਚੈਕਾਂ ਬਾਰੇ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜ਼ੋਨਾਂ (dev-test, staging-prod, ext) ਵਿਚਕਾਰ ਵੰਡਣ ਲਈ, ਪਰ Icinga API ਰਾਹੀਂ ਤਬਦੀਲੀਆਂ ਭੇਜਣ ਵਿੱਚ ਕੁਝ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ, ਪਰ ਸਾਰੇ ਮੇਜ਼ਬਾਨਾਂ ਲਈ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਕਠਪੁਤਲੀ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਵਿੱਚ ਕੁਝ ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਇਹ ਅਜੇ ਵੀ ਮੇਰੇ 'ਤੇ ਦੋਸ਼ ਲਗਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਹਾਲਾਂਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਈ ਵਾਰ ਸਮਝਾਇਆ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਇੰਨਾ ਸਮਾਂ ਕਿਉਂ ਲੈਂਦਾ ਹੈ।

ਤੀਸਰਾ, ਇੱਥੇ ਸਨੋਫਲੇਕਸ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ - ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਆਮ ਪ੍ਰਣਾਲੀ ਤੋਂ ਵੱਖਰੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਕੋਲ ਕੁਝ ਖਾਸ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ 'ਤੇ ਆਮ ਨਿਯਮ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ ਹਨ। ਇਹ ਇੱਕ ਫਰੰਟਲ ਅਟੈਕ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ - ਜੇਕਰ ਅਲਾਰਮ ਹਨ, ਪਰ ਅਸਲ ਵਿੱਚ ਸਭ ਕੁਝ ਕ੍ਰਮ ਵਿੱਚ ਹੈ, ਤਾਂ ਮੈਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਖੋਦਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਅਤੇ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਇਹ ਮੈਨੂੰ ਕਿਉਂ ਸੁਚੇਤ ਕਰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ. ਜਾਂ ਇਸ ਦੇ ਉਲਟ - ਕਿਉਂ ਨਾਗੀਓਸ ਘਬਰਾਉਂਦੇ ਹਨ, ਪਰ ਆਈਸਿੰਗਾ ਨਹੀਂ ਕਰਦਾ.

ਚੌਥਾ, ਨਾਗਿਓਸ ਨੇ ਮੇਰੇ ਤੋਂ ਪਹਿਲਾਂ ਇੱਥੇ ਤਿੰਨ ਸਾਲਾਂ ਲਈ ਕੰਮ ਕੀਤਾ ਅਤੇ ਸ਼ੁਰੂ ਵਿੱਚ ਮੇਰੇ ਨਵੇਂ ਹਿਪਸਟਰ ਸਿਸਟਮ ਨਾਲੋਂ ਉਸ ਵਿੱਚ ਵਧੇਰੇ ਭਰੋਸਾ ਸੀ, ਇਸ ਲਈ ਹਰ ਵਾਰ ਆਈਸਿੰਗਾ ਨੇ ਘਬਰਾਹਟ ਪੈਦਾ ਕੀਤੀ, ਕਿਸੇ ਨੇ ਵੀ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਜਦੋਂ ਤੱਕ ਨਾਗੀਓਸ ਉਸੇ ਮੁੱਦੇ ਬਾਰੇ ਉਤਸ਼ਾਹਿਤ ਨਹੀਂ ਹੁੰਦਾ। ਪਰ ਬਹੁਤ ਘੱਟ ਹੀ ਆਈਸਿੰਗਾ ਨੇ ਨਾਗਿਓਸ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਅਲਾਰਮ ਤਿਆਰ ਕੀਤੇ ਹਨ ਅਤੇ ਮੈਂ ਇਸਨੂੰ ਇੱਕ ਗੰਭੀਰ ਸਮੱਸਿਆ ਸਮਝਦਾ ਹਾਂ, ਜਿਸ ਬਾਰੇ ਮੈਂ "ਸਿੱਟਾ" ਭਾਗ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗਾ।

ਨਤੀਜੇ ਵਜੋਂ, ਕਮਿਸ਼ਨਿੰਗ ਵਿੱਚ 5 ਮਹੀਨਿਆਂ ਤੋਂ ਵੱਧ ਦੇਰੀ ਹੋਈ (28 ਜੂਨ, 2018 ਲਈ ਯੋਜਨਾਬੱਧ, ਅਸਲ ਵਿੱਚ - 3 ਦਸੰਬਰ, 2018), ਮੁੱਖ ਤੌਰ 'ਤੇ "ਪੈਰਿਟੀ ਜਾਂਚ" ਦੇ ਕਾਰਨ - ਉਹ ਬਕਵਾਸ ਜਦੋਂ ਨਾਗੀਓਸ ਵਿੱਚ ਕਈ ਸੇਵਾਵਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ। ਬਾਰੇ ਪਿਛਲੇ ਦੋ ਸਾਲਾਂ ਤੋਂ ਕੁਝ ਨਹੀਂ ਸੁਣਿਆ ਹੈ, ਪਰ ਹੁਣੇ ਉਨ੍ਹਾਂ ਨੇ ਬਿਨਾਂ ਕਿਸੇ ਕਾਰਨ ਦੇ ਆਲੋਚਨਾ ਕੀਤੀ ਅਤੇ ਮੈਨੂੰ ਇਹ ਦੱਸਣਾ ਪਿਆ ਕਿ ਉਹ ਮੇਰੇ ਪੈਨਲ 'ਤੇ ਕਿਉਂ ਨਹੀਂ ਸਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਆਈਸਿੰਗਾ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਪਿਆ ਤਾਂ ਕਿ "ਪੈਰਿਟੀ ਜਾਂਚ ਪੂਰਾ" (ਨਾਗਿਓਸ ਵਿੱਚ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ/ਚੈਕਾਂ ਆਈਸਿੰਗਾ ਵਿੱਚ ਸੇਵਾਵਾਂ/ਚੈਕਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ)

ਲਾਗੂ ਕਰਨ:
ਪਹਿਲਾ ਕੋਡ ਬਨਾਮ ਡਾਟਾ ਯੁੱਧ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਠਪੁਤਲੀ ਸ਼ੈਲੀ. ਸਾਰਾ ਡਾਟਾ, ਬਿਲਕੁਲ ਸਭ ਕੁਝ, ਹੀਰਾ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਸਾਰਾ ਕੋਡ .pp ਫਾਈਲਾਂ ਵਿੱਚ ਹੈ। ਵੇਰੀਏਬਲ, ਐਬਸਟਰੈਕਸ਼ਨ, ਫੰਕਸ਼ਨ - ਸਭ ਕੁਝ pp ਵਿੱਚ ਜਾਂਦਾ ਹੈ।
ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡੇ ਕੋਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ (ਲਿਖਣ ਦੇ ਸਮੇਂ 165) ਅਤੇ 68 ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ SSL ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਵੈਧਤਾ ਲਈ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਰ ਇਤਿਹਾਸਕ ਹੇਮੋਰੋਇਡਜ਼ ਦੇ ਕਾਰਨ, ਨਿਗਰਾਨੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਜਾਣਕਾਰੀ ਇੱਕ ਵੱਖਰੀ ਗਿਟਲੈਬ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਲਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕਠਪੁਤਲੀ 3 ਤੋਂ ਡਾਟਾ ਫਾਰਮੈਟ ਨਹੀਂ ਬਦਲਿਆ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਸੰਰਚਨਾ ਵਿੱਚ ਵਾਧੂ ਗੁੰਝਲਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕਠਪੁਤਲੀ-ਕੋਡ, ਤੁਹਾਡੀਆਂ ਅੱਖਾਂ ਦੀ ਰੱਖਿਆ ਕਰੋ

define profiles::services::monitoring::docker_apps(
  Hash $app_list,
  Hash $apps_accessible_from,
  Hash $apps_access_list,
  Hash $webhost_defaults,
  Hash $webcheck_defaults,
  Hash $service_overrides,
  Hash $targets,
  Hash $app_checks,
  )
{
#### APPS ####
  $zone = $name
  $app_list.each | String $app_name, Hash $app_data |
  {

    $notify_group = { 'notify_group' => ($webcheck_defaults[$zone]['notify_group'] + pick($app_data['notify_group'], {} )) } # adds notifications for default group (systems) + any group defined in int/pm_docker_apps.eyaml

    $data = merge($webhost_defaults, $apps_accessible_from, $app_data)

    $site_domain = $app_data['site_domain']

    $regexp = pick($app_data['check_regex'], 'html')        # Pick a regex to check

    $check_url = $app_data['check_url'] ? {
      undef   => { 'http_uri' => '/' },
      default => { 'http_uri' => $app_data['check_url'] }
    }

    $check_regex = $regexp ?{
      'absent' => {},
      default  => {'http_expect_body_regex' => $regexp}
    }

    $site_domain.each | String $vhost, Hash $vdata | {        # Split an app by domains if there are two or more
      $vhost_name = {'http_vhost' => $vhost}

      $vars = $data['vars'] + $vhost_name + $check_regex + $check_url

      $web_ipaddress = is_array($vdata['web_ipaddress']) ? {  # Make IP-address an array if it's not, because askizzy has 2 ips and it's an array
        true  => $vdata['web_ipaddress'],
        false => [$vdata['web_ipaddress']],
      }

      $access_from_zones = [$zone] + $apps_access_list[$data['accessible_from']] # Merge default zone (where the app is defined) and extra zones if they exist
      $web_ipaddress.each | String $ip_address | {            # For each IP (if we have multiple)
        $suffix = length($web_ipaddress) ? {                  # If we have more than one - add IP as a suffix to this hostname to avoid duplicating resources
          1       => '',
          default => "_${ip_address}"
        }
        $octets = split($ip_address, '.')
        $ip_tag = "${octets[2]}.${octets[3]}" # Using last octet only causes a collision between nginx-vip 203.15.70.94 and ext. ip 49.255.194.94

        $access_from_zones.each | $zone_prefix |{
          $zone_target = $targets[$zone_prefix]

          $nginx_vip_name = "${zone_prefix}_nginx-vip-${ip_tag}" # If it's a host for ext - prefix becomes 'ext_' (ext_nginx-vip...)
          $nginx_host_vip = {
            $nginx_vip_name => {
              ensure        => present,
              target        => $zone_target,
              address       => $ip_address,
              check_command => 'hostalive',
              groups        => ['nginx_vip',],
            }
          }

          $ssl_vars = $app_checks['ssl']
          $regex_vars = $app_checks['http'] + $vars + $webcheck_defaults[$zone] + $notify_group

          if !defined( Profiles::Services::Monitoring::Host[$nginx_vip_name] ) {
          ensure_resources('profiles::services::monitoring::host', $nginx_host_vip)
          }

          if !defined( Icinga2::Object::Service["${nginx_vip_name}_ssl"] ) {
            icinga2::object::service {"${nginx_vip_name}_ssl":
              ensure         => $data['ensure'],
              assign         => ["host.name == $nginx_vip_name",],
              groups         => ['webchecks',],
              check_command  => 'ssl',
              check_interval => $service_overrides['ssl']['check_interval'],
              target         => $targets['services'],
              apply          => true,
              vars           => $ssl_vars
            }
          }
          if $regexp != 'absent'{
            if !defined(Icinga2::Object::Service["${vhost}${$suffix} regex"]){
              icinga2::object::service {"${vhost}${$suffix} regex":
                ensure          => $data['ensure'],
                assign          => ["match(*_nginx-vip-${ip_tag}, host.name)",],
                groups          => ['webchecks',],
                check_command   => 'http',
                check_interval  => $service_overrides['regex']['check_interval'],
                target          => $targets['services'],
                enable_flapping => true,
                apply           => true,
                vars            => $regex_vars
              }
            }
          }
        }
      }
    }
  }
}

ਮੇਜ਼ਬਾਨਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕੋਡ ਵੀ ਭਿਆਨਕ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

monitoring/config.pp

class profiles::services::monitoring::config(
  Array $default_config,
  Array $hostgroups,
  Hash $hosts = {},
  Hash $host_defaults,
  Hash $services,
  Hash $service_defaults,
  Hash $service_overrides,
  Hash $webcheck_defaults,
  Hash $servicegroups,
  String $servicegroup_target,
  Hash $user_defaults,
  Hash $users,
  Hash $oncall,
  Hash $usergroup_defaults,
  Hash $usergroups,
  Hash $notifications,
  Hash $notification_defaults,
  Hash $notification_commands,
  Hash $timeperiods,
  Hash $webhost_defaults,
  Hash $apps_access_list,
  Hash $check_commands,
  Hash $hosts_api = {},
  Hash $targets = {},
  Hash $host_api_defaults = {},
)
{

  # Profiles::Services::Monitoring::Hostgroup <<| |>> # will be enabled when we move to icinga completely
#### APPS ####
  case $location {
    'int', 'ext': {
      $apps_by_zone = {}
    }
    'pm': {
      $int_apps         = hiera('int_docker_apps')
      $int_app_defaults = hiera('int_docker_app_common')

      $st_apps          = hiera('staging_docker_apps')
      $srs_apps         = hiera('pm_docker_apps_srs')
      $pm_apps          = hiera('pm_docker_apps') + $st_apps + $srs_apps
      $pm_app_defaults  = hiera('pm_docker_app_common')

      $apps_by_zone = {
        'int' => $int_apps,
        'pm'  => $pm_apps,
      }

      $app_access_by_zone = {
        'int' => {'accessible_from' => $int_app_defaults['accessible_from']},
        'pm'  => {'accessible_from' => $pm_app_defaults['accessible_from']},
      }
    }

    default: {
      fail('Please ensure the node has $location fact set (int, pm, ext)')
    }
  }

  file { '/etc/icinga2/conf.d/':
    ensure  => directory,
    recurse => true,
    purge   => true,
    owner   => 'icinga',
    group   => 'icinga',
    mode    => '0750',
    notify  => Service['icinga2'],
  }

  $default_config.each | String $file_name |{
    file {"/etc/icinga2/conf.d/${file_name}":
      ensure => present,
      source => "puppet:///modules/profiles/services/monitoring/default_config/${file_name}",
      owner  => 'icinga',
      group  => 'icinga',
      mode    => '0640',
    }
  }

  $app_checks = {
    'ssl' => $services['webchecks']['checks']['ssl']['vars'],
    'http' => $services['webchecks']['checks']['http_regexp']['vars']
  }

  $apps_by_zone.each | String $zone, Hash $app_list | {
    profiles::services::monitoring::docker_apps{$zone:
      app_list             => $app_list,
      apps_accessible_from => $app_access_by_zone[$zone],
      apps_access_list     => $apps_access_list,
      webhost_defaults     => $webhost_defaults,
      webcheck_defaults    => $webcheck_defaults,
      service_overrides    => $service_overrides,
      targets              => $targets,
      app_checks           => $app_checks,
    }
  }

####    HOSTS    ####

  # Profiles::Services::Monitoring::Host <<| |>> # This is for spaceship invasion when it's ready.
  $hosts_has_large_disks = query_nodes('mountpoints.*.size_bytes >= 1099511627776')

  $hosts.each | String $hostgroup, Hash $list_of_hosts_with_settings | {           # Splitting site lists by hostgroups - docker_host/gluster_host/etc
    $list_of_hosts_in_group = $list_of_hosts_with_settings['hosts']
    $hostgroup_settings     = $list_of_hosts_with_settings['settings']
    $merged_hostgroup_settings = deep_merge($host_defaults, $list_of_hosts_with_settings['settings'])
    $list_of_hosts_in_group.each | String $host_name, Hash $host_settings |{  # Splitting grouplists by hosts
      # Is this host in the array $hosts_has_large_disks ? If so set host.vars.has_large_disks
      if ( $hosts_has_large_disks.reduce(false) | $found, $value| { ( $value =~ "^${host_name}" ) or $found } ) {
        $vars_has_large_disks = { 'has_large_disks' => true }
      } else {
        $vars_has_large_disks = {}
      }
      $host_data = deep_merge($merged_hostgroup_settings, $host_settings)
      $hostgroup_settings_vars = pick($hostgroup_settings['vars'], {})
      $host_settings_vars = pick($host_settings['vars'], {})
      $host_notify_group = delete_undef_values($host_defaults['vars']['notify_group'] + $hostgroup_settings_vars['notify_group'] + $host_settings_vars['notify_group'])
      $host_data_vars = delete_undef_values(deep_merge($host_data['vars'] , {'notify_group' => $host_notify_group}, $vars_has_large_disks)) # Merging vars separately

      $hostgroups = delete_undef_values([$hostgroup] + $host_data['groups'])

      profiles::services::monitoring::host{$host_name:
        ensure             => $host_data['ensure'],
        display_name       => $host_data['display_name'],
        address            => $host_data['address'],
        groups             => $hostgroups,
        target             => $host_data['target'],
        check_command      => $host_data['check_command'],
        check_interval     => $host_data['check_interval'],
        max_check_attempts => $host_data['max_check_attempts'],
        vars               => $host_data_vars,
        template           => $host_data['template'],
      }
    }
  }
  if !empty($hosts_api){                                                                # All hosts managed by API
    $hosts_api.each | String $zone, Hash $hosts_api_zone | {                            # Split api hosts by zones
      $hosts_api_zone.each | String $hostgroup, Hash $list_of_hosts_with_settings | {   # Splitting site lists by hostgroups - docker_host/gluster_host/etc
        $list_of_hosts_in_group = $list_of_hosts_with_settings['hosts']
        $hostgroup_settings     = $list_of_hosts_with_settings['settings']
        $merged_hostgroup_settings = deep_merge($host_api_defaults, $list_of_hosts_with_settings['settings'])
        $list_of_hosts_in_group.each | String $host_name, Hash $host_settings |{        # Splitting grouplists by hosts
          # Is this host in the array $hosts_has_large_disks ? If so set host.vars.has_large_disks
          if ( $hosts_has_large_disks.reduce(false) | $found, $value| { ( $value =~ "^${host_name}" ) or $found } ) {
            $vars_has_large_disks = { 'has_large_disks' => true }
          } else {
            $vars_has_large_disks = {}
          }
          $host_data = deep_merge($merged_hostgroup_settings, $host_settings)
          $hostgroup_settings_vars = pick($hostgroup_settings['vars'], {})

          $host_settings_vars = pick($host_settings['vars'], {})
          $host_api_notify_group = delete_undef_values($host_defaults['vars']['notify_group'] + $hostgroup_settings_vars['notify_group'] + $host_settings_vars['notify_group'])
          $host_data_vars = delete_undef_values(deep_merge($host_data['vars'] , {'notify_group' => $host_api_notify_group}, $vars_has_large_disks))
          $hostgroups = delete_undef_values([$hostgroup] + $host_data['groups'])

          if defined(Profiles::Services::Monitoring::Host[$host_name]){
            $hostname = "${host_name}_from_${zone}"
          }
          else
          {
            $hostname = $host_name
          }
          profiles::services::monitoring::host{$hostname:
            ensure             => $host_data['ensure'],
            display_name       => $host_data['display_name'],
            address            => $host_data['address'],
            groups             => $hostgroups,
            target             => "${host_data['target_base']}/${zone}/hosts.conf",
            check_command      => $host_data['check_command'],
            check_interval     => $host_data['check_interval'],
            max_check_attempts => $host_data['max_check_attempts'],
            vars               => $host_data_vars,
            template           => $host_data['template'],
          }
        }
      }
    }
  }

#### END OF HOSTS ####

####   SERVICES   ####

  $services.each | String $service_group, Hash $s_list |{             # Service_group and list of services in that group
    $service_list = $s_list['checks']                                 # List of actual checks, separately from SG settings
    $service_list.each | String $service_name, Hash $data |{

      $merged_defaults = merge($service_defaults, $s_list['settings']) # global service defaults + service group defaults
      $merged_data = merge($merged_defaults, $data)

      $settings_vars = pick($s_list['settings']['vars'], {})
      $this_service_vars = pick($data['vars'], {})
      $all_service_vars = delete_undef_values($service_defaults['vars'] + $settings_vars + $this_service_vars)

      # If we override default check_timeout, but not nrpe_timeout, make nrpe_timeout the same as check_timeout
      if ( $merged_data['check_timeout'] and ! $this_service_vars['nrpe_timeout'] ) {
        # NB: Icinga will convert 1m to 60 automatically!
        $nrpe = { 'nrpe_timeout' => $merged_data['check_timeout'] }
      } else {
        $nrpe = {}
      }

      # By default we use nrpe and all commands are run via nrpe. So vars.nrpe_command = $service_name is a default value
      # If it's server-side Icinga command - we don't need 'nrpe_command'
      # but there is no harm to have that var and the code is shorter

      if $merged_data['check_command'] == 'nrpe'{
        $check_command = $merged_data['vars']['nrpe_command'] ? {
          undef   => { 'nrpe_command' => $service_name },
          default => { 'nrpe_command' => $merged_data['vars']['nrpe_command'] }
        }
      }else{
        $check_command = {}
      }

      # Assembling $vars from Global Default service settings, servicegroup settings, this particular check settings and let's not forget nrpe settings.
      if $all_service_vars['graphite_template'] {
        $graphite_template = {'check_command' => $all_service_vars['graphite_template']}
      }else{
        $graphite_template = {'check_command' => $service_name}
      }
      $service_notify = [] + pick($settings_vars['notify_group'], []) + pick($this_service_vars['notify_group'], []) # pick is required everywhere, otherwise becomes "The value '' cannot be converted to Numeric"

      $service_notify_group = $service_notify ? {
        []      => $service_defaults['vars']['notify_group'],
        default => $service_notify
      } # Assing default group (systems) if no other groups are defined

      $vars = $all_service_vars + $nrpe + $check_command + $graphite_template + {'notify_group' => $service_notify_group}

      # This needs to be merged separately, because merging it as part of MERGED_DATA overwrites arrays instead of merging them, so we lose some "assign" and "ignore" values

      $assign = delete_undef_values($service_defaults['assign'] + $s_list['settings']['assign'] + $data['assign'])
      $ignore = delete_undef_values($service_defaults['ignore'] + $s_list['settings']['ignore'] + $data['ignore'])

      icinga2::object::service {$service_name:
        ensure             => $merged_data['ensure'],
        apply              => $merged_data['apply'],
        enable_flapping    => $merged_data['enable_flapping'],
        assign             => $assign,
        ignore             => $ignore,
        groups             => [$service_group],
        check_command      => $merged_data['check_command'],
        check_interval     => $merged_data['check_interval'],
        check_timeout      => $merged_data['check_timeout'],
        check_period       => $merged_data['check_period'],
        display_name       => $merged_data['display_name'],
        event_command      => $merged_data['event_command'],
        retry_interval     => $merged_data['retry_interval'],
        max_check_attempts => $merged_data['max_check_attempts'],
        target             => $merged_data['target'],
        vars               => $vars,
        template           => $merged_data['template'],
      }
    }
  }
#### END OF SERVICES ####

#### OTHER BORING STUFF ####

  $servicegroups.each | $servicegroup, $description |{
    icinga2::object::servicegroup{ $servicegroup:
      target       => $servicegroup_target,
      display_name => $description
    }
  }

  $hostgroups.each| String $hostgroup |{
    profiles::services::monitoring::hostgroup { $hostgroup:}
  }

  $notifications.each | String $name, Hash $settings |{

    $assign = pick($notification_defaults['assign'], []) + $settings['assign']
    $ignore = pick($notification_defaults['ignore'], []) + $settings['ignore']

    $merged_settings = $settings + $notification_defaults

    icinga2::object::notification{$name:
      target       => $merged_settings['target'],
      apply        => $merged_settings['apply'],
      apply_target => $merged_settings['apply_target'],
      command      => $merged_settings['command'],
      interval     => $merged_settings['interval'],
      states       => $merged_settings['states'],
      types        => $merged_settings['types'],
      assign       => delete_undef_values($assign),
      ignore       => delete_undef_values($ignore),
      user_groups  => $merged_settings['user_groups'],
      period       => $merged_settings['period'],
      vars         => $merged_settings['vars'],
    }
  }

  # Merging notification settings for users with other settings
  $users_oncall = deep_merge($users, $oncall)
  # Magic. Do not touch.
  create_resources('icinga2::object::user', $users_oncall, $user_defaults)
  create_resources('icinga2::object::usergroup', $usergroups, $usergroup_defaults)
  create_resources('icinga2::object::timeperiod',$timeperiods)
  create_resources('icinga2::object::checkcommand', $check_commands)
  create_resources('icinga2::object::notificationcommand', $notification_commands)

  profiles::services::sudoers { 'icinga_runs_ping_l2':
    ensure            => present,
    sudoersd_template => 'profiles/os/redhat/centos7/sudoers/icinga.erb',
  }

}

ਮੈਂ ਅਜੇ ਵੀ ਇਹਨਾਂ ਨੂਡਲਜ਼ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਅਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਉਹਨਾਂ ਨੂੰ ਬਿਹਤਰ ਬਣਾ ਰਿਹਾ ਹਾਂ। ਹਾਲਾਂਕਿ, ਇਹ ਇਹ ਕੋਡ ਸੀ ਜਿਸ ਨੇ ਸਾਨੂੰ ਹੀਰਾ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਸਮਝਣ ਯੋਗ ਸੰਟੈਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ:

ਡਾਟਾ

profiles::services::monitoring::config::services:
  perf_checks:
    settings:
      check_interval: '2m'
      assign:
        - 'host.vars.type == linux'
    checks:
      procs: {}
      load: {}
      memory: {}
      disk:
        check_interval: '5m'
        vars:
          notification_period: '24x7'
      disk_iops:
        vars:
          notifications:
            - 'silent'
      cpu:
        vars:
          notifications:
            - 'silent'
      dns_fqdn:
        check_interval: '15m'
        ignore:
          - 'xenserver in host.groups'
        vars:
          notifications:
            - 'silent'
      iftraffic_nrpe:
        vars:
          notifications:
            - 'silent'
  logging:
    settings:
      assign:
        - 'logserver in host.groups'
    checks:
       rsyslog: {}
      nginx_limit_req_other: {}
      nginx_limit_req_s2s: {}
      nginx_limit_req_s2x: {}
      nginx_limit_req_srs: {}
     logstash: {}
      logstash_api:
        vars:
          notifications:
            - 'silent'

ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਨੂੰ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਹਰੇਕ ਸਮੂਹ ਵਿੱਚ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ ਕਿ ਇਹਨਾਂ ਚੈਕਾਂ ਨੂੰ ਕਿੱਥੇ ਅਤੇ ਕਿੰਨੀ ਵਾਰ ਚਲਾਉਣਾ ਹੈ, ਕਿਹੜੀਆਂ ਸੂਚਨਾਵਾਂ ਭੇਜਣੀਆਂ ਹਨ ਅਤੇ ਕਿਸ ਨੂੰ ਭੇਜਣੀਆਂ ਹਨ।

ਹਰੇਕ ਚੈਕ ਵਿੱਚ, ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਹ ਸਭ ਆਖਿਰਕਾਰ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਦੀਆਂ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਇਸ ਲਈ ਅਜਿਹੀ ਬਕਵਾਸ ਨੂੰ config.pp ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ - ਇਹ ਸਮੂਹ ਸੈਟਿੰਗਾਂ ਅਤੇ ਫਿਰ ਹਰੇਕ ਵਿਅਕਤੀਗਤ ਜਾਂਚ ਨਾਲ ਸਾਰੀਆਂ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਸੀ, ਉਦਾਹਰਨ ਲਈ, http_regex ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਪੋਰਟ, ਐਡਰੈੱਸ ਅਤੇ url ਨੂੰ ਬਦਲਣ ਦਾ ਕੰਮ।

http_regexp:
  assign:
    - 'host.vars.http_regex'
    - 'static_sites in host.groups'
  check_command: 'http'
  check_interval: '1m'
  retry_interval: '20s'
  max_check_attempts: 6
  http_port: '{{ if(host.vars.http_port) { return host.vars.http_port } else { return 443 } }}'
  vars:
    notification_period: 'host.vars.notification_period'
    http_vhost: '{{ if(host.vars.http_vhost) { return host.vars.http_vhost } else { return host.name } }}'
    http_ssl: '{{ if(host.vars.http_ssl) { return false } else { return true } }}'
    http_expect_body_regex: 'host.vars.http_regex'
    http_uri: '{{ if(host.vars.http_uri) { return host.vars.http_uri } else { return "/" } }}'
    http_onredirect: 'follow'
    http_warn_time: 8
    http_critical_time: 15
    http_timeout: 30
    http_sni: true

ਇਸਦਾ ਮਤਲਬ ਹੈ - ਜੇ ਹੋਸਟ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਹੈ http_port — ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ, ਨਹੀਂ ਤਾਂ 443। ਉਦਾਹਰਨ ਲਈ, ਜੈਬਰ ਵੈੱਬ ਇੰਟਰਫੇਸ 9090 'ਤੇ ਹੈਂਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਯੂਨੀਫਾਈ 7443 'ਤੇ ਹੈਂਗ ਹੁੰਦਾ ਹੈ।
http_vhost ਮਤਲਬ DNS ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ ਅਤੇ ਇਸ ਐਡਰੈੱਸ ਨੂੰ ਲਓ।
ਜੇਕਰ uri ਮੇਜ਼ਬਾਨ ਵਿੱਚ ਨਿਰਦਿਸ਼ਟ ਹੈ, ਤਾਂ ਇਸਦਾ ਪਾਲਣ ਕਰੋ, ਨਹੀਂ ਤਾਂ “/” ਲਓ।

http_ssl ਦੇ ਨਾਲ ਇੱਕ ਮਜ਼ਾਕੀਆ ਕਹਾਣੀ ਸਾਹਮਣੇ ਆਈ - ਇਹ ਲਾਗ ਮੰਗ 'ਤੇ ਡਿਸਕਨੈਕਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ. ਮੈਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇਸ ਲਾਈਨ ਬਾਰੇ ਉਲਝਣ ਵਿੱਚ ਸੀ ਜਦੋਂ ਤੱਕ ਇਹ ਮੇਰੇ 'ਤੇ ਨਹੀਂ ਆਇਆ ਕਿ ਹੋਸਟ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰੀਏਬਲ ਹੈ:

http_ssl: false

ਪ੍ਰਗਟਾਵੇ ਵਿੱਚ ਬਦਲਿਆ

if(host.vars.http_ssl) { return false } else { return true }

ਨੂੰ ਝੂਠੇ ਅਤੇ ਅੰਤ ਵਿੱਚ ਇਹ ਬਾਹਰ ਕਾਮੁਕ

if(false) { return false } else { return true }

ਭਾਵ, ssl ਜਾਂਚ ਹਮੇਸ਼ਾ ਕਿਰਿਆਸ਼ੀਲ ਹੁੰਦੀ ਹੈ। ਮੈਂ ਇਸਨੂੰ ਸੰਟੈਕਸ ਨੂੰ ਬਦਲ ਕੇ ਹੱਲ ਕੀਤਾ:

http_ssl: no

ਸਿੱਟਾ:

ਪ੍ਰੋ:

• ਸਾਡੇ ਕੋਲ ਹੁਣ ਇੱਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਹੈ, ਦੋ ਨਹੀਂ, ਜਿਵੇਂ ਕਿ ਸਾਡੇ ਕੋਲ ਪਿਛਲੇ 7-8 ਮਹੀਨਿਆਂ ਤੋਂ ਹੈ, ਜਾਂ ਇੱਕ ਜੋ ਪੁਰਾਣਾ ਅਤੇ ਕਮਜ਼ੋਰ ਹੈ।
• ਮੇਜ਼ਬਾਨ/ਸੇਵਾਵਾਂ (ਚੈੱਕ) ਡਾਟਾ ਢਾਂਚਾ ਹੁਣ (ਮੇਰੀ ਰਾਏ ਵਿੱਚ) ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਸਮਝਣ ਯੋਗ ਹੈ। ਦੂਜਿਆਂ ਲਈ, ਇਹ ਇੰਨਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ, ਇਸਲਈ ਮੈਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਸਥਾਨਕ ਵਿਕੀ 'ਤੇ ਕੁਝ ਪੰਨੇ ਪੋਸਟ ਕਰਨੇ ਪਏ ਕਿ ਇਹ ਸਭ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਸੰਪਾਦਿਤ ਕਰਨਾ ਹੈ।
• ਵੇਰੀਏਬਲ ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਚੈਕਾਂ ਨੂੰ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਉਦਾਹਰਨ ਲਈ, http_regexp ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਲੋੜੀਂਦਾ ਪੈਟਰਨ, ਰਿਟਰਨ ਕੋਡ, url ਅਤੇ ਪੋਰਟ ਹੋਸਟ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਸੈੱਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
• ਇੱਥੇ ਕਈ ਡੈਸ਼ਬੋਰਡ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਲਈ ਤੁਸੀਂ ਪ੍ਰਦਰਸ਼ਿਤ ਅਲਾਰਮ ਦੀ ਆਪਣੀ ਖੁਦ ਦੀ ਸੂਚੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸ ਸਭ ਨੂੰ ਕਠਪੁਤਲੀ ਅਤੇ ਮਰਜ ਬੇਨਤੀਆਂ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਨੁਕਸਾਨ:

• ਟੀਮ ਦੇ ਮੈਂਬਰਾਂ ਦੀ ਜੜਤਾ - ਨਾਗਿਓਸ ਨੇ ਕੰਮ ਕੀਤਾ, ਕੰਮ ਕੀਤਾ ਅਤੇ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਤੁਹਾਡਾ ਇਹ ਇਸਿੰਗਾ ਲਗਾਤਾਰ ਬੱਗਾ ਅਤੇ ਹੌਲੀ ਹੈ। ਤੁਸੀਂ ਇੱਥੇ ਇਤਿਹਾਸ ਨੂੰ ਕਿਵੇਂ ਦੇਖ ਸਕਦੇ ਹੋ? ਓਹ, ਬਦਨਾਮ, ਇਹ ਅਪਡੇਟ ਨਹੀਂ ਹੋਇਆ ਹੈ... (ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਲਾਰਮ ਇਤਿਹਾਸ ਆਪਣੇ ਆਪ ਅਪਡੇਟ ਨਹੀਂ ਹੁੰਦਾ, ਸਿਰਫ F5 ਦੁਆਰਾ)
• ਸਿਸਟਮ ਦੀ ਜੜਤਾ - ਜਦੋਂ ਮੈਂ ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ "ਅਪਡੇਟ" (ਹੁਣੇ ਚੈੱਕ ਕਰੋ) 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹਾਂ - ਲਾਗੂ ਕਰਨ ਦਾ ਨਤੀਜਾ ਮੰਗਲ 'ਤੇ ਮੌਸਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਗੁੰਝਲਦਾਰ ਸੇਵਾਵਾਂ 'ਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਈ ਸਕਿੰਟਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਜਿਹਾ ਨਤੀਜਾ ਆਮ ਹੈ.
• ਆਮ ਤੌਰ 'ਤੇ, ਦੋਵਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ-ਨਾਲ ਚੱਲਣ ਦੇ ਛੇ ਮਹੀਨਿਆਂ ਦੇ ਅੰਕੜਿਆਂ ਦੇ ਅਨੁਸਾਰ, ਨਾਗਿਓਸ ਨੇ ਹਮੇਸ਼ਾ ਆਈਸਿੰਗਾ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕੀਤਾ ਅਤੇ ਇਸ ਨੇ ਮੈਨੂੰ ਸੱਚਮੁੱਚ ਪਰੇਸ਼ਾਨ ਕੀਤਾ. ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੇ ਟਾਈਮਰਾਂ ਨਾਲ ਕੁਝ ਗੜਬੜ ਕੀਤੀ ਹੈ ਅਤੇ ਜਾਂਚ ਹਰ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਸਲ ਵਿੱਚ ਇਹ ਹਰ 5:30 ਵਜੇ ਜਾਂ ਅਜਿਹਾ ਕੁਝ ਹੁੰਦਾ ਹੈ।
• ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਸਮੇਂ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦੇ ਹੋ (systemctl ਰੀਸਟਾਰਟ icinga2) - ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਜੋ ਉਸ ਸਮੇਂ ਚੱਲ ਰਹੀਆਂ ਸਨ, ਇੱਕ ਨਾਜ਼ੁਕ ਅਲਾਰਮ ਪੈਦਾ ਕਰਨਗੇ। ਸਕਰੀਨ 'ਤੇ ਅਤੇ ਬਾਹਰੋਂ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਜਿਵੇਂ ਸਭ ਕੁਝ ਡਿੱਗ ਗਿਆ ਹੋਵੇ (ਪੁਸ਼ਟੀ ਕੀਤੀ ਬੱਗ).

ਪਰ ਕੁੱਲ ਮਿਲਾ ਕੇ, ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ.

ਸਰੋਤ: www.habr.com