OpenTelemetry pada 2023

 (bit.kevinslin.com)
2 poin oleh GN⁺ 2023-08-29 | 1 komentar | Bagikan ke WhatsApp
  • OpenTelemetry, yang dimulai dari penggabungan OpenTracing dan OpenCensus pada 2019, dalam 4 tahun telah menjadi standar observabilitas yang mencakup trace, metric, dan log
  • Struktur intinya terbagi menjadi spesifikasi dan implementasi, yang bersama-sama menyediakan acuan kompatibilitas vendor serta alat instrumentasi dan pengumpulan yang nyata
  • Spesifikasi OTEL menstabilkan tracing pada 2020, metric pada 2021, dan log pada 2023, sehingga semua sinyal kini berstatus stable, tetapi dukungan log masih berbeda-beda antar SDK
  • OTLP dan Collector menjadi fondasi untuk mengirim dan memproses data observabilitas dalam format umum, dan agen vendor seperti Grafana dan Datadog juga mengimplementasikannya
  • OTEL memperluas cakupannya ke Collector, Semantic Conventions, OpAMP, OTTL, hingga Demo, dan berkembang sebagai fondasi bersama observabilitas yang netral terhadap vendor

Posisi OpenTelemetry saat ini

  • OpenTelemetry, disingkat OTEL, dimulai pada 2019 dari penggabungan OpenTracing dan OpenCensus
  • Pada awalnya ini adalah proyek yang berpusat pada tracing, tetapi setelah penggabungan cakupannya meluas ke seluruh observabilitas
  • Tujuannya adalah membantu organisasi menyediakan telemetri yang berkualitas tinggi, umum, dan portabel
  • Setelah 4 tahun, OTEL kini memiliki fondasi berikut
    • standar stabil untuk metric, log, dan trace
    • Collector yang dapat menerima, memproses, dan mengekspor telemetri di lingkungan apa pun
    • SDK yang mendukung instrumentasi kode di bahasa-bahasa utama
    • standar tambahan terkait Semantic Conventions dan manajemen agen
  • Saat ini OTEL adalah proyek paling aktif di CNCF setelah Kubernetes, dengan kontributor yang tersebar di berbagai vendor observabilitas utama, dan protokolnya juga telah diadopsi hampir secara universal di antara para penyedia observabilitas

Komponen OTEL yang terbagi menjadi spesifikasi dan implementasi

  • Secara garis besar, OTEL terdiri dari spesifikasi (specification) dan implementasi (implementation)
  • Spesifikasi mendefinisikan cara menangkap, mengumpulkan, memproses, dan mengekspor telemetri
    • Ini mendekati standar bersama yang harus diikuti vendor agar kompatibel dengan OTEL
  • Implementasi adalah library klien dan alat untuk menangani data telemetri
    • Inilah bagian yang langsung dihadapi pengguna akhir saat menginstrumentasi kode
  • Stabilitas proyek biasanya ditandai per sinyal
    • Dalam OTEL, sinyal berarti jenis data telemetri seperti metric, log, dan trace
  • Subproyek utamanya adalah sebagai berikut
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification adalah fondasi OTEL dan menyediakan API, SDK, serta model data yang menjadi dasar standar OTEL lainnya
  • Proses stabilisasi berlangsung per sinyal
    • September 2020: tracing stable
    • November 2021: metric stable
    • April 2023: log stable
  • Saat ini spesifikasi OTEL berada dalam status stable untuk semua sinyal
  • Karena sinyal log baru distabilkan pada 2023, masih banyak OTEL SDK yang belum mendukung log

OpenTelemetry SDK dan instrumentasi otomatis

  • OTEL SDK menyediakan instrumentasi sisi klien berdasarkan spesifikasi OTEL
  • Setiap SDK per bahasa memiliki tingkat kematangan tersendiri untuk sinyal metric, log, dan trace
  • Beberapa SDK mendukung instrumentasi otomatis (auto instrumentation) tergantung bahasa pemrogramannya
    • Instrumentasi otomatis adalah cara SDK menyuntikkan sinyal ke dalam kode aplikasi secara otomatis, terutama trace, untuk mengurangi beban instrumentasi manual
  • Pada bahasa terkompilasi seperti go dan rust, instrumentasi otomatis tidak berjalan
  • Namun, di luar SDK, instrumentasi trace otomatis bisa diperoleh dengan alat berbasis eBPF atau service mesh

OTLP 1.0 dan standar pengiriman data

  • OTLP adalah wire protocol umum untuk mengirim data observabilitas
  • Ada dua metode transport resmi
  • Spesifikasi ini dianggap stable dan dapat diimplementasikan di semua layanan yang menerima, memproses, dan mengekspor data OTEL
  • OTLP diimplementasikan oleh OpenTelemetry Collector, dan juga oleh agen dari vendor observabilitas seperti Grafana dan Datadog

OpenTelemetry Collector 0.83.0

  • OTEL Collector adalah agen netral vendor yang mengumpulkan, mengubah, dan mengirim data observabilitas
  • Collector terdiri dari komponen berikut
    • receivers: menerima data dari berbagai sumber dengan metode push/pull
    • processors: mengubah, memfilter, memperkaya, dan menurunkan data saat transit
    • exporters: mengirim data ke tujuan downstream
    • connectors: bertindak sebagai receiver sekaligus exporter dan menghubungkan beberapa pipeline
    • pipelines: rantai yang terdiri dari receiver, nol atau lebih processor, dan exporter
    • extensions: menyediakan fungsi di luar pemrosesan telemetri, seperti basic auth dan health check
  • Komponen-komponen ini bersama-sama bekerja sebagai pipeline observabilitas untuk mengumpulkan telemetri dari sumber mana pun, memprosesnya saat transit, lalu mengirimkannya ke tujuan yang diinginkan
  • Collector terbagi menjadi dua proyek
    • otel-collector: hanya mencakup komponen inti Collector dan terutama berisi logika yang langsung terkait dengan pemrosesan data OTLP
    • otel-collector-contrib: kumpulan integrasi yang mencakup exporter dan receiver untuk sebagian besar penyedia observabilitas
  • Pada saat penulisan, otel-collector-contrib mencakup 91 receiver, 48 exporter, dan 24 processor
  • Pengguna akhir disarankan menggunakan OpenTelemetry Collector Builder untuk membuat build kustom otel-collector-contrib yang hanya berisi komponen yang diperlukan
  • Vendor seperti AWS dan Splunk juga menyediakan distribusi OTEL mereka sendiri

OpAMP dan manajemen agen jarak jauh

  • OpAMP adalah protokol jaringan untuk manajemen agen jarak jauh
  • Ini adalah standar yang relatif baru yang ditambahkan ke OTEL pada 2022, dan menyediakan cara netral vendor untuk mengendalikan sekumpulan agen
  • Objek yang dikelola bisa berupa instance otel-collector, atau agen khusus vendor yang mengimplementasikan OpAMP
  • Dengan OpAMP, fitur berikut dapat diaktifkan
    • deployment konfigurasi dinamis
    • pembaruan agen
    • manajemen kredensial
  • Saat ini implementasi Go dari spesifikasi OpAMP masih berstatus work in progress

Semantic Conventions dan proyek tambahan

  • OTEL Semantic Conventions mendefinisikan sekumpulan atribut umum yang digunakan dalam data observabilitas
  • Cakupan penerapannya mencakup resource cloud, database, exception, sistem, dan lainnya
  • Semantic Conventions digunakan oleh OTEL SDK, dan pada SDK yang mendukung instrumentasi otomatis, ia diterapkan secara otomatis
  • Semantik bersama memungkinkan korelasi di antara sinyal yang berbeda
  • Komponen penting lain dari OTEL juga ada secara terpisah
    • OpenTelemetry Transformation Language (OTTL): bahasa transformasi umum untuk telemetri, dengan performa dan fleksibilitas, yang dirancang dan diimplementasikan di otel-collector-contrib
    • OTEL Demo: situs belanja berbasis microservice yang menampilkan kapabilitas OTEL dan sebagian besar SDK bahasanya

Perubahan selama 4 tahun

  • OTEL berawal dari penggabungan spesifikasi tracing yang saling bersaing lalu berkembang menjadi standar industri untuk observabilitas
  • Empat tahun terakhir adalah periode membangun fondasi bersama di seluruh vendor dan alat

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-29
Komentar Hacker News

  • Ada dua masalah dengan OpenTelemetry

    1. Identitasnya tidak jelas. Apakah ini standar semantik, protokol, facade, library, atau lapisan abstraksi seperti apa yang disediakan—semuanya ambigu, dan jawabannya hampir “semuanya”
    2. Di pihak OpenTelemetry, tampaknya tidak ada yang benar-benar pernah menginstrumentasi library. Tidak ada juga saran tentang bagaimana pelaku instrumentasi harus memakai metrik, trace, dan log; apakah harus memakai ketiganya atau cukup salah satunya. Saya pernah bertanya 2 tahun lalu, tetapi tidak mendapat jawaban: https://github.com/open-telemetry/opentelemetry-specificatio...
    • Setuju. Ini seperti memberikan wastafel beserta rumah yang menempel padanya sekaligus, sehingga dokumentasinya pun tipis dan membingungkan
      Mirip dengan itu, saya ingin mengimplementasikan heartbeat sederhana untuk memahami penggunaan di aplikasi desktop, tetapi mengingat nama proyeknya, secara mengejutkan itu hampir mustahil. Respons terhadap pertanyaan juga minim, jadi saya sepenuhnya membatalkan rencana memakai OpenTelemetry: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • Setuju. Sebagian hal yang direkomendasikan OpenTelemetry tidak mungkin dilakukan dengan SDK yang sebenarnya
      Misalnya, bucket tidak bisa didefinisikan di dekat tempat histogram didefinisikan. Anda harus meneruskan daftar “override” yang memetakan nama histogram ke bucket ke tempat seperti exporter global. Ini jadi sangat berantakan jika ada library yang mengekspor metrik: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • Pertanyaan-pertanyaan itu bagus, tetapi saya tidak menganggapnya terlalu penting. Pertanyaan seperti ini sulit dijawab secara jelas di ranah observability, baik di OpenTelemetry maupun sistem proprietary lain
      Kalau melihat situs web perusahaan-perusahaan observability terkemuka, tulisan tentang instrumentasi kustom hanya sekitar 4 halaman dan hanya membahas hal-hal yang sangat dasar. OTel tidak secara khusus tertinggal; jawabannya umumnya lebih dekat ke “tergantung situasinya”. Seiring bertambahnya pengalaman, bagian-bagian seperti ini yang membingungkan bagi pemula bisa diselesaikan
    • Yang diperlukan sebenarnya hanya memelihara 3 file skema JSON
    • Pertanyaan ketiganya adalah apakah ada skalabilitas

  • Saya sangat menyukai OpenTelemetry dan ingin melacak hampir semua span. Kalau memakai vendor tertentu, mungkin sudah bangkrut karena biayanya
    Dengan instrumentasi otomatis Java, saya memasang OpenTelemetry hampir tanpa upaya, lalu mengirimkannya ke ClickHouse yang di-host sendiri dan menyimpan lebih dari 700 juta span per hari di EC2 seharga 100 dolar: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • Di proyek pribadi kecil, saya mengirim trace/log/metrik ke ClickHouse melalui SigNoz. Sekitar 400 ribu–800 ribu span per hari(https://i.imgur.com/s0J6Mzo.png), dan pada satu t4g.small CPU biasanya sekitar 11%, IOPS sekitar 4%
      Dengan retensi trace 1 bulan, signoz_index_v2 berisi 26,9 juta baris dengan 17.06GiB, trace_log berisi 123 juta baris dengan 2.64GiB, dan samples_v2 berisi 949 juta baris dengan 345MiB, jadi rasio kompresinya bagus. Kalau memakai mesin ClickHouse sesuai spesifikasi rekomendasi, mungkin waktu tuning bisa dikurangi, tetapi sekarang pun berjalan baik
      Kekurangannya adalah IOPS disk sc1 kecil hanya sekitar 4, jadi startup ClickHouse memakan waktu sekitar 5 menit, dan meski UI SigNoz fungsinya cukup, sulit berharap polish setingkat Datadog
    • Perlu menetapkan rasio sampling, tetapi pastikan semua error tetap dikirim
      Di tempat kerja sebelumnya, kami hanya mengumpulkan 5% trace yang bukan error
    • Secara realistis, kebanyakan orang tidak ingin mengoperasikan penyimpanan ClickHouse sendiri, dan tidak semua engineer bisa menangani SQL seefisien kode. Meski begitu, ini konfigurasi yang cukup keren
    • Yang juga keren adalah upaya yang dibutuhkan untuk konfigurasi kecil. Kombinasinya adalah instrumentasi otomatis Java + exporter ClickHouse + plugin Grafana ClickHouse

  • Saya sangat kecewa dengan OpenTelemetry. Dari pengalaman, ini adalah gumpalan membingungkan yang dirancang berlebihan, dan pengalaman penggunaan default-nya sangat tidak ramah pengguna
    Ia mempromosikan dirinya sebagai format tracing/metrik/log yang umum serta kumpulan pustaka plug-and-play dengan adaptor untuk semua yang dibutuhkan, tetapi pada kenyataannya lebih dekat ke kumpulan pustaka setengah matang dengan banyak implementasi internal yang bocor, kualitas adaptor buruk, dan fitur yang tidak banyak

    • Setuju. Setiap kali memakai SDK-nya, rasanya harus berpikir dengan cara yang ortogonal terhadap akal sehat. Tidak ada yang bekerja seperti yang diharapkan, segala sesuatu punya tiga lapis abstraksi yang tidak perlu, dan harus diakses lewat pintu belakang
      Banyak fitur disertai petunjuk seperti kapan, di mana, seberapa banyak, saat fase bulan seperti apa, ketika Jupiter terlihat di langit, dan ketika panjang string kira-kira berapa fitur itu akan bekerja
      Meski begitu, jika mengabaikan API SDK yang bocor dan fitur-fitur yang setengah diimplementasikan, janji dapat diganti-ganti cukup ditepati. Sebelum OTel, semuanya adalah stack khusus, tetapi sekarang kita bisa mencolokkan backend logging lain ke satu SDK standar dan berharap sebagian besar berfungsi. Ini lebih buruk daripada stack yang terintegrasi vertikal, tetapi dari sudut pandang arsitektur ini adalah kemenangan parsial karena memungkinkan persaingan dan evolusi per bagian tanpa harus merombak seluruh stack observability
    • Saya mengalami rasa sakit yang sama, tetapi alternatif yang mengklaim lebih baik karena punya spesifikasi OpenAPI pun saat dicoba tidak jauh lebih baik: https://github.com/openzipkin/zipkin-api-example
      Contohnya hanya menunjukkan cara mem-parsing spesifikasi OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) dengan tool swagger, menghasilkan kode perekat Go secara otomatis, lalu mencatat trace dengan memanggil satu fungsi yang dihasilkan otomatis
      Tidak ada dokumentasi atau contoh lain sama sekali, jadi saya jadi bertanya-tanya apakah ada orang yang benar-benar memakai pendekatan ini, dan akhirnya memakai API layanan (https://zipkin.io/zipkin-api/#/) secara langsung lewat panggilan REST. OTel memang menyakitkan, tetapi alternatifnya juga tidak lebih baik. Seiring pengukuran SLO dan SLI makin penting, saya berharap ada lebih banyak perhatian di area ini
    • Kalau begitu, saya penasaran apakah ada alternatif yang bisa direkomendasikan, atau apakah kita hanya perlu menerima OTel apa adanya
    • Akan bagus jika bisa memberikan pengalaman konkret dan usulan perbaikan

  • Pustaka resmi OTel masih belum bekerja dengan baik di frontend web. Misalnya, dalam kondisi default tidak ada cara untuk mengaitkan error dengan sourcemap
    Kolektor browser web yang dirilis proyek OTel memakai Zone.js untuk mencegat hampir semua hal di browser sebagai konteks. Jika pernah memakai Angular modern, Anda tahu Zone.js kadang cukup menyakitkan dan dapat menyentuh global sehingga menghasilkan perilaku yang sulit diprediksi
    Saya juga tidak tahu apakah ada standar OTel untuk hal seperti session replay. Banyak platform telemetry seperti Sentry, Rollbar, dan DataDog mendukungnya. Tim backend tampaknya cukup menyukainya, dan saya suka sifat lintas batas span yang bisa mengikuti seluruh sistem dengan tag unik. Namun payload yang dihasilkan terkadang sangat verbose, dan sebagian platform logging lebih ringkas. Dalam praktiknya saya tidak merasa ini masalah besar

    • Dalam lingkungan Promise native dan async/await, sepertinya saat ini tidak ada cara untuk mengimplementasikan sesuatu seperti Zone.js dengan benar
      Saya juga pernah melakukan instrumentasi langsung, tetapi rawan error dan verbose. Browser benar-benar membutuhkan sesuatu seperti https://nodejs.org/api/async_context.html#class-asynclocalst...
    • Di sebagian besar platform, Otel lebih dekat sebagai titik awal untuk membuat pustaka instrumentasi yang baik
      Di paket kami, kami menambahkan session replay, pelacakan exception yang lebih baik, dan sebagainya di atas implementasi SDK browser Otel/Splunk. Sayangnya, hal-hal seperti ini jauh dari bawaan. Meski begitu, kemampuan menghubungkan sesi frontend dengan trace/log backend menurut saya telah sangat mengubah developer experience: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Dokumen Otel ini juga layak dilihat: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      Tidak sepenuhnya menyelesaikan masalah, tetapi bisa menjadi titik awal
    • Instrumentasi frontend DataDog, Real User Monitoring, juga terasa jelas belum dipoles. Tingkat ketelitiannya seperti menyusun balok Duplo
      Saya penasaran apakah ada orang yang pernah mulai melakukan frontend tracing sedikit saja
    • Saya penasaran apakah Anda pernah melihat Grafana Faro. Bisa dikirim ke Grafana Agent, dan Grafana Agent bersifat open source serta dapat menyimpan trace di lokasi lain

  • Bersama beberapa rekan, saya pernah punya gagasan yang agak nyeleneh bahwa kita tidak lagi membutuhkan log. Alih-alih pesan log, cukup tempelkan span event: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    Lalu yang dicatat sebagai log hanya judul span dan tautan span terkait di Jaeger. Saya baru mencobanya di proyek pribadi, tapi rasanya cukup bagus; hanya saja akan lebih baik kalau UI Jaeger lebih mendukung pola penggunaan seperti ini
    Bahkan rekan-rekan itu juga pernah memberi presentasi tentang topik ini. Kalau berada di sekitar Hannover, Jerman, coba cari “Nie wieder Log-Files!” di https://javaforumnord.de/2023/programm/

    • Tergantung seberapa greenfield proyeknya, kalau yang dibutuhkan hanya timestamp dari pekerjaan tertentu dan bukan durasinya, bahkan span event mungkin tidak diperlukan
      Memakai span untuk semua pekerjaan yang bermakna mirip dengan memakai structured log yang lebih kuat. Ini sulit untuk banyak sistem yang harus tetap membawa log lama, tetapi kalau cukup greenfield, saya merekomendasikannya
    • Saya juga pernah memikirkan pendekatan ini, tapi saya suka bahwa dengan alat sederhana kita bisa memahami secara garis besar apa yang sedang terjadi
      Untuk memakai trace, ada banyak hal yang harus berjalan dengan benar. Atau mungkin saya masih kurang pengalaman sehingga alat-alatnya terasa menakutkan
    • Ini adalah ide dari proyek Veneur milik Stripe. Caranya memperlakukan span, log, dan metrik dalam format yang sama, lalu “secara otomatis” melakukan roll-up cardinality sesuai kebutuhan
      Saat melihat presentasinya beberapa tahun lalu, saya pikir itu keren, tetapi tampaknya akan sangat sulit meyakinkan developer yang bukan SRE: https://github.com/stripe/veneur
    • Trace juga tidak perlu dikirim ke mana pun. Bisa disimpan di dalam proses, lalu membuat API di atas data trace in-memory itu
    • Kami juga membicarakan hal yang sama di perusahaan. Ini cukup masuk akal, dan saya rasa log bisa hampir sepenuhnya dihilangkan

  • OpenTelemetry adalah proyek yang digerakkan pemasaran, dirancang secara naif dan tidak efisien ala komite, dan tampaknya tujuan utamanya adalah membantu CTO Fortune X00 mencentang kotak di dokumen roadmap strategis mereka
    Ini bukan sesuatu yang seharusnya dipakai oleh orang yang punya pilihan

    • Komentar lain di thread ini umumnya mendukung atau sangat positif, jadi saya ingin mendengar lebih detail apa yang menurut Anda buruk secara spesifik
    • Sebagai pendiri highlight.io, dari sisi konsumen saya melihat banyak nilai dalam OTEL. Kami memakainya untuk memperluas dukungan bahasa bagi berbagai pelanggan, dan komunitasnya juga sangat terbuka
      Contoh perubahan yang kami ajukan ada di sini: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      Saya ingin tahu alasan Anda mengapa menurut Anda tidak seorang pun sebaiknya memakainya
    • Menurut saya penilaian itu tidak tepat. Justru ini lebih mirip “software open-source mengekspor metrik Prometheus dan trace Jaeger, sementara kami ingin menjual produk proprietary sebagai alternatifnya dan tidak ingin mengirim patch ke semua proyek”
      Datadog memang benar-benar menugaskan banyak orang untuk menambahkan dukungan Datadog ke proyek OSS. Terjun ke codebase asing adalah kemampuan yang kuat, jadi mungkin cukup bagus untuk awal karier
      OTel membuat proyek open-source memakai lapisan abstraksi, sehingga pengguna bisa membeli layanan alih-alih self-hosting. Saya tidak terlalu menyukainya, tetapi untuk layanan yang dioperasikan orang di luar perusahaan, sekarang saya mungkin akan mempertimbangkan OTel. Karena kalau ada pengguna yang ingin memakai Datadog, kami tidak menghalanginya
      Saat saya memakai OTel yang masih sangat awal, API Go-nya sangat tidak efisien sehingga mengecewakan. Untuk menaikkan counter perlu context.Context, dan abstraksinya juga bocor, misalnya tidak ada cara mengatur bucket histogram saat mengekspor ke Prometheus. Saya rasa sekarang kemungkinan sudah diperbaiki
    • Itu terlalu keras. Menurut saya model data-nya adalah kemajuan ke arah yang benar
      Processor-nya juga cukup mumpuni, dan kumpulan receiver serta exporter contrib secara umum juga cukup baik. Saya tidak mengatakan ini solusi terbaik dan memang tergantung use case, tetapi kritik sekeras itu tampaknya tidak beralasan. Sebagai catatan, saya termasuk tim maintainer fluent-bit
    • Kemampuan membuat layanan berbicara dengan OTLP, lalu menyederhanakan konfigurasi aplikasi menjadi mengirim data ke OTEL Collector, itu bagus
      Dari sudut pandang operasi, apa pun observability yang ditambahkan developer ke kode, kita bisa memaksakan filtering secara terpusat, dan cukup ada satu jalur masuk terpusat yang digunakan aplikasi
      Karena semuanya mengekspor OTLP, ketika ingin pindah ke backend baru, cukup ubah file YAML; tidak perlu menulis ulang aplikasi untuk mendukung backend logging baru. Dibanding kembali ke cara lama memakai library logging khusus vendor, dengan segala kekurangannya saya akan tetap memilih OTEL 10 dari 10 kali

  • Saya benar-benar tidak suka popup langganan di blog ini. Tidak ada tombol x, jadi sama sekali tidak jelas bahwa kita bisa menutupnya tanpa memberikan email
    Di bawah tombol berlangganan ada “continue reading” yang sangat tidak intuitif; saya tidak menyangka itu bisa dipakai, dan mengeklik area luar juga tidak menutupnya. Hal seperti ini perlu diperbaiki
    Soal OpenTelemetry, saya sudah lama ingin menguji apakah ia menyediakan semua fitur yang dibutuhkan saat mengirim data ke Datadog. Namun jika selain fitur dasar kita masih tetap membutuhkan agen Datadog, itu berarti ada satu hal lagi yang harus dikelola dan diajarkan, jadi saya ragu
    Saya penasaran apakah ada yang benar-benar pernah menghubungkannya ke Datadog. Tujuannya memang bukan harus terus terikat pada Datadog, tetapi saat ini cukup banyak alert dan log kami ada di sana, jadi jika lebih dulu beralih ke OpenTelemetry, secara teori nanti kami bisa pindah ke yang lain

    • Popup itu adalah fitur dari medium.com. Saya setuju, sangat menyebalkan
    • Secara pribadi, surveinya lebih buruk. Ia meminta pendapat, jadi saya menekan salah satu opsi, lalu sebagai imbalannya saya disuguhi layar penuh untuk membuat akun
      Saat saya menekan tombol kembali, saya malah kembali ke HN

  • Saya penasaran apakah masih ada frontend yang tidak banyak menggerus aliran pendapatan dari sisi biaya tenaga kerja, infrastruktur, dan lisensi
    Saat menerima lebih dari 2.000 request per detik, mempertahankan log saja sudah mahal

    • Kalau belum melakukannya, saya menyarankan trace sampling. Datadog APM tidak mengesankan karena tidak ada konfigurasi yang murah
      Kami menjalankan stack Jaeger sendiri dengan sampling 0,1%, dan dibanding Datadog APM biayanya bisa dibilang dapat diabaikan
      Untuk metrik dan log, sampling tidak terlalu berguna, jadi tidak ada jawaban yang bagus. Jika margin kotor Datadog 80%, maka dari pembayaran Anda biaya infrastrukturnya paling banyak 20%; dan jika biaya tenaga kerja lebih kecil dari 80% itu, Anda bisa memangkas banyak biaya dengan menjalankan sendiri stack open source. Meski memakai Datadog, kami tetap menjalankan proyek untuk mengurangi penggunaan tiap 3 bulan, jadi bagaimanapun tetap perlu dirawat terus
    • Jawabannya adalah sampling. Cukup sampling 1% request yang berhasil dan kumpulkan semua error
      Biaya memang masalah, tetapi Anda mungkin terkejut bahwa observability membebani layanan lebih berat dari yang dikira. Ia memakai CPU cukup banyak
    • Perlu menetapkan tolok ukur untuk “banyak”. Di perusahaan sebelumnya, kami merutekan trace ke Cassandra dan menyimpannya di domain AWS Elasticsearch, lalu memvisualisasikannya dengan Jaeger
      Saya juga menulis beberapa query Elasticsearch untuk membuat laporan dasar guna menemukan query yang lambat. Jika mengikuti tutorial OTEL/Jaeger, ini konfigurasi yang cukup standar
      Trace berada di kisaran ratusan per detik dan semuanya dikumpulkan tanpa downsampling. Masa retensi bisa disetel 7 hari, dan saat saya keluar hampir tidak ada optimasi nyata. Seingat saya biaya bulanannya sekitar puluhan sampai ratusan dolar
      Anda bisa mendefinisikan perilaku tracing sampler lewat environment variable yang dapat disetel pada container. Lihat OTEL_TRACES_SAMPLER di dokumentasi: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • Sebagian besar vendor observability kini mendukung OTEL. Proyek OSS yang saya ikuti juga mendukung pengumpulan OTEL: https://github.com/grafana/tempo/
    • Saya tidak tahu kenapa ini di-downvote. Kami juga merasakan masalah yang sama, hanya saja pada skala 500 ribu request per detik
      Saat ini kami memakai Datadog, tetapi semua orang tahu itu terlalu mahal

  • Sebagian besar thread ini membahas pengiriman metrik/log dengan OpenTelemetry ke pekerjaan collector yang di-hosting sendiri
    Memakai library standar yang didukung berbagai alat collector seperti ClickHouse itu sendiri sudah berguna, tetapi manfaat lainnya adalah spesifikasinya memungkinkan trace ID diteruskan melintasi batas sistem
    Jika Anda dan semua dependency Anda mengimplementasikan spesifikasi OpenTelemetry, Anda bisa mendapatkan span yang menunjukkan secara terperinci apa yang terjadi sepanjang perjalanan. Misalnya, Anda bisa mengetahui apakah penyebab pemuatan halaman lama adalah pemuatan disk page di database, atau apakah span metadata plane dari layanan cloud adalah penyebab latensi tinggi

  • Saya sangat puas dengan kemajuan OpenTelemetry. Ketika saya mendorong adopsinya beberapa tahun lalu, para developer ragu karena itu baru dan belum pernah mereka dengar; tetapi ketika saya melihatnya lagi setahun lalu, OpenTelemetry sudah ada di berbagai bagian sistem kami dan vendor log/tracing yang kami gunakan juga sedang beralih ke sana