Announcing Jaeger 1.0 Release!



  • In February we introduced Jaeger in a blog post Evolving Distributed Tracing at Uber Engineering. Two months later Jaeger backend has been released as an open source project. So many things have happened since then. We built a great community of users who deploy Jaeger in their organizations and contribute to the project (special kudos to RedHat’s Hawkular team). We added many new features. We joined the Cloud Native Computing Foundation as its 12th project. And now we are proud to announce the official 1.0 release of Jaeger backend.

    Even though Jaeger has been integrated with thousands of applications at Uber and running in production for almost two years, we started the open source journey with modest 0.x versions. We knew we had some work ahead of us before we could make Jaeger easily deployable in the cloud environments, flexible in its infrastructure dependencies, backwards compatible with existing solutions, and integrated with other CNCF projects. We think we reached a milestone where we are ready for a 1.0 version.

    Storage backends

    The first release of Jaeger only supported Cassandra as a storage backend for traces. We chose Cassandra mostly because our team had operational experience with it, but it was obvious that not every team felt that way. Over the summer we implemented another backend store based on ElasticSearch. ES is a lot more popular as a hosted service, which makes deploying a high throughput Jaeger installation even easier. Later on our community made additional improvements to these backends, including support for various authentication methods for securing db connections.

    We were also considering support for MySQL backend, but could not prioritize it above other development. Interestingly, we’ve seen our community experimenting with other backends, such as ScyllaDB and InfluxDB.

    Improvements in Jaeger UI

    Jaeger 1.0 brings a significant number of improvements in its Web UI. Aside from performance optimizations to make it more efficient, we refactored the trace view using a virtual viewport technique that allows it to smoothly handle large traces containing as many as 50,000 spans. Other UI improvements include better navigation through large traces using the zoom-in feature of the minimap and keyboard shortcuts. The top level menu of the UI can now be customized via configuration, which is very useful when deploying Jaeger inside a company and providing links to internal resources such as help pages or opening a ticket for the tracing team.

    Prometheus, Docker, and Kubernetes

    Jaeger backend itself is a moderately complex distributed system that needs proper production monitoring. In the 1.0 release we made Prometheus the default metrics system integration in all Jaeger backend components. Deploying Jaeger in the cloud manually, “the hard way”, is no fun, even though we provide ready to run Docker images. Fortunately, fellow contributors at RedHat have created a GitHub project jaeger-kubernetes that contains templates for running Jaeger on Kubernetes. Then the Helm community picked up the torch and built a Helm chart that makes the whole process as simple as helm install incubator/jaeger –name myjaeger.

    Instrumentation libraries

    Even though Jaeger instrumentation libraries are versioned separately from the backend, it is worth mentioning that they are an active area of development, and the 1.0 milestone coincides with the release of the early version of C++ client. Having a C++ client in the toolbelt allows not only an easier path for other scripting languages, but also integration with high performance load balancers like nginx and haproxy and service meshes like Envoy.

    Our community is also working on client libraries in other languages, including Objective-C, Ruby, PHP. We are looking forward to bringing these libraries into the Jaeger project as officially supported.

    Backwards compatibility with Zipkin

    Another active area of development across the Jaeger ecosystem was backwards compatibility with Zipkin. Jaeger backend was enhanced to be a drop-in replacement for Zipkin backend by accepting several Zipkin span formats (Thrift and JSON). Jaeger client libraries include configuration options to make them use Zipkin in-band wire format for trace context propagation.

    Why? For many years Zipkin was the only game in town if you wanted to use an open source tracing system. Many organizations have already invested in instrumenting their applications with Zipkin APIs, instead of, say, vendor-neutral OpenTracing APIs. Jaeger’s interop features allow those organizations to switch to Jaeger backend with minimum cost, and to continue using Zipkin in-band wire format while instrumenting new applications with OpenTracing and Jaeger.

    Roadmap

    Even though we are proud of the functionality we are releasing in v1.0, we are even more excited about the next generation features we are currently working on. Jaeger is a great tool if you want to look at individual traces and investigate performance issues, but individual traces are a tiny portion of the of the overall knowledge that can be gained from tracing data. For example, Jaeger installations at Uber are ingesting over 10 billion spans a day. Thus our top priority are the features that support aggregations, analytics, and data mining, tools on top of Jaeger platform that allow gathering insights about the whole architecture at large. Some of those features are described on the Roadmap page.

    We are also looking at tighter integrations with other CNCF projects like Envoy, Linkerd, and Istio, emerging standards like the Trace-Context HTTP header, and alternative instrumentation APIs like OpenCensus.

    Try it out!

    You can try out Jaeger 1.0 by following our Getting Started guide. Join us on Twitter (@JaegerTracing), Gitter chat room, or the mailing list.

    Finally, we would like to thank all our users who extensively tested the pre-releases and helped us in debugging issues. This huge milestone would not have been possible without you!

    Connect at KubeCon + CloudNativeCon

    If you are attending KubeCon + CloudNativeCon North America this week, please join us December 8th for a Jaeger Salon to discuss the project and basic tracing concepts, as well as more advanced topics like adaptive sampling, dependency graphs and tracing with Envoy proxy.

    Additionally, do not miss the December 6th session by Jaeger founder Yuri Shkuro, “Would You Like Some Tracing With Your Monitoring?” and the December 7th sessions on SIG Jaeger Update and SIG Jaeger Deep Dive Session.

    The post Announcing Jaeger 1.0 Release! appeared first on The Linux Foundation.

    https://www.linuxfoundation.org/press-release/announcing-jaeger-1-0-release/





Tmux Commands

screen and tmux

A comparison of the features (or more-so just a table of notes for accessing some of those features) for GNU screen and BSD-licensed tmux.

The formatting here is simple enough to understand (I would hope). ^ means ctrl+, so ^x is ctrl+x. M- means meta (generally left-alt or escape)+, so M-x is left-alt+x

It should be noted that this is no where near a full feature-set of either group. This - being a cheat-sheet - is just to point out the most very basic features to get you on the road.

Trust the developers and manpage writers more than me. This document is originally from 2009 when tmux was still new - since then both of these programs have had many updates and features added (not all of which have been dutifully noted here).

Action tmux screen
start a new session tmux OR
tmux new OR
tmux new-session
screen
re-attach a detached session tmux attach OR
tmux attach-session
screen-r
re-attach an attached session (detaching it from elsewhere) tmux attach -d OR
tmux attach-session -d
screen -dr
re-attach an attached session (keeping it attached elsewhere) tmux attach OR
tmux attach-session
screen -x
detach from currently attached session ^b d OR
^b :detach
^a ^d OR
^a :detach
rename-window to newname ^b , <newname> OR
^b :rename-window <newn>
^a A <newname>
list windows ^b w ^a w
list windows in chooseable menu ^a "
go to window # ^b # ^a #
go to last-active window ^b l ^a ^a
go to next window ^b n ^a n
go to previous window ^b p ^a p
see keybindings ^b ? ^a ?
list sessions ^b s OR
tmux ls OR
tmux list-sessions
screen -ls
toggle visual bell ^a ^g
create another window ^b c ^a c
exit current shell/window ^d ^d
split window/pane horizontally ^b " ^a S
split window/pane vertically ^b % ^a |
switch to other pane ^b o ^a <tab>
kill the current pane ^b x OR (logout/^D)
collapse the current pane/split (but leave processes running) ^a X
cycle location of panes ^b ^o
swap current pane with previous ^b {
swap current pane with next ^b }
show time ^b t
show numeric values of panes ^b q
toggle zoom-state of current pane (maximize/return current pane) ^b z
break the current pane out of its window (to form new window) ^b !
re-arrange current panels within same window (different layouts) ^b [space]
Kill the current window (and all panes within) ^b killw [target-window]
  • Make ISO from DVD

    In this case I had an OS install disk which was required to be on a virtual node with no optical drive, so I needed to transfer an image to the server to create a VM

    Find out which device the DVD is:

    lsblk

    Output:

    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 464.8G 0 part ├─centos-root 253:0 0 50G 0 lvm / ├─centos-swap 253:1 0 11.8G 0 lvm [SWAP] └─centos-home 253:2 0 403G 0 lvm /home sdb 8:16 1 14.5G 0 disk /mnt sr0 11:0 1 4.1G 0 rom /run/media/rick/CCSA_X64FRE_EN-US_DV5

    Therefore /dev/sr0 is the location , or disk to be made into an ISO

    I prefer simplicity, and sometimes deal with the fallout after the fact, however Ive repeated this countless times with success.

    dd if=/dev/sr0 of=win10.iso

    Where if=Input file and of=output file

    I chill out and do something else while the image is being copied/created, and the final output:

    8555456+0 records in 8555456+0 records out 4380393472 bytes (4.4 GB) copied, 331.937 s, 13.2 MB/s

    Fin!

    read more
  • Recreate postrgresql database template encode to ASCII

    UPDATE pg_database SET datistemplate = FALSE WHERE datname = 'template1';

    Now we can drop it:

    DROP DATABASE template1;

    Create database from template0, with a new default encoding:

    CREATE DATABASE template1 WITH TEMPLATE = template0 ENCODING = 'UNICODE'; UPDATE pg_database SET datistemplate = TRUE WHERE datname = 'template1'; \c template1 VACUUM FREEZE;

    read more
});