ДТАП
Поскольку мониторинг является частью производства, он также должен быть частью DTAP. Это также подразумевает мониторинг разработки, тестирования, приемки и производства. Если кто-то модифицирует проверку в производстве, и это приведет к отключению какой-либо проверки, и если команде не сообщат о наличии проблем, это повлияет на клиента, и это может стать огромной проблемой. Короче говоря, если мониторинг является частью производства, его следует применять и ко всем этапам DTAP.
Тестирование
Если в splunk используются пользовательские сценарии, написанные на Python или каком-либо другом языке, вам также следует применить модульные тесты и интеграционные тесты. В большинстве систем мониторинга проверяются коды выхода 0, 1, 2 и 3, поэтому это также следует учитывать в тестах. Если мониторинг написан на bash, можно использовать BATS, а Powershell также можно протестировать с помощью Pester.
Зачем тестировать эти скрипты? Опять же, причина та же, что описана в разделе DTAP. Представьте, что кто-то нарушает какой-то сценарий мониторинга, допустив опечатку, и вы не получаете уведомления, тогда это может оказать огромное влияние на клиента, а также на команду. Представьте, что вам нужно провести отладку пару дней из-за того, что какой-то скрипт работает некорректно, хотя это можно было предотвратить. Поэтому я советую применять модульные тесты, интеграционные тесты и даже CI для этих «простых» скриптов мониторинга.
![Живой курс чудес, через практику и эксперименты [ЭКСКЛЮЗИВ]](/assets/images/icons/forum7.png){kind=icon}
