Продолжение нашего разговора о логах отсылает к известной фразе “Quis custodiet ipsos custodes?” («Кто устережёт самих сторожей?» или «Кто наблюдает за самими наблюдателями?»).
Любые большие системы — технические или социальные (например, общество и его институты) — нуждаются в средствах мониторинга и логирования, чтобы в случае нештатной ситуации понять, что пошло не так, и раскрутить всю ситуацию в обратную сторону к источнику проблемы (на жаргоне программистов это называется раздебажить проблему — от английского слова debug).
После того как проблема найдена, можно начать её решать, сделать всё возможное, чтобы она не повторилась в будущем. Но пока причины проблемы не ясны, наши руки связаны неопределенностью.
Примечание: но даже в условиях неопределенности есть способы недопустить нештатные ситуации, несмотря на то, что мы заранее не знаем их потенциальный источник. Такие способы на жаргоне программистов называются «заборы» («давайте поставим здесь забор») или “guards” на английском. О них мы ещё поговорим отдельно в своё время.
Однако парадокс в том, что система мониторинга, слежения, логирования — это тоже система и она тоже подвержена ошибкам (и злоупотреблениям, если мы говорим про общество). В каком-то смысле, это похоже на кота, который пытается догнать свой собственный хвост.
Из-за того, что на системы логирования/мониторинга возлагается такая серьезная «миссия», они требуют более тщательного проектирования и отладки. Ошибки в этой системе будут стоить дороже, так как они пронизывают всю систему. То же самое можно сказать про правоохранительные органы, управления внутренней безопасности и тому подобные службы, которые призваны следить за тем, что всё идет как надо.
Но это ещё не все. Помимо того, что подсистема логирования и мониторинга может быть сама источником ошибок, которые уже некому будет обнаружить, её использование в рамках общей системы — не бесплатно. Так же, как обществу приходится (в виде налогов) оплачивать работу всех контролирующих и правоохранительных органов, так и внутри технической системы логирование и мониторинг:
-
потребляют время CPU (процессора);
-
отъедают часть оперативной памяти (RAM);
-
тратят место на диске (SSD / HDD / флеш-карта), увеличивая, в том числе, износ диска;
-
нагружают сеть при передаче логов или сигналов мониторинга в централизованное хранилище.
А ещё, самое главное — чтобы создавать и поддерживать системы логирования и мониторинга, на них тоже надо тратить время разработчиков (то, что называется человеко-часы), а не только на разработку основной программы.
Всё перечисленное выше увеличивает стоимость конечного программного продукта. Но для многих систем наличие подсистем логирования и мониторинга — не роскошь, а необходимость, потому что ущерб от нештатной ситуации часто может перекрыть всё, что вы сэкономили ранее на этих системах.
И последнее: мы добавляем в наши программы логирование, чтобы лучше понимать, что и когда она делает. Чтобы лучше разобраться в причинах потенциальных проблем. Но иногда само добавление логов меняет поведение программы (ведь мы влияем и на загруженность процессора, и на распределение данных в памяти, и на временные характеристики нашей программы).
Здесь можно провести параллель с физикой: эффектом наблюдателя — когда наблюдатель самим фактом своего присутствия влияет на систему. Особенно ярко это проявляется в квантовой физике.
Кстати, в квантовой криптографии эффект наблюдателя используется в позитивном ключе — при попытке подслушать «передачу», она необратимо меняется, — таким образом позволяя обнаружить факт прослушки.
В последней части, посвященной нашему разговору (со звездочкой) о логах, мы поговорим о том, как уменьшить влияние системы логирования на общую систему: снизить нагрузку на CPU, уменьшить потребление памяти итп. А ещё поговорим о том, как не захлебнуться в логах.