Начинаем новый проект, решили посмотреть что есть помимо камунды на рынке. Есть интересное решение - flowable. Как бы от тех же разработчиков что и activiti и camunda. Создатели flowable преподносят свою реализацию как более продуманную, усовершенствованную чем activiti и camunda. также есть возможность подключать nosql бд. какие-то улучшения в производительности есть. движок также подстроен больше под BPMN а не PVM. https://forum.flowable.org/t/compare-flowable-vs-camunda/317/4

😈 Некоторое количество BSD пропаганды в канал.

Why you should migrate everything from Linux to BSD: Part I.
Why you should migrate everything from Linux to BSD: Part II.
FreeBSD is an amazing operating system.

Автор показывает плюсы BSD систем перед Linux и пытается ответить на аргументы других людей, прокомментировавших сего татьи на популярных ресурсах.

#напочитать #freebsd #bsd

The Dark Side of Microservices
https://link.kelda.io/2uV45P2

Материалы для изучения terraform

https://blog.gruntwork.io/an-introduction-to-terraform-f17df9c6d180

https://www.udemy.com/course/rus-terraform/

https://www.youtube.com/watch?v=R0CaxXhrfFE&list=PLg5SS_4L6LYujWDTYb-Zbofdl44Jxb2l8

https://www.terraform.io/docs/index.html

https://blog.gruntwork.io/an-introduction-to-terraform-f17df9c6d180

Terraform up and running от o'reilly

#terraform

Ух ты
Все видяшки с FOSDEM: https://video.fosdem.org/2020/

Серия видео-уроков по AWS Lambda от Tomasz Łakomy

#aws #serverless

#wasm #java https://medium.com/leaningtech/cheerpj-2-0-released-381f6d03e4e

Cronyo – A simple CLI to manage your cron jobs on AWS
https://github.com/cronyo/cronyo

⚙️ А вот тут собраны интересные вещи, которые можно делать с помощью LD_PRELOAD в системе: https://github.com/gaul/awesome-ld-preload

#фидбечат #github #ldpreload

​Про систему мониторинга, которая строит графы из элементов приложения, а потом при помощи искусственного интеллекта ищет корневую причину проблемы уже писал в канале. То был Fixstream, кстати. Основа для работы алгоритма — netflow-трафик от сетевых устройств. Кроме netflow, конечно, ещё используются данные из CMDB и события из других систем мониторинга.

Сегодня расскажу про кое-что попроще. На просторах гитхаба обнаружил репозиторий с клёвой штукой, которая называется skydive. Чем она хороша? Помимо бесплатности еще много чем.

Skydive в режиме реального времени достаёт данные по netflow из базы данных Elasticsearch. Есть коннекторы к OpenStack, Docker, OpenContrail и Kubernetes.

Я уже давно считаю, что анализ netflow — недооценённая технология мониторинга и её стоило бы использовать активнее. А тем более это делать для распределённых приложений.

​Поднимите руки кто знает Instana. Это observability-система для контроля распределённых (=микросервисных) приложений. Очень крутая и динамично развивающаяся, как говорится. Самое охрененское — это их визуализации. Больше так никто не делает. Причём все технологии контролируются одним единственным агентом, который после установки на сервер сам распознает что там и как работает. Распространение агентов заточено под использование CI/CD. По деньгам они получаются дешевле Appdynamics или New Relic, если посчитать стоимость за агента.

А сама новость заключается в том, что Instana теперь начала поддерживать мониторинг стека vmware. И это очень позитивная новость, т.к. добавляет дополнительный уровень абстракции в рамках одной системы.

Если хотите пилот на вашей инфре или просто узнать больше — пишите в личку.

👍 — слышал про Instana и считаю интересным решением

👎 — я свой Jaeger, OpenTracing или <свой вариант> не променяю на платное решение

👀 — у меня монолитное приложение, работает на физическом сервере в кладовке и мне не до ваших распределённых глупостей

​Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.

Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.

1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.

2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.

3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».

4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.

5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.

6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.

7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).

Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.

GoTo DevOps: DevOps Conferences 2020

Интересный сборник DevOps-related  конференций с фильтрами по местоположению, времени и стоимости. Можно подписаться и получать уведомления:

https://www.gotodevops.org/

Годный доклад про мониторинг Postgres
https://habr.com/ru/post/486710/
#postgres #monitoring

​Порой кажется, что задача собирать и анализировать трафик сети неподъемная и очень трудоёмкая.

Причин, требующих мониторить трафик может быть множество, начиная от неправильных конфигураций, которые нагружают вашу сеть, до создания поведенческого baseline сетевой активности и анализа аномалий.

Задача поставлена, рынок спешит предложить решения, и тут они на любой вкус и цвет: пакетные анализаторы, анализаторы потоков (flow), десятки способов получения трафика: SPANы, TAP'ы, отправка различных flow и пр.

Но, что если хочется «бисплатно» и с рюшками? Тут тоже целый простор для фантазии, open-source, отодвигая кровавый энтерпрайз, тоже готов предложить массу интересных систем, например небезизвестное в широких кругах Moloch — масштабируемое решение для захвата и индексации пакетов внутри вашей сети, которое отлично дополнит IDS систему.

GitHub: https://github.com/aol/moloch
Quick Start: https://medium.com/swlh/indexing-network-traffic-with-moloch-and-elastic-931dda8a1685

А также другие решения, если вдруг захочется «а можно всех посмотреть?»:

Traffic Analysis/Inspection: https://github.com/caesar0301/awesome-pcaptools#analysis
Traffic Capture: https://github.com/caesar0301/awesome-pcaptools#capture

Hashicorp Vault on Kubernetes with Auto-Unseal
https://itnext.io/hashicorp-vault-on-kubernetes-with-auto-unseal-b7e64edbe63e