​Поднимите руки кто знает 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

Выложили доклады с AppSec Day 2019
https://www.youtube.com/playlist?list=PLPvxR0i93gjRu5ZWvoqf6-jd__FyFoqmQ

Программа тут
https://appsecday.io/schedule/

Новость из серии - Ого, а он еще живой?
https://searchdatamanagement.techtarget.com/news/252477977/Couchbase-Cloud-takes-a-new-approach-to-database-delivery

Написали небольшую статью по первым инцидентам, которые скушал амиксер: https://blog.amixr.io/what-weve-learned-once-processed-first-150000-production-incidents/

Moto - Python библиотека для мока AWS ресурсов.

В ридми есть таблица совместимости с существующими сервисами Амазона

#aws

Database visualization, create entity-relationship diagrams for your colleagues, boss or whatever

https://dbdiagram.io/

Just sharing #usefullinks with you guys, peace ✌️

​Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.

И ещё вдогонку к предыдущему посту. Статья о мониторинге DIsk I/O на Linux-системах при помощи Prometheus c небольшим рассказом о том, как устроена файловая система в Linux.

👾 Скрипт для быстрой установки wireguard. https://github.com/angristan/wireguard-install Перед установкой убеждаемся, что система запущена с последней, актуальной версией ядра. Всё остальное скрипт сделает сам.

#wireguard #github

🔎 https://ihateregex.io/ - пачка примеров регэкспов, с объяснением того, как они работают. #линк #regexp

Bottlenecks in Serverless Applications
https://xn--r1a.website/iv?url=https://jaxenter.com/serverless-bottlenecks-167268.html&rhash=086d57c832108f