Думаю, проще его представить как событие, которое длится от и до. Это как полоска в диаграмме Ганта. У каждой такой полоски, есть контекст, в котором хранится, например, название сервиса, тип http-запроса, код http-ответа, была ли ошибка при обработке Можно и свои тэги добавлять, например, идентификатор пользователя, а потом, в WEB-интерфейса Jaeger указать фильтр по этому тэгу и посмотреть, что тормознуло у этого клиента.
Ну а в коде, да, это структура данных. Прицепленная некоторым образом к текущему потоку обработки запроса.
OpenTracing и в частности Jaeger, так и работает. Можно дописать свои инъекторы, которые пропихивают заголовки и в нестандартные протоколы. Причем, поверх штатных библиотек Jaeger есть и более вкусные. Так, для Java + Spring Boot есть стартер opentracing-spring-jaeger-cloud-starter, который умеет эти заголовки прокидывать не только в HTTP но и в очереди, например.
Мне статья не понравилась. Вначале, очевидные вещи о CISC и RISC. Для кого они? Менеджеру, это не нужно, а любой ИТ-шник это знает с первого курса ВУЗ-а. Т.е. плохая рекламная статья.
Я не против ARM, и тех, кто продвигает сервера на их основе. Даже наоборот, скоро запущу несколько серверов в бой, будут работать в кластерах параллельно с x86 серверами, очень хочется сравнить по показателям производительности/цены. Хочется посмотреть как будет жить на них Java, на большем количестве ядер. На сколько хорош RHEL, bare metal и kvm. Да, забудем про ESX, нет его пока.
Cassandra имеет схему данных, значительно легче масштабируется, в отличии от классических реляционных СУБД, вроде Oracle DB, MySql, Postgre. Имеет язык запросов CQL, похожий на SQL. И обладает, я бы сказал, управляемым ACID и CAP, Вы сами можете выдирать, что для Вас важно, конфигурируя кластер, указывая Replication Factor и Consistency level. И по моему мнению, мало задач, с которыми она бы не справилась, Вы просто не умеете ее готовить:)
Да, есть задачи, для которых классические реляционные БД подходят лучше, но так ведь никто и не заставляет нас в современном мире ограничиваться чем-то одним, почему нельзя использовать и то и то сразу?
Сервера мониторили? Во что упираются сервера кассандры, память, диск, паузы GC? Если не во что не упираются, значит вы ее просто не догрузили. Пишите в Кассандру не в 5 а в 50 потоков через 1 коннект.
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
Сейчас GTK имеет более свежую версию, чем поддерживается gotk3 (3.6-3.16), например у меня — 3.18 и так просто, как в статье скомпилировать сам gotk3 и приложение не получится, используем:
для установки:
go install -tags gtk_3_18 github.com/gotk3/gotk3/gtk
для сборки приложения:
go build -v -tags gtk_3_18 -gcflags "-N -l"
Можно попробовать развернуть кубернетес через Rancher, мне показалось это проще, сразу получите все что нужно, и легкое добавление хостов через web-интерфейс и настроенный из коробки и fluentd и grafana и web-дашборд.
Но если хотите в деталях понять как это все работает, лучше, хоть раз, поставить руками мастера, ноды, попробовать их по обновлять, по выгонять, по добавлять в кластер, перед тем как внедрить это все на бой.
Да, понимаю. Я о том, что новые возможности, это конечно хорошо! Но что делать со старыми ограничениями? Понятно, что ключи, на то они и ключи, чтоб быть уникальными (в пределах хоста), но хотелось бы иметь возможность добавлять им уникальности не только добавлением пробелов (например, jmx-endpoint использовать как параметр ключа). Это ограничение приводит к тому, что, использовать JMX, для мониторинга базовых параметров JVM, например, когда на сервере несколько десятков микросервисов, очень не удобно. Свои MBean-ны внутри микросервисов можно называть уникально и мониторить их свойства без проблем.
Почти все, конечно можно обойти, благо, например, мониторить память и процессор можно и «снаружи» JVM через итемы самого Zabbix-agent-а.
Эх, разрабы заббикса как не предполагали, что на одном сервере могут работать несколько джава-приложений, так и не предполагают. Попробуйте промониторить, скажем память нескольких jvm через jmx. Получите дублирование ключей итемов. Приходится использовать хак с пробелами в названии ключей.
Ну тут все понятно, чтобы метод был законным, нужно, что бы был закон, в котором написано, что так информацию распространять можно. И для того, что бы удостовериться, что граждане не передают законным образом сведения, составляющие гос. тайну, соответствующие органы должны иметь возможность контроля. Никто же не собирается из наших сообщений вырезать слова и мысли, значит и с цензурой все хорошо. Так что, ничего не нарушается.
Согласен. Для проектов на JAX-RS использую maven-javadoc-plugin вместе с swagger-doclet, Он генерирует swagger-документацию по JavaDoc. Помимо обычных аннотаций используются специфические дополнительные аннотации, которые не мешают читать код, но помогают уточнить документацию. Дополнительный бонус — приучает писать полноценные комментарии :)
Ну, за уши притянуто. Тут дело в другом, используя «OCP-совместимое» оборудование одного производителя, организация всегда может заменить его на совместимое оборудование другого производителя. Т.е. организация, купившая 1000 серверов IBM не будет подсажено на его иглу и при более выгодных условиях, следующие 1000 серверов купит у HP. Причем, если в серверах HP накроется какой либо компонент, куллер или БП, например. Не придется втридорога покупать родной хитровыделанный куллер именно у HP. Т.е. понятно, из за нормальной конкуренции, цены снизятся. А из за совместимости компонент, меньше зависимость от конкретного производителя и его политики поддержки того или иного железа.
За что же Digma DiScooter Urban Sky самоваром-то обозвали? :)
Ну а в коде, да, это структура данных. Прицепленная некоторым образом к текущему потоку обработки запроса.
Мне статья не понравилась. Вначале, очевидные вещи о CISC и RISC. Для кого они? Менеджеру, это не нужно, а любой ИТ-шник это знает с первого курса ВУЗ-а. Т.е. плохая рекламная статья.
Я не против ARM, и тех, кто продвигает сервера на их основе. Даже наоборот, скоро запущу несколько серверов в бой, будут работать в кластерах параллельно с x86 серверами, очень хочется сравнить по показателям производительности/цены. Хочется посмотреть как будет жить на них Java, на большем количестве ядер. На сколько хорош RHEL, bare metal и kvm. Да, забудем про ESX, нет его пока.
Да, есть задачи, для которых классические реляционные БД подходят лучше, но так ведь никто и не заставляет нас в современном мире ограничиваться чем-то одним, почему нельзя использовать и то и то сразу?
Сравнение не честное, т.к. про HBase Вы все знаете, а Кассандра, для Вас, черный ящик.
key_cache_size_in_mb — задайте несколько гигов. Он куда более важен для производительности на чтение, чем row_cache, строки и так будут в кеше операционки. И 8 дисков, для данного теста, Кассандре не нужны, она свалит все на один. Много дисков понадобится для множества кейспейсов и таблиц. Писать с CL=ALL, это еще можно понять, но читать смысла нет, достаточно LOCAL_QUORUM.
Самое серьезное ограничение, на мой взгляд, когда процессов, на которые наложены ограничения cgroups много, проще будет перезагрузить сервер)
для установки:
go install -tags gtk_3_18 github.com/gotk3/gotk3/gtk
для сборки приложения:
go build -v -tags gtk_3_18 -gcflags "-N -l"
Это есть в issue проекта
Но если хотите в деталях понять как это все работает, лучше, хоть раз, поставить руками мастера, ноды, попробовать их по обновлять, по выгонять, по добавлять в кластер, перед тем как внедрить это все на бой.
Почти все, конечно можно обойти, благо, например, мониторить память и процессор можно и «снаружи» JVM через итемы самого Zabbix-agent-а.
Эх, разрабы заббикса как не предполагали, что на одном сервере могут работать несколько джава-приложений, так и не предполагают. Попробуйте промониторить, скажем память нескольких jvm через jmx. Получите дублирование ключей итемов. Приходится использовать хак с пробелами в названии ключей.