Istio Telemetry API: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Istio Telemetry API: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya

Ilustrasi Istio Telemetry API untuk observability Kubernetes Service Mesh

Setelah membahas Istio PeerAuthentication dan Mutual TLS (mTLS), kita telah memahami bagaimana Istio melindungi komunikasi antar workload di dalam service mesh. Namun, keamanan saja belum cukup untuk memastikan sistem berjalan dengan baik.

Pada lingkungan microservices yang terdiri dari banyak service, administrator juga membutuhkan kemampuan untuk melihat apa yang sedang terjadi di dalam sistem. Berapa banyak request yang masuk? Berapa lama response diberikan? Berapa banyak request yang mengalami error? Service mana yang memiliki latency tinggi? Dan bagaimana alur sebuah request dari satu service menuju service lainnya?

Untuk menjawab kebutuhan tersebut, Istio menyediakan Telemetry API. Resource ini memungkinkan administrator mengatur bagaimana telemetry seperti metrics, access logs, dan distributed tracing dihasilkan serta dikonfigurasi pada service mesh.

Telemetry API menjadi salah satu komponen penting dalam penerapan observability pada arsitektur cloud-native karena membantu tim DevOps, SRE, dan developer memahami kondisi aplikasi Dewa234 secara lebih menyeluruh.

Apa Itu Istio Telemetry API?

Istio Telemetry API adalah resource konfigurasi Istio yang digunakan untuk mengatur telemetry yang dihasilkan oleh workload dalam service mesh. Telemetry tersebut dapat berupa metrics, access logs, maupun distributed tracing.

Dengan Telemetry API, administrator dapat menentukan konfigurasi telemetry secara lebih terstruktur tanpa harus mengubah kode aplikasi.


Application

      │

      ▼

Istio Proxy

      │

      ├── Metrics
      │
      ├── Access Logs
      │
      └── Tracing

      │

      ▼

Observability Platform

Pendekatan ini memungkinkan pengumpulan informasi operasional dilakukan pada lapisan service mesh sehingga aplikasi dapat tetap fokus pada fungsi bisnisnya.

Mengapa Telemetry Penting?

Dalam sistem monolithic sederhana, administrator mungkin cukup memeriksa beberapa log aplikasi. Namun, pendekatan tersebut menjadi jauh lebih sulit ketika aplikasi telah berkembang menjadi puluhan atau ratusan microservices.


                    ┌── Service A
                    │
Client ── Gateway ──┼── Service B
                    │
                    ├── Service C
                    │
                    ├── Service D
                    │
                    └── Service E

Jika salah satu service mengalami latency tinggi, tim perlu mengetahui service mana yang bermasalah, request berasal dari mana, berapa lama proses berlangsung, dan apakah terdapat error selama komunikasi.

Telemetry membantu menyediakan informasi tersebut secara terstruktur sehingga proses monitoring dan troubleshooting menjadi lebih mudah.

Hubungan Telemetry dengan Observability

Telemetry merupakan data yang dihasilkan sistem dan digunakan untuk membangun observability. Dalam konteks Istio, tiga bentuk telemetry yang sangat umum adalah metrics, logs, dan traces.

Telemetry	Fungsi
Metrics	Mengukur kondisi dan performa sistem menggunakan data numerik.
Access Logs	Mencatat aktivitas request dan response.
Distributed Tracing	Melacak perjalanan request antar service.

Arsitektur Istio Telemetry

Telemetry dalam Istio melibatkan workload, proxy, control plane, serta platform observability yang digunakan untuk menyimpan dan menampilkan data.


Client

   │

   ▼

Gateway

   │

   ▼

Istio Proxy

   │
   ├──────── Metrics
   │
   ├──────── Access Logs
   │
   └──────── Traces

            │

            ▼

   Observability Platform

   ├── Prometheus
   ├── Grafana
   └── Jaeger

Proxy Istio mengumpulkan informasi mengenai traffic yang melewatinya. Data tersebut kemudian dapat dikirim atau diekspos kepada sistem observability yang sesuai.

Komponen Utama Telemetry API

Telemetry API memiliki beberapa konsep penting yang perlu dipahami sebelum membuat konfigurasi.

Komponen	Peran
Telemetry Resource	Menentukan konfigurasi telemetry.
Metrics	Menyediakan informasi numerik mengenai traffic dan performa.
Access Logging	Mencatat request yang melewati proxy.
Tracing	Melacak perjalanan request antar service.
Provider	Menentukan tujuan atau sistem yang menerima telemetry.

Metrics pada Istio

Metrics merupakan salah satu sumber informasi terpenting dalam observability. Metrics menghasilkan data numerik yang dapat digunakan untuk mengukur performa dan kondisi service.


Request Count
      │
      ├── Success
      ├── Error
      └── Total

Latency
      │
      ├── Average
      ├── P50
      ├── P95
      └── P99

Traffic
      │
      ├── Inbound
      └── Outbound

Dengan metrics, administrator dapat mengetahui jumlah request, response code, latency, traffic, dan berbagai indikator operasional lainnya.

Access Logging

Access logging digunakan untuk mencatat aktivitas request yang melewati proxy Istio. Informasi yang dicatat dapat membantu administrator memahami siapa yang melakukan request, endpoint yang diakses, response code, serta waktu pemrosesan.


Client

   │

HTTP Request

   │

   ▼

Istio Proxy

   │

   ├── Method
   ├── Path
   ├── Status Code
   ├── Duration
   └── Source

   │

   ▼

Access Log

Access log sangat berguna ketika melakukan troubleshooting karena administrator dapat melihat detail aktivitas request tanpa harus menambahkan logging khusus pada setiap aplikasi.

Distributed Tracing

Distributed tracing digunakan untuk mengikuti perjalanan sebuah request ketika melewati beberapa microservices. Fitur ini sangat penting pada aplikasi yang memiliki banyak service karena satu request pengguna dapat menghasilkan komunikasi ke banyak workload.


Client

  │

  ▼

Gateway

  │
  ▼

Service A

  │
  ▼

Service B

  │
  ▼

Service C

Tracing memungkinkan setiap tahapan tersebut direpresentasikan sebagai trace dan span sehingga administrator dapat mengetahui bagian mana yang membutuhkan waktu paling lama.

Fungsi Istio Telemetry API

Mengatur konfigurasi telemetry pada service mesh.
Menghasilkan dan mengatur metrics.
Mengelola access logging.
Mendukung distributed tracing.
Meningkatkan kemampuan observability.
Membantu troubleshooting microservices.
Menganalisis latency dan error.
Mendukung monitoring aplikasi secara terpusat.
Membantu tim DevOps dan SRE memahami kondisi service mesh.

Hubungan Telemetry API dengan Istio Proxy

Telemetry API bekerja erat dengan proxy yang menangani traffic workload. Proxy memiliki visibilitas terhadap traffic yang melewatinya sehingga dapat menghasilkan informasi telemetry tanpa harus mengubah source code aplikasi.


Application

    │

    ▼

Istio Proxy

    │

    ├── Request
    ├── Response
    ├── Latency
    ├── Status
    └── Trace Context

    │

    ▼

Telemetry

Model tersebut menjadi salah satu keunggulan service mesh karena observability dapat diterapkan pada lapisan infrastruktur tanpa membebani setiap aplikasi dengan implementasi monitoring yang berbeda-beda.

Telemetry API dan Ambient Mesh

Pada Ambient Mesh, arsitektur telemetry perlu dipahami bersama komponen seperti ztunnel dan Waypoint Proxy. Ztunnel menangani fungsi networking Layer 4, sedangkan Waypoint Proxy dapat menangani kebutuhan Layer 7 ketika diperlukan.


Application

      │

      ▼

Waypoint Proxy

      │

      ├── L7 Telemetry
      │
      └── HTTP Information

      │

      ▼

ztunnel

      │

      ├── L4 Traffic
      └── Secure Communication

      │

      ▼

Observability

Dengan demikian, konfigurasi telemetry pada Ambient Mesh perlu disesuaikan dengan jenis traffic dan komponen mesh yang menangani traffic tersebut.

Telemetry Resource

Konfigurasi utama Telemetry API menggunakan resource Kubernetes dengan kind: Telemetry. Resource ini menentukan bagaimana telemetry diterapkan pada mesh, namespace, maupun workload tertentu.

apiVersion: telemetry.istio.io/v1

kind: Telemetry

metadata:

  name: mesh-telemetry

spec:

  metrics:

  - providers:

    - name: prometheus

Melalui resource tersebut, administrator dapat menentukan provider dan konfigurasi telemetry yang ingin digunakan.

Scope pada Telemetry API

Salah satu keunggulan Telemetry API adalah kemampuan menerapkan konfigurasi pada beberapa tingkat. Konfigurasi dapat dibuat secara luas untuk seluruh mesh maupun lebih spesifik untuk namespace atau workload tertentu.

Telemetry

   │

   ├── Mesh

   │
   ├── Namespace

   │
   └── Workload

Pendekatan tersebut memungkinkan organisasi memiliki konfigurasi telemetry global sekaligus konfigurasi khusus untuk service yang membutuhkan observability lebih detail.

Telemetry pada Tingkat Mesh

Konfigurasi pada tingkat mesh digunakan ketika administrator ingin menerapkan standar telemetry secara luas ke seluruh service mesh.

Istio Mesh

   │
   ├── Service A
   ├── Service B
   ├── Service C
   ├── Service D
   └── Service E

        │

        ▼

Global Telemetry

Konfigurasi global cocok digunakan untuk menetapkan standar monitoring dasar yang harus dimiliki seluruh workload.

Telemetry pada Tingkat Namespace

Administrator juga dapat membuat Telemetry resource pada namespace tertentu. Dengan cara ini, service yang berada di namespace tersebut dapat memiliki konfigurasi telemetry yang berbeda dari namespace lainnya.

production

   │

   ├── order-service
   ├── payment-service
   └── inventory-service

        │

        ▼

Production Telemetry

Pendekatan ini berguna ketika lingkungan production membutuhkan konfigurasi observability yang berbeda dibandingkan development atau staging.

Telemetry pada Tingkat Workload

Untuk kebutuhan yang lebih spesifik, Telemetry API dapat diarahkan pada workload tertentu menggunakan selector. Misalnya, administrator ingin mengaktifkan konfigurasi tracing khusus untuk Payment Service.

Telemetry

   │

Selector

app=payment

   │

   ▼

Payment Service

Dengan selector, konfigurasi tidak perlu diterapkan kepada seluruh namespace.

Konfigurasi Metrics

Metrics merupakan salah satu fitur utama Telemetry API. Metrics memberikan informasi numerik mengenai traffic dan performa workload.

Contoh informasi yang dapat digunakan untuk monitoring antara lain jumlah request, response code, serta latency.

Request

   │

   ▼

Istio Proxy

   │

   ├── Request Count
   ├── Response Code
   ├── Request Duration
   └── Traffic Volume

   │

   ▼

Prometheus

Data metrics tersebut kemudian dapat digunakan oleh platform monitoring seperti Prometheus dan divisualisasikan menggunakan Grafana.

Contoh Konfigurasi Metrics

apiVersion: telemetry.istio.io/v1

kind: Telemetry

metadata:

  name: metrics

spec:

  metrics:

  - providers:

    - name: prometheus

Konfigurasi tersebut menunjukkan penggunaan provider Prometheus untuk metrics. Dalam implementasi nyata, nama provider harus disesuaikan dengan konfigurasi telemetry provider yang tersedia pada lingkungan Istio.

Konfigurasi Access Logging

Selain metrics, Telemetry API dapat digunakan untuk mengatur access logging. Access log memberikan informasi mengenai request yang melewati proxy.

Client

   │

GET /api/order

   │

   ▼

Istio Proxy

   │

   ├── Method
   ├── Path
   ├── Status
   ├── Duration
   └── Source

   │

   ▼

Access Log

Access logging sangat berguna ketika administrator ingin mengetahui aktivitas request secara lebih detail.

Contoh Konfigurasi Access Logging

apiVersion: telemetry.istio.io/v1

kind: Telemetry

metadata:

  name: access-log

spec:

  accessLogging:

  - providers:

    - name: envoy

Provider yang digunakan harus tersedia pada konfigurasi Istio. Pada deployment tertentu, administrator dapat mengarahkan log menuju sistem logging yang sesuai dengan arsitektur observability organisasi.

Distributed Tracing

Tracing digunakan untuk mengikuti perjalanan request dari satu service menuju service lainnya. Hal ini sangat penting pada arsitektur microservices karena sebuah request pengguna dapat melibatkan banyak workload.

Client

  │

  ▼

Gateway

  │
  ├── Span 1
  │
  ▼

Order Service

  │
  ├── Span 2
  │
  ▼

Payment Service

  │
  ├── Span 3
  │
  ▼

Database

Gabungan seluruh span tersebut membentuk sebuah trace yang menggambarkan perjalanan request secara lengkap.

Trace dan Span

Dalam distributed tracing, trace menggambarkan keseluruhan perjalanan sebuah request, sedangkan span menggambarkan satu operasi atau tahapan tertentu dalam perjalanan tersebut.

Istilah	Pengertian
Trace	Keseluruhan perjalanan sebuah request.
Span	Satu operasi dalam sebuah trace.
Trace ID	Identitas yang menghubungkan seluruh span.

Contoh Konfigurasi Tracing

apiVersion: telemetry.istio.io/v1

kind: Telemetry

metadata:

  name: tracing

spec:

  tracing:

  - providers:

    - name: otel

    randomSamplingPercentage: 10

Nilai sampling digunakan untuk menentukan persentase request yang akan dibuatkan trace. Pada lingkungan production berskala besar, sampling dapat membantu mengontrol volume data tracing.

Telemetry Provider

Provider menentukan sistem yang menerima telemetry dari Istio. Provider dapat digunakan untuk metrics, logging, maupun tracing sesuai konfigurasi yang diterapkan.

Istio

  │

  ├── Metrics ─────► Prometheus
  │
  ├── Logs ────────► Logging System
  │
  └── Traces ──────► OpenTelemetry
                         │
                         ▼
                    Tracing Backend

Penggunaan provider yang tepat membantu organisasi mengintegrasikan Istio dengan platform observability yang telah digunakan sebelumnya.

Integrasi dengan Prometheus

Prometheus banyak digunakan untuk mengumpulkan dan menyimpan metrics. Istio dapat menyediakan metrics yang kemudian dikonsumsi oleh Prometheus untuk kebutuhan monitoring.

Istio Proxy

    │

    ▼

Metrics

    │

    ▼

Prometheus

    │

    ▼

Grafana

Grafana kemudian dapat digunakan untuk membuat dashboard yang menampilkan kondisi traffic dan performa service mesh.

Integrasi dengan Grafana

Grafana berfungsi sebagai lapisan visualisasi. Metrics yang dikumpulkan dapat ditampilkan dalam bentuk dashboard sehingga administrator lebih mudah melihat kondisi sistem.

Prometheus

     │

     ▼

Grafana

     │

     ├── Request Rate
     ├── Error Rate
     ├── Latency
     └── Traffic

Dashboard tersebut dapat membantu tim menemukan anomali sebelum berkembang menjadi gangguan yang lebih serius.

Integrasi dengan Distributed Tracing

Tracing dapat diintegrasikan dengan sistem seperti OpenTelemetry maupun backend tracing lainnya. Tujuannya adalah menyimpan dan menganalisis trace yang dihasilkan dari request antar service.

Client

  │

  ▼

Istio

  │

Trace

  │

  ▼

OpenTelemetry

  │

  ▼

Tracing Backend

  │

  ▼

Trace Visualization

Dengan tracing, tim dapat menemukan service yang menyebabkan latency tinggi maupun bottleneck dalam komunikasi antar workload.

Telemetry API pada Ambient Mesh

Pada Ambient Mesh, telemetry perlu dilihat berdasarkan layer komunikasi yang ditangani oleh komponen mesh. Ztunnel menangani fungsi Layer 4, sedangkan Waypoint Proxy dapat menyediakan kemampuan Layer 7 untuk workload yang membutuhkannya.

Application

     │

     ▼

Waypoint Proxy

     │

     ├── HTTP Metrics
     ├── HTTP Logs
     └── L7 Tracing

     │

     ▼

ztunnel

     │

     ├── L4 Metrics
     └── Secure Traffic

     │

     ▼

Observability Platform

Arsitektur ini memungkinkan observability diterapkan secara bertahap sesuai kebutuhan aplikasi tanpa harus memasang sidecar proxy pada setiap Pod.

Contoh Arsitektur Observability

                  Client
                    │
                    ▼
                 Gateway
                    │
                    ▼
              Waypoint Proxy
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       Service A Service B Service C
          │         │         │
          └─────────┼─────────┘
                    │
                    ▼
                Telemetry
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
   Prometheus    Logging      Tracing
       │            │            │
       ▼            ▼            ▼
    Grafana      Log UI     Trace UI

Arsitektur tersebut menggambarkan bagaimana telemetry dapat menjadi lapisan observability yang menghubungkan service mesh dengan berbagai platform monitoring dan troubleshooting.

Best Practice Menggunakan Istio Telemetry API

Implementasi Telemetry API sebaiknya dilakukan dengan perencanaan yang baik agar observability memberikan informasi yang berguna tanpa menghasilkan beban data dan resource yang berlebihan. Terlalu banyak metrics, log, maupun trace dapat meningkatkan penggunaan storage, bandwidth, dan resource observability.

Tentukan metrics utama yang benar-benar dibutuhkan untuk monitoring.
Gunakan tracing sampling secara proporsional terhadap kebutuhan sistem.
Hindari menyimpan access log secara berlebihan tanpa kebijakan retensi.
Pisahkan konfigurasi telemetry berdasarkan kebutuhan namespace atau workload.
Gunakan dashboard untuk memantau request rate, error rate, dan latency.
Gunakan alerting untuk mendeteksi anomali penting secara otomatis.
Pastikan provider telemetry memiliki kapasitas yang sesuai dengan volume traffic.
Lakukan pengujian konfigurasi telemetry pada staging sebelum production.
Terapkan kebijakan retensi log dan trace untuk mengontrol penggunaan storage.
Dokumentasikan konfigurasi Telemetry API agar mudah dipelihara.

Sampling pada Distributed Tracing

Pada lingkungan dengan traffic tinggi, tidak selalu diperlukan untuk menyimpan trace dari setiap request. Sampling dapat digunakan untuk menentukan persentase request yang akan direkam sebagai distributed trace.

100.000 Requests

       │

       ▼

Sampling

       │

       ├── 10% Trace
       │
       └── 90% Tidak Disimpan

       │

       ▼

Tracing Backend

Penggunaan sampling dapat membantu mengurangi jumlah data yang dikirim ke tracing backend sekaligus mempertahankan informasi yang cukup untuk analisis performa.

Monitoring Metrics Istio

Metrics dapat digunakan untuk membangun indikator kesehatan service mesh. Beberapa indikator yang umum dipantau adalah jumlah request, error rate, response time, dan traffic volume.

Metric	Kegunaan
Request Rate	Mengetahui jumlah request dalam periode tertentu.
Error Rate	Mengetahui tingkat request yang mengalami error.
Latency	Mengukur waktu yang dibutuhkan service memberikan response.
Traffic Volume	Melihat jumlah data yang melewati service mesh.

Alerting pada Observability

Monitoring akan menjadi lebih efektif apabila dikombinasikan dengan alerting. Alert dapat dibuat ketika kondisi tertentu melewati batas yang telah ditentukan.

Metrics

   │

   ▼

Threshold

   │

   ├── Normal
   │
   └── Anomaly
          │
          ▼
        Alert
          │
          ▼
       DevOps

Contohnya, tim dapat membuat alert ketika error rate meningkat secara signifikan atau latency sebuah service melewati batas yang telah ditentukan.

Troubleshooting Istio Telemetry API

1. Metrics Tidak Muncul

Apabila metrics tidak terlihat pada monitoring platform, periksa terlebih dahulu konfigurasi Telemetry resource dan provider yang digunakan.

Application

    │

Istio Proxy

    │

Telemetry

    │

Provider

    │

Monitoring Backend

Pastikan seluruh komponen pada jalur tersebut tersedia dan dapat berkomunikasi dengan baik.

2. Access Log Tidak Muncul

Periksa konfigurasi access logging dan pastikan provider logging telah dikonfigurasi. Periksa juga log proxy untuk mengetahui apakah terdapat error pada proses pengiriman log.

3. Trace Tidak Terlihat

Jika distributed tracing tidak muncul, periksa konfigurasi tracing provider, sampling percentage, serta propagation trace context yang digunakan oleh aplikasi.

4. Volume Telemetry Terlalu Besar

Volume telemetry dapat meningkat secara signifikan pada cluster dengan traffic tinggi. Kurangi sampling tracing, evaluasi access logging, dan kumpulkan hanya metrics yang benar-benar diperlukan.

High Traffic

    │

    ▼

Telemetry Volume ↑

    │

    ├── Sampling
    ├── Filtering
    └── Retention Policy

    │

    ▼

Controlled Volume

Implementasi Telemetry API pada Production

Pada lingkungan production, Telemetry API sebaiknya menjadi bagian dari strategi observability secara keseluruhan. Metrics digunakan untuk mengetahui kondisi sistem, access log digunakan untuk investigasi aktivitas request, sedangkan distributed tracing digunakan untuk memahami perjalanan request antar microservices.

                    Production
                        │
                        ▼
                  Istio Service Mesh
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       Metrics         Logs         Tracing
          │             │             │
          ▼             ▼             ▼
     Prometheus      Log System   Trace Backend
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                     Grafana
                        │
                        ▼
                    DevOps / SRE

Dengan arsitektur tersebut, tim dapat memperoleh gambaran yang lebih lengkap mengenai kesehatan aplikasi dan service mesh.

Kelebihan Istio Telemetry API

Menyediakan konfigurasi telemetry secara deklaratif.
Mendukung metrics, access logging, dan distributed tracing.
Dapat diterapkan pada berbagai scope.
Mendukung integrasi dengan platform observability.
Membantu troubleshooting microservices.
Meningkatkan visibilitas traffic dalam service mesh.
Dapat dikombinasikan dengan Ambient Mesh.
Mengurangi kebutuhan implementasi monitoring pada setiap aplikasi.
Mendukung pengaturan telemetry yang lebih terpusat.
Membantu tim DevOps dan SRE melakukan analisis performa.

Kekurangan Istio Telemetry API

Konfigurasi yang kompleks membutuhkan pemahaman mengenai Istio dan observability.
Volume telemetry dapat menjadi sangat besar pada cluster dengan traffic tinggi.
Membutuhkan platform penyimpanan dan visualisasi telemetry.
Tracing dapat meningkatkan penggunaan resource apabila sampling tidak dikontrol.
Kesalahan konfigurasi provider dapat menyebabkan telemetry tidak terkirim dengan baik.
Pengelolaan metrics, log, dan trace membutuhkan kebijakan retensi yang jelas.

Contoh Implementasi pada Aplikasi Microservices

Bayangkan sebuah aplikasi e-commerce memiliki beberapa service seperti Product Service, Order Service, Payment Service, dan Notification Service. Setiap request pengguna dapat melewati beberapa service sebelum menghasilkan response.

User

 │

 ▼

Gateway

 │

 ▼

Product Service

 │

 ▼

Order Service

 │

 ▼

Payment Service

 │

 ▼

Notification Service

Tanpa observability yang baik, ketika terjadi latency tinggi akan sulit menentukan service mana yang menjadi sumber masalah. Telemetry API membantu menyediakan metrics, log, dan trace untuk menganalisis perjalanan request tersebut.

Request

  │
  ├── Metrics
  │
  ├── Access Log
  │
  └── Trace
       │
       ▼
   Observability
       │
       ▼
   Troubleshooting

Hubungan Telemetry dengan PeerAuthentication

PeerAuthentication dan Telemetry memiliki fungsi yang berbeda tetapi saling melengkapi. PeerAuthentication berfokus pada keamanan komunikasi menggunakan mTLS, sedangkan Telemetry memberikan visibilitas terhadap traffic yang terjadi di dalam service mesh.

Service A

   │

mTLS

   │

Service B

   │

   ├── Security
   │      │
   │      ▼
   │ PeerAuthentication
   │
   └── Observability
          │
          ▼
       Telemetry

Dengan menggabungkan keduanya, administrator dapat mengetahui apakah komunikasi aman sekaligus melihat bagaimana performa komunikasi tersebut.

Hubungan Telemetry dengan Authorization Policy

Authorization Policy menentukan apakah sebuah request diizinkan atau ditolak, sedangkan telemetry membantu mencatat dan mengukur aktivitas traffic tersebut.

Request

   │

   ▼

Authorization Policy

   │

   ├── ALLOW
   │
   └── DENY

        │

        ▼

    Telemetry

        │

        ├── Metrics
        ├── Logs
        └── Tracing

Kombinasi tersebut membantu administrator memahami tidak hanya keamanan akses, tetapi juga kondisi traffic secara keseluruhan.

Artikel Selanjutnya

Setelah memahami bagaimana Istio Telemetry API menyediakan metrics, access logs, dan distributed tracing, pembahasan berikutnya dapat dilanjutkan ke Istio EnvoyFilter.

Istio Telemetry API

        │

        ▼

Observability

        │

        ▼

EnvoyFilter

        │

        ▼

Advanced Proxy Customization

EnvoyFilter memungkinkan administrator melakukan kustomisasi lebih lanjut terhadap konfigurasi proxy Envoy yang digunakan Istio. Karena kemampuan tersebut bersifat lebih advanced, pembahasannya akan menjadi kelanjutan yang sesuai setelah memahami fondasi service mesh, security, dan observability.

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu Istio Telemetry API?

Istio Telemetry API adalah resource Istio yang digunakan untuk mengatur telemetry seperti metrics, access logging, dan distributed tracing pada service mesh.

Apa fungsi utama Telemetry API?

Fungsi utamanya adalah mengatur bagaimana telemetry dikumpulkan dan digunakan untuk meningkatkan observability terhadap workload dan traffic dalam service mesh.

Apa saja jenis telemetry pada Istio?

Tiga jenis telemetry yang umum digunakan adalah metrics, access logs, dan distributed tracing.

Apa fungsi metrics?

Metrics memberikan informasi numerik mengenai traffic, request, response, error, latency, dan kondisi performa service.

Apa fungsi access log?

Access log mencatat aktivitas request sehingga administrator dapat melakukan investigasi terhadap traffic yang melewati proxy.

Apa fungsi distributed tracing?

Distributed tracing digunakan untuk mengikuti perjalanan request ketika berpindah dari satu microservice ke microservice lainnya.

Apakah Telemetry API dapat digunakan pada Ambient Mesh?

Ya. Telemetry dapat digunakan pada lingkungan Ambient Mesh dengan mempertimbangkan komponen yang menangani traffic, seperti ztunnel dan Waypoint Proxy.

Apakah Telemetry API mengubah kode aplikasi?

Tujuan utama Telemetry API adalah menyediakan konfigurasi telemetry pada service mesh sehingga banyak kebutuhan observability dapat ditangani pada lapisan infrastruktur tanpa harus menambahkan implementasi monitoring secara langsung ke source code aplikasi.

Apakah Telemetry API membutuhkan Prometheus?

Telemetry API tidak secara mutlak bergantung pada Prometheus untuk seluruh jenis telemetry. Namun Prometheus umum digunakan untuk menyimpan dan memproses metrics pada lingkungan Istio.

Apakah Grafana digunakan untuk mengumpulkan metrics?

Grafana umumnya digunakan sebagai platform visualisasi dan dashboard, sedangkan pengumpulan dan penyimpanan metrics dapat dilakukan oleh sistem seperti Prometheus.

Mengapa tracing membutuhkan sampling?

Sampling digunakan untuk mengontrol jumlah request yang dibuatkan trace sehingga volume data tracing dan penggunaan resource dapat dikendalikan.

Apa itu trace?

Trace adalah representasi keseluruhan perjalanan sebuah request dari awal hingga selesai melalui berbagai service.

Apa itu span?

Span merupakan satu operasi atau tahapan tertentu yang menjadi bagian dari sebuah trace.

Apakah Telemetry membantu troubleshooting?

Ya. Metrics, logs, dan traces dapat membantu administrator menemukan error, latency tinggi, bottleneck, maupun pola traffic yang tidak normal.

Apakah Telemetry API sama dengan monitoring?

Telemetry merupakan data yang digunakan untuk membangun observability. Monitoring kemudian memanfaatkan data tersebut untuk memantau kondisi sistem dan mendeteksi masalah.

Apakah Telemetry API dapat diterapkan pada workload tertentu?

Ya. Konfigurasi dapat dibuat lebih spesifik menggunakan selector sehingga hanya workload tertentu yang menerima konfigurasi telemetry tersebut.

Apakah Telemetry dapat diterapkan pada namespace?

Ya. Telemetry resource dapat digunakan untuk mengatur konfigurasi pada namespace tertentu sesuai kebutuhan organisasi.

Mengapa telemetry perlu dikontrol?

Karena metrics, logs, dan traces dalam jumlah besar dapat meningkatkan penggunaan CPU, memory, bandwidth, dan storage. Oleh karena itu, sampling dan kebijakan retensi perlu direncanakan.

Kesimpulan

Istio Telemetry API merupakan komponen penting dalam membangun observability pada Kubernetes Service Mesh. Dengan Telemetry API, administrator dapat mengatur berbagai bentuk telemetry seperti metrics, access logging, dan distributed tracing untuk mendapatkan gambaran yang lebih jelas mengenai kondisi aplikasi dan traffic.

Metrics membantu mengukur performa dan kondisi sistem, access logs memberikan informasi mengenai aktivitas request, sedangkan distributed tracing membantu mengikuti perjalanan request antar microservices. Ketiganya dapat digunakan secara bersama-sama untuk mempercepat proses monitoring dan troubleshooting.

Telemetry API juga dapat diterapkan secara fleksibel pada berbagai scope dan diintegrasikan dengan platform observability seperti Prometheus, Grafana, OpenTelemetry, maupun sistem logging dan tracing lainnya. Pada Ambient Mesh, konfigurasi telemetry dapat disesuaikan dengan peran ztunnel dan Waypoint Proxy dalam menangani traffic.

Dengan menerapkan Telemetry API secara terencana, organisasi dapat membangun lingkungan service mesh yang tidak hanya aman melalui PeerAuthentication dan Authorization Policy, tetapi juga memiliki visibilitas yang kuat terhadap performa, traffic, dan perilaku aplikasi.

Setelah memahami Telemetry API, pembahasan berikutnya dapat diarahkan pada Istio EnvoyFilter untuk memahami bagaimana konfigurasi proxy Envoy dapat dikustomisasi secara lebih lanjut pada kebutuhan service mesh yang lebih advanced.