Java agent 1.0.0 Release Candidate ready for testing

Elastic Observability APM
1

We have just released a release candidate for the Java agent: https://github.com/elastic/apm-agent-java/releases/tag/v1.0.0.RC1

This is your chance to give us feedback before the general availability (1.0.0 release) of the agent. It comes with lots of cool stuff like support for distributed tracing, an annotation based API for creating transactions and spans as well as support for the Elasticsearch Rest Client.

Note that the agent 1.0.0.RC1 only compatible with the upcoming APM Server version 6.5.0. At the time of writing, this version is not released yet.

5 Likes
3

The easiest way to test is to use this docker-compose.yml file to set up APM Server, Kibana and Elasticsearch:

---
networks:
  default:
    name: apm-integration-testing
services:
  apm-server:
    cap_add:
    - CHOWN
    - DAC_OVERRIDE
    - SETGID
    - SETUID
    cap_drop:
    - ALL
    command:
    - apm-server
    - "-e"
    - "--httpprof"
    - ":6060"
    - "-E"
    - apm-server.frontend.enabled=true
    - "-E"
    - apm-server.frontend.rate_limit=100000
    - "-E"
    - apm-server.host=0.0.0.0:8200
    - "-E"
    - apm-server.read_timeout=1m
    - "-E"
    - apm-server.shutdown_timeout=2m
    - "-E"
    - apm-server.write_timeout=1m
    - "-E"
    - logging.json=true
    - "-E"
    - logging.metrics.enabled=false
    - "-E"
    - setup.kibana.host=kibana:5601
    - "-E"
    - setup.template.settings.index.number_of_replicas=0
    - "-E"
    - setup.template.settings.index.number_of_shards=1
    - "-E"
    - setup.template.settings.index.refresh_interval=1ms
    - "-E"
    - xpack.monitoring.elasticsearch=true
    - "-E"
    - xpack.monitoring.enabled=true
    - "-E"
    - apm-server.instrumentation.enabled=true
    - "-E"
    - setup.dashboards.enabled=true
    - "-E"
    - output.elasticsearch.enabled=true
    - "-E"
    - output.elasticsearch.hosts=[elasticsearch:9200]
    container_name: localtesting_6.5.0_apm-server
    depends_on:
      elasticsearch:
        condition: service_healthy
      kibana:
        condition: service_healthy
    healthcheck:
      interval: 5s
      retries: 12
      test:
      - CMD
      - curl
      - "--write-out"
      - "'HTTP %{http_code}'"
      - "--fail"
      - "--silent"
      - "--output"
      - "/dev/null"
      - http://localhost:8200/healthcheck
    image: docker.elastic.co/apm/apm-server:6.5.0-SNAPSHOT
    labels:
    - co.elatic.apm.stack-version=6.5.0
    logging:
      driver: json-file
      options:
        max-file: '5'
        max-size: 2m
    ports:
    - 127.0.0.1:8200:8200
    - 127.0.0.1:6060:6060
  elasticsearch:
    container_name: localtesting_6.5.0_elasticsearch
    environment:
    - cluster.name=docker-cluster
    - bootstrap.memory_lock=true
    - discovery.type=single-node
    - ES_JAVA_OPTS=-XX:UseAVX=2 -Xms1g -Xmx1g
    - path.data=/usr/share/elasticsearch/data/6.5.0
    - xpack.security.enabled=false
    - xpack.license.self_generated.type=trial
    - xpack.monitoring.collection.enabled=true
    healthcheck:
      interval: '20'
      retries: 10
      test:
      - CMD-SHELL
      - curl -s http://localhost:9200/_cluster/health | grep -vq '"status":"red"'
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.0-SNAPSHOT
    labels:
    - co.elatic.apm.stack-version=6.5.0
    logging:
      driver: json-file
      options:
        max-file: '5'
        max-size: 2m
    ports:
    - 127.0.0.1:9200:9200
    ulimits:
      memlock:
        hard: -1
        soft: -1
    volumes:
    - esdata:/usr/share/elasticsearch/data
  kibana:
    container_name: localtesting_6.5.0_kibana
    depends_on:
      elasticsearch:
        condition: service_healthy
    environment:
      ELASTICSEARCH_URL: http://elasticsearch:9200
      SERVER_NAME: kibana.example.org
      XPACK_MONITORING_ENABLED: 'true'
      XPACK_XPACK_MAIN_TELEMETRY_ENABLED: 'false'
    healthcheck:
      interval: 5s
      retries: 20
      test:
      - CMD
      - curl
      - "--write-out"
      - "'HTTP %{http_code}'"
      - "--fail"
      - "--silent"
      - "--output"
      - "/dev/null"
      - http://kibana:5601/api/status
    image: docker.elastic.co/kibana/kibana:6.5.0-SNAPSHOT
    labels:
    - co.elatic.apm.stack-version=6.5.0
    logging:
      driver: json-file
      options:
        max-file: '5'
        max-size: 2m
    ports:
    - 127.0.0.1:5601:5601
version: '2.1'
volumes:
  esdata:
    driver: local
  pgdata:
    driver: local
3 Likes
4

Hello, I'm giving a try to Java Agent and I successfully use your docker-compose file. I'd like to add RUM functionalities but it your compatibility matrix says that I have to use Javascript agent in 2.x version, which I cannot find anywhere. Could you please give me a hint about it?
Thank you

5

The RUM agent 2.0 is not released yet. It will be released very soon alongside the Java agent 1.0. You can build the RUM agent from master yourself in the meantime: https://github.com/elastic/apm-agent-js-base

Cheers,
Felix

6

We've been testing Java Agent RC and so far it has been doing very well in our ecosystem except on two scenarios:

  1. An application with a very old JDBC Derby driver. Adding the agent causes the application to crash on start. We updated to a new driver designed for Java8 and up and it worked.

  2. Grizzly-based components. Some of our components are legacy and have not yet been scheduled for upgrading. I've looked in the documentations, and tried searching in Github and the forums, and couldn't find anything about Grizzly support. Our apps run with the Java agent, but we just don't get any instrumentation data. Is Grizzly definitively not supported?

Many thanks for the really great job you guys are doing here. Cheers!

7

Thanks a lot for your feedback, much appreciated :slight_smile:

Which version of the Derby driver caused problems (link to exact artifact on search.maven.org would be helpful)? I'll try to reproduce. Ideally the agent should rather not instrument the driver than crash the application, of course.

We have not tested the agent with Grizzly yet but we don't have dedicated Grizzly support. It may work when you are using the Grizzly servlet modules. Which Grizzly modules are you specifically using?

Cheers,
Felix

8

Hi Felix, thanks for the feedback.

For Derby, we originally used 10.10.1.1 which failed so we bumped it up to 10.14.2.0 and that worked. (https://db.apache.org/derby/derby_downloads.html)

For Grizzly, we actually didn't use the Grizzly servlet. We simply used core frameworks for web services support.

I hope this helps.

Regards,

Ronald

9

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.