How to resolve errors in continuous profiling logs - Application Real-Time Monitoring Service

Bu konu, sürekli profilleme kullanımıyla ilgili sık sorulan soruları yanıtlar.

Sürekli Profillemeyi Etkinleştirdikten Sonra Veri Görünmüyor

Yapılandırmalarınızın doğru olduğunu kontrol edin. Yapılandırılan CIDR bloğunun uygulama örneğinin IP adresini içerdiğinden emin olun.
3.1.4'ten önceki bir aracı sürümü kullanıyorsanız, Alpine temel görüntüsüyle uyumluluk sorunları nedeniyle profilleme motoru başarısız olabilir. Bu sorun 3.1.4 sürümünde giderilmiştir. Kararlılığı ve veri bütünlüğünü sağlamak için aracıyı 3.1.4 veya daha yeni bir sürüme yükseltmenizi öneririz.

Not
Alpine Linux temel görüntüsü kullandığınızı kontrol etmek için Diğer işlemler bölümüne bakın.
Sürekli profilleme, veri toplamak için geliştirilmiş açık kaynaklı Async Profiler'ı kullanır ve birden fazla Async Profiler'in aynı anda bağlanmasını desteklemez. Uygulamanız ayrıca Pyroscope aracısının sürekli profilleme özelliğini kullanıyorsa uygulamanız başlatılamayabilir.
Sürekli profilleme sayfasında sorgu zamanını 8 saat geriye ayarlayın ve verilerin görünüp görünmediğini kontrol edin. Veriler görüntüleniyorsa uygulamanın saat dilimi UTC+0 olarak ayarlanmış olabilir. Bu durum, UTC+8'e kıyasla 8 saatlik bir veri yazma gecikmesine neden olur.

Çözüm: Saat dilimini UTC+8 olarak ayarlamak için uygulamaya bir ortam değişkeni ekleyin.

Not
Önce sürekli profilleme sayfasında geçerli pod adına göre filtreleme yapın; böylece son 8 saat içindeki birden fazla konteyner yeniden başlatmasından kaynaklanan karışıklığı önlersiniz.
```
Key: JAVA_TOOL_OPTIONS, Value: -Duser.timezone=GMT+8
```
Bu sorun aracı sürüm 4.1.10'da giderilmiştir. Sorunun bu olduğundan eminseniz aracıyı 4.1.10 veya daha yeni bir sürüme de yükseltebilirsiniz.
Uygulamanın başka Async Profiler dinamik kitaplıkları bağlayıp bağlamadığını kontrol edin:
1. Aşağıdaki komutu çalıştırın. [pid] yerine uygulamanızın işlem kimliğini (PID) yazın.
```
lsof -p [pid] | grep libasync
```
2. Sonuç aşağıda gösterilen gibi Alibaba Cloud dışı bir dinamik kitaplık içeriyorsa uygulamanız kendi Async Profiler dinamik kitaplığını kullanıyor demektir. Bu kitaplık Application Real-Time Monitoring Service (ARMS) ile uyumlu değildir. ARMS özelliklerini kullanmak için kendi dinamik kitaplığınızı kaldırmanız gerekir.
```
/home/admin/xxx/.default/temp/libasyncProfiler1309163652530490111.so
```

Yeni Sürekli Performans Profillemesi İçin Depolama Ücretleri Neden Değişti?

Raporlanan hacimdeki değişikliğin başlıca nedenleri şunlardır:

Sürekli performans profilleme, orijinal sürekli profilleme özelliğiyle tamamen uyumlu yeni bir özelliktir. Birden fazla örnek arasında toplu sorgulamayı, iş parçacığı düzeyinde analizi ve Copilot destekli akıllı alev grafiği analizini destekler.
Depolama yapısı değişmiştir. Kullanıcıların profilleme verileri üzerinde ikincil analiz yapabilmesi için depolama ortamı, yerleşik Object Storage Service (OSS) yerine hesabınızdaki bir Simple Log Service (SLS) örneğine taşınmıştır. SLS Project proj-xtrace-<encode>-<region-id> ve SLS Logstore logstore-profiling şeklindedir. Bu değişiklik, depolanan profilleme verilerinin hacmini ve buna bağlı depolama ücretlerini etkiler.

Veri Sorguları İçin Desteklenen Zaman Aralığı

Sürekli performans profilleme verileri 7 gün boyunca saklanır. Bu dönemdeki verileri sorgulayabilirsiniz.

Yığın Bellek İzlemesinden Elde Edilen Bellek Kullanımı İle Sürekli Profillemdeki Bellek Sıcak Noktaları Tarafından Tespit Edilen Bellek Kullanımı Farklı Olması Normal Midir?

Sürekli Profilleme yalnızca belirtilen süre içindeki yığın bellek tahsislerini kaydeder; işlemin toplam bellek kullanımını kaydetmez.

CPU Tanılamasında Veri Var Ancak Bellek Tanılamasında Veri Yok

Bu sorun genellikle 3.1.4 ve sonraki aracı sürümlerinde görülür.

Bellek tanılamasında veri eksikliğinin nedeni genellikle Alpine temel görüntüsü kullanmanızdır. Alpine temel görüntüleri boyutlarını küçültmek için JDK hata ayıklama sembollerini kaldırır; bu da sürekli profillemenin düzgün çalışmasını engeller. Bu sorunu çözmek için görüntünüzde JDK hata ayıklama sembollerini yükleyebilir veya Alpine olmayan bir temel görüntü kullanabilirsiniz. Bazı JDK sürümlerinde karşılık gelen hata ayıklama sembolü paketlerinin bulunmadığını ve bunun başarılı kurulumu engelleyebileceğini unutmayın.

Not

Ortamınızdaki JDK'nın hata ayıklama sembolleri içerip içermediğini doğrulamak için Ortamınızdaki JDK'nın hata ayıklama sembolleri içerip içermediğini kontrol etme bölümüne bakın.

Kod Sıcak Noktaları İçin Neden Veri Yok veya Veriler Beklentileri Karşılamıyor?

JDK'da sanal iş parçacıkları veya benzer teknolojileri kullanan uygulamalar (Alibaba Dragonwell JDK dahil) için sıcak nokta profilleme desteklenmez.
Kod sıcak noktası özelliği SkyWalking protokolü tarafından desteklenmez. Protokol türünü bir izlemenin span ayrıntılarında doğrulayabilirsiniz.
Kod sıcak noktası özelliği için aracı sürüm 3.1.4 veya üzeri gerekir. Daha eski sürümler bu özelliği desteklemez.
4.2.1'den önceki aracı sürümleri yalnızca senkron çağrıları destekler ve eksiksiz veri toplamayabilir. Asenkron çağrılar için veri eksikliği yaşanabilir. Örneğin, Spring Cloud Gateway, Undertow veya Lettuce kullanımı asenkron iş parçacığı geçişlerine neden olabilir ve bu durum veri toplamanın yanlış olmasına yol açar. 4.2.1 ve sonraki aracı sürümleri bu sorunlar için iyileştirmeler içerir. Aracıyı en son sürüme yükseltmenizi öneririz.
Kod sıcak noktası özelliği yalnızca sabit oranlı örnekleme ile toplanan izlemeler için desteklenir. Hata örnekleme (s9) veya yavaş örnekleme (s10) gibi sabit olmayan örnekleme oranlarıyla toplanan izlemeler için desteklenmez; çünkü bu durum yüksek performans yüküne neden olur. Bu örnekleme türleri yalnızca bir izleme tamamlandıktan sonra tetiklenir. Örnekleme türünü belirlemek için span niteliklerindeki sample.reason alanını kontrol edebilirsiniz.

Sabit olmayan örnekleme oranıyla toplanan izlemeler için İzleme Analizi sayfasına gidin. Sorunları tanılamak üzere kod sıcak noktaları içeren izlemeleri filtrelemek için Kod Sıcak Noktaları Olan İzlemeler parametresini kullanın.
4.2.1 veya sonraki aracı sürümlerini kullanıyorsanız toplanan yürütme süresi dış span tarafından kaydedilen süreden çok daha düşük olabilir. Bu durum, uygulamanız Spring Cloud Gateway gibi asenkron, engellemesiz G/Ç (NIO) çerçeveleri kullanıyorsa gerçekleşebilir. Bu çerçeveler upstream hizmetten istek aldığında veya downstream hizmete istek gönderdiğinde veriler hazır değilse iş parçacığını engellemez. Bunun yerine iş parçacığı hemen döner ve diğer görevleri gerçekleştirebilir; bu da iş parçacığı kullanımını artırır. İş parçacığı G/Ç beklerken engellenmediği için performans darboğazı mevcut uygulamada değildir. Bu durumda kod sıcak noktası için toplanan süre span süresinden çok daha düşük olabilir. Upstream veya downstream uygulamanın istek işlemedeki darboğazlarını veya ağdaki sorunları kontrol etmelisiniz.

Sürekli Profillemenin Performans Yükü Nedir?

Performans testleri sürekli profilleme için aşağıdaki yükü göstermektedir: Saniyede 500 İşlem (TPS) hızında ve tüm özelliklerin etkin olduğu standart bir Spring Web uygulamasında CPU yükü yaklaşık %5 artar ve yığın dışı bellek yükü yaklaşık 50 MB artar. Garbage Collection (GC) ve istek gecikmesindeki artış önemli değildir.
Aşırı durumlarda bellek sıcak noktası profilleme için hız sınırı yoktur. Uygulama çok sık bellek tahsis ediyorsa dakikada on binlerce olay gibi yüksek hacimli olaylar oluşabilir. Bu durum P99 gecikmesini etkileyebilir. Sorunu çözmek için bellek profillemeyi devre dışı bırakabilirsiniz.

Bu sorun 4.1.10 sürümünde giderilmiştir. Aracıyı 4.1.10 veya daha yeni bir sürüme yükseltebilirsiniz.

Uygulamadaki JFR İle İlgili İş Parçacıkları

Sürekli profilleme özelliği JDK Flight Recorder (JFR) iş parçacıkları oluşturur. Bu iş parçacıkları çoğunlukla 4.1.10 öncesi aracı sürümlerinde bulunur. 4.1.10 ve sonraki aracı sürümleri JFR iş parçacıkları oluşturmaz.
Bu iş parçacıkları uygulamada performans darboğazlarına neden olmaz.
Sürekli profilleme anahtarını dinamik olarak kapatırsanız iş parçacığı hemen yok edilmez. Yalnızca uygulama yeniden başlatıldıktan sonra kaybolur.

Uygulama Başlangıç Süresi İçin Sürekli Profilleme

Sürekli profilleme uygulama başlangıcını yavaşlatabilir. Bu durum, JDK'da hata ayıklama sembolleri eksikse ve Classloader birçok yöntem yüklüyorsa gerçekleşebilir. Uygulama başladıktan sonra çalışma zamanı performansı üzerinde herhangi bir etkisi yoktur.

Bu sorun aracı sürüm 4.2.1'de giderilmiştir. Sorunu çözmek için aracıyı bu sürüme yükseltebilirsiniz.

Alev Grafiğindeki Toplam Bellek Neden Gerçek Yapılandırılmış Bellek Limitini Aşıyor?

Sürekli profillemedeki veriler sunucunun bellek yapılandırmasıyla doğrudan ilişkili değildir. Analiz dönemi sırasında tahsis edilen toplam yığın bellek miktarını gösterir. Garbage Collection nedeniyle bu miktarın sunucuda yapılandırılan bellekten büyük olması normaldir.

OpenJ9 JDK Bağlantı Hatası

ARMS sürekli profilleme IBM OpenJ9'u desteklemez. Bu JDK'nın kullanılması entegrasyonun başarısız olmasına ve hataların oluşmasına neden olabilir. Bunun yerine OpenJDK veya Oracle JDK kullanmanızı öneririz.

Span'lardaki Kod Sıcak Noktası Verileri Eksik

Kod sıcak noktaları, bir izlemedeki iş parçacıklarının yöntem yığınlarını belirli aralıklarla örnekleme yoluyla belirlenir. Bir yöntem kod sıcak noktası alev grafiğinde eksikse yürütme süresi 500 ms'den az olduğu için yakalanmamış olabilir. Böyle kısa yürütme sürelerine sahip yöntemler örnekleme süreci tarafından yakalanmayabilir. Kısa süreli çalışan yöntemler performans darboğazı olarak kabul edilmediğinden bu durum yavaş izlemelerin tanılanmasını etkilemez.

Alev Grafiğinde Neden .GC_active Yığınları Görünür?

.GC_active, alev grafiği için veri toplama sırasında garbage collection (GC) etkin olduğunu gösterir. GC işlemi "Stop-the-World" olarak bilinen bir olayda tüm Java iş parçacıklarını durdurur. .GC_active bir kod sıcak noktasında görünüyorsa GC duraklaması isteğin gecikmesine katkıda bulunmuş demektir.

Alev Grafiğinde Neden "unknown" Girişleri Görünür?

Alpine işletim sisteminde JDK'da hata ayıklama sembolleri eksikse ve classloader birçok yöntem yüklüyorsa sürekli profillemeyi etkinleştirmek uygulamayı yavaşlatabilir veya zaman aşımına uğramasına neden olabilir. Bunu önlemek için 4.2.1 ve sonraki aracı sürümleri yükleme süresini izler. Varsayılan eşik 150 ms'dir. Yükleme bu süreyi aşarsa aracı bazı zaman alıcı adımları durdurur. Bu durum bazı yöntem sembollerinin doğru şekilde ayrıştırılamamasına ve "unknown" girişlerinin oluşmasına neden olabilir. Bu sorunu azaltmak için eşiği ayarlayabilirsiniz. Örneğin, ortam değişkeni AP_JMID_TIME_LIMIT değerini 500 (milisaniye) olarak ayarlayın: export AP_JMID_TIME_LIMIT=500.

Alev Grafiğinde Neden .no_Java_frame Girişleri Görünür?

Bu durum genellikle Alpine temel görüntüsü kullandığınızda gerçekleşir. Alpine, görüntü boyutunu küçültmek için JDK hata ayıklama sembollerini kaldırır. Bu durum sistemin JDK içindeki C++ iş parçacıklarının yöntem yığınlarında fonksiyon adlarını tanımlamasını engeller. Bu yığınlar daha sonra .no_Java_frame olarak görüntülenir. Bu yığınlar çoğunlukla VM Thread veya Just-In-Time (JIT) derleyici iş parçacığı gibi Java dışı iş parçacığı bilgilerini temsil eder. .no_Java_frame girişlerinin oranı düşükse bunları yok sayabilirsiniz. Performans analizi için diğer Java yöntem yığınlarına odaklanın. Oran yüksekse temel görüntünüzdeki JDK için hata ayıklama sembollerini yükleyin. Veya Alpine olmayan bir temel görüntüye geçin. Bazı JDK sürümlerinde karşılık gelen hata ayıklama sembolü paketlerinin bulunmadığını ve bunun kurulumu engelleyebileceğini unutmayın.

Alev Grafiğinde Neden "other" Öğesi Görünür?

Sorun

Alev grafiğinde bir "other" öğesi görünür. Örneğin, profilleme türü olarak Allocated Memory seçildiği analiz sonuçlarında bellek tahsisi sıralama tablosunda belirli Java yöntemleri (örneğin AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter() 8,99 MB ve java.util.Arrays.copyOfRange(char[], int, int) 8,90 MB) arasında turuncu renkle vurgulanan other öğesi (6,41 MB) yer alır. Sağ taraftaki alev grafiği ilgili çağrı yığını hiyerarşisini gösterir.

Neden

Alev grafiğindeki "other" öğesi normaldir. Alev grafiği ağaç yapısına sahiptir. Düğüm sayısı çok fazla olduğunda anahtar bilgileri tespit etmek zorlaşabilir. ARMS, grafiği basitleştirmek ve önemli bilgileri öne çıkarmak için daha az önemli düğümleri "other" kategorisinde birleştirir.

Günlük Çıktısı: parse lib sigsegv handler installed

ARMS aracı bu bilgilendirici günlük mesajını yazdırır. Yalnızca sürekli profillemeyi etkinleştirdikten sonra görünür ve uygulamanın çalışma zamanı performansını etkilemez. ARMS bu günlük çıktısını gelecekteki bir sürümde devre dışı bırakacaktır.

perf_event_open Kısıtlamalarından Kaynaklanan "No access to perf events" Hatasını Nasıl Çözerim?

Sorun

Async-Profiler CPU profilleme için perf_event_open sistem çağrısına bağımlıdır. Ancak Linux çekirdeğindeki seccomp gibi güvenlik politikaları işlemlerin belirli sistem çağrılarını kullanmasını engelleyebilir.

Hata mesajı aşağıdaki gibidir:

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr'
[ERROR] Failed to start Continuous Profile Collector
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1'

Çözümler

Docker ortamları için konteyneri aşağıdaki komutla çalıştırın. Sistem çağrıları üzerinde daha ayrıntılı kontrol için resmi belgelere bakın.
```
  docker run --security-opt seccomp=unconfined  XXX
```
Kubernetes ortamları için privileged konteyner parametresini privileged: true olarak ayarlayın. Privileged konteynerler her zaman Unconfined durumundadır.

Sistem çağrıları üzerinde daha ayrıntılı kontrol için resmi belgelere bakın.

"No AllocTracer symbols found. Are JDK debug symbols installed?" Hatasını Nasıl Çözerim?

Bu hata veya veri eksikliği Java işleminiz Alpine temel görüntüsü kullanan bir konteynerde çalışıyorsa gerçekleşebilir. Alpine temel görüntüleri boyutlarını küçültmek için JDK hata ayıklama sembollerini kaldırır; bu da sürekli profillemenin düzgün çalışmasını engeller. Bu sorunu çözmek için hata ayıklama sembollerinin eksikliğinden kaynaklanan bellek sıcak noktası toplama hatasına yönelik çözümlere bakın.

"perf_event mmap failed..." Hatasını Nasıl Çözerim?

Sorun

Bu hata genellikle Java Sanal Makinesinin (JVM) standart çıktısında görünür. Sürekli profilleme CPU sıcak noktalarını örneklerken hem yerel yığınları (Linux Kernel, JVM ve C/C++) hem de Java yığınlarını toplar. Yerel yığınları toplamak için her Java iş parçacığı için perf_event dosya tanımlayıcısında bir bellek eşlemesi (MMap) gerçekleştirmesi gerekir. Linux çekirdeği bu MMap işlemleri için toplam belleği sınırlar. Varsayılan limit 516 KB'dir. Java uygulamanızda çok sayıda iş parçacığı varsa bu limit aşılabilir. Bu durum Java standart çıktısında perf_event mmap failed... uyarısını tetikler. Bu uyarı Java uygulamanızı veya iş mantığınızı etkilemez. Tek yan etkisi yerel yığınların alev grafiğinde görünmemesidir. Java yöntem yığını genellikle CPU sıcak noktalarını tanılamak için yeterli olduğundan bu uyarıyı genellikle yok sayabilirsiniz.

Çözümler

Bu hata mesajını gidermek için aşağıdaki adımları uygulayın:

Ana makinede aşağıdaki komutu çalıştırın.
```
echo 1028 > /proc/sys/kernel/perf_event_mlock_kb
```
Varsayılan eşik 516'dır. Uyarı durana kadar bu değeri artırabilirsiniz. Değer 8*N + 4 formülüne uygun olmalıdır; burada N bir doğal sayıdır. Örneğin, 516 = 512 + 4 ve 1028 = 1024 + 4.
Hatayı çözmek için Docker'ı yeniden başlatın.

Diğer İşlemler

Ortamınızdaki JDK'nın Hata Ayıklama Sembolleri İçerip İçermediğini Kontrol Etme

Hata ayıklama sembollerinin eksik olması bellek sıcak noktası aktivasyonunun başarısız olmasına neden olur. Sonuç olarak hiçbir bellek sıcak noktası verisi toplanamaz.

Eksik hata ayıklama sembolleri için aracı günlüklerini kontrol edin.

Aracı kurulum dizininde logs dizini altındaki cpc.log dosyasını kontrol edin. Bazı eski aracı sürümlerinde bu dosya logs/arms_log dizinindedir. Günlükte No AllocTracer symbols found. Are JDK debug symbols installed? anahtar kelimesi varsa hata ayıklama sembolleri eksik demektir.
```
2023-03-08 11:32:00 [continuous Profile collector] [INFO]
Some or all engines success, details below
CPU:true
Alloc:false:No AllocTracer symbols found. Are JDK debug symbols installed?
Wall:true
Other:false
Lock:false
```
Ortamda hata ayıklama sembollerinin eksik olup olmadığını kontrol etmek için komutları kullanın.
- JDK kurulum yoluna gidin.
  
  which java veya echo $JAVA_HOME komutunu kullanarak ortamınızdaki JDK kurulum yolunu bulabilirsiniz.
- JDK kurulum yolunun en üst düzeyinden başlayarak libjvm.so dosyasının yolunu bulmak için aşağıdaki komutu çalıştırın.
```
find ./ -name "*libjvm.so*"
```
- Dosyadan hata ayıklama sembollerinin silinip silinmediğini kontrol etmek için aşağıdaki komutu çalıştırın. /path/to/ yerine gerçek yolu yazın.
```
file /path/to/libjvm.so
```
  Komut not stripped döndürürse ortamınızdaki JDK hata ayıklama sembolleri içeriyor demektir. stripped döndürürse hata ayıklama sembolleri içermiyor demektir.
```
[root@iZj6cbirlzrhmgljxdfxw9Z jdk-directory]# cd jdk8u412-b08
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# ls
ASSEMBLY_EXCEPTION  LICENSE  NOTICE  THIRD_PARTY_README  bin  include  jre  lib  man  release  sample  src.zip
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# find ./ -name "*libjvm.so*"
./jre/lib/amd64/server/libjvm.so
[root@iZj6cbirlzrhmgljxdfxw9Z jdk8u412-b08]# file ./jre/lib/amd64/server/libjvm.so
./jre/lib/amd64/server/libjvm.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped
```

Hata Ayıklama Sembollerinin Eksikliğinden Kaynaklanan Bellek Sıcak Noktası Toplama Hatasına Yönelik Çözümler

Yöntem 1: JDK 11 veya Sonrasına Yükseltin

JDK 11 ve sonraki sürümlerin uygulaması değiştirilmiştir ve artık hata ayıklama sembolü bilgilerine bağımlı değildir.

Yöntem 2: Temel Görüntüyü Değiştirin

Docker Hub adresine gidip openjdk anahtar kelimesini kullanarak eclipse-temurin, ibm-semeru-runtimes ve amazoncorretto gibi popüler JDK dağıtımlarını bulabilirsiniz. Ardından Alpine Linux üzerine kurulmamış bir JDK görüntüsü arayın. Kendi JDK görüntü kitaplığınız varsa buradan da alternatif bulabilirsiniz. Alpine Linux üzerine kurulu JDK görüntülerinin etiketlerinde genellikle alpine ifadesi yer alır.

Örneğin, eclipse-temurin:8u382-b05-jdk-alpine görüntüsünün etiketinde alpine ifadesi bulunur; bu da Alpine Linux üzerine kurulu olduğunu gösterir. Bu görüntüyü kullanmaktan kaçının.

Alpine olmayan Linux temel görüntüsü üzerine kurulu bir JDK sürümüne örnek:

Örneğin, Docker Hub'daki eclipse-temurin:8u392-b08-jdk görüntüsünün etiketinde alpine ifadesi yoktur. Alpine olmayan Linux temel görüntüsü üzerine kurulu bir JDK sürümüdür ve linux/amd64, linux/arm/v7, linux/arm64/v8, linux/ppc64le ve windows/amd64 dahil olmak üzere birden fazla mimariyi destekler.

Temel görüntüyü değiştirdikten sonra hala veri yoksa yerel cpc.log dosyasında No AllocTracer symbols found. Are JDK debug symbols installed? hata mesajını kontrol edin. Bu mesaj ortamınızda hata ayıklama sembollerinin hala eksik olduğunu gösterir. Bu durumda başka bir temel görüntü kullanın veya Yöntem 3: Standart Alpine Linux ve JDK Kullanın yöntemini uygulayın.

Yöntem 3: Standart Alpine Linux ve JDK Kullanın

ARMS aracı sürüm 3.2.8 veya sonrasını kullanın ve Dockerfile'da Alpine Linux ile JDK'yı belirtin.

from Alpine:3.9
RUN apk add openjdk8