Mana yang harus Anda gunakan: Agen logging atau library klien?
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini memberikan informasi yang Anda perlukan untuk membantu Anda memutuskan apakah akan mengirim log aplikasi ke Cloud Logging secara terprogram menggunakan library klien atau menggunakan agen logging. Agen logging mengirim data yang ditulis ke file, seperti
stdout atau file, sebagai log ke Cloud Logging. Layanan seperti Google Kubernetes Engine, lingkungan fleksibel App Engine, dan fungsi Cloud Run, berisi agen logging terintegrasi. Untuk Compute Engine, Anda dapat menginstal Agen Operasional atau agen Cloud Logging lama.
Agen ini mengumpulkan log dari lokasi file yang diketahui atau layanan logging
seperti Windows Event Log, journald, atau syslogd.
Jika tidak dapat menggunakan library klien atau agen Logging, atau jika
hanya ingin bereksperimen, Anda dapat menulis log menggunakan perintah
gcloud logging write
atau dengan mengirim perintah HTTP ke endpoint Cloud Logging API
entries.write.
Cloud Logging API mendukung panggilan HTTP dan gRPC. Agen Ops dan sebagian besar library klien Logging memanggil gRPC Logging API. Agen logging dan library klien lama untuk beberapa bahasa memanggil REST Logging API.
Memilih library klien atau agen
Saat Anda memutuskan antara agen atau library klien, pertimbangkan
pertanyaan berikut:
Apakah aplikasi Anda berjalan di luar Google Cloud?
Jika aplikasi tidak berjalan di Google Cloud, Anda memerlukan
beberapa cara untuk mengirim log ke Logging API. Untuk merutekan log dari
sistem lokal ke Logging, sebaiknya gunakan
Bindplane, yang men-deploy dan mengelola
kolektor OpenTelemetry untuk mengirim telemetri ke Google Cloud. Untuk informasi
selengkapnya, lihat Tentang Bindplane.
Atau, Anda dapat merutekan log ke Logging langsung dari
aplikasi menggunakan library klien. Untuk lingkungan sementara, seperti komputasi Serverless, Anda harus menggunakan library klien untuk melakukan panggilan langsung ke Logging API.
Apakah layanan Google Cloud yang menjalankan aplikasi Anda mendukung
menulis konten stdout dan stderr ke project Anda?
Beberapa Google Cloud layanan dikelola sepenuhnya, sehingga Anda tidak perlu
menggunakan agen untuk mengirim log ke project Google Cloud Anda. Anda dapat menggunakan
framework logging yang sudah ada dalam
bahasa pilihan Anda, seperti Go, Node.js, dan Python, untuk mengirim log ke
Logging di produk yang mendukung stdout dan stderr
secara default. Keuntungan mengandalkan stdout dan stderr,
bukan menggunakan library klien, adalah error aplikasi tidak akan mengganggu
pengiriman log ke project Anda. Untuk informasi tentang cara mengirim
log terstruktur melalui stdout dan
stderr, lihat bagian, Apakah aplikasi Anda memiliki fleksibilitas untuk
mengubah format log?.
Anda dapat menggunakan library klien Logging, tetapi perlu diingat bahwa
library ini dapat menyebabkan dependensi pada Logging untuk pengujian lokal,
saat Anda tidak terlalu membutuhkannya. Penggunaan library klien mungkin juga memerlukan coding yang lebih kompleks untuk menangani buffering dan percobaan ulang secara eksplisit.
Selain itu, setiap penggunaan library klien Logging akan membuat streaming koneksi baru ke API. Koneksi baru ini akan menimbulkan lebih banyak
kompleksitas, menggunakan port tambahan, dan mengirim permintaan terpisah hanya dengan
log dari aplikasi, yang dapat menjadi pemborosan jika tidak ada banyak
log.
Apakah log aplikasi harus dapat diakses di lingkungan lokal Anda?
Jika perlu mengakses log aplikasi di lingkungan lokal, untuk
proses debug dan tujuan lainnya, Anda dapat menggunakan modul logging dalam beberapa
bahasa untuk menghasilkan output ke stdout dan stderr. Library klien logging untuk beberapa bahasa mendukung log pemilihan rute ke stdout dan stderr.
Saat menjalankan aplikasi di layanan Google Cloud yang tidak mendukung pengiriman log yang ditulis ke stdout dan stderr secara otomatis ke projectGoogle Cloud , Anda dapat mengumpulkan log stdout dan stderr dalam file di disk dan mengonfigurasi agen untuk mengambilnya dan mengirimkannya ke Logging. Untuk mengetahui informasi selengkapnya,
lihat panduan konfigurasi untuk Agen Operasional
atau Agen logging lama.
Apakah proses penginstalan agen dilakukan secara manual atau otomatis?
Beberapa layanan menginstal agen secara otomatis atau mengizinkan Anda menginstal agen
sendiri. Jika layanan yang Anda gunakan tidak mengizinkan Anda menginstal agen,
Anda harus menggunakan library klien untuk menggunakan Logging.
Apakah Anda sudah menjalankan Fluentd di sistem?
Agen Logging lama didasarkan pada Fluentd.
Jika Anda sudah menjalankan Fluentd di sistem, dan ingin
menggunakan daemon tersebut untuk mengirim log ke Logging, gunakan
Google Cloud Plugin logging untuk
fluentd.
Apakah Anda juga mengumpulkan metrik aplikasi untuk Cloud Monitoring?
Di VM Compute Engine, Agen Ops dapat mengumpulkan log dan sebagian besar metrik. Lihat
Fitur Ops Agent untuk mengetahui informasi selengkapnya.
Apakah aplikasi Anda memiliki fleksibilitas untuk mengubah format log?
Pertanyaan ini membantu Anda memutuskan apakah aplikasi Anda dapat menghasilkan
log terstruktur.
Logging mengenali log terstruktur jika Anda mengirim log ke Logging API dalam format logging terstruktur.
Library klien menyediakan metode untuk menangani format ini.
Ada dua cara untuk menulis log terstruktur: satu cara adalah menetapkan kolom tertentu
dalam amplop LogEntry,
dan cara lainnya adalah menetapkan kolom jsonPayload dalam amplop
LogEntry.
Skema untuk yang pertama ditentukan oleh Cloud Logging, sedangkan skema untuk yang kedua ditentukan oleh pengguna.
Anda harus mengonfigurasi agen untuk mengenali log terstruktur.
Secara default, agen dikonfigurasi untuk mendeteksi log dalam format JSON dan menanganinya sebagai log terstruktur. Jika aplikasi Anda memiliki format lognya sendiri
yang tidak dapat Anda ubah, tetapi Anda ingin log tersebut dikenali sebagai log
terstruktur, Anda harus menulis log dalam format logging terstruktur, biasanya
JSON, ke stdout dan stderr, sehingga agen dapat mengenalinya sebagai
log terstruktur. Jika tidak, Anda harus mengonfigurasi agen untuk memahami format Anda sendiri.
Ringkasan setiap opsi
Library klien Cloud Logging
Kelebihan
Anda dapat merutekan log langsung ke Cloud Logging API.
Beberapa bahasa dapat menghasilkan log ke stdout dan stderr menggunakan
library.
Kekurangan
Error aplikasi akan mengganggu pengiriman log ke project Google Cloud Anda.
Agen Operasional
Kelebihan
Agen Operasional dapat mengirim log dan metrik menggunakan teknologi open source yang stabil: Fluent Bit untuk pengumpulan log dan OpenTelemetry Collector untuk pengumpulan metrik.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-18 UTC."],[],[],null,["# Which should you use: Logging agent or client library?\n\nThis document provides the information that you need to help you decide whether\nto programmatically send application logs to Cloud Logging by using\n[client libraries](/logging/docs/reference/libraries) or by using a\nlogging agent. Logging agents send data written to a file, such as\n`stdout` or a file, as logs to Cloud Logging. Services such as\nGoogle Kubernetes Engine, App Engine flexible environment, and Cloud Run functions, contain an integrated\nlogging agent. For Compute Engine, you can install the\n[Ops Agent or the legacy Cloud Logging agent](/logging/docs/agent).\nThese agents collect logs from known file locations or logging\nservices like the `Windows Event Log`, `journald`, or `syslogd`.\n\nWhen you can't use a client library or a Logging agent, or when\nyou only want to experiment, you can write logs by using the\n[`gcloud logging write`](/sdk/gcloud/reference/logging/write)\ncommand or by sending HTTP commands to the Cloud Logging API endpoint\n[`entries.write`](/logging/docs/reference/v2/rest/v2/entries/write).\nThe [Cloud Logging API](/logging/docs/reference/api-overview) supports both\nHTTP and gRPC calls. The Ops Agent and most Logging client\nlibraries call the gRPC Logging API. The legacy Logging\nagent and client libraries for some languages call the REST\nLogging API.\n| **Note:** There will be no new feature development or support for new operating systems for the legacy Logging agent. We recommend that you use the [Ops Agent](/logging/docs/agent/ops-agent) for new workloads and eventually transition your existing VMs to use the Ops Agent.\n\nChoosing an agent or client libraries\n-------------------------------------\n\nWhen you're deciding between an agent or the client libraries, consider\nthe following questions:\n\nIs your application running outside of Google Cloud?\n\n: If your application isn't running on Google Cloud, you need\n some way to send logs to the Logging API. To route logs from\n on-premises systems to Logging, we recommend that you use\n [Bindplane](https://bindplane.com/google), which deploys and manages\n OpenTelemetry collectors to send telemetry to Google Cloud. For more\n information, see [About Bindplane](/stackdriver/bindplane).\n\n Alternatively, you can route logs to Logging directly from\n the application by using client libraries. For ephemeral environments,\n like Serverless computing, you must use client libraries to make direct\n calls to the Logging API.\n\nDoes the Google Cloud service running your application support\nwriting `stdout` and `stderr` content to your project?\n\n: Some Google Cloud services are fully managed, so you don't need\n to use agents to send logs to your Google Cloud project. You can use any\n established logging framework in\n the language of your choice, such as Go, Node.js, and Python, to send logs to\n Logging in products where `stdout` and `stderr` are supported\n by default. An advantage to relying on `stdout` and `stderr`\n instead of using client libraries is that application crashes don't break\n sending logs to your project. For information about sending\n [structured logs](/logging/docs/structured-logging) through `stdout` and\n `stderr`, see the section, [Does your application have the flexibility to\n change the log format?](#log-format).\n\n You can use Logging client libraries, but keep in mind that\n it might introduce a dependency on Logging for local testing,\n when you don't necessarily need it. Using the client libraries might also\n require more complex coding to explicitly handle buffering and retries.\n Also, each use of the Logging client libraries creates a new\n connection stream to the API. These new connections introduce more\n complexity, use additional ports, and send separate requests with only the\n logs from the application, which could be wasteful if there aren't many\n logs.\n\nDo the application logs need to be accessible in your local environment?\n\n: If you need to access the application logs in your local environment, for\n debugging and other purposes, then you can use the logging modules in some\n languages to output to `stdout` and `stderr`. Logging client\n libraries for some languages support routing logs to `stdout` and `stderr`.\n\n When running your application in Google Cloud services that don't support\n automatically sending logs written to `stdout` and `stderr` to your\n Google Cloud project, you can collect\n `stdout` and `stderr` logs in on-disk files and configure the agent to\n scrape those and send them to Logging. For more information,\n see the configuration guide for the [Ops Agent](/logging/docs/agent/ops-agent/configuration)\n or the legacy [Logging agent](/logging/docs/agent/logging/configuration).\n\nIs the agent-installation process manual or automatic?\n\n: Some services install agents automatically or allow you to install the agents\n yourself. If the service you are using doesn't allow you to install agents,\n then you must use the client libraries to use Logging.\n\nAre you running Fluentd in your system already?\n\n: The legacy Logging agent is based on Fluentd.\n\n If you already have Fluentd running in your system, and you would like to\n use that daemon to send your logs to Logging, then use the\n [Google Cloud Logging plugin for\n fluentd](https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud).\n\nAre you collecting application metrics for Cloud Monitoring as well?\n\n: In Compute Engine VMs, the Ops Agent can collect logs and most metrics. See\n [Ops Agent features](/stackdriver/docs/solutions/agents/ops-agent#features) for more information.\n\n If the Ops Agent doesn't address your use cases, then you can use the\n [legacy Monitoring agent](/monitoring/agent/monitoring) or the\n [Monitoring client libraries](/monitoring/docs/reference/libraries)\n to collect your metrics.\n\nDoes your application have the flexibility to change the log format?\n\n: This question helps you decide if your application can generate\n [structured logs](/logging/docs/structured-logging).\n Logging recognizes structured logs if you send the logs to the\n Logging API in [the structured-logging format](/logging/docs/reference/v2/rpc/google.logging.v2#google.logging.v2.WriteLogEntriesRequest).\n Client libraries provide the methods for handling this format.\n\n There are two way of writing structured logs: one is to set [specific fields\n in the `LogEntry` envelope](/logging/docs/structured-logging#special-payload-fields),\n and the other is to set the [`jsonPayload` field within the `LogEntry`\n envelope](/logging/docs/structured-logging#use-gcloud).\n The schema for the former is determined by Cloud Logging, while the\n schema for the latter is determined by the user.\n\n You must configure the agent to recognize [structured logs](/logging/docs/structured-logging).\n By default, the agents are configured to detect logs in JSON format and to\n handle them as structured logs. If your application has its own log format\n that you can't change, but you want the logs to be recognized as structured\n logs, then you must write logs in the structured-logging format, usually\n JSON, to `stdout` and `stderr`, so that the agents can recognize them as\n structured logs. Otherwise, you must configure your agent to understand your\n own format.\n\nSummary of each option\n----------------------\n\n- Cloud Logging client libraries\n\n - Advantages\n\n - You can route logs directly to Cloud Logging API.\n - Some languages can output logs to `stdout` and `stderr` by using the library.\n - Disadvantages\n\n - Application crashes break sending logs to your Google Cloud project.\n- Ops Agent\n\n - Advantages\n\n - The Ops Agent can send logs and metrics by using stable open source technologies: Fluent Bit for log collection and the OpenTelemetry Collector for metric collection.\n - You can collect both logs and metrics from many common applications; see [Monitor and collect logs from third-party\n applications](/stackdriver/docs/solutions/agents/ops-agent/third-party).\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - The Ops Agent is under active development.\n - Disadvantages\n\n - Fluent Bit only supports UTF-8 encoding. It doesn't support encoding conversion.\n- Legacy Logging agent\n\n - Advantages\n - The agent uses Fluentd to collect logs, which supports encoding conversion.\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - The agent is currently supported but is not under active development.\n- `stdout` and `stderr` logs automatically sent to your Google Cloud project\n\n - Advantages\n - This process is a common way to emit logs to local environments.\n - You can use arbitrary logging libraries.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - Not all environments automatically route logs to Logging."]]
