SRE
Вторая часть статьи "Наблюдаемость сетевой инфраструктуры Kubernetes" про рассмотрение Observability инструментов.
В этой части мы сравним разворачиваемые решения в выбранном сетевом сценарии на основе собранных метрик приложения и кластера Kubernetes. Сделаем выводы о дальнейшем использовании инструментов в DevOps/K8S окружении.
Присоединяйтесь к нам, чтобы узнать больше о том, как обеспечить наблюдаемость в Kubernetes и облегчить жизнь разработчиков и администраторов.
Вопрос о столах поднимался несколько раз (раз, два).
Фото с сайта linkerd.io
Пару лет назад ребята из Kinvolk сравнили производительность Linkerd и Istio и узнали, что Linkerd значительно быстрее и меньше Istio везде, кроме одной области. Linkerd использовала больше процессорных ресурсов в плоскости данных (data plane). Недавно мы повторили эти эксперименты с последними версиями обеих service mesh. Как показывают результаты, Linkerd не только по-прежнему заметно быстрее Istio, но и использует на порядок меньше ресурсов памяти и процессора в плоскости данных (data plane). Причем это происходит, даже если число запросов в секунду в три с лишним раза больше, чем в бенчмарке Kinvolk. Вы легко можете это повторить.
А теперь подробности.
Всем здравствуйте! Я расскажу о том, как решал задачу ускорения проверки merge request’ов(MR) в нашей команде. Почему вообще это понадобилось? Потому что разработчики ленивы экономят силы и обычно не стремятся брать новые MR на проверку, либо выбирают что попроще. Так что я решил сделать бота, который для каждого MR автоматически расставлял бы приоритеты и назначал проверяющего.
yaml). В предыдущих постах по этой теме я познакомил читателей с фреймворком и рассказал об использовании библиотеки cdk8s-plus для дальнейшего расширения базовых возможностей функций библиотеки cdk8s. В этом посте мы ещё больше расширим границы возможностей cdk8s.cdk8s. Мы начнём с простого примера Nginx, а затем используем комбинацию CRD проекта Strimzi вместе с Go cdk8s для описания и развёртывания кластера Kafka на Kubernetes!
Об этом спрашивают на собеседованиях. Структурированное понимание этого может помочь вам, даже если вы давно строите сложные архитектурные процессы или кодите 20-ый год подряд. Я — программист уже много лет, последние пару из которых пишу на Go в Каруне. Работа работой, а внутренний исследователь не дремлет. И вот я наконец-то решил привести в порядок информацию, разбросанную по разным закоулкам чертогов разума, по добротным книгам и статьям на тему сетевых технологий.
Хочу представить краткую выжимку о работе протоколов. А если тема окажется интересной, могу продолжить работать с ней более детально. Рассмотрим простейший пример: вы ввели некоторый url в адресную строку. Поехали.
Настройка производительности базы данных — разработчики обычно либо любят это, либо ненавидят. Я получаю удовольствие от этого и хочу поделиться некоторыми методами, которые я использовал в последнее время для настройки плохо выполняющихся запросов в PostgreSQL. Мои методы не является исчерпывающими, скорее учебником для тех, кто просто тащится от тюнинга.SELECT *
FROM
pg_stat_statements
ORDER BY
total_time DESC;| user_id | dbid | queryid | query | calls | total_time |
|---|---|---|---|---|---|
| 16384 | 16385 | 2948 | SELECT address_1 FROM addresses a INNER JOIN people p ON a.person_id = p.id WHERE a.state = @state_abbrev; | 39483 | 15224.670 |
| 16384 | 16385 | 924 | SELECT person_id FROM people WHERE name = name; | 26483 | 12225.670 |
| 16384 | 16385 | 395 | SELECT _ FROM orders WHERE EXISTS (select _ from products where is_featured = true) | 18583 | 224.67 |
Добрый день, дорогие хаброжители и в особенности те, которые в той или иной мере интересуются блокчейном. Так уж получилось, что придя работать java-разработчиком в одну компанию, мне пришлось заниматься проектами, использующими блокчейн.
Про сам блокчейн, его особенности и различные реализации в интернете, и на Хабре в частности, можно найти тонну информации. Но чем глубже вопросы, тем меньше на них ответов. В официальной документации fabric очень мало информации про дебаг, а та которая есть заключается в том, что бы просто залогировать весь код и смотреть, что же пошло не так. Русскоязычные разработчики IBM ответили точно так же. Так что в данной статье будет освещена одна из наших бывших проблем, связанная с дебагом чейнкода в одном из проектов Hyperledger, а именно — Fabric (v0.6).
Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.
