Solr i Open Tracing

Wraz z wydaniem Solr w wersji 8.2 dostaliśmy w nasze ręce wsparcie dla Open Tracing. Niezależne od dostawców API dostarczające możliwości dodania rozproszonego tracingu do naszej aplikacji. Ważne jest także to, iż nie jesteśmy związani z żadnym szczególnym dostawcą, czy rozwiązaniem – w tej chwili jest kilka rozwiązań open-source oraz tych komercyjnych, więc jest w czym wybierać. Spójrzmy zatem jak skonfigurować Solr, aby skorzystać z Open Tracing.

Na początek

Na potrzebny tego wpisu przygotowałem sobie klaster SolrCloud zbudowany z dwóch instancji Solr działających na tej samej maszynie. Nic skomplikowanego, ale na potrzeby tego wpisu jest wystarczające.

Open Tracing

Oczywiście, aby móc skorzystać z dobrodziejstw tracingu potrzebujemy miejsca, gdzie Solr będzie wysyłać dane, które zostaną wygenerowane przy pomocy API Open Tracing. W momencie pisania tego tekstu jedynym wspieranym domyśnie przez Solr rozwiązaniem jest Jaeger. Jest to rozwiązanie ze stajni CNCF, w pełni otwarte i darmowe. Dodanie innego dostawcy wspierającego API Open Tracing jest możliwe, ale nie jest to temat tego wpisu.

Do swoich testów wykorzystałem kontener Dockera jaegertracing/all-in-one w najnowszej wersji. Uruchomienie go jest proste i wystarczy do tego następujące polecenie:

$ docker run -d --name jaeger -p 16686:16686 -p 6831:6831/udp -p 5775:5775/udp jaegertracing/all-in-one:latest

Uruchomiliśmy kontener pod nazwą jaeger oraz przygotowaliśmy porty 16686, 6831 oraz 5775. Port 16686 będzie wykorzystywany do wyświetlenia UI Jaeger, natomiast port 5775 będzie wykorzystany jako port agenta, czyli tam gdzie będziemy wysyłać nasze dane wyprodukowane przez API Open Tracing.

Aby sprawdzić, czy kontener działa wystarczy następujące polecenie:

$ docker ps

Konfiguracja Solr z Open Tracing

Następną rzeczą jaką musimy zrobić to przygotowanie Solr. Na początek musimy przekopiować wszystkie biblioteki z katalogu contrib/jaegertracer-configurator/lib/ oraz bibliotekę jaegertracer-configurator-8.6.0.jar z katalogu dist i umieścić je w miejscu, gdzie Solr będzie je widzieć. W moim wypadku był to katalog lib w katalogu server/solr.

Musimy także zmodyfikować plik solr.xml który dostępny jest w katalogu server/solr. W tym pliku musimy dodać wpis konfigurujący odpowiednie elementy Solr. W większości wypadków plik ten nie będzie pusty, wystarczy więc dodać do niego następujący wpis:

<tracerConfig name="tracerConfig" class="org.apache.solr.jaeger.JaegerTracerConfigurator">
  <str name="agentHost">localhost</str>
  <int name="agentPort">5775</int>
  <bool name="logSpans">true</bool>
  <int name="flushInterval">1000</int>
  <int name="maxQueueSize">10000</int>
</tracerConfig>

Powyższa konfiguracja konfiguruje Jaeger. Stwierdzamy, iż nasz agent działa lokalnie – localhost i jest dostępny na porcie 5775. Dodatkowe opcje definiują czas wysyłania danych oraz wielkość kolejki.

Klaster testowy i dane

Po przygotowaniu naszych dwóch instancji w powyżej opisany sposób możemy je wreszcie uruchomić. Robimy to za pomocą następujących poleceń:

$ bin/solr start -c -f
$ bin/solr start -f -p 6883 -z localhost:9983

Uruchomiliśmy dwie instancje Solr. Pierwsza, oprócz samego Solr uruchamia Zookeepera, natomiast druga instancja łączy się do tego Zookeepera. Razem tworzą klaster testowy.

Przed stworzeniem kolekcji, której będziemy używać do testów zrobiłem jedną, dodatkową rzecz. Ustawiłem próbkowanie na 100%, co oznacza, iż wszystkie dane wyprodukowane przez API Open Tracing będą dostarczane do Jaegera. Aby to zrobić wystarczy ustawić właściwość klastra o nazwie samplePercentage na wartość 100. Ja zrobiłem to następującym poleceniem:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=CLUSTERPROP&name=samplePercentage&val=100'

Oczywiście jest to ustawienie do testów. W przypadku produkcyjnego systemu, możemy nie chcieć trzymać 100% wszystkich danych ze względu ze względu na wielkość danych.

Następnie stworzyłem kolekcję o nazwie test z wykorzystaniem konfiguracji _default. Do wpisu nic więcej nie potrzeba. Sama kolekcja została stworzona przy pomocy następującego polecenia:

$ curl -XPOST -H 'Content-type:application/json' 'http://localhost:8983/api/c/'  -d '{ 
  "create": { 
    "name": "test",
    "numShards": "2"
  } 
}'

Następnie zaindeksowałem następujące dane:

$ curl -XPOST -H 'Content-type:application/json' 'localhost:8983/solr/test/update?commit=true' -d '[
 {
  "id": 1,
  "name": "Test document 1",
  "tags": [ "doc", "test" ]
 },
 {
  "id": 2,
  "name": "Test document 2",
  "tags": [ "doc", "test" ]
 },
 {
  "id": 3,
  "name": "Test document 3",
  "tags": [ "doc", "test" ]
 }
]'

Po czym zadałem proste zapytanie:

$ curl -XGET -H 'Content-type:application/json' 'localhost:8983/solr/test/select' -d '{
  "query" : "name:document",
  "facet": {
    "tags" : {
      "terms" : {
        "field" : "tags"
      }
    }
  }	
}'

Spójrzmy na dane

Po indeksowaniu oraz zadaniu zapytania powinniśmy mieć już jakieś dane dostępne w Jaeger. Aby to sprawdzić wystarczy otworzyć w przeglądarce adres localhost:16686 i wybrać solr z listy serwisów. Na przykład to pokazał Jaeger dla zapytania Solr:

Jeżeli potrzebujemy więcej danych sekcja tags może być pomocna:

I wszystko to dostępne po dodaniu kilku bibliotek oraz kawałka konfiguracji do Solr.

Krok dalej – tracing poza Solr

Oczywiście tracing uruchomiony tylko w ramach Solr to nie jest idealne rozwiżanie i chcielibyśmy mieć cały kod odpowiedniego przygotowany.

Na przykład, jeżeli mamy bardzo prostą aplikację odpytującą Solr możemy skorzystać z Open Tracing i samemu przygotować odpowiednie elementy typu span, które zostaną wysłane do Jaeger, tego samego, do którego wysyłane są dane z API Open Tracing w Solr. Przykładowy kod realizujący takie założenia może wyglądać następująco (cały projekt dostępny jest na Githubie):

public class App {
    private JaegerTracer tracer;
    private HttpSolrClient solrClient;

    public static void main(String[] args) throws Exception {
        App app = new App();
        app.initTracer();
        app.initSolrClient();
        app.start();
    }

    public void start() throws Exception {
        Span span = tracer.buildSpan("example query").start();

        final Map<String, String> query = new HashMap<>();
        query.put("q", "*:*");
        MapSolrParams queryParams = new MapSolrParams(query);

        final QueryResponse queryResponse = solrClient.query("test", queryParams);
        final SolrDocumentList documents = queryResponse.getResults();

        sleep(10);
        processDocumentsSlow(documents, span, 100);

        span.finish();
    }

    private void processDocumentsSlow(SolrDocumentList documents, Span rootSpan, long sleepTime) {
        Span span = tracer
            .buildSpan("process documents")
            .asChildOf(rootSpan)
            .start();

        processDocumentsSlowNext(documents, span, 300);
        sleep(sleepTime);

        span.finish();
    }

    private void processDocumentsSlowNext(SolrDocumentList documents, Span rootSpan, long sleepTime) {
        Span span = tracer
            .buildSpan("process documents next")
            .asChildOf(rootSpan)
            .start();

        sleep(sleepTime);

        span.finish();
    }

    private void sleep(long millis) {
        try {
            Thread.sleep(millis);
        } catch (Exception ex) {}
    }

    public void initTracer() {
        if (this.tracer == null) {
            Configuration.SamplerConfiguration samplerConfiguration = new Configuration
                .SamplerConfiguration()
                .withType(ConstSampler.TYPE)
                .withParam(1);

            Configuration.ReporterConfiguration reporterConfiguration = Configuration
                .ReporterConfiguration
                .fromEnv();

            Configuration.SenderConfiguration senderConfig = reporterConfiguration
                .getSenderConfiguration()
                .withAgentHost("localhost")
                .withAgentPort(5775);

            reporterConfiguration
                .withLogSpans(true)
                .withSender(senderConfig);

            Configuration configuration = new Configuration("Jaeger with Solr")
                .withSampler(samplerConfiguration)
                .withReporter(reporterConfiguration);

            this.tracer = configuration.getTracer();
        }
    }

    public void initSolrClient() {
        if (this.solrClient == null) {
            this.solrClient = new HttpSolrClient
                .Builder("http://localhost:8983/solr")
                .build();
        }
    }
}

Oprócz metody initTracer, która konfiguje Jaegera interesująca część kodu znajduje się w metodzie start. Tworzymy span, a następnie budujemy zapyatnie do Solr, wykonujemy je i pobieramy wyniki wyszukiwania. Następnie symulujemy opóźnienia wykonywania i wywołujemy metodę processDocumentsSlow, a w niej processDocumentsSlowNext. Każda z tym metod tworzy span oraz korzysta z metody asChildOf, aby poinformować, iż span jest częścią dłuższego wywołania logiki. To wszystko, w Jaeger, wygląda następująco:

W tym momencie mamy wgląd nie tylko w Solr, ale także w naszą aplikację.

Następne kroki

Cała siła rozproszonego tracingu widoczna jest wtedy, kiedy cały kod jest odpowiednio przygotowany, a my mamy możliwość śledzenia wywołań metod i funkcji oraz obserwacji z tym związanych. Open Tracing wspiera nie tylko język Java, ale także JavaScript, Go, Python, PHP, Objective-C, C++, C# i Ruby. A zatem jeżeli Twoja aplikacja korzysta z wymienionych języków instrumentalizacja kodu nie powinna być problemem.

Ważne jest także to, iż Open Tracing jest tylko zbiorem API, które nie jest związane z żadnym dostawcą, czy rozwiązaniem. Korzystając z API Open Tracing możemy wybrać dowolnego dostawcę lub rozwiązanie, które będzie dla nas odpowiednie, czy to komercyjne, czy w pełni otwarte. Warto o tym pomyśleć jeżeli chcemy dodać rozproszony tracing do naszej aplikacji i oprócz logów i metryk mieć także dostęp do tracingu.