Как-то мне рассказали о такой интересно штуке, как exception driven development. Это когда вы начинаете налавливать эксепшены и просто таки строить на них всю логику приложения. После такого в логе можно найти что-то типа:

 This is not an error. Even foobar captured

Так вот, такого делать не надо. Анти-патерны окружают нас на самом деле повсюду и не только в сфере разработки приложений. Это я к тому, что завтра я бы хотел написать либо о анти-паттернах, либо о логах — ещё не решил.

А пока почитайте про другие пагубный паттерны в статье с прекрасным названием "Asshole-driven development"
#anti-pattern #development

У меня выдался крайне загруженный день, поэтому написать что-либо вразумительное ни про логи, ни про анти-паттерны я тупо не успел.

Зато Puppetlabs тут сделали опрос, по которому вы можете определить, насколько глубоко DevOps практики засели в вашей компании.

Там всего 17 вопросов и мне выпало 'Advanced'. Хотя у нас далеко не все хорошо, там такой опрос, что получить не 'Advanced', наверное, сложно

С другой стороны, на основании подобных опросов они скорее всего делают ежегодный отчёт, так что ваш голос улучшит выборку

Как раз для пятницы. Кстати, https://www.commitstrip.com прикольный, почитайте)

Тем временем вышел апдейт Atom'а. Они наконец-то сделали поддержку Git. В MS Visual Studio Code, вроде, изначально была.

Кроме того, есть интеграция с GitHub: можно ресолвить конфликты и просматривать пул реквесты.

Создать issue прямо из редактора, к сожалению, пока нельзя
#editors

Atom Editor 1.18 Released with Rich Git Integration
😁 goo.gl/3v7YVr

Ну и ещё подъехали записи с очередного SRECon

Опубликованы видеозаписи докладов с SREcon 2017 Asia. Отдельно хотел бы обратить внимание на доклад Golang's Garbage про некоторые особенности работы сборщика мусора в Golang.

Список докладов со ссылками на видео можно найти на официальной странице конференции:
https://www.usenix.org/conference/srecon17asia/program

#srecon #videos #sre

Так вот, о логах. Я бы не хотел зострять на них внимания с точки хрения разработчика. Уже очень много было сказано о том, что логгировать необходимо только значимые события, дифференцировать разные уровни (ERROR, WARN, INFO, DEBUG, etc) и стараться стандартизировать сообщения. Об этом вы можете почитать здесь или тут

Я бы хотел акцентировать на том, что как бы вы их не писали, ходить и вручную собирать сообщения по серверам — плохая идея. Да и вообще, хранить их там долго — не очень хорошо. Логи могут тупо забить весь диск. Думаю, все слышали про ELK (elasticsearch + logstash+ kibana) для сбора, поиска и визуализации системных сообщений.

Это удобно, во-первых, потому что вам не надо рыскать по пачке машин в поисках ошибки, во-вторых, потому что упрощает capacity planning. Вы без проблем сможете прикинуть, сколько места вам понадобится под это дело, как часто надо чистить старые сообщения и т.д

Но всё-таки иногда в компаниях работают "по-старинке". Из моей практики, при этом подходе есть пару советов:

- ротируйте логи не по времени, а по размеру. Допустим, вы проводите ротацию раз в сутки и держите записи за неделю. Не исключён вариант, что произойдёт непредвиденное событие или же кто-то включит DEBUG mode и всего за пару часов лог вырастет до нескольких Гигабайт.
- не делайте ротацию логов внешней зависимостью. Да, существует logrotate, можно чистить логи по крону, но много лучше, когда этим занимается само приложение. По крйней мере, log4j в Java прекрасно это умеет

И да, всё же задумайтесь о централизованном логгировании. Конечно, это потребует дополнительных ресурсов, как на инфраструктуру, так и на людей, для поддержания этого дела. Но потом это сильно упростит вам жизнь при скейлинге. Или же можно просто купить поддержку готового решения, где головную боль о настройке и поддержании работоспособности возьмут на себя третьи лица (ествественно за деньги) Благо, таких решений хватает.

Ну и под конец, статья JetRuby со сравнительным обзором Graylog и ELK, наверное, самых известных системах централизованного хранения логов for free
#logs #elk #graylog

Да, вы, наверное, могли заметить, что я обычно не делаю постов в выходные. Сегодня у меня был рабочий день, так что всё честно.

Однако, если вам интересно, почему я не пишу сюда в дни, когда, казалось бы, логичней всего, ответ прост. Во-первых, я стараюсь отдохнуть от всего этого дерьма, и на работе хватает, во-вторых, я смотрю стримы D&D.

Серьёзно, это очень интересно! Всё равно, что смотреть фэнтезийный сериал, только тут персонажи реально могут помереть волею случая и дайсов. Плюс, поскольку прямо таки на видео не происходит прямо такого уж экшона, можно слушать в фоне. Я даже работаю иногда под это дело. Кстати, неплохо разгружает мозг

Смотрю тут

И нет, это не реклама. Просто хочу поделиться реально интересной штукой, а то все дотка, да дотка

P.S. Отдельно у них хочу выделить вот эту серию. Я в неё реально залип. 2-3 сессии, правда, у них идёт раскачка, зато потом огонь!

Очередная бесплатная книга по Ansible. Собственно, написана ими самими

https://www.ansible.com/smart-devops-ebook?utm_campaign=DevOps&utm_content=55588598&utm_medium=social&utm_source=twitter

Вдруг кому пригодится

В продолжение темы логов, статья человека, который заменил Logstash в ELK стэке на Rsyslog и почему ему с этим хорошо:

tl;dr: rsyslog быстрый и простой. В довесок, он выкинул из своей цепочки Redis, а уменьшение числа движущихся частей в системе -- это хорошо
#logs #elk

Несколько постов назад я писал о системах управления конфигурациями, но вскользь упомянул, что можно и без них, в принципе.

Вот, можете почитать статью Жени Брикмана о том, как управлять инфраструктурой лишь при помощи Terraform. Immutable infrastructure as is.

И вообще, я очень рекомендую его блог всем, кто хочет познакомиться с Terraform или лучше его понять. Кроме того Евгений написал о нём книгу, но книга платная.
#terraform

История о том, что встроенный в AWS ElasticSearch as a Service не всегда работает.

Ну и поскольку у вас нет админ доступа к потрохам Эластика, быть уверенным на 146% в том, что там происходит вы не можете.

З.Ы. Мне же тем временем пришёл инфайт в DataDog. Потому что у компании дофига бабла. Пока не крутил его: посомтрю, что там — расскажу
#elk #aws

Есть такая книга — Red Team Field Manual. Это название производно от аббревиатуры RTFM (а не наоборот) что означает Read The Fucking Manual. У этой фразы даже есть своя собственная странца в Википедии. Видимо, в мире действительно реально есть много желающих делать что-то не вникая в матчасть.

Так вот, данная книга по сути своей является просто сборником часто используемых команд с кратким описанием. Но в отличии от стандартных man pages, многие команды приведены с наиболее часто используемыми ключами (ну вот никто не делает просто df, вегда df -h)

Книгу даже можно купить на Amazon. Только вот найти там что-то конкретно — задача не из лёгких.

В честь этого, GitHub юзер leostat написал поиск по базе RTFM, которую составил на основании книги. Enjoy!
#unix #linux #rtfm #books

Занимательная заметка Joe Shaw о том, почему использовать defer Close() в Go приложениях — не лучшая идея.

И хотя в примерах рассмотрен конкретно Go, механизмы работы с I/O описаны на уровне ОС и будут общими для приложений на любых языках. Так что Close() вполне может вернуть ошибку, хотя Write() закончился успешно (как нам показалось)
#golang

Я вот засел писать два более-менее больших поста для канала, но никак не доведу это дело до ума. Так что полистайте пока GitHub Национального Агентства Безопасности США

https://nationalsecurityagency.github.io/

А тем временем, в nix-подобных ОС нашли очередную дыру, которая позволяет повысить привелегии. Суть в том, что если у вас рядом расположены stack и heap, то при перезаполнени кого-то из них, данные могут быть переписаны. Так данные из heap могут попасть в область stack и наоборот.

Во имя избежания сей напасти, разработчики сделали т.н. guard-page. Как раз в ней дыры и нашлись.

Больше о разнице между stack vs heap можно почитать тут
#security #nix

Вот тут подробней про механизм уязвимости описано:
https://nullprogram.com/blog/2017/06/21/

Netflix в своём блоге рассказывает как они анализируют использование CPU Java приложениями с помощью flame graphs.

Это достаточно большая стаья с примерами, видео с конференции и роадмапом.

Бонусом: статья об использовании flame graphs для визуализации CPU usage от всё тех же Netflix. На этот раз для NodeJS приложений
#netflix #java #nodejs #cpu

P.S. О, собственно, CPU Flame Graphs можно почитать в статье Брэндана Грегга

Вообще, очень много интересного о Linux performance можно прочесть у Брэндана Грегга 😉

https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html